ОСОБЕННОСТИ РАБОТЫ С ТРЕБОВАНИЯМИ НА ЭТАПЕ НАПИСАНИЯ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Управление требованиями включает в себя процессы сбора потребностей от основных стейкхолдеров, их первичной обработки и анализа, документирования, определения приоритетов, контроля изменений и реализации [1].

Количество требований и их логическая сложность непредсказуемы, а в дополнении с возможными изменениями во время разработки может привести к некачественному и некорректному формату разработки, поэтому важно, чтобы в любой момент времени аналитик мог определить историчность функциональности.

Жизненный цикл управления требованиями состоит из следующих этапов [2]: выявление требований; согласование требований; фиксация и анализ требований; систематизация требований в рамках единой документации (техническое задание, пояснительная записка или любой другой формат аналитической документации).

В рамках проектной работе на каждом этапе может возникнуть вариативность действий аналитика. При выборе некорректного варианта действия могут повлечь за собой срыв сроков и увеличения стоимости проекта.

Выявление согласование требований

Данный этап включает в себя выявление и управление стейкхолдерами, проведение процедуры сбора требований, а также фиксация результатов.

Чаще всего аналитики на проекте пропускают момент фиксации договоренностей, что в дальнейшем приводит к неудовлетворенности Заказчика. Каждый аналитик должен помнить, что необходимо не только собирать требования с Заказчика, но также и валидировать соответствие виденья реализации системы.

На данном этапе рекомендуется после каждой встречи с стейкхолдерами подготавливать соответствующие артефакты (протоколы встречи), с которыми каждый стейкхолдер должен иметь возможность ознакомиться.

Такие артефакты позволят в дальнейшем на любом этапе отследить, кто является носителем потребности и насколько корректно потребность легла в описания требования, а затем и в реализацию функциональности.

Фиксация и анализ требований

В рамках инженерии требований самыми популярными способами фиксации требований являются [3.4]:

• канонический вид «Система должна…»;
• пользовательские истории «Как «роль» должен иметь возможность…»;
• модель прецедентов, включающая в себя пошаговое описание варианта использования системы.

Чаще всего аналитики прибегают к тому способу, который удобен аналитику, понятен Заказчику, учитывает специфику того или иного требования.

На данном этапе чаще всего не учитываются способности Заказчика корректно прочитать и воспринять описания требования. Для дальнейшей корректной работы рекомендуется на раннем этапе согласовать с стейкхолдерами формат передачи требований, предоставить пробный артефакт и найти баланс между принятыми нормами понимания требований и возможностями к восприятию конкретным стейкхолдером.

Анализ требований должен включать в себя не только проверку на однозначность, ясность, возможность исполнения, но и контроль согласованности требований от каждого стейкхолдера. Артефакты, подготовленные на этапе выявления требований смогут помочь восстановить источник требований и найти более подходящий вариант обработки потребности.

Подготовка аналитической документации

В проектной деятельности могут встречаться разные типы аналитической документации, помимо этого могут быть добавлены ограничения и особенности ГОСТ 19 или ГОСТ 34.

Подготовка детальной документации с требованиями по ГОСТ может повлечь за собой дополнительные затраты времени аналитики, что приведет к удорожанию проекта. Чаще всего аналитик настаивает на принятом в компании формате документации, не обращая внимания на особенности проекта (размер, сроки, наличие прошлых аналитических атрибутов у Заказчика).

Для написания корректного и адекватно отображающего особенности проект аналитического документа для всех стейкхолдеров рекомендуется заранее, по возможности на начальном этапе согласовать основные требования к документу, а в дальнейшем лишь до уточнять их. Такой подход гарантирует удовлетворенность как Заказчиком, так и команду проекта.

Управление изменениями

В ходе разработки ИТ-проекта как со стороны Заказчика, так и со стороны команды могут появиться дополнительные требования не только на этапе аналитики, но и позже. Новые требования достаточно просто добавляются в проект при гибкой методологии разработки. Так как в рамках рассматриваемого проекта разработка системы проводилась по фиксированной оплате за фиксированный объем задач добавление новых требований со стороны Заказчика в систему было решено фиксировать в дополнительном аналитическом документе. Важным аспектом выполнения этой работы была корректная интеграция новых требований в систему с учетом уже разработанной функциональности.

Выводы

По результатам выполненных работы был подготовлен ряд выводов:

• на этапе сбора требований к проекту аналитику рекомендуется фиксировать все договоренности и контролировать ознакомление с ними у всей рабочей группы;
• на ранних этапах работы на проекте рекомендуется согласовывать формат представления требований и написания аналитической документации, что позволит гарантировать единое понимание поведения системы всей командой;
• отслеживание историчности требований (трассировка) позволяет на поздних этапах разработки интегрировать новые требования к системе с минимальными затратами.

1. Карл Вигерс, Джой Битти. Разработка требований к программному обеспечению. 3-е изд., дополненное / Пер. с англ. М.: Издательство «Русская редакция»; СПб.: БХВ-Петербург, 2014. 736 стр.
2.  Элизабет Халл, Кен Джексон, Джереми Дик. Разработка и управление требованиями. Практическое руководство пользователя (Второе издание). [Электронный ресурс]: Электронная версия. URL: http://www.interface.ru/iarticle/files/19771_42776753.pdf (дата обращения: 10.09.2021).
3. Пилон, Д. Управление разработкой ПО / Д. Пилон, Р. Майлз. – СПб.: Питер, 2011. – 460 с.
4. Грэхем, И. Объектно-ориентированные методы. Принципы и правктика / И. Грэхем; пер. с англ., ред. Н.Н. Куссуль. – 3-е изд. – М.: Вильямс, 2004. – 800 с.