1) Неформально т.Е. Словесно в свободном формате прописанные требования в соответствии с приведенной классификацией. Лабораторная работа 3. Специфицирование требований

Цель: Выполнить формальное описание требований

Повысить уровень информативности требований к ПО возможно с помощью реестра акторов и вариантов использования.

1. 1. Глоссарий

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

Пример:

1) База данных;

2) Интерфейс;

3) Пользователь;

4) Датчики;

5) Система

6) Прокатка

7) Станок

8) Отчет

9) Оборудование

10) Запрос

2. 2. Акторы и варианты использования

Результатом выявления требований является реестр требований.

Самым популярным способом повышения информативности требований является оформление их в виде вариантов использования (use case).

Актор - это некто или нечто, обладающее активностью по отношению к программной системе.

Например:

1) Пользователь, набирающий текст.

2) Датчик, сообщающий, что выполнен этап сборки кузова;

3) Система управления выводом, работающая с целью вывода и базой правил в экспертной системе;

И т.д.

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

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

3. 3. Спецификация варианта использования

Существуют различные шаблоны описания вариантов использования:

• Таблица в две колонки,

• Таблица в три колонки,

1. 3.3. Табличные представления варианта использования

См. ниже таблицу.

Отчет:

1) Глоссарий предметной области (10-15 терминов).

2) Акторы для:

- бизнес требований;

- требований пользователя;

- функциональных требований поведения

(всего 15-20 акторов).

3) Таблица вариантов использования в две колонки для всех перечисленных выше требований.

Таблица 8.1. Таблица в 2 колонки:
Актор	Действие
Система	Загрузка пользователем системы.
Запрос	Чтение информации по запросу пользователя.
Станок	Запуск подачи металла станком.
Прокатка	При получении металла, обработка металла, т.е. - прокатка оборудованием.
Оборудование
	Сообщение о готовности продукции, приступление к изготовлению оборудованием самой детали.
Отчет
	Отчет о готовности. Сообщить пользователю о конечном результате.

Лабораторная работа 4. Анализ свойств требований.

Цель: Выполнить анализ свойств по ряду требований

Свойства требований подвергаются анализу на этапе проверки требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.

Имеются такие типичные свойства требований к программной системе:

• полнота,

• ясность,

• корректность,

• согласованность,

• верифицируемость,

• необходимость,

• полезность при эксплуатации,

• осуществимость,

• модифицируемость,

• трассируемость,

• упорядоченность по важности и стабильности,

• наличие количественной метрики.

Большинство из этих свойств раскрыто в первом разделе стандарта IEEE.