Функциональная спецификация
Функциональная спецификация описывает ожидаемый результат работы над проектом с точки зрения владельца. Она является подготовительным этапом перед составлением технического проекта и обеспечивает понимание владельцем конечного результата. В этом документе указываются действия, выполняемые программным решением. Видимые промежуточные результаты нужно подробно описать, чтобы разработчик создавал программное решение без дополнительных вопросов к владельцу. Функциональная спецификация создается с технически абстрагированной точки зрения и не содержит технических инструкций по созданию решения.
| 1 | Функциональная спецификация | Бизнес-аналитик. |
| 2 | Квалифицированная оценка функциональных требований | Разработчики. |
| 3 | Квалифицированный план проекта для функциональных требований | Менеджер проекта. |
| 4 | Согласие владельца с определенными функциональными требованиями, даты окончания работ в плане | Менеджер проекта. |
Функциональная спецификация занимает объем не более 30 страниц и состоит из следующих элементов.
- Определение каждого функционального требования; это нужно, чтобы специалисты по разработке и контролю качества могли определенным образом называть компоненты спецификации в технической спецификации и сценариях тестирования.
- Рисунки или диаграммы каждого окна, связанного с результатом проекта или представляемого конечному пользователю.
- Запись контроля за изменениями.
- Содержание.
- Титульная страница с именем владельца и названием проекта.
- Нижний колонтитул с именем компании разработки, сведениями о конфиденциальности информации и датой печати документа.
- Идентификация проекта запоминающимся именем.
Хорошим методом уникальной идентификации каждого элемента в функциональной спецификации является нумерация фрагментов текста, описывающих работу того или иного компонента. Данный метод целесообразен для описания субординации функциональных спецификаций.
На рисунке 6. 4 приведен пример фрагмента текста в документе, в котором используется иерархическая нумерация для определения функциональных спецификаций.
Рекомендуемый объем функциональной спецификации не должен превышать 30 страниц, так как он должен оперативно просматриваться членами команды разработки перед планированием и началом непосредственной работы над программным решением. Не создавайте спецификацию произвольного размера. Если функциональные требования занимают более 30 страниц, не урезайте их, а вместо этого создайте еще одну функциональную спецификацию для определения всех функциональных требований.
Рис. 6.4. Уникально определенные с помощью иерархической нумерации функциональные требования
При наличии нескольких небольших функциональных спецификаций вместо одной в проекте появляется большее число итераций. Функциональная спецификация может рассматриваться как область итераций. Функциональная спецификация определяет мельчайшие части проекта, с которыми нужно ознакомить владельца.
Разработка всегда осуществляется согласно функциональным требованиям. Итерации уменьшают цикл разработки и снижают вероятность получения некорректного результата. Чем больше в проекте итераций, тем больше промежуточных результатов, с которыми нужно ознакомить владельца. Ему будет намного спокойнее наблюдать за успешным выполнением промежуточных этапов проекта, чем находиться в томительном ожидании конечного результата. Выполнение проекта с итерациями будет "занимать" голову владельца позитивными событиями, связанными с проектом. Если владелец не может видеть или понять промежуточные результаты, или если между ними проходит длинный промежуток времени, то он начинает отрицательно судить о ходе выполнения проекта.
На титульной странице спецификации необходимо разместить имя владельца, название проекта, область контроля за изменением, область нижнего колонтитула и содержание. Имя владельца и название проекта определяют происхождение проекта.
Нижний колонтитул сообщает о компании, издавшей данный документ, о дате издания и конфиденциальности документа.
Заключение о конфиденциальности имеет юридическую силу, если документ предоставляется другой организации, не имеющей права на его просмотр. При составлении с компанией контракта на разработку ПО владелец обычно подписывает договор о неразглашении, который запрещает предоставление полученных материалов другим организациям. Если документ имеет статус конфиденциального, то получатели несут правовую ответственность при нелегальном прочтении документа. Владелец должен соблюдать большую осторожность при распространении документа, а получатель документа должен понимать требования конфиденциальности перед прочтением документа.
Область контроля за изменениями на лицевой странице документа определяет дату, номер версии, обзор изменений, внесенных в документ, с указанием авторов изменений. На рисунке 6.5 показан пример титульной страницы функциональной спецификации.
Примечание. Многие текстовые процессоры, такие как Microsoft Word и Word Perfect, автоматически создают оглавление. Для правильной работы генератора оглавления необходимо, чтобы в тексте использовались определенные стили. Например, оглавление на рисунке 6.5 сгенерировано с использованием стилей Heading 1 (Заголовок 1) и Heading 2 (Заголовок 2). Многие авторы спецификаций допускают ошибку, создавая весь документ в текстовом процессоре и игнорируя форматирование текста.
Примечание. Документ Word, использованный в качестве демонстрационной функциональной спецификации, доступен с исходным кодом на веб-сайте автора книги.
увеличить изображение
Рис. 6.5. Титульная страница демонстрационной функциональной спецификации
Разработка шаблона функциональной спецификации или ее общей структуры является хорошо зарекомендовавшим себя конструктивным подходом, который позволяет всем пользователям документа отыскивать определенную информацию по аналогии с другими спецификациями, изученными ранее.Недостатком такого подхода является то, что однажды допущенная ошибка может повторяться снова и снова.
Чтобы привести в равновесие конструктивность и предоставление документации, отвечающей требованиям организации, сконцентрируйтесь на сути проекта. При необходимости отклонитесь от шаблона, принятого по умолчанию, чтобы поточнее описать работу программного решения.
Если функциональная спецификация изменяется в каждом проекте, то следует изменить шаблон документа. Ниже приведены основные положения, которыми следует руководствоваться при составлении функциональной спецификации.
