3. Предварительные условия, связанные с выработкой требований

Важность явного набора требований объясняется несколькими причинами:

- Явные требования помогают гарантировать, что функциональность системы определяется пользователем, а не программистом. Если требования сформулированы явно, пользователь может проанализировать и утвердить их.

- Наличие явных требований помогает избегать споров.

- Внимание к требованиям помогает свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соответствовал измененным требованиям.

Требования подробно описывают, что должна делать программная система, а их

выработка - первый шаг к решению проблемы.

Среди специфических функциональных требований должны быть определены:

- все способы ввода и вывода данных в систему с указанием источника, точности, диапазона значений и частоты ввода;

- все форматы вывода для Web-страниц, отчетов;

- внешние аппаратные и программные интерфейсы, внешние коммуникационные интерфейсы с указанием протоколов установления соединения, проверки ошибок и коммуникации;

- задачи, в выполнении которых нуждается пользователь;

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

Среди специфических нефункциональных требований (требований к качеству) должны быть определены:

- ожидаемое пользователем время реакции для всех необходимых операций;

- другие временные параметры, такие как время обработки данных, скорость их передачи и пропускная способность системы;

- уровень защищенности системы;

- надежность системы, в том числе такие аспекты, как следствия сбоев в ее работе;

- информация, которая должна быть защищена от сбоев, и стратегия обнаружения и исправления ошибок;

- минимальные требования программы к объему памяти и свободного дискового пространства;

- аспекты удобства сопровождения системы, в том числе способность системы адаптироваться к изменениям специфических функций, ОС и интерфейсов с другими приложениями.

Качество требований:

1. Требования должны быть написаны на языке, понятном пользователям.

2. Между требованиями не должно быть конфликтов.

3. Должно быть определено приемлемое равновесие между параметрами-антагонистами, такими как устойчивость к нарушению исходных предпосылок и корректность.

4. Не должны присутствовать в требованиях элементы проектирования.

5. Должен быть согласован уровень детальности требований.

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

7. Каждое требование должно быть релевантно для проблемы и ее решения.

8. Должно быть возможно протестировать каждое требование, чтобы можно было провести независимое тестирование, которое позволит сказать, выполнены ли все требования.

9. Должны быть определены все возможные изменения требований и вероятность каждого изменения.

Полнота требований:

1. Должны быть указаны недостающие требования, которые невозможно определить до начала разработки.

2. Требования должны быть полны в том смысле, что если приложение будет удовлетворять всем требованиям, то оно будет приемлемо.

3. Требования не должны вызывать у вас дискомфорта. Должны быть исключены требования, которые не поддаются реализации и были включены лишь для успокоения клиента или начальника.