Что понимается под сообщениями о состоянии? При каких условиях и как именно они поставляются пользователю? Как долго они остаются видимыми после их отображения? Продолжительность временного интервала не сформулирована точно, а слово «каждый» только вносит дополнительную неясность. Один из способов оценить требование — проверить, устраивают ли пользователя нелепые, но имеющие право на существование интерпретации этого требования. Если нет, то над требованием необходимо еще поработать. В этом примере интервал
должен равняться по крайней мере 60 секундам; таким образом, если сообщение будет появляться раз в год, это нормально? А если промежуток не должен превышать 60 секунд, то будет ли интервал, составляющий одну миллисекунду, слишком коротким? Эти утрированные интерпретации не выходят за рамки первоначального требования, но совершенно очевидно, что пользователь хотел совершенно другого.
Из-за этих причин требование нельзя проверить. А вот возможные способы исправления недостатков этого требования, которыми вы можете воспользоваться после того, как получите дополнительную информацию от клиента:
1. Диспетчер фоновых задач (ДФЗ) отобразит сообщения о состоянии в назначенной области пользовательского интерфейса.
1.1 Сообщения будут обновляться каждые 60 секунд плюс/минус 10 секунд после запуска фоновой задачи.
1.2 Сообщения должны оставаться видимыми постоянно.
1.3 Если взаимодействие с фоновой задачей возможно, то ДФЗ отобразит процент выполнения фоновой задачи.
1.4 По завершению фоновой задачи ДФЗ отобразит сообщение «Выполнено».
1.5 Если выполнение фоновой задачи остановлено, ДФЗ отобразит соответствующее сообщение.
Мы разделили это требование на нескольких дочерних, потому что для каждого понадобится отдельный вариант тестирования, кроме того, так каждое проще отслеживать. Если несколько требований объединено в один абзац, то при сборке или тестировании существует опасность пропуска одного из них. В измененном требовании не указан способ отображения сообщения о состоянии. Это проблема дизайна; если вы сейчас определите ее здесь, то разработчики воспримут ее как ограничение, а это может их расстроить. Кроме того, в этом случае вряд ли можно рассчитывать на оптимальный продукт.
Компьютеры не могут сделать что-либо моментально, поэтому это требование невыполнимо. Кроме того, это требование неполное, поскольку в нем не указана условие переключения. Выполняет ли это изменение при определенных условиях само ПО или это происходит по инициативе пользователя? Какая часть документа изменяется: выделенный фрагмент текста, весь документ, текущая страница или что-то еще? Какие именно непечатаемые символы: скрытый текст, управляющие символы, тэги разметки или что-то еще? До тех пор пока на эти вопросы не будут получены ответы, требование будет невозможно проверить.
Вот как это требование можно улучшить:
«Пользователь сможет переключать отображение и сокрытие всех тэгов XML в редактируемом документе с помощью активации механизма определенного триггера. Отображение должно изменяться в течение 0,1 секунды или менее».
Вот теперь стало ясно, что непечатаемые символы — это тэги разметки XML. Мы знаем, что пользователь инициирует изменение изображения, но требование не ограничивает разработку определением точного механизма. Мы также добавили требование производительности, которое определяет, как быстро отображение должно изменяться.
«Моментально» означает «моментально для зрения человека», что вполне достижимо на достаточно быстром компьютере.
Многозначное слово «быстро» относится к действию, выполняемому человеком, а не анализатором. Из-за этого недостаточного объяснения сообщение об ошибке определено не полностью, кроме того, мы не знаем, когда создается этот отчет. Как проверить это требование? Найдите какого-нибудь новичка в XML и посмотрите, сможет ли он быстро исправить ошибки с помощью этого отчета? Это требование содержит важное понятие определенного класса пользователей — в данном случае это пользователи, мало знакомые с XML, которым нужна помощь ПО для нахождения синтаксических ошибок XML. Аналитик должен найти подходящего представителя этого класса пользователей, чтобы выяснить, какую информацию следует поместить в отчет об ошибке анализатора разметки. Попробуем вместо этого другой способ.
1. После того, как XML Parser полностью проанализирует файл, он генерирует отчет об ошибках, в котором указан номер строки и текст любых XML-ошибок, обнаруженных в анализируемом файле, а также описание каждой найденной ошибки.
2. Если никаких ошибок в разметке не было найдено, отчет не генерируется.
Теперь мы знаем, когда создается отчет об ошибках и что в нем содержится, однако то, как отчет будет выглядеть, мы оставили на усмотрение дизайнера. Мы также сформулировали условие исключения, которое первоначальное требование не затрагивает: если ошибки нe найдено, генерировать отчет не надо.
Что означает «если возможно»? Технически осуществимо? Или когда доступен основной список счетов во время запуска? Если вы не уверены, можно ли реализовать функцию, сделайте пометку «TBD», чтобы указать, что эта проблема еще не решена. После проверки одно из двух будет ликвидировано — либо пометка «TBD», либо требование.
В требовании не указано, что произойдет, если проверка пройдет успешно или окончится неудачей. Избегайте неточных слов вроде «следовало бы». Некоторые авторы требований пытаются выразить тонкие различия, используя «будет», «следовало бы» и «возможно», чтобы подчеркнуть значимость. Я предпочитаю использовать «будет» или «должен» как ясное указание на цель требования и приоритеты. Вот как выглядит исправленный вариант требования.
«В момент ввода номера счета система проверит его по основному корпоративному списку счетов. Если номер счета в списке не найден, система отобразит сообщение об ошибке и не примет заказ».
Связанное требование будет относиться к условию исключения: основной список счетов не доступен во время проверки достоверности.
Понятие «катастрофичные результаты» можно интерпретировать по-разному. Непреднамеренное глобальное изменение может обернуться катастрофой, если пользователь не обнаружит ошибку или не может ее исправить. Будьте благоразумны при составлении обратных требований, описывающих, что система не будет делать. Основная забота в этом примере— защита содержимого файла от непреднамеренных повреждений или потерь. Возможно, настоящие требования выглядят вот так.
1. Редактор будет запрашивать подтверждения от пользователя, где тот должен подтвердить глобальные изменения текста, удаления и вставки, которые могут привести к потере данных.
2. В приложении будет реализована многоуровневая функция отмены, ограниченная только системными ресурсами, которые доступны приложению.
Это требования к продукту, содержащему встроенное ПО, которое используется для тестирования различных типов измерительных приборов. Слово «легко» подразумевает требование легкости и простоты использования, но он не измеряемо и не поддается проверке. «В том числе» не дает точности, полный ли это список внешних устройств, которые должны быть подключены к испытательному устройству, или существует еще множество других приборов, о которых мы не знаем. Вот какие альтернативные требования содержат хорошо обдуманные ограничения дизайна.
1. Испытательное устройство содержит USB-порт, чтобы пользователь смог подключить любое измерительный прибор, у которого есть USB-подключение.
2. USB-порт будет установлен на передней панели для того, чтобы позволить квалифицированному оператору подключить измерительный прибор за 15 секунд или менее.