Целевые программы

В результате всех выше перечисленных операций был создан проект в программе RequisitePro, который содержит в себе все требования к проекту. Эти требования упорядочены, каждое из них имеет уникальный идентификатор и набор атрибутов, который полностью описывает требование. Упорядоченные требования были разбиты по двум так называемым пакетам (package). Пакет — это структурная единица внутри проекта Rational RequisitePro, которая содержит требования и другие артефакты. В проекте «Конкуренция», было создано два пакета: веб-система мастера (Master’s Web System) и веб-система игрока. Такое решение было принято, потому что возможности мастера и игрока, принципиально различные, соответственно и требования к реализации их возможностей тоже разные, поэтому удобно их разделить по двум разным пакетам, общие же требования находятся на уровень выше.

Далее приведем самые основные функциональные требования к системе:

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

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

После наполнения проекта «Конкуренция» требованиями, созрела необходимость в создание бизнес-прецедентов и их диаграммы, как и документирования.
Поведение системы — это ее реакция в ответ на внешние события. В языке UML внешне наблюдаемое и допускающие тестирование поведение фиксируется в виде прецедентов. Прецедент (use case) выполняет бизнес-функцию, которую может наблюдать внешний субъект и которая может быть впоследствии отдельно протестирована в процессе разработки.

Не смотря на то, что многие функциональные требования совпадают с прецедентами, необходима особая форма документирования прецедентов. Каждый прецедент должен быть описан с помощью документально описанного потока событий (flow of events). Соответствующий текстовый документ определяет, что должна делать система, когда субъект инициирует действие.

Рисунок 2. Диаграмма прецедентов игры «Конкуренция»