12.7. АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ

12.7. АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ

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

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

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

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

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

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

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