2.10. Уточнение нефункциональных требований
Детализация требования “удобство использования (практичность)”:
определимость пригодности, то есть ПП должен удовлетворять представлениям пользователям о том, что он может с ним делать,
изучаемость, то есть легкость изучения ПП (легкость вхождения),
управляемость, то есть что-то можно изменить в ПП,
защита от ошибки пользователя,
эстетика пользовательского интерфейса - дело субъективное,
доступность, то есть им можно реально воспользоваться даже на старой технике.
2.11. Стандарты практичности (usability)
Common User Access (CUA) — IBM.
Команды меню, требующие уточнения параметров выполняемого действия, заканчиваются многоточием («...»).
В программах есть встроенная справочная система, вызываемая из меню «Справка», расположенного в конце строки меню; контекстно-зависимая справка может вызываться клавишей F1.
Первое меню должно называться «Файл» и должно содержать операции по работе с файлами (создать, открыть, сохранить, сохранить как) и команду выхода.
Следующее меню «Правка» содержит команды отмены, повтора, вырезания, копирования, вставки и удаления.
Команда «вырезать» выполняется нажатием Shift+Del, «копировать» — Ctrl+Ins, а «вставить» — Shift+Ins.
2.12. Бизнес-правила
Типы бизнес-правил:
факты,
ограничения,
активаторы операций,
выводы,
вычисления.
Источники бизнес-правил:
законы государства,
корпоративная политика,
стандарты и нормативные документы,
формулы,
модели данных.
2.12.1. Примеры бизнес-правил
Факт:
— Каждый товар должен иметь штрих-код.
Ограничение:
— Доставка всех заказов должна выполняться между 10:00 и 14:00 по местному времени.
Активатор операции:
— После добавления покупателем товара в корзину предложить ему приобрести сопутствующие товары.
Вывод:
— Если товар данного вида на складе отсутствует, присвоить данному товару статус «нет в наличии».
Вычисления:
— Цена единицы товара снижается на 10 % при заказе более 6 единиц данного товара.
Лекция 3. Анализ и моделирование требований к по
3.1. Атрибуты качества требований
Полнота описания (отдельного требования, задачи в целом). Все нюансы должны быть выявлены при сборе информации у потребностях пользователя.
Необходимость (обоснованность). Показывает, что требование может выйти за границы нашего ПП, нашей концепции.
Осуществимость. Нужно реально оценивать реализацию требования.
Корректность (в плане написания слов, например, нельзя «Защита от дурака»).
Однозначность толкования. Не должно быть двусмысленности.
Непротиворечивость.
Проверяемость (требования должны быть проверяемы).
Приоритет. На основе приоритета будут выпускаться версии, выставляется приоритеты экспертами. Чем выше приоритет, тем первее реализация в версии.
Статус.
3.2. Статус требования
Порядок такой, 5 вариант используется не обязательно:
1. Предложено
2. Одобрено или отклонено (если отклонено, то удаляется, дальше не продолжается цепочка)
3. Реализовано
4. Проверено
5. Удалено (опционально)
3.3. Полный набор требований по
Минимальные группы требований для ПО:
Вводы системы
Выводы системы
Функции системы
Атрибуты системы
Атрибуты системного окружения (используются диаграммы: контекстная и Use Case)
Не включаются в полный набор требований ПО:
Календарные планы
Выделенные средства
Тесты