Программирование в IIS

Сбор функциональных требований


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

Бизнес-аналитик обдумывает информацию, предоставленную владельцем, и создает подробную функциональную спецификацию, после чего команда разработки эффективно разрабатывает программное решение. Аналитик идентифицирует все требования программного решения, начиная с документов, описывающих область работы.

Затем с помощью 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. Действующие лица: Пользователь. Предварительные условия: Пользователь должен осуществить успешный вход на сайт.

Процесс:

  1. Пользователь щелкает на ссылке "Поиск рецепта".
  2. В окне браузера открывается окно "Поиск рецепта".
  3. Пользователь вводит в диалоговом окне ключевое слово, которое присутствует в искомом рецепте.
  4. Пользователь нажимает на клавишу Enter.
  5. Окно обновляется с отображением результатов поиска.
  6. Если пользователь получает искомое имя рецепта:
    1. Пользователь щелкает на ссылке для получения рецепта.
    2. Рецепт отображается в окне браузера.
  7. Если пользователь не получает искомого имени рецепта:
    1. Пользователь вводит новый критерий поиска рецепта в диалоговом окне ввода ключевого слова.
    2. Пользователь осуществляет поиск, до тех пор пока рецепт не будет найден.




Последующие условия: пользователю в окне браузера отображается нужный рецепт.

Такой тип анализа помогает при разработке решений. Шаблон use-case соответствует шаблону функционирования самого кода программы. Секция "Процесс" последовательности use-case является алгоритмом, который является частью создаваемого программного решения.

После проверки и подтверждения владельцем задокументированных последовательностей use-case их связывают с требованиями, определенными владельцем. Если use-case-не соответствуют этим требованиям, то они либо отбрасываются, либо определяются другие требования.

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


Содержание раздела