Что мы узнали

В данной главе представлен рабочий поток определения требований в UP и общее обсуждение требований, предъявляемых к программному обеспечению. Вы узнали следующее.
• Большая часть работы в рабочем потоке определения требований выполняется в фазах Начало и Уточнение жизненного цикла проекта UP.
• Наша метамодель требований показывает, что существует два способа представления требований: 1) функциональные и нефункциональные требования и 2) прецеденты и актеры.
• Детализация рабочего потока определения требований в UP включает следующие деятельности, представляющие интерес для ОО аналитиков и разработчиков:
• Выявление актеров и прецедентов;
• Детализация прецедента;
• Построение модели прецедентов.
• Стандартный рабочий поток определения требований в UP расширяется:
• актером: Разработчик требований;
• деятельностью: Выявление функциональных требований;
• деятельностью: Выявление нефункциональных требований;
• деятельностью: Назначение приоритетов требований;
• деятельностью: Отображение (trace) требований в прецеденты.
• Большинство провалов проектов обусловлено недостатками выработки требований.
• Существует два типа требований:
• функциональные требования – какое поведение должна предлагать система;
• нефункциональные требования – определенное свойство или ограничение, накладываемое на систему.
• Правильно сформированные требования должны быть выражены в простых структурированных фразах на английском языке, использующих выражения shall (должен), для того чтобы инструментальные средства выработки требований могли без труда проводить их синтаксический анализ.
<id> <система> shall <действие>
• Модель требований содержит функциональные и нефункциональные требования к системе. Это может быть:
• документ;
• база данных в системе управления требованиями.
• Требования могут быть организованы в таксономию – иерархию типов требований, которая классифицирует требования.
• Требования могут иметь атрибуты – дополнительную информацию (метаданные), ассоциированную с каждым требованием:
• например приоритет – MoSCoW (Must have, Should have, Could have, Want to have);
• например атрибуты RUP (Status, Benefit, Effort, Risk, Stability, TargetRelease);
• количество атрибутов требований должно быть минимальным, от этого проект только выиграет.
• Карта местности еще не территория. Естественный язык содержит:
• пропуски – информация отфильтровывается;
• искажения – информация модифицируется;
• обобщения – информация обобщается в правила, убеждения и понятия об истинности и ложности.
• Кванторы общности (например, «все», «каждый») могут указывать границы чьей-либо ментальной карты сферы деятельности; их необходимо ставить под сомнение.
• Техники выявления требований:
• интервью;
• анкеты;
• семинары.

Запись опубликована в рубрике Компьютеры и интернет с метками . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

code