Недавно, читая блог своего коллеги по профессии, IT аналитика Виталия Григораша, обнаружил довольно-таки практичный способ выявления требований к разрабатываемой программной системе, которая либо уже имеет аналоги, либо которую попросту необходимо переделать/улучшить, добавив функциональности.
Для выявления требований Виталий предлагает для начала проанализировать функциональность существующей системы, ознакомившись с руководством пользователя и прочей справочной информацией.
После первоначального ознакомления с документацией:
- Смотрим оглавление справки, "видим" компоненты системы. Таким образом, получаем высокоуровневое представление о системе - функциональные области системы.
- Руководство пользователя - это всегда какая-либо последовательность действий пользователя для достижения определённой цели. Значит, есть уже почти готовые варианты использования. Остаётся только доработать их!
- Что касается пользовательского интерфейса, то, как правило, справочные документы пользователя уже имеют готовые скриншоты экранных форм. Дело за малым - остаётся спроектировать интерфейс, опираясь на аналоги.
- В итоге, необходимо актуализировать требования к разрабатываемому продукту, добавив либо новые, либо изменив существующие требования в соответствии с необходимой функциональностью.
Я сейчас восстановлением требований к системе занимаюсь, есть еще такой шаг: открыть исходник, найти сообщение об ошибке (в документации как правило не все), попросить разработчика по коду выявить условие возникновения (всех ошибок скопом по исходнику) и задокументировать. Причем серверная логика мною не затрагивается, только приложение
ОтветитьУдалитьkas, а как, кстати, ты документируешь сообщения об ошибках?
ОтветитьУдалить