ТРЕБОВАНИЕ ДОЛЖНО БЫТЬ КОНКРЕТНЫМ! Об общих формулировках и их вреде для разработки

0
Акашева Василиса Игоревна12/9/2020

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

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

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

1. Диспетчер фоновых задач (ДФЗ) отобразит сообщения о состоянии в назначенной области пользовательского интерфейса. 
1.1 Сообщения будут обновляться каждые 60 секунд плюс/минус 10 секунд после запуска фоновой задачи. 
1.2 Сообщения должны оставаться видимыми постоянно. 
1.3 Если взаимодействие с фоновой задачей возможно, то ДФЗ отобразит процент выполнения фоновой задачи. 
1.4 По завершению фоновой задачи ДФЗ отобразит сообщение «Выполнено». 
1.5 Если выполнение фоновой задачи остановлено, ДФЗ отобразит соответствующее сообщение. 

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

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

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

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

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

«Моментально» означает «моментально для зрения человека», что вполне достижимо на достаточно быстром компьютере. 

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

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

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

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

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

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

В требовании не указано, что произойдет, если проверка пройдет успешно или окончится неудачей. Избегайте неточных слов вроде «следовало бы». Некоторые авторы требований пытаются выразить тонкие различия, используя «будет», «следовало бы» и «возможно», чтобы подчеркнуть значимость. Я предпочитаю использовать «будет» или «должен» как ясное указание на цель требования и приоритеты. Вот как выглядит исправленный вариант требования. 

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

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

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

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

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

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

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

Вигерс К. Разработка требований к программному обеспечению. — М.: Издательство-торговый дом «Русская Редакция», 2004. — С. 199-203.
Следующая статья
Бизнес и экономика
Как удержать клиента с помощью музыки?
Мы часто недоумеваем, почему время идет так быстро или медленно, почему наши внутренние часы легко поддаются влиянию самочувствия (мы нервничаем, устаем, нам жарко) и всего окружающего нас. Приятные мелодии тоже способны сказаться на восприятии времени. Иногда благодаря музыке время просто летит. В йоркском магазинчике сувениров по воскресеньям время тянулось долго: я обычно оставалась одна, и не с кем было поговорить, кроме горстки случайных покупателей. В такие вялые дни приятная фоновая музыка в магазине помогала скоротать бесконечные минуты, пока я вы...
Бизнес и экономика
Как удержать клиента с помощью музыки?
Бизнес и экономика
«По правде сказать, я не люблю балет. Но я не дурак», или как войти в доверие к клиенту?
Бизнес и экономика
Хронометраж + видеокамера: как сократить внутренние издержки на производстве?
Бизнес и экономика
Почему опасно «‎терпеть» ухудшающееся финансовое положение in a wartime situation?
Бизнес и экономика
1 500 туземцев, ни слова по-английски и оптимизация африканского производства
Бизнес и экономика
Малый, средний и крупный бизнес. Почему так важно правильно масштабировать фирму?
Бизнес и экономика
«Недопустима даже тень сомнения в собственной правоте», или как должна работать пропаганда
Бизнес и экономика
Раскрутка сети магазинов на примере «Избёнки» и «ВкусВилла»
Бизнес и экономика
Этот самолет слишком сложен, чтобы на нем мог летать один человек
Бизнес и экономика
Питер Друкер: «Кто наш клиент?»
Бизнес и экономика
Основные положения доктрины человеческих отношений
Бизнес и экономика
НЕИЗБЕЖНОСТЬ PUBLIC RELATIONS. Часть 1. Фрагмент из книги «Приёмы рекламы и Public Relations»
Бизнес и экономика
НЕИЗБЕЖНОСТЬ PUBLIC RELATIONS. Часть 2. Тренировочные задания.
Бизнес и экономика
Питер Друкер: «Фредерик Тейлор разрушил романтику труда»
Бизнес и экономика
Джеймс Уотсон: как работать с Белым домом?
Бизнес и экономика
Теория градостроительства, проектирование улиц и нумерация домов