3. Рекомендации по разработке требований

Не существует определенной методики написания идеальных требований. Качество требований определяется опытом и здравым смыслом. Хорошую спецификацию требований отличает технический стиль изложения и пользовательская терминология, а не компьютерный сленг [4]. Литература по разработке требований содержит большое число рекомендаций.

Приведем некоторые из них.

• Абзацы и предложения должны быть краткими и ясными. Следите за правильностью правописания, грамматики и пунктуации, используйте действительный залог (например, «Система выполнит …», а не «Произойдет …»).

• Используйте термины так, как они определены в словаре, не используйте синонимов и близких по значению слов. Не старайтесь заинтересовать читателя разнообразной лексикой и другими литературными приемами. Помните, что требования, изложенные неясным языком, не поддаются проверке.

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

• Применяйте визуальное представление информации: списки, таблицы, графики, диаграммы и рисунки, чтобы не утомлять читателя большими объемами сплошного текста.

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

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

• Нельзя тратить слишком много времени на попытки сделать требования идеальными. Ваша цель – написать требования, которые достаточно хороши, чтобы разработчики могли приступить к конструированию продукта при приемлемом уровне риска.

При документировании пользовательских требований можно пользоваться следующими рекомендациями:

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

2. Если требование представляет собой взаимодействие (пользователя и системы), то его можно описать с помощью варианта использования.

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

4. Если требование определяет состояния системы, то для его фиксации можно применить конечный автомат.

Рекомендации для документирования системных требований:

1. Перед написанием спецификации системных требований необходимо выбрать стиль описания.

2. Для каждого требования нужно выполнить следующие работы:

• определить требование как функциональное или нефункциональное; оценить сложность функционального требования (требование большое – трудно управлять, очень маленькое – нет смысла рассматривать отдельно);

• сделать требование прослеживаемым и проверяемым (написать проверочный тест), доопределить требование для случая нештатных ситуаций;

• проверить недвусмысленность требования, назначить ему приоритет, проверить полноту и согласованность требования.