Сбор функциональных требований
Для написания функциональной спецификации ее автор должен знать функциональные требования. Он должен выполнить сбор функциональных требований, консультируясь с бизнес-аналитиком, обсудившим функциональность программного решения с владельцем. Успех данного исследования зависит от места расположения владельца, который либо доступен для беседы с аналитиком, либо не может предоставить необходимую информацию. Бизнес-аналитик помогает владельцу сосредоточиться на важной и полезной для проекта информации, исключая технические детали построения проекта.
Бизнес-аналитик обдумывает информацию, предоставленную владельцем, и создает подробную функциональную спецификацию, после чего команда разработки эффективно разрабатывает программное решение. Аналитик идентифицирует все требования программного решения, начиная с документов, описывающих область работы.
Затем с помощью UML составляются диаграммы use-case бизнес-процессов. Как и многие другие задачи, диаграммы use-case создаются с максимальном количеством деталей для более точного описания бизнес-процессов. Диаграммы UML упрощают документацию use-case и облегчают ее понимание и сверку.
После сбора аналитиком всей необходимой информации use-case она документируется в виде формы или таблицы. Шаблон или форма для документирования информации use-case включает в себя следующие элементы.
- Имя use-case. Короткое информативное имя.
- Идентификатор use-case. Уникальный буквенно-цифровой код.
- Действующие лица. Все конечные пользователи, принимающие участие в use case.
- Предварительные условия. Часть среды, присутствующая в реализации use-case.
- Процесс. Что происходит в процессе use-case.
- Последующие условия. Что представляет собой среда после выполнения use-case.
Например:
Имя: Поиск рецепта. Идентификатор: UC001. Действующие лица: Пользователь. Предварительные условия: Пользователь должен осуществить успешный вход на сайт.
Процесс:
- Пользователь щелкает на ссылке "Поиск рецепта".
- В окне браузера открывается окно "Поиск рецепта".
- Пользователь вводит в диалоговом окне ключевое слово, которое присутствует в искомом рецепте.
- Пользователь нажимает на клавишу Enter.
- Окно обновляется с отображением результатов поиска.
- Если пользователь получает искомое имя рецепта:
- Пользователь щелкает на ссылке для получения рецепта.
- Рецепт отображается в окне браузера.
- Если пользователь не получает искомого имени рецепта:
- Пользователь вводит новый критерий поиска рецепта в диалоговом окне ввода ключевого слова.
- Пользователь осуществляет поиск, до тех пор пока рецепт не будет найден.
Последующие условия: пользователю в окне браузера отображается нужный рецепт.
Такой тип анализа помогает при разработке решений. Шаблон use-case соответствует шаблону функционирования самого кода программы. Секция "Процесс" последовательности use-case является алгоритмом, который является частью создаваемого программного решения.
После проверки и подтверждения владельцем задокументированных последовательностей use-case их связывают с требованиями, определенными владельцем. Если use-case-не соответствуют этим требованиям, то они либо отбрасываются, либо определяются другие требования.
По завершении работы над функциональной спецификацией следует проверить оценку и план, представленные на этапе выявления области работы. Для внесения изменений следует определить вспомогательные функциональные требования, позволяющие увеличить сроки или использовать дополнительные ресурсы. Если владелец согласится с новым расписанием, переходите к выполнению следующего этапа проекта. В противном случае измените область работы для удовлетворения требованиям по доставке готового продукта.
