2.3. Характеристики классов пользователей
Название класса пользователей.
Привилегированный и непривилегированный. Непривилегированный - нежелательный пользователь, например примеру, хакер.
Численность пользователей. Помогает расставить приоритеты для функций.
Описание типичного представителя класса пользователей:
— поведение,
— выполняемые операции, решаемые задачи,
— квалификация в предметной области,
— опыт и навыки работы с информационной системой,
— предпочтения. Оказывает влияние на нефункциональные требования,
— раздражающие факторы. Оказывает влияние на нефункциональные требования.
2.4. Представление системных событий и реакции на них
ID |
Событие |
Исходное состояние |
Реакция системы |
1 |
Нажать на кнопку Вкл. |
Кондиционер включен, пульт в состоянии «включен» |
Кондиционер выключится |
2 |
Нажать на кнопку Вкл. |
Кондиционер выключен, пульт в состоянии «выключен» |
Кондиционер включится |
3 |
Нажать на кнопку Вкл. |
Кондиционер выключен, пульт в состоянии «включен» |
Кондиционер в прежнем состоянии |
4 |
Нажать на кнопку Вкл. |
Кондиционер включен, пульт в состоянии «выключен» |
Кондиционер в прежнем состоянии |
2.5. CRC-карточки
CRC: Class — Responsibility — Collaboration
(Класс — обязанность — взаимодействие)
Основное внимание в этом методе уделяется внешнему поведению объекта. Классы должны реагировать адекватно.
Итог: выявление ошибочных или отсутствующих требований.
2.5.1. Пример crc-карточки
2.6. Прототипы (макеты) по
Делает для того, чтобы программисты правильно все поняли.
Задачи:
— уточнение формулировки требования,
— исследование альтернативных решений,
— создание готового программного продукта.
Варианты прототипов:
— горизонтальные (интерфейсы пользователя),
— вертикальные (структура ПО, временнЫе характеристики, алгоритмы, структура БД).
Прототипы одноразовые и эволюционные.
2.7. Представление требований пользователя на основе варианта использования
Идентификатор;
Имя (глагол+объект);
Источник (автор);
Дата создания;
Основное действующее лицо;
Дополнительно действующее лицо;
Триггер (действие, инициирующее вариант использования);
Предварительные условия (начальное состояние);
Выходные условия;
Нормальное и альтернативное направление варианта использования;
Исключения;
Приоритет;
Частота использования;
Бизнес-правила;
Специальные требования (Другая информация);
Предположения.
2.8. Процессы обработки данных варианта использования
Этим занимается системный аналитик.
Составить список функциональных требований должен быть параллельно продублирован со списком тестов. Сколько функц. требований столько (как минимум) и тестов.
Составить предварительный список моделей анализа. Анализируются данные и алгоритмы (как минимум), будут представлены в виде диаграмм.
Составить словарь данных. Термины предметной области должны быть понятны программистам. В результате будет сформулирован список функциональных требований.
2.9. Нефункциональные требования
нефункциональные = эксплуатационные (качественные). С точки зрения ПП. Каждое требование также имеется детализация.
функциональная пригодность (functional suitability),
уровень производительности (performance efficiency),
аппаратная и программная совместимость (compatibility),
удобство использования, практичность (usability),
надежность (reliability),
защищенность (security),
сопровождаемость (maintainability),
переносимость (portability).
ГОСТ Р ИСО/МЭК 25010-2015 Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов.