Примеры требований: до и после

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

Я высказал свои соображения о проблемах для каждого требования и предложил несколько путей их решения. Дополнительные проверки еще их улучшат, однако на определенном этапе вы должны приступить к непосредственному написанию ПО. Больше примеров по исправлению неудачных требований изложено Hooks и Farry (2001), Florence i(2002), а также Alexander и Stevens (2002).

Пример 1. «Диспетчер фоновых задач обеспечивает сообщение о состоянии через регулярные интервалы, составляющие не менее 60 секунд».

Что понимается под сообщениями о состоянии? При каких условиях и как именно они поставляются пользователю? Как долго они остаются видимыми после их отображения? Продолжительность временного интервала не сформулирована точно, а слово «каждый» только вносит дополнительную неясность. Один из способов оценить требование — проверить, устраивают ли пользователя нелепые, но имеющие право на существование интерпретации этого требования. Если нет, то над требованием необходимо еще поработать. В этом примере интервал должен равняться по крайней мере 60 секундам; таким образом, если сообщение будет появляться раз в год, это нормально? А если промежуток не должен превышать 60 секунд, то будет ли интервал, составляющий одну миллисекунду, слишком коротким? Эти утрированные интерпретации не выходят за рамки первоначального требования, но совершенно очевидно, что пользователь хотел совершенно другого. Из-за этих причин требование нельзя проверить.

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

1. Диспетчер фоновых задач (ДФЗ) отобразит сообщения о состоянии в назначенной области пользовательского интерфейса.

1.1. Сообщения будут обновляться каждые 60 секунд плюс/минус 10 секунд после запуска фоновой задачи.

1.2. Сообщения должны оставаться видимыми постоянно.

1.3. Если взаимодействие с фоновой задачей возможно, то ДФЗ отобразит процент выполнения фоновой задачи.

1.4. По завершению фоновой задачи ДФЗ отобразит сообщение «Выполнено».

1.5. Если выполнение фоновой задачи остановлено, ДФЗ отобразит соответствующее сообщение.

Я разделили это требование на нескольких дочерних, потому что для каждого понадобится отдельный вариант тестирования, кроме того, так каждое проще отслеживать. Если несколько требований объединено в один абзац, то при сборке или тестировании существует опасность пропуска одного из них. В измененном требовании не указан способ отображения сообщения о состоянии. Это проблема проектирования; если вы сейчас определите ее здесь, то разработчики воспримут ее как ограничение, а это может их расстроить. Кроме того, в этом случае вряд ли можно рассчитывать на оптимальный продукт.

Пример 2. «Редактор ХМL должен моментально переключаться между режимами отображения и сокрытия непечатаемых символов».

Компьютеры не могут сделать что-либо моментально, поэтому это требование невыполнимо. Кроме того, это требование неполное, поскольку в нем не указана условие переключения. Выполняет ли это изменение при определенных условиях само ПО или это происходит по инициативе пользователя? Какая часть документа изменяется: выделенный фрагмент текста, весь документ, текущая страница или что-то еще? Какие именно непечатаемые символы: скрытый текст, управляющие символы, тэги разметки или что-то еще? До тех пор пока на эти вопросы не будут получены ответы, требование будет невозможно проверить. Вот как это требование можно улучшить:

«Пользователь сможет переключать отображение и сокрытие всех тэгов XML в редактируемом документе с помощью активации механизма определенного триггера. Отображение должно изменяться в течение 0,1 секунды или менее».

Вот теперь стало ясно, что непечатаемые символы — это тэги разметки XML. Мы знаем, что пользователь инициирует изменение изображения, но требование не ограничивает разработку определением точного механизма. Мы также добавили требование производительности, которое определяет, как быстро отображение должно изменяться. «Моментально» означает «моментально для зрения человека», что вполне достижимо на достаточно быстром компьютере.

Пример 3. «Анализатор XML выведет отчет об ошибках в разметке, с помощью которого даже пользователи, мало знакомые с языком XML, смогут быстро устранить ошибки».

Многозначное слово «быстро» относится к действию, выполняемому человеком, а не анализатором. Из-за этого недостаточного объяснения сообщение об ошибке определено не полностью, кроме того, мы не знаем, когда создается этот отчет. Как проверить это требование? Найдите какого-нибудь новичка в XML и посмотрите, сможет ли он быстро исправить ошибки с помощью этого отчета?

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

«1. После того, как XML Parser полностью проанализирует файл, он генерирует отчет об ошибках, в котором указан номер строки и текст любых XML-ошибок, обнаруженных в анализируемом файле, а также описание каждой найденной ошибки.

2. Если никаких ошибок в разметке не было найдено, отчет не генерируется.»

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

Пример 4, «Если возможно, номера счетов следовало бы проверить, по списку корпоративных счетов».

Что означает «если возможно»? Технически осуществимо? Или когда доступен основной список счетов во время запуска? Если вы не уверены, можно ли реализовать функцию, сделайте пометку «TBD», чтобы указать, что эта проблема еще не решена. После проверки одно из двух будет ликвидировано — либо пометка «TBD», либо требование. В требовании не указано, что произойдет, если проверка пройдет успешно или окончится неудачей. Избегайте неточных слов вроде «следовало бы». Некоторые авторы требований пытаются выразить тонкие различия, используя «будет», «следовало бы» и «возможно», чтобы подчеркнуть значимость. Я предпочитаю использовать «будет» или «должен» как ясное указание на цель требования и приоритеты. Вот как выглядит исправленный вариант требования.

«В момент ввода номера счета система проверит его по основному корпоративному списку счетов. Если номер счета в списке не найден, система отобразит сообщение об ошибке и не примет заказ».

Связанное требование будет относиться к условию исключения: основной список счетов не доступен во время проверки достоверности.

Пример 5. «В редакторе не будет функций поиска и замены, результаты которых могут быть катастрофичными».

Понятие «катастрофичные результаты» можно интерпретировать по-разному. Непреднамеренное глобальное изменение может обернуться катастрофой, если пользователь не обнаружит ошибку или не может ее исправить. Будьте благоразумны при составлении обратных требований, описывающих, что система не будет делать. Основная забота в этом примере — защита содержимого файла от непреднамеренных повреждений или потерь. Возможно, настоящие требования выглядят вот так.

«1. Редактор будет запрашивать подтверждения от пользователя, где тот должен подтвердить глобальные изменения текста, удаления и вставки, которые могут привести к потере данных.

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

Пример 6. «Испытательный прибор позволит пользователю легко подключить дополнительные компоненты, в том числе импульсный генератор, вольтметр, измеритель емкости и нестандартные зондовые платы».

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

«1. Испытательное устройство содержит USB-порт, чтобы пользователь смог подключить любое измерительный прибор, у которого есть USB-подключение.

2. USB-порт будет установлен на передней панели для того, чтобы позволить квалифицированному оператору подключить измерительный прибор за 15 секунд или менее.»

Словарь данных

Давным-давно я вел проект, в котором три программиста иногда небрежно использовали различные имена, длину переменных и критерий достоверности для одного и того же элемента. Результат очевиден: путаница с настоящим определением, повреждение данных и головная боль при обслуживании. Мы пострадали из-за отсутствия словаря данных (data dictionary) — общего хранилища, где определены значение, тип данных, длина, формат, необходимая степень точности идопустимые диапазоны значений или список значений всех элементов данных и атрибутов, используемых в приложении.

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

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

Элементы в словаре данных представлены с помощью простой нотации (DeMarco, 1979; Robertson и Robertson, 1994). Определяемый элемент расположен слева от знака равенства, а его определение — справа. Так определяются простейшие элементы данных, объединение нескольких элементов данных в структуры, необязательные элементы данных, итерация (повтор) элемента данных и список значений элемента данных. Следующие примеры взяты из проекта Chemical Tracking System (ну откуда же еще!).

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

Request ID = * 6-значный, сгенерированный системой, последовательный номер, состоящий из целого числа, начинающийся с 1, уникальным образом идентифицирующий каждый запрос *

Структура. Структура данных или записей содержит несколько элементов данных. Если элемент в структуре данных является необязательным, поставьте его в скобки:

Запрошенный химикат=ID химиката

+ Количество контейнеров

+ Класс

+ Объем

+ Единицы объема

+ (Поставщик)

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

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

3anpoc=ID Запроса

+ Дата запроса

+ Номер счета

+1:10(3апрошенный химикат)

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

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

Единицы количества = [«граммы» | «килограммы» | «миллиграммы» | «каждый»]

* текстовая строка, состоящая из 9 символов, указывающая

единицы, связанные с количеством запрошенного химиката *

Эта запись указывает на то, что существует только четыре допустимых значения для текстовой строки Единицы количества. Комментарий, ограниченный звездочками, — это текстовое определение элемента данных.

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