Существуют четыре способа записи спецификаций (см. табл. 2.1).
Таблица 2.1 – Способы записи спецификаций требований
| Структурирован-ный естественный язык | Использование стандартных форм и шаблонов для написания спецификации. |
| Языки описания программ | Использование специальных структурированных языков, подобных языкам программирования, где спецификация требований строится на основе выбранной операционной модели системы. |
| Графические нотации | Графический язык, использующий для описания функциональных требований диаграммы и блок-схемы, дополненные текстовыми пояснениями. |
| Математические спецификации | Это системы нотаций, основанные на математических концепциях, таких, как теория конечных автоматов или теория множеств. Это формализованная однозначная и лишенная двусмысленности запись системных требований. |
В спецификацию системных требований входит также спецификация интерфейсов.
Различают три типа специфицируемых интерфейсов.
4. Процедурные интерфейсы, когда существующие подсистемы предлагают набор сервисов, доступных посредством вызываемой интерфейсной процедуры.
5. Структуры (интерфейсные форматы) данных, которые пересылаются от одной подсистемы к другой.
6. Специальные представления данных, например в виде упорядоченной последовательности двоичных разрядов.
Атрибуты требований
Каждое требование должно включать семь атрибутов, перечисленные ниже:
а) идентификатор – каждое требование должно включать идентификатор для облегчения трассировки требований при последовательном выполнении фаз проекта;
б) необходимость – каждое существенное требование должно быть помечено особо, так как они не обсуждаются, они обязательны; другие требования могут быть менее важны и быть предметом обсуждения для выбора их приемлемого варианта;
в) приоритет –каждое требование должно включать уровень приоритета с тем, чтобы разработчик мог обоснованно составить календарный график разработки;
г) стабильность –некоторые требования могут быть постоянными на протяжении жизненного цикла программного обеспечения; другие могут изменяться на протяжении этого жизненного цикла, поэтому такие непостоянные требования должны быть помечены;
д) источник –источник каждого требования должен быть установлен, это может быть ссылка на внешний документ или на группу пользователей, выработавших требование;
е) ясность –требование является ясным, если оно имеет одну и только одну интерпретацию, т.е. отсутствует двусмысленность, неоднозначное требование должно быть заменено другим, более конкретным;
ж) проверяемость –каждое требование к системе должно быть проверяемым, т.е. должны быть возможны:
· контроль за тем, чтобы требование было включено в проект;
· доказательство того, что требование принято к реализации;
· проверка того, что требование реализовано в программном обеспечении.
Но требования к программному обеспечению должны характеризоваться еще следующими тремя категориями:
- полнота;
- корректность;
- дублирование.
Полнота. Суть. Нет неучтенных требований заказчика; для каждого возможного набора входов данных или состояний должен быть определен процесс (т.е. последовательность изменений).
Корректность. Суть. Не должно быть противоречий между отдельными требованиями, например: один и тот же термин описывает различные состояния и наоборот; описываются одновременно несовместимые процессы; неправильная последовательность процессов.
Дублирование. Суть. Не желательно дублировать требования т.к. при его изменении, модификации или уточнении могут быть внесены поправки не во все места их записи.
Проект, для которого надо разработать спецификации требований различного назначения.
В табл.1.1. процессы технологического цикла и определяемые задачи
Табл.1.1..
| Процессы | Задачи |
| Управление продуктом | Общие цели проекта; выявление нужд и требований заказчика; документ общего описания и рамок проекта. |
| Управление программой | Цели дизайна; концепция решения; структура проекта. |
| Разработка | Прототипирование; анализ технологических возможностей; анализ осуществимости. |
| Удовлетворение потребителя | Необходимые эксплуатационные характеристики решения и их влияние на его разработку. |
| Тестирование | Стратегии тестирования; критерии приемлемости, их влияние на разработку решения. |
| Управление выпуском | Требования внедрения и их влияние на разработку решения; требования сопровождения. |
LABA 5
Теоретический материал.