Регистрация   E-Mail     Пароль   
  
Портал «Профессионал управления проектами»
!!!! Обращаем внимание регионов!
Первый курс по MS Project 2010 в он-лайн формате, 20-27 июля 2010 года.

Анализ требований и управление изменениями программных проектов

 
 
Дата публикации: 14.10.2014
Версия для печати (доступна только зарегистрированным пользователям)Версия для печати
 

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

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

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

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

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

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

Календарное планирование - Анализ требований и управление изменениями программных проектов
Рисунок 2. Диаграмма прецедентов игры «Конкуренция»

Предыдущая страницапредыдущая 1. 2. 3. 4. 5. 6. следующаяСледующая страница
Страница 4 из 6
Обсуждение Обсуждение

Пожалуйста, авторизуйтесь или зарегистрируйтесь для участия в обсуждении.

Вызов консультанта