Принципы создания требований

Не существует выверенного способа написания идеальных требований, а лучший учитель — это опыт, который нарабатывается со временем. Безупречную документацию по требованиям отличает технический стиль изложения и пользовательская терминология, а не компьютерный сленг. Kovitz (1999) предлагает множество рекомендаций и примеров на эту тему. Вот некоторые из них:

· используйте полные предложения, с правильной грамматикой, правописанием и пунктуацией. Предложения и абзацы должны быть краткими и ясными;

· используйте действительный залог (например, «Система сделает то-то», а не «Произойдет то-то);

· последовательно используйте термины и именно так, как они определены в словаре. Остерегайтесь синонимов и слов, близких по значению. Не следует в спецификации требований к ПО пытаться разнообразить лексику, чтобы заинтересовать читателя;

· нечеткие требования верхнего уровня следует детализировать таким образом, чтоб они стали абсолютно ясны;

· требования следует излагать последовательно, например «Система будет» или «Пользователь будет», затем — активный глагол, а после — наблюдаемый результат. Укажите инициирующие условия или действия, вследствие которых система ведет себя определенным образом. Например, «Если запрошенный химикат найден на складе химикатов, система отобразит список всех хранимых на складе контейнеров с указанным химикатом». Вы можете использовать «должно» как синоним «будет», однако следует избегать «следовало бы», «может», «можно было бы» и аналогичных слов, из которых не ясно, необходимо ли действие;

· при указании требования в форме «Пользователь будет...» идентифицируйте определенного исполнителя (например, «Покупатель будет...»);

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

· подчеркните наиболее значимые фрагменты информации. Здесь годятся: графики, последовательности, в которых первый элемент подчеркивается, повторы, пустое пространство и визуальный контраст, например затенения (Kovitz, 1999);

· требования, изложенные неясным языком, не поддаются проверке, поэтому избегайте двусмысленных и субъективных терминов, В табл. 10-1 перечислены некоторые из них, а также приводятся рекомендации, как исправить такие неясности.

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

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

Создатели документации зачастую тратят массу сил, чтоб «поймать» нужный уровень детализации. Попробуйте отдельно описать требования, которые можно протестировать. Если вам удастся придумать несколько вариантов тестирования, значит, необходимый уровень детализации достигнут. Если ваши тесты многочисленны и разнообразны, вероятно, несколько требований соединены вместе; их следует разделить на более простые. Тестируемые требования были предложены в качестве атрибута размера ПО (Wilson, 1995).

При написании требований соблюдайте уровень детализации. Мне приходилось видеть в одной и той же спецификации положения, которые значительно варьировались в их границах. Например, «Комбинация клавишей Ctrl+S будет интерпретироваться как «Сохранить файл» и «Комбинация клавишей Ctrl+P будет интерпретироваться как «Печать файла» считались отдельными требованиями, а «Продукт будет реагировать на команды редактирования, введенные голосом» описывалось как целая подсистема (или даже продукт!), а не одно функциональное требование.

Избегайте длинных повествовательных абзацев, которые содержат несколько требований. Наличие в требовании таких слов, как «и», «или» и «также», предполагает, что несколько требований могли быть объединены. Это не означает, что вы не можете использовать союз «и», но если вы делаете это, проверяйте, соединяет ли он две части одного требования или два отдельных требования. Никогда не используйте «и/или» в требованиях; это оставляет читателю свободу маневра. Такие выражения, как «пока не» и «кроме» также указывают на наличие нескольких требований: «Кредитная карточка покупателя будет считаться действительной для платежей до тех пор, пока не истечет ее срок действия». Разделите это положение на два — для двух условий, когда срок действия кредитной карты истек, и когда она действительна.

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

Попытайтесь найти наиболее эффективный метод представления каждого требования. Как-то я проверял спецификацию требований к ПО, в которой содержался набор требований, предлагаемый в качестве образца: «Текстовый редактор сможет проанализировать документы следующего <формат>, определяющих постановления следующей <юрисдикции> ».Предлагалось три возможных значения <формат> и четыре возможных значения <уровень юрисдищии> для двенадцати схожих требований. Однако из этих двенадцати одного не хватало, а одно повторялось. Найти ошибку можно было одним единственным образом — составить таблицу всех возможных вариантов и проверить их. Ошибку удалось бы предотвратить, если требования в спецификации были составлены по образу и подобию табл. 10-2. Требования более высокого уровня могут звучать так: «ТР-13 Текстовый редактор сможет провести анализ документов нескольких форматов, определяющих постановления на уровнях юрисдикции, как показано в табл. 10-2 ». Если у какой-либо комбинации нет соответствующего функционального требования, укажите в ячейке таблицы Н/П (неприменимо).

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