Следующий контрольный список содержит вопросы, позволяющие определить качество требований. Ни книга, ни этот список не научат вас грамотно вырабатывать требования. Используйте его во время конструирования для определения того, насколько прочна земля, на которой вы стоите.
Не все вопросы будут актуальны для вашего проекта. Если вы работаете над
неформальным проектом, над некоторыми вопросами даже не нужно задумываться. Другие вопросы важны, но не требуют формальных ответов. Однако если вы работаете над крупным формальным проектом, вам, наверное, следует ответить на каждый вопрос.
Специфические функциональные требования
- Определены ли все способы ввода данных в систему с указанием источника, точности, диапазона значений и частоты ввода?
- Определены ли все способы вывода данных системой с указанием назначения, точности, диапазона значений, частоты и формата?
- Определены ли все форматы вывода для Web-страниц, отчетов и т. д.?
- Определены ли все внешние аппаратные и программные интерфейсы?
- Определены ли все внешние коммуникационные интерфейсы с указанием протоколов установления соединения, проверки ошибок и коммуникации?
- Определены ли все задачи, в выполнении которых нуждается пользователь?
- Определены ли данные, используемые в каждой задаче, и данные, являющиеся результатом выполнения каждой задачи?
Специфические нефункциональные требования (требования к качеству)
- Определено ли ожидаемое пользователем время реакции для всех необходимых операций?
- Определены ли другие временные параметры, такие как время обработки данных, скорость их передачи и пропускная способность системы?
- Определен ли уровень защищенности системы?
- Определена ли надежность системы, в том числе такие аспекты, как следствия сбоев в ее работе, информация, которая должна быть защищена от сбоев, и стратегия обнаружения и исправления ошибок?
- Определены ли минимальные требования программы к объему памяти и
свободного дискового пространства?
- Определены ли аспекты удобства сопровождения системы, в том числе способность системы адаптироваться к изменениям специфических функций, ОС и интерфейсов с другими приложениями?
- Включено ли в требования определение успеха? Или неудачи?
Качество требований
- Написаны ли требования на языке, понятном пользователям? Согласны ли с этим пользователи?
- Нет ли конфликтов между требованиями?
- Определено ли приемлемое равновесие между параметрами-антагонистами, такими как устойчивость к нарушению исходных предпосылок и корректность?
- Не присутствуют ли в требованиях элементы проектирования?
- Согласован ли уровень детальности требований? Следует ли какое-нибудь требование определить подробнее? Менее подробно?
- Достаточно ли ясны и понятны требования, чтобы их можно было передать независимой группе конструирования? Согласны ли с этим разработчики?
- Каждое ли требование релевантно для проблемы и ее решения? Можно ли проследить каждое требование до его источника в проблемной среде?
- Можно ли протестировать каждое требование? Можно ли будет провести независимое тестирование, которое позволит сказать, выполнены ли все требования?
- Определены ли все возможные изменения требований и вероятность каждого изменения?
Полнота требований
- Указаны ли недостающие требования, которые невозможно определить до начала разработки?
- Полны ли требования в том смысле, что если приложение будет удовлетворять всем требованиям, то оно будет приемлемо?
- Не вызывают ли какие-нибудь требования у вас дискомфорта? Исключили ли вы требования, которые не поддаются реализации и были включены лишь для успокоения клиента или начальника?
© Стив Макконнелл
Комментариев нет:
Отправить комментарий