Не существует выверенного способа написания идеальных требований, а лучший учитель — это опыт, который нарабатывается со временем. Безупречную документацию по требованиям отличает технический стиль изложения и пользовательская терминология, а не компьютерный сленг. Kovitz (1999) предлагает множество рекомендаций и примеров на эту тему. Вот некоторые из них:
· используйте полные предложения, с правильной грамматикой, правописанием и пунктуацией. Предложения и абзацы должны быть краткими и ясными;
· используйте действительный залог (например, «Система сделает то-то», а не «Произойдет то-то);
· последовательно используйте термины и именно так, как они определены в словаре. Остерегайтесь синонимов и слов, близких по значению. Не следует в спецификации требований к ПО пытаться разнообразить лексику, чтобы заинтересовать читателя;
· нечеткие требования верхнего уровня следует детализировать таким образом, чтоб они стали абсолютно ясны;
· требования следует излагать последовательно, например «Система будет» или «Пользователь будет», затем — активный глагол, а после — наблюдаемый результат. Укажите инициирующие условия или действия, вследствие которых система ведет себя определенным образом. Например, «Если запрошенный химикат найден на складе химикатов, система отобразит список всех хранимых на складе контейнеров с указанным химикатом». Вы можете использовать «должно» как синоним «будет», однако следует избегать «следовало бы», «может», «можно было бы» и аналогичных слов, из которых не ясно, необходимо ли действие;
· при указании требования в форме «Пользователь будет...» идентифицируйте определенного исполнителя (например, «Покупатель будет...»);
|
|
· применяйте списки, рисунки, графики и таблицы, чтобы представить информацию визуально. Читателей утомляет большой объем сплошного текста;
· подчеркните наиболее значимые фрагменты информации. Здесь годятся: графики, последовательности, в которых первый элемент подчеркивается, повторы, пустое пространство и визуальный контраст, например затенения (Kovitz, 1999);
· требования, изложенные неясным языком, не поддаются проверке, поэтому избегайте двусмысленных и субъективных терминов, В табл. 10-1 перечислены некоторые из них, а также приводятся рекомендации, как исправить такие неясности.
| Ловушка Оценка качества требований зависит от того, кто их оценивает. Аналитик может верить, что создал документ абсолютно ясный, безо всяких неясностей и проблем. Однако если у читателей возникли вопросы, значит, требуется доработка. |
Таблица 10-1. Неоднозначные термины, которых следует избегать в спецификаций к требованиям
| Неоднозначные термины | Способы их улучшения |
| Приемлемый, адекватный | Определите, что понимается под приемлемостью и как система это может оценить |
| Практически выполнимо | Не заставляйте разработчиков определять, что под этим понимается. Поставьте пометку «TBD» и определите дату, к которой эту проблему следует разрешить |
| По меньшей мере, как минимум, не более чем, не должно превышать | Укажите минимальное и максимальное допустимые значения |
| Между | Определите, указаны ли конечные точки |
| Зависит от | Определите природу зависимости. Обеспечивает ли другая система ввод данных в вашу систему, надо ли установить другое ПО до запуска вашей системы и зависит ли ваша система от другой при выполнении определенных расчетов или служб? |
| Эффективный | Определите, насколько эффективно система использует ресурсы, насколько быстро она выполняет определенные операции и насколько она проста в обращении |
| Быстрый, моментальный | Укажите минимальную приемлемую скорость, при которой система выполняет определенное действие |
| Гибкий | Опишите способы изменения системы в ответ на изменения условий или бизнес-потребностей |
| Улучшенный, лучший, более быстрый, превосходный | Определите количественно, насколько лучше или быстрее стали показатели в определенной функциональной области |
| Включает; включает в себя, но не огранечен этим; и т.д.; и т.п.; такой как | Список элементов должен включать все возможности. В противном случае его нельзя использовать при разработке или тестировании |
| Максимизируйте, минимизируйте, оптимизируйте | Укажите минимальное и максимальное допустимые значения определенного параметра |
| Обычно, в идеальном варианте | Также опишите поведение системы при нештатных или неидеальных условиях |
| Необязательно | Укажите, кто делает выбор: системы, пользователь или разработчик |
| Разумный, при необходимости, при соотвествующих условиях | Объясните, как это выполнить |
| Устойчивый к сбоям | Определите, как система должны обрабатывать исключения и реагировать на неожиданные условия работы |
| Цельный, прозрачный, элегантный | Выразите ожидания пользователя, применяя характеристики продукта, которые можно наблюдать |
| Несколько | Укажите сколько или задайте минимальную и максимальную границы диапазона |
| Не следует | Старайтесь формулировать требования в позитивной форме, описывая, что именно система будет делать |
| Реальный | Поясните этот термин |
| Достаточный | Укажите, какая степень чего-либо свидетельствует одостаточности |
| Поддерживает, позволяет | Дайте точное определение, какие действия система будет выполнять, поддерживая конкретную возможность |
| Дружественный, простой, легкий | Опишите системные характеристики, которые будут отвечать потребностям пользователей и его ожиданиям, касающимся легкости и простоты применения продукта |
|
|
|
|
Составляйте требования настолько подробно, чтобы при удовлетворении требования задача клиента была бы выполнена, однако избегайте ненужных ограничений разработки. Требования должны быть сформулированы достаточно подробно, чтобы риск непонимания был минимальным, для этого необходимо учесть знания и опыт разработчиков. Если разработчики предлагают несколько способов удовлетворения требования и все они приемлемы, значит, особенности продукта и детализация изложения выбраны верно. Точно сформулированные требования повышают вероятность того, что ожидания клиентов будут реализованы; менее строгие формулировки дают разработчикам больше свободы для интерпретаций. Если разработчику по составленной спецификации не удается абсолютно ясно представить себе ожидания клиентов, следует включить дополнительную информацию, чтобы снизить риск последующих исправлений.
Создатели документации зачастую тратят массу сил, чтоб «поймать» нужный уровень детализации. Попробуйте отдельно описать требования, которые можно протестировать. Если вам удастся придумать несколько вариантов тестирования, значит, необходимый уровень детализации достигнут. Если ваши тесты многочисленны и разнообразны, вероятно, несколько требований соединены вместе; их следует разделить на более простые. Тестируемые требования были предложены в качестве атрибута размера ПО (Wilson, 1995).
При написании требований соблюдайте уровень детализации. Мне приходилось видеть в одной и той же спецификации положения, которые значительно варьировались в их границах. Например, «Комбинация клавишей Ctrl+S будет интерпретироваться как «Сохранить файл» и «Комбинация клавишей Ctrl+P будет интерпретироваться как «Печать файла» считались отдельными требованиями, а «Продукт будет реагировать на команды редактирования, введенные голосом» описывалось как целая подсистема (или даже продукт!), а не одно функциональное требование.
Избегайте длинных повествовательных абзацев, которые содержат несколько требований. Наличие в требовании таких слов, как «и», «или» и «также», предполагает, что несколько требований могли быть объединены. Это не означает, что вы не можете использовать союз «и», но если вы делаете это, проверяйте, соединяет ли он две части одного требования или два отдельных требования. Никогда не используйте «и/или» в требованиях; это оставляет читателю свободу маневра. Такие выражения, как «пока не» и «кроме» также указывают на наличие нескольких требований: «Кредитная карточка покупателя будет считаться действительной для платежей до тех пор, пока не истечет ее срок действия». Разделите это положение на два — для двух условий, когда срок действия кредитной карты истек, и когда она действительна.
Избегайте излишних положений о требованиях. Повторяя требований в нескольких местах спецификации требований к ПО, вы облегчаете чтение документа, но затрудняете его поддержку. Одинаковые требования придется изменять одновременно, в противном случае возникнет несогласованность. Перекрестные ссылки на связанные между собой элементы в спецификации помогут вам синхронизировать последние при внесении изменений. Сохраняя отдельные требования в средстве управления требованиями или в базе данных только один раз, вы решите проблему избыточности и упростите повторное использование требований, общих для нескольких проектов.
Попытайтесь найти наиболее эффективный метод представления каждого требования. Как-то я проверял спецификацию требований к ПО, в которой содержался набор требований, предлагаемый в качестве образца: «Текстовый редактор сможет проанализировать документы следующего <формат>, определяющих постановления следующей <юрисдикции> ».Предлагалось три возможных значения <формат> и четыре возможных значения <уровень юрисдищии> для двенадцати схожих требований. Однако из этих двенадцати одного не хватало, а одно повторялось. Найти ошибку можно было одним единственным образом — составить таблицу всех возможных вариантов и проверить их. Ошибку удалось бы предотвратить, если требования в спецификации были составлены по образу и подобию табл. 10-2. Требования более высокого уровня могут звучать так: «ТР-13 Текстовый редактор сможет провести анализ документов нескольких форматов, определяющих постановления на уровнях юрисдикции, как показано в табл. 10-2 ». Если у какой-либо комбинации нет соответствующего функционального требования, укажите в ячейке таблицы Н/П (неприменимо).
Таблица 10-2. Образец табличного формата для перечисления номеров требований, предлагаемых в качестве образца