Навыки моделирования (аналитик должен уметь работать с разнообразными средствами, начиная с древних блок-схем и структурированных моделей анализа (диаграммы потоков информации, диаграммы «сущность-связь» и т.д.) и заканчивая современным языком UML).
Творческий подход (аналитик – не просто секретарь, записывающий все высказывания клиентов. Лучшие аналитики изобретают требования).
3.3 Процесс разработки и управления требованиями
3.3.1 Особенности процесса
Акцентируем внимание на том факте, что требования не только “определяются” на начальных этапах работ, но и модифицируются и используются во всем жизненном цикле. Поэтому в название процесса включено не только слово «разработка», но и управление.
Ключевые особенности процесса разработки и управления требованиями:
Ø Не является дискретным; это постоянно действующий процесс на всех этапах жизненного цикла ПО. Процесс работы с требованиями инициируется в начале проекта и продолжается на протяжении всего жизненного цикла, в плоть до завершения проекта. Например, функциональные тесты создаются в соответствии с функциональными требованиями к программной системе и обычно выполняются, в том числе, при проведении приемочных испытаний.
Ø Идентифицирует программные требования как элементы конфигурации (в терминах конфигурационного управления) и контролирует их с использованием тех же практик конфигурационного управления, что и для других активов программных проектов (например, файлов исходных текстов или запросов на изменения).
Ø Требует адаптации к проектному и/или организационному контексту, в рамках которого ведется соответствующий программный проект.
Структура процесса РУТ представлена на рисунке 3.5.
Рисунок 3.5 – Структура процесса разработки и управления требованиями
3.3.2 Разработка требований
В разработку требований входят все действия, включающие сбор, оценку, документирование и утверждение требований для ПО. Далее описаны основные действия в каждой из составных частей.
Выявление и сбор требований
Выявление и сбор требований (извлечение требований) охватывает все действия, связанные с выявлением требований, такие как интервью, совещания, анализ документов, создание прототипов и другие.
К ключевым действиям (работам) выявления и сбора требований относятся:
1. Определение классов ожидаемых пользователей продукта и других заинтересованных лиц.
2. Понимание задач и целей, а также бизнес-целей, которым соответствуют эти задачи.
3. Изучение среды, в которой будет использоваться новый продукт.
4. Работа с отдельными людьми, которые представляют каждый класс пользователей, чтобы понять их потребности и ожидания в отношении качества.
Анализ требований
Анализ требований подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Далее перечислены основные действия:
- анализ информации, полученной от пользователей, чтобы отделить их задачи от функциональных и нефункциональных требований, бизнес-правил, предполагаемых решений и другой информации;
- разложение высокоуровневых требований до нужного уровня детализации;
- выведение функциональных требований из других требований;
- понимание относительной важности атрибутов качества;
- распределение требований по компонентам ПО, определенным в системной архитектуре.
- согласование приоритетов реализации;
- выявление пробелов в требованиях или излишних требований, не соответствующих заданным границам проекта.
Документирование требований
Документирование требований предусматривает представление и хранение совокупного знания о требованиях постоянным и хорошо организованным способом. Ключевым действием является преобразование собранных потребностей пользователей в письменные требования и диаграммы, пригодные для понимания, анализа и использования целевой аудиторией.
Утверждение требований
Утверждение требований (requirements validation) должна подтвердить правильность имеющегося набора требований, которые позволят разработчикам создать решение, удовлетворяющее бизнес-целям. Далее перечислены основные действия:
- проверка задокументированных требований для устранения всех недостатков до принятия требований группой разработки;
- разработка приемочных тестов и критериев, которые должны подтвердить, что созданный на основе требований продукт будет отвечать потребностям заказчика и удовлетворять поставленным бизнес-целям.
| Вы никогда не сможете создать идеальные требования. С практической точки зрения цель разработки требований – накопить общее понимание требований, достаточно хорошее для создания очередной порции продукта |
Из-за разнообразия проектов по разработке ПО и организационных культур единого, шаблонного подхода к созданию требований не существует. На рис. 3.6 показан каркас создания требований, который с разумными исправлениями подойдет для большинства проектов. Предшественником процесса показанного на рис. 3.6 является бизнес-потребность или рыночная возможность. Как правило, действия выполняются в основном по порядку, однако сам процесс не является строго последовательным. Первые семь действий обычно однократно выполняются на ранних стадиях работы над проектом (тем не менее, команде разработчиков придется периодически проверять эти действия). Остальные необходимы для каждого очередного выпуска или этапа работы над проектом.
Рисунок 3.6 – Каркас процесса создания требований (Карл Вигерс, 2014)
3.3.3 Управление требованиями
Начальные требования неизбежно корректируются в процессе работы клиентами, руководителями, специалистами по маркетингу, разработчиками и другими лицами. Для эффективного управления требованиями необходим процесс, позволяющий предлагать изменения и оценивать их возможную стоимость и влияние на проект, а также гарантировать, что соответствующие заинтересованные лица принимают разумные бизнес-решения о том, какие из предложенных изменений внедрить в требования.
Для эффективного управления требованиями жизненно необходимы выверенные способы управления конфигурацией. Для управления требованиями годятся те же утилиты для управления версиями, которые вы используете для управления базой кода. А лучше всего хранить требования в средстве управления требованиям, которое специально предназначено для этого.
Далее рассмотрим некоторые составляющие процесса управления требованиями, которые можно использовать в любой организации.
Дата: 2019-02-19, просмотров: 238.
