Способы записи спецификаций

Существуют четыре способа записи спецификаций (см. табл. 2.1).

Таблица 2.1 – Способы записи спецификаций требований

В спецификацию системных требований входит также спецификация интерфейсов.

Различают три типа специфицируемых интерфейсов.

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

5. Структуры (интерфейсные форматы) данных, которые пересылаются от одной подсистемы к другой.

6. Специальные представления данных, например в виде упорядоченной последовательности двоичных разрядов.

Атрибуты требований

Каждое требование должно включать семь атрибутов, перечисленные ниже:

а) идентификатор – каждое требование должно включать идентификатор для облегчения трассировки требований при последовательном выполнении фаз проекта;

б) необходимость – каждое существенное требование должно быть помечено особо, так как они не обсуждаются, они обязательны; другие требования могут быть менее важны и быть предметом обсуждения для выбора их приемлемого варианта;

в) приоритет –каждое требование должно включать уровень приоритета с тем, чтобы разработчик мог обоснованно составить календарный график разработки;

г) стабильность –некоторые требования могут быть постоянными на протяжении жизненного цикла программного обеспечения; другие могут изменяться на протяжении этого жизненного цикла, поэтому такие непостоянные требования должны быть помечены;

д) источник –источник каждого требования должен быть установлен, это может быть ссылка на внешний документ или на группу пользователей, выработавших требование;

е) ясность –требование является ясным, если оно имеет одну и только одну интерпретацию, т.е. отсутствует двусмысленность, неоднозначное требование должно быть заменено другим, более конкретным;

ж) проверяемость –каждое требование к системе должно быть проверяемым, т.е. должны быть возможны:

· контроль за тем, чтобы требование было включено в проект;

· доказательство того, что требование принято к реализации;

· проверка того, что требование реализовано в программном обеспечении.

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

- полнота;

- корректность;

- дублирование.

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

Корректность. Суть. Не должно быть противоречий между отдельными требованиями, например: один и тот же термин описывает различные состояния и наоборот; описываются одновременно несовместимые процессы; неправильная последовательность процессов.

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

Проект, для которого надо разработать спецификации требований различного назначения.

В табл.1.1. процессы технологического цикла и определяемые задачи

Табл.1.1..

LABA 5

Теоретический материал.