Тестирование требований
На основе пользовательских требований создаются сценарии функционального тестирования, и документируется ожидаемое поведение продукта в конкретных условиях. Совместно с клиентами изучаются сценарии тестирования, с целью убедиться, что они отражают нужное поведение системы. Прослеживается связь между отдельным сценарием и функциональным требованием, с целью убедиться, что для каждого требования есть сценарий проверки.
Валидация модели является одним из способов обеспечения качества требований, это осуществляется либо через формальное утверждение - когда пользователь со всем согласен, либо на основе статистического анализа, заключающегося в поиске связей и путей взаимодействия между описанными объектами и последующим выявлением несоответствий.
Определение критериев приемлемости
Пользователям предлагается описать, как они собираются определять соответствие продукта их потребностям и его пригодность к работе. Тесты на приемлемость обычно основываются на сценариях использования. Так требования, выполнение которых нельзя проверить – являются пожеланиями и не могут быть основой для разработки ПО, или основанием для его принятия или отклонения. Приемосдаточные тесты должны быть четким и формальным выражением того соответствует ли продукт пожеланиям заказчика или нет. Следовательно, возможность создания приемосдаточных тестов на этапе валидации требований говорит о том, что они верифицированы и сформулированы точно и однозначно. Разработка требований считается выполненной полностью тогда, когда включенные в спецификацию требований обладают методами оценки соответствия
Управление требованиями по Вигерсу.
Управление требованиями
Это выработка и поддержание взаимного согласия с заказчиками по поводу требований к разрабатываемому ПО.
Способ разделения областей разработки требований и управления ими.
Начальные требования неизбежно корректируются. Для эффективного управления требованиями необходим процесс, позволяющий вносить изменения оценивать их стоимость и влияния на весь проект.
Решение о внесении изменений принимается советом по внесению изменений, в который входит по одному человеку от каждой заинтересованной группы.
Контроль за выполнением требований на разных стадиях разработки и тестирования системы позволяет лучше понять состояние проекта в целом. Для этого используются методы управления конфигурацией
Методы управления конфигурацией
Конфигурация
конфигурация это функциональные и физические характеристики программы, сформулированные в технической документации и реализованные в продукте.
Конфигурация может восприниматься как сочетание конкретных версий аппаратных и программных элементов объединенных вместе в соответствии …и отвечающих определённому назначению
Процесс управления требований
Процесс управления требований состоит из 8 этапов:
Этап 1
Определяется и фиксируется процесс представления, анализа и утверждения изменений. Применяется для управления всеми изменениями.
Этап 2
Создается CCB из представителей заинтересованных групп, которые будут рассматривать изменения и решать, какие изменения принять, а какие отклонить и в какой версии.
Этап 3
Анализ влияния изменений требований. оценивается как каждое изменение повлияет на проект. На основе матрицы связей выявляются другие требования, элементы архитектуры, исходный код и сценарии тестирования, которые возможно придется изменить и оцениваются затраты на реализацию.
Этап 4
Создание базовой версии с последующим управлением версиями. Базовая версия содержит неизменяемый набор. После создания базовой версии вносятся изменения, всем версиям присваиваются уникальные идентификаторы, чтобы избежать путаницы между черновыми вариантами и последней базовой версией, а также между предыдущей и текущей версией требований.
Этап 5
Ведение журнала изменений требований. Фиксируются даты изменения спецификаций. Заносятся даты, причина, следствие и лица связанные с коррективами. Для автоматизации этого процесса существуют специальные утилиты управления версиями.
Этап 6
Контроль за состоянием всех требований. Создается БД, включающая по одной записи на каждое функциональное требование. В нее заносятся атрибуты этого требования, а также атрибут состояния: (Предложено, одобрено, реализовано, проверено).
Этап 7
Оценка изменяемости требований. Еженедельно фиксируется количество требований внесенных в базовую версию, а также число предложенных и одобренных требований.
Этап 8
Создается матрица связей и требований, сопоставляющая все функциональные требований с элементами архитектуры и кода, которые реализуют данное требованиями. Матрица связей позволяет сопоставить функциональные требования с требованиями более высоких уровней, на основе которых они созданы, и с другими родственными требованиями.
Методика составления спецификаций требований к программному обеспечению (IEEE-830-1998)
Данная методика описывает рекомендуемые принципы составления спецификации требований к программному обеспечению. Она разделена на пять разделов. Раздел 1 указывает область действия этой методики. В разделе 2 перечисляются ссылки на другие стандарты. В разделе 3 даны определения используемых терминов. Раздел 4 предоставляет предварительную информацию для составления качественной SRS. В разделе 5 обсуждается каждая из необходимых частей SRS. Данная методика имеет два приложения; в одном из них приведены альтернативные шаблоны формата, а в другом обеспечиваются указания по обеспечению соответствия со стандартом IEЕЕ/ЕIА 12207.1-1997.
1.1 Область действия
Этот документ представляет рекомендуемую методику составления спецификаций требований к программному обеспечению. В нем описываются содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и представлено несколько типовых образцов SRS.
Данная методика имеет своей целью определение требований к разрабатываемому программному обеспечению, но также может применяться для обеспечения помощи в выборе внутренних и коммерческих программных изделий. Однако ее применение к уже разработанному программному обеспечению может оказаться непродуктивным.
При встраивании программного обеспечения в большую систему, такую, как например медицинское оборудование, может потребоваться обращение к другим изданиям кроме указанных в данной методике.
Данная рекомендуемая методика описывает процесс создания продукта и его содержание. Продуктом является SRS. Эта методика может использоваться для создания такой SRS непосредственно или может использоваться как модель для более специфических стандартов.
Данная методика не определяет какой-либо конкретный метод, терминологию или инструмент для подготовки SRS.