Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
11 / тп / Venchkovsky.doc
Скачиваний:
113
Добавлен:
19.05.2015
Размер:
515.07 Кб
Скачать

6.5. Атрибуты требований к программному изделию

Требование к программному изделию после всестороннего изу­чения и согласования должно быть документировано. Описание каждого требования включает следующие атрибуты.

1.Идентификатор, обеспечивающий возможность кон­троля реализации этого требования в течение всех фаз ЖЦПИ.

2-Уровень важности, указывающий, насколько суще­ственно это требование, может ли оно в дальнейшем обсуждаться и изменяться или оно является категорическим.

3. Приоритет, указывающий некоторый порядок очеред­ности при планировании работ и при проектировании изделия.

4. Стабильность отражает степень постоянства требо­вания. Здесь приводятся все те требования, которые могут быть из­менены на протяжении ЖЦПИ в результате получения дополни­тельной информации об изделии.

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

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

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

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

6.6. Документ Требования к программному изделию

Основным выходным материалом рассматриваемой фазы дол­жен быть документ Требования к программному изделию. Главным показателем качества этого документа является полнота охвата тре­бований пользователя. Для контроля и доказательства полноты в документ помещается таблица (матрица), показывающая, как тре­бования пользователя соотносятся с требованиями к программному обеспечению. Таблица позволяет организовать трассировку требо­ваний как вручную, так и с привлечением автоматизированных средств.

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

Основное в документе — функциональные требования, которые структурируются по нисходящему принципу с последовательной де­тализацией требований предыдущего, более высокого уровня. Не­функциональные требования подключаются к функциональным и могут появиться на всех уровнях иерархии функциональной деком­позиции.

Документ не содержит описания деталей реализации программ­ного изделия, т.е. функциональные требования отражают лишь то, что будет выполнять программный продукт. Многие из функцио­нальных требований вытекают из схем потоков данных, которые являются результатом структурного системного анализа проектиру­емого продукта. При этом схема потоков данных верхнего уровня дает общий обзор функций будущего изделия.

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

Документ Требования к программному изделию должен быть написан на естественном языке. В его рассмотрении и критическом обзоре, кроме разработчиков, принимают участие пользователи, операционный персонал и менеджеры, поэтому стиль и форма из­ложения требований должна быть понятна всем участникам этой фазы. Однако при описании ряда специфических требований воз­можно использование формальных языков описания спецификаций, во избежание нежелательных неточностей и многозначности естест­венного языка. В этом случае формальное описание (например, в виде таблиц или деревьев решений и т.п.) должно быть дополнено пояснениями на естественном языке.

Соседние файлы в папке тп