Прецеденты могут отражать только функциональные требования, которые являются описанием того, что будет делать система. Однако есть и другие требования, не относящиеся к функциональности, которые являются описаниями ограничений, накладываемых на систему (производительность, надежность и т. п.), и не могут быть представлены в виде прецедентов.
SRS - Software requirements specification
• Выявление нефункциональных требований.
• Назначение приоритетов требований.
• Отображение (trace) требований в прецеденты.
• Выявление актеров и прецедентов.
• Детализация прецедента.
• Построение модели прецедентов.
• Назначение приоритетов прецедентов.
• Создание прототипа пользовательского интерфейса.
• функциональные требования – какое поведение должна предлагать система;
• нефункциональные требования – особое свойство или ограничение, накладываемое на систему.
Требования указывают, что должно быть построено, но не говорят, как это сделать.
Наверное, самым распространенным атрибутом требований является priority (приоритет). Его значение определяет приоритет требования относительно остальных требований. Обычно для назначения приоритетов применяется набор критериев MoSCoW.
Ниже приведён набор атрибутов требований, использующийся в RUP:
• непосредственные пользователи системы;
• другие заинтересованные стороны (например, руководители, специалисты обслуживания, установщики);
• другие системы, с которыми взаимодействует данная система;
• аппаратные устройства, с которыми взаимодействует данная система;
• правовые и регулирующие ограничения;
• технические ограничения;
• коммерческие цели.
При выяснении у людей требований, предъявляемых к программной системе, вы всегда пытаетесь добиться от них точной картины, или карты, модели их сферы деятельности.
Подробная карта создается тремя процессами: пропуск (deletion), искажение (distortion) и обобщение (generalization). Эти процессы абсолютно необходимы, поскольку мы просто не располагаем механизмом познания, способным фиксировать каждый нюанс и деталь нашей сферы деятельности в некоторой воображаемой, подробной до мельчайших деталей карте. Поэтому приходится быть изобретательными. Мы осуществляем «выборку» из огромного массива возможной информации, применяя три фильтра:
• пропуск – информация отфильтровывается;
• искажение – информация изменяется взаимосвязанными механизмами вымысла и представления;
• обобщение – информация обобщается в правила, убеждения и понятия об истинности и ложности.
Эти фильтры образуют естественный язык. О них важно знать при тщательном сборе и анализе требований, поскольку для восстановления информации может понадобиться активно их идентифицировать и ставить под сомнение.
Примеры кванторов общности:
• все
• каждый
• всегда
• никогда
• никто
• нисколько
При встрече с квантором общности всегда можно найти пропуск, искажение или обобщение. Кванторы общности обычно свидетельствуют о достижении границ или пределов ментальной карты субъекта. Обычно при проведении анализа следует ставить под сомнение кванторы общности. Чуть не написали «всегда следует ставить под сомнение кванторы общности», но тогда мы бы опровергали самих себя!
• Анкеты
• Семинары
SRS - Software requirements specification
Задачи рабочего потока
• Выявление функциональных требований.• Выявление нефункциональных требований.
• Назначение приоритетов требований.
• Отображение (trace) требований в прецеденты.
• Выявление актеров и прецедентов.
• Детализация прецедента.
• Построение модели прецедентов.
• Назначение приоритетов прецедентов.
• Создание прототипа пользовательского интерфейса.
Понятие требования
Требование можно определить как «подробное описание того, что должно быть реализовано». Существует два основных типа требований:• функциональные требования – какое поведение должна предлагать система;
• нефункциональные требования – особое свойство или ограничение, накладываемое на систему.
Требования указывают, что должно быть построено, но не говорят, как это сделать.
Атрибуты требований
Каждый атрибут требования имеет описательное имя и значение. Так же требование может иметь атрибут source (источник), в качестве значения которого выступает описание того, откуда возникло данное требование. Конкретный набор используемых атрибутов зависит от природы и нужд проекта и может меняться в зависимости от типа требования.Наверное, самым распространенным атрибутом требований является priority (приоритет). Его значение определяет приоритет требования относительно остальных требований. Обычно для назначения приоритетов применяется набор критериев MoSCoW.
Ниже приведён набор атрибутов требований, использующийся в RUP:
Поиск требований
Требования следуют из контекста моделируемой системы. В этот контекст входят:• непосредственные пользователи системы;
• другие заинтересованные стороны (например, руководители, специалисты обслуживания, установщики);
• другие системы, с которыми взаимодействует данная система;
• аппаратные устройства, с которыми взаимодействует данная система;
• правовые и регулирующие ограничения;
• технические ограничения;
• коммерческие цели.
При выяснении у людей требований, предъявляемых к программной системе, вы всегда пытаетесь добиться от них точной картины, или карты, модели их сферы деятельности.
Подробная карта создается тремя процессами: пропуск (deletion), искажение (distortion) и обобщение (generalization). Эти процессы абсолютно необходимы, поскольку мы просто не располагаем механизмом познания, способным фиксировать каждый нюанс и деталь нашей сферы деятельности в некоторой воображаемой, подробной до мельчайших деталей карте. Поэтому приходится быть изобретательными. Мы осуществляем «выборку» из огромного массива возможной информации, применяя три фильтра:
• пропуск – информация отфильтровывается;
• искажение – информация изменяется взаимосвязанными механизмами вымысла и представления;
• обобщение – информация обобщается в правила, убеждения и понятия об истинности и ложности.
Эти фильтры образуют естественный язык. О них важно знать при тщательном сборе и анализе требований, поскольку для восстановления информации может понадобиться активно их идентифицировать и ставить под сомнение.
Примеры кванторов общности:
• все
• каждый
• всегда
• никогда
• никто
• нисколько
При встрече с квантором общности всегда можно найти пропуск, искажение или обобщение. Кванторы общности обычно свидетельствуют о достижении границ или пределов ментальной карты субъекта. Обычно при проведении анализа следует ставить под сомнение кванторы общности. Чуть не написали «всегда следует ставить под сомнение кванторы общности», но тогда мы бы опровергали самих себя!
Способы выявления требований
• Интервью• Анкеты
• Семинары
Комментариев нет:
Отправить комментарий