Лабораторная работа №4 Управление требованиями
Цель работы:
изучение основ процесса управления требованиями;
изучение основных подходов к документированию требований;
изучение основных принципов и методов управления масштабом проекта;
изучение методики анализа относительных приоритетов функций;
анализ приоритетов функций программного проекта;
определение отношений трассировки функций программного продукта к бизнес-требованиям;
знакомство с системами автоматизированного управления требованиями.
Управление требованиями – это систематический подход к выявлению, документированию, организации и сопровождению изменяющихся требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и проектной группой по поводу изменяющихся требованиях к системе.
В небольших проектах для управления требованиями используются электронные таблицы или простые базы данных, сохраняющие как текст, так и отдельные атрибуты каждого требования. В более крупных проектах применяются коммерческие средства управления требованиями. Такие продукты позволяют пользователям импортировать требования из исходных документов, определять значения атрибутов, фильтровать и выводить на экран содержание базы данных, экспортировать требования в различных форматах, контролировать связи трассирования и соединять требования с элементами, хранящимися в других средствах разработки ПО.
Документирование требований
Результат этапа разработки требований - задокументированное соглашение между клиентами и разработчиками о создаваемом продукте. Спецификацию требований к ПО также называют функциональной спецификацией, спецификацией продукта, документ о требованиях и системной спецификацией. В этом документе точно указываются функции и возможности, которыми должен обладать программный продукт, а также необходимые ограничения. Именно на основе спецификации составляются планы разработки проекта и написания кода, а также особенности тестирования системы и пользовательской документации. Будучи конечным хранилищем требований к продукту, спецификация требований к ПО должна быть ясной и понятной, чтобы у разработчиков и клиентов не оставалось ни малейших возможностей для разночтения.
Типичная система может состоять из сотен или тысяч формулировок требований. Для надлежащего управления таким огромным количеством требований их необходимо пронумеровать с помощью некоторой схемы идентификации. Схема может включать классификацию требований в виде групп, которые легче поддаются управлению.
Существует несколько методов классификации и идентификации требований.
Уникальный номер – порядковый номер, сгенерированный вручную или с помощью CASE-средства.
Иерархический номер – присваивается с учетом положения требования в пределах документа описания требований. Это наиболее распространенный способ. Если функциональные требования приводятся в разделе 3.2 спецификации, то все их номера будут начинаться с 3.2 (например, 3.2.4.3). Чем больше цифр, тем больше уровень детализации требования.
Порядковый номер в пределах категории требований – присваивается в дополнение к префиксу, обозначающему категорию требований. (FEAT12, UC23). Например, UC означает «use case» (вариант использования). Коммерческие средства управления требованиями присваивают такой идентификатор, когда пользователь добавляет новое требование в БД.(Эти средства также поддерживают функцию иерархического именования.)
Требования можно упорядочить в виде иерархической структуры, представляющей отношение родитель-потомок. Родительское требование составлено из дочерних требований. Дочернее требование – фактически подтребование родительского.
Требование 1. Оформление заказа с учетом текущего наличия товаров на складе
Требование 1.1 Автоматический подсчет НДС и налога с продаж
Требование 1.2 Резервирование товара неутвержденных заказов
Требование 2 Возможность изменения неутвержденного заказа
Требование 3. Печать счета-фактуры и счета на оплату
Требование 4. Формирование бухгалтерских проводок при утверждении заказа
Требование 5. Возможность аннулировать заказ с возвратом товара на склад
Требование 6. Возможность просмотра статуса заказа.
Требование 7. Учет скидок для определенных групп клиентов
Требование 8. Учет наценок в зависимости от выбранной отсрочки платежа
Требование 9. Экспорт счета-фактуры в Excel.
В дополнение к тестовому описанию, каждое функциональное требование должно иметь несколько поддерживающих его фрагментов информации,или атрибутов (attributes), связанных с ним. Присваивая требованиям различные атрибуты, можно более успешно управлять сложностью информации. Хотя атрибуты могут быть самыми разнообразными, существуют общеупотребительные атрибуты, которые применяются в большинстве систем управления требования.
дата создания требования;
номер его текущей версии;
автор требования;
лицо, ответственное за удовлетворение требования;
состояние требования;
происхождение или источник требования;
подсистема (или подсистемы), для которых предназначено требование;
номер версии продукта, для которого предназначено требование;
используемый метод проверки или критерий тестирования приемлемости;
приоритет реализации;
стабильность (показатель того, какова вероятность изменения требования в будущем; нестабильность требований может показывать плохо определенные или изменчивые бизнес-процессы или бизнес-правила).