Хочу пройтись по теме разработки программного обеспечения, рассмотрев основные этапы и методологии этого процесса. Когда я начал писать эту статью, рабочий заголовок был "Разработка программного обеспечения: основные этапы и методология". Однако, по мере размышлений о том, что я хотел бы рассказать на каждом конкретном этапе, объем информации, которую следует охватить, становился все больше и больше. Чтобы избежать перегрузки читателя, да и чтобы позволит самому сфокусироваться на конкретной теме, чтобы довести ее до состояния достойного прочтения, я решил сделать небольшую серию статей. Первый аспект, который мы рассмотрим: работа с требованиями.
Работа с требованиями
Одним из первых и весьма важным этапом разработки программного обеспечения является понимание потребностей и требований заказчика. На этом этапе команде разработки нужно определить, что должна делать разрабатываемая программа и какие функции она должна включать.
Давайте разберем какую работу требуется проделывать с требованиями, по мере усложнения и улучшения процессов организации:
1. Записывать/Фиксировать требования
Если вы начинающий разработчик-фриласер, студент или псих-одиночка, вполне возможно вам будет этого достаточно для начала работы. Более того, в небольшой организации или стартапе, вполне возможно на первых этапах этого тоже будет достаточно. В большей степени достижения дальнейших успехов будет зависеть от конкретных сотрудников или от вас самих. Но построить вокруг такого подхода эффективную команду, которая дает стабильный результат получится уже далеко не всегда.
Появление следующих артефактов может говорить об успешности данного шага:
- Список требований (или как водится их зовут на данном этапе, в силу слабой детализации и однозначности "список хотелок")
- Техническое задание
- Варианты использования
2. Требуется выявить потребности, ожидания, ограничения, а также интерфейсы или связи между заинтересованными сторонами
В англоязычной литературе в подобной тематике часто будет встречаться термин "stakeholders".
Заинтересованные стороны (stakeholders) - это группы или люди, которые могут быть затронуты или иметь интерес в проекте, продукте или организации. Они влияют на процесс разработки, принятие решений и достижение целей проекта.
Примеры заинтересованных сторон могут включать:
- Клиенты: потенциальные или существующие пользователи продукта или услуги.
- Руководство компании: высшее руководство, владельцы или управляющие организации.
- Команда проекта: разработчики, дизайнеры, тестировщики и другие участники проекта.
- Партнеры и поставщики: компании или организации, предоставляющие необходимые ресурсы или услуги.
- Конкуренты: другие компании, работающие в том же сегменте рынка.
- Регуляторные органы: государственные или международные организации, которые устанавливают нормы и правила для определенных отраслей.
- Общественность: широкая общественность, включая клиентов, потенциальных потребителей и общественные организации.
- Финансовые инвесторы: лица или компании, вложившие деньги или интересующиеся финансовыми результатами проекта.
- Локальное сообщество: жители или группы, проживающие рядом с объектом проекта.
- Сотрудники компании: работники, которые могут быть прямо или косвенно задействованы в проекте.
Каждая из этих заинтересованных сторон может иметь свои уникальные потребности, ожидания и интересы, которые должны быть приняты во внимание при разработке проекта или продукта.
Появление следующих артефактов может говорить об успешности данного шага:
- Список потребностей, ожиданий и ограничений заинтересованных сторон
- Список интерфейсов и/или связей: ссылки, системы, люди, отношения, взаимодействия, взаимозависимости
3. Преобразовать потребности, ожидания, ограничения и интерфейсы или связи заинтересованных сторон в требования, установив приоритет для них
Во-первых, после того как мы все выявили и собрали, нам нужно превратить это в конечные требования заказчика. Независимо от того, в каком виде к нам попали изначальные требования на первом шаге их нужно сопоставить с мнением заинтересованных сторон и превратить в "зачаток" бэклога. Конечный, список требований для реализации.
В процессе формирования данного списка необходимо учесть следующее:
Описание основных функций или свойств, которые должны быть реализованы в конечном продукте или услуге. Например, заказчик может требовать, чтобы программа для учета имела возможность регистрации и хранения информации о клиентах, товарах и продажах.
Препятствия, которые могут возникнуть при реализации требуемых функций или свойств. Например, заказчик может указать, что необходимо интегрировать программу учета с уже существующей системой управления складом, что может потребовать согласования с поставщиками и внесения изменений в текущие бизнес-процессы.
Какая выгода или преимущество достигается с помощью реализации требуемых функций или свойств. Например, заказчик может утверждать, что если программа для учета будет включать функцию автоматического расчета налогов, это поможет компании сократить время и снизить возможность ошибок при подготовке налоговой отчетности, что в свою очередь повысит эффективность работы и увеличит конкурентоспособность.
Насколько легко можно будет поддерживать и обновлять реализованные функции или свойства в будущем. Например, заказчик может требовать, чтобы программа для учета была написана на определенном языке и/или использовались библиотеки с открытым исходным кодом, чтобы в случае изменения требований или обновления оборудования, можно было бы вносить изменения без большого количества дополнительных затрат (здесь можно дискутировать, о том насколько на самом деле открытость кода поможет в конкретном случае и насколько реально уменьшит затраты, но в контексте примера не будем этого делать).
Ограничения, которые заказчик устанавливает в отношении дизайна, верификации и валидации, чтобы обеспечить выполнение своих требований и ожиданий от конечного продукта или услуги:
- Ограничения дизайна могут включать требования по стилю, внешнему виду, эстетике или функциональности. Заказчик может иметь ограничения на использование определенных материалов, технологий или дизайнерских элементов.
- Ограничения верификации связаны с необходимостью проверить правильность реализации требований. Заказчик может устанавливать ограничения на необходимость проведения определенных типов тестов, требовать определенной степени надежности или точности, или указывать на необходимость соответствия определенным стандартам или регуляторным требованиям.
- Ограничения валидации являются требованиями, которые должны быть выполнены для подтверждения того, что продукт или услуга соответствуют ожиданиям и целям заказчика. Это может включать проведение определенных проверок, тестирование с участием реальных пользователей, сравнительные исследования или другие методы оценки качества и соответствия.
При этом требования не должны указывать или ограничивать конкретные проектные решения без тщательного рассмотрения. Требования должны быть выражены в более общем и абстрактном виде, чтобы оставить возможность для выбора оптимальных решений. Например, заказчик может указать, что программа для учета должна быть интуитивно понятной и иметь простой интерфейс, но не должен указывать, каким именно образом это должно быть реализовано, чтобы не ограничивать возможности разработчиков в выборе технологий и дизайна. Самый яркий антипаттерн - заказчик в описании требований указывает какие поля необходимо добавить в таблицу или какой стандарт использовать для какого-либо взаимодействия.
Во-вторых, приоритезировать требования клиента. Приоритетные требования заказчика помогают определить объем проекта, итерации или инкремента. Расстановка приоритетов гарантирует, что функциональные требования и требования к качеству, критичные для заказчика и других заинтересованных сторон, получат наибольшее внимание.
Появление следующих артефактов может говорить об успешности данного шага:
- Приоритезированные требования
- Ограничения
4. Получить взаимопонимание с поставщиками требований относительно их смысла
Те, кто занимается реализацией и тестированием решения должны анализировать требования вместе с их поставщиком, чтобы достичь общего понимания смысла требований. Результатом такого взаимодействия является набор утвержденных требований. Важно выявить и устранить из набора требований как можно больше двусмысленностей.
Появление следующих артефактов может говорить об успешности данного шага:
- Списки соответствующих поставщиков требований - перечень источников или сторон, которые могут предоставить требования проекту. Это могут быть заказчики, пользователи, менеджеры проекта или другие заинтересованные стороны, которые могут внести свои требования и ожидания к продукту, услуге или конкретному ее аспекту.
- Критерии для оценки и принятия требований - определенные меры, параметры или стандарты, по которым требования будут оцениваться, чтобы определить их приемлемость для проекта. Это может включать полноту, однозначность, измеримость, соответствие бизнес-целям, техническую выполнимость и другие критерии.
- Результаты анализа по критериям - последствия оценки требований с использованием установленных критериев. Они могут показывать, насколько требования соответствуют критериям и какие изменения или доработки требуются для их улучшения или полного соответствия.
- Зафиксированные изменения в требованиях - записи о внесенных изменениях в требования проекта. Это может быть связано с добавлением новых требований, изменением существующих или удалением ненужных требований. Зафиксированные изменения помогают отслеживать и контролировать изменения в требованиях в течение жизненного цикла проекта.
- Набор утвержденных требований - совокупность требований, которые были оценены, приняты и утверждены как действительные и обязательные для проекта. Это отражает общее понимание и согласие между командой проекта и клиентами относительно того, что требуется достичь и реализовать в конечном продукте или услуге.
5. Получить от участников проекта подтверждение того, что они смогут реализовать требования
Участники проекта должны полностью осознают необходимость принятия обязательств по утверждению требований и внесению изменений в планы, мероприятия и результаты работ по проекту. Перед тем, как они приступят к выполнению своих ролей, проведите встречу и обсудите, четкое распределение обязанностей и ожидания, проясните, как их работа будет способствовать достижению целей проекта.
Появление следующих артефактов может говорить об успешности данного шага:
- Оценка влияния (требований) - включает оценку стоимости и влияния на качество, риски и график выполнения работ;
- Зафиксированы обязательства по выполнению требований
6. Создание, документирование и поддержание взаимосвязи между требованиями, деятельностями и рабочими продуктами
Здесь важно пояснить что такое рабочий продукт (work products). Рабочим продуктом называют конкретный результат созданный в рамках проекта или конкретных работ. Он может представлять собой конечный или промежуточный результат. Рабочий продукт может быть программным кодом, дизайном веб-страницы, отчетом, прототипом, макетом, артефактом проекта и т.д. Он является видимым и измеримым результатом работы команды проекта. Рабочие продукты могут являться основой для последующих итераций или фаз проекта.
Записи двусторонней прослеживаемости требований отражают связи и взаимосвязи между различными требованиями и другими элементами проекта, такими как деятельности или рабочие продукты. Эти записи помогают отследить, какие требования были удовлетворены и реализованы в процессе разработки или изменений проекта. Это важный инструмент, который обеспечивает прозрачность и контроль в процессе выполнения проекта, а также помогает в дальнейшем анализе и проверке выполнения требований.
Примеры:
- Требование: Веб-сайт должен быть совместим с различными браузерами.
Деятельность/рабочий продукт: Заключение договора с внешними тестерами для проверки совместимости на различных браузерах.
Запись прослеживаемости: Требование 1 связано с деятельностью/рабочим продуктом 1 (заключение договора с тестерами) для проверки совместимости на разных браузерах. - Требование: Система должна поддерживать многопользовательскую аутентификацию.
Деятельность/рабочий продукт: Создание модуля аутентификации с возможностью регистрации и входа для разных пользователей.
Запись прослеживаемости: Требование 2 связано с деятельностью/рабочим продуктом 2 (создание модуля аутентификации) для поддержки многопользовательской аутентификации. - Требование: Мобильное приложение должно поддерживать платежи через мобильную платежную систему.
Деятельность/рабочий продукт: Интеграция API мобильной платежной системы в приложение.
Запись прослеживаемости: Требование 3 связано с деятельностью/рабочим продуктом 3 (интеграция API платежной системы) для поддержки платежей через мобильную платежную систему.
Появление следующих артефактов может говорить об успешности данного шага:
- Записи о двунаправленной прослеживаемость требований
7. Гарантировать соответствие планов, деятельностей или рабочих продуктов требованиям
Важно, чтобы все планы, деятельности и продукты проекта были согласованы и соответствовали требованиям. Для этого необходим контроль и проверка, включая аудиты, ревизии и тестирование и выработка корректирующих мер. Это помогает уменьшить риски и достичь целей проекта.
Появление следующих артефактов может говорить об успешности данного шага:
- Записи о несоответствиях между требованиями, планами и рабочими продуктами
- Корректирующие действия
Если у вас прослеживаются все описанные ваше действия, можно считать, что вы на пути формирования четких и прозрачных процессов, ведущих к ожидаемым результатам.
Дальнейшие элементы работы с требованиями тесно связаны с непосредственной работой нат техническими и интеграционными решениями, работой с рисками и т.д. Рассмотрим их в следующий раз.
