Переход от варианта использования к функциональным требованиям
Бизнес-требование: 3. сократить затраты на закупку химикатов на 25 % к концу первого года эксплуатации системы.
Вариант использования: сотрудник, размещающий заказ на химикат, указывает в заказе необходимый химикат, вводя его название или идентификатор или выбирая эти данные из предложенного системой списка. Система выполняет заказ, предлагая контейнер с химикатом со склада или предоставляя возможность заказать его у поставщика.
Функциональное требование в спецификации: 3.1. Обработка заказа сотрудника на химикат.
3.1.1.Система получает информацию о том, что сотрудник сделал заказ на определенный химикат.
3.1.2.Если на складе есть контейнеры с химикатом, на который поступил заказ, система отобразит список доступных контейнеров.
3.1.3.Пользователь выберет один из контейнеров или попросит разместить заказ нового контейнера у поставщика. . . .
11
Пример логической модели данных
12
Словарь данных
13
Проверка спецификации
Формы проверки:
неофициальное рецензирование,
официальное рецензирование (экспертиза). Цели проверки требований:
соответствие требований бизнес-требованиям,
правильность и полнота описания требования,
проверяемость требования (разработка теста на основе требования),
проверка возможности реализации требования (прототип).
14
Экспертиза
Участники:
разработчики документации требований (бизнесаналитик),
люди, послужившие источником проверяемых требований (пользователь),
люди, которые будут работать с проверяемыми требованиями (тестировщик, разработчик),
люди, отвечающие за работу систем, взаимодействующих с системой, требования которой проверяются.
Роли экспертов:
автор спецификации,
координатор,
читатель, секретарь.
15