31.Уровни требований

1. бизнес-требования (business requirements), 2. требования пользователей (user requirements), 3. функциональные требования (functional requirements).

Корректность и согласованность (непротиворечивость) уровней требований

Требования не должны противоречить требованиям своего уровня иерархии и требованиям "родительского" уровня:

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

32. Требования функциональные и нефункциональные.

1.Функц-ные требования регламентируют функционирование или поведение системы (behavioral requirements).

2.Нефункц-ные требования, регламентируют внутренние и внешние условия или атрибуты функционирования системы

Нефункциональные требования

1.Внешние интерфейсы (External Interfaces): пользователя UI, внешних устройств (аппаратные), программные, передачи инф-ции (коммуникационные), 2.Атрибуты качества (Quality Attributes): Применимость, Надежность, Производительность, Эксплуатационная пригодность, 3.Ограничения (Constraints) - формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации.

Методологии и стандарты, регламентирующие работу с требованиями.

1. Разработки IEEE:

2. Отечественные ГОСТ:

ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.

ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы

ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

Брукс Ф.: Строжайшее и единственное правило построения систем ПО - решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.

33. Свойства требований.

1.Полнота (совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы),

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

3.Корректность и согласованность (не должны противоречить требованиям своего уровня иерархии и требованиям "родительского" уровня),

4.Верифицируемость (пригодность к проверке) - если требование является полным, то его можно проверить,

5.Необходимость и полезность при эксплуатации (Невозможность выполнения автоматизированных бизнес-функций пользователей; Полезными считаются любые свойства, повышающие эргономические качества продукта),

6.Осуществимость ((выполнимость) - определяется разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами),

7.Модифицируемость,

8.Трассируемость (возможность отследить связь между требованием и другими артефактами ИС (документами, моделями, текстами программ и пр.)),

9.Упорядоченность по важности и стабильности (количественная оценка степени значимости (важности) требования),

10.Наличие кол-ной метрики (запрос должен отрабатываться не более, чем _ секунд; средняя наработка на отказ должна составлять не менее, чем _ часов.)

Каких требований не должно быть:1.система должна предоставлять пользователям доступ к балансу его банковского счета.2.балансы счетов клиентов будут храниться в БД Access

Спецификация требований не должна содержать деталей проектирования или реализации (кроме известных ограничений).

Требования должны отвечать на вопрос: "что должна делать система", абстрагируясь от вопроса "как она это должна делать"