Проектирование бизнес-приложения: Управление требованиями
Следующим шагом после анализа является фиксирование требований к системе и управление ими. Требования могут быть функциональные и нефункциональные.
Нефункциональные требования фиксируют параметры приложения, которые не относятся к выполняемым им функциям – это обычно какие-либо технические характеристики: ограничение на какую-либо операционную систему, технологию, требования к интерфейсу и т.п.
Функциональные требования описывают функции системы и определяют ограничения на них. Они строятся на основе ранее проведенного анализа и первоначально могут полностью соответствовать результатам модульного анализа.
Зачастую, заказчик в момент обследования не может вспомнить каких-то нюансов бизнес-процессов, необходимых для корректной автоматизации. Так же бывает, что заказчик меняет некоторые требования в процессе разработки. Чтобы уменьшить риски при реализации того или иного требования (функции системы), необходимо научиться управлять требованиями.
Первым делом переводим все выявленные функции будущего приложения в требования. Иногда некоторые требования следует разбить на несколько более мелких, т.к. какая-то часть требования может быть существенной (влияющей на архитектуру), а другие просто определяют несущественные расширения функций системы.
Следующим шагом будет являться простановка приоритетов для каждого требования. Этот процесс следует проводить совместно с заказчиком и архитекторами (инфраструктуры и приложения).
Для начала необходимо выявить базовые требования, без которых невозможно будет построить базовую архитектуру приложения. Обычно эти требования фиксируются и практически не изменяются до момента выпуска версии. Изменение данных требований зачастую может носить фатальные последствия для приложения и проекта в целом.
Далее расставляем приоритеты на остальные требования в зависимости от их важности с учетом того, что они могут достаточно серьезно повлиять на архитектуру приложения.
Составленный список требований необходимо тщательно согласовать с заказчиком. Чем выше приоритет у требования, тем внимательнее заказчику необходимо проверить его на полноту и корректность. Если в высокоприоритетное требование будут вноситься существенные требования в процессе разработки приложения, то это может существенно изменить архитектуру приложения и увеличить время и стоимость разработки. Чем раньше будет найдена и исправлена ошибка, тем меньшая стоимость будет у нее.
В процессе построения приложения требования могут изменяться (практически все проекты подвержены этому). В зависимости от приоритета требования и степени его реализации следует производить переоценку его приоритетности и возможности реализации в измененном виде на текущей стадии создания приложения. Возможны варианты, когда изменения в требования настолько существенны, что объем работ по модификации приложения может оказаться достаточно большим. В таких случаях изменение требования переносят на последующую версию или начинают процесс практически с начала.
Похожие статьи: