Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Ранжированность по важности и стабильности




Совместимость

Полнота

Однозначность

Корректность

Показатели качества требований

Структурирование требований

В отдельные главы должны быть выделены технические и нетехнические требования.

Технические требования должны быть разделены внутри разделов на функциональные и нефункциональные требования.

Разделы могут быть структурированы в зависимости от особенностей проекта по режимам функционирования, классам/объектам, группам пользователей, опциям, функциональной иерархии, управляющим воздействиям и пр. Различные подходы могут быть использованы на различных уровнях структуры документа. Выбор различных способов структурирования требований целесообразно выполнять на основе стандарта IEEE Std 830. Обязательным является описание во введении способа структуризации документа.

В данном разделе приведены показатели качества требований, которым должны удовлетворять разрабатываемые технические задания.

Требования являются корректными, если они соответствуют требованиям и условиям, содержащимися в документах, на основе которых разработаны, прежде всего: контракту, а также, - концепции, результатам обследования, общим требованиям к аппаратно-программной системе и т.д.

Требование является однозначным, если оно допускает единственное толкование.

Совокупность требований является полной, если она включает:

· Все существенные требования, относящиеся к функциональности, производительности, ограничениям, атрибутам, внешним интерфейсам и пр.

· Определение всех реакций системы на все реализуемые классы входных данных во всех реализуемых ситуациях (включая ошибочные входные данные).

· Определения всех нестандартных терминов, все необходимые внутренние и внешние ссылки, определение используемых единиц измерения.

Требования являются совместимыми, если отсутствуют противоречия между любыми двумя подмножествами требований.

Возможные примеры несовместимостей:

· Различные требования описывают противоречивые характеристики одного объекта

· Различные требования описывают противоречивые действия одного и того же объекта

· Различные требования при описании одних и тех же объектов используют различную терминологию

Требования должны быть отмечены идентификаторами, которые устанавливают их относительную важность (значение) для заказчика и стабильность.

Ранжирование требований по важности обеспечивает более полное согласование ожиданий заказчика и усилий исполнителя. Ранжирование требований также важно для более оптимальной организации процесса проектирования и разработки программного обеспечения.

Рекомендуется следующий минимальный набор степеней важности:

· «обязательное» – требование должно быть выполнено и будет проходить проверку при сдаче системы.

· «рекомендуемое» – требование целесообразно, согласовано с Заказчиком, оно улучшает характеристики системы, однако отсутствие его либо неполное удовлетворение не является основанием для отказа от приемки.

· «опциональное» – требование желательно с точки зрения разработчика, целесообразность его со стороны заказчика в текущий момент не подтверждена.

Рекомендуется также ранжировать требования по степени стабильности, отмечая требования количеством предполагаемых изменений в процессе выполнения проекта.




Поделиться с друзьями:


Дата добавления: 2014-01-07; Просмотров: 483; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.008 сек.