Неоднозначность и нужная степень детализации

Главные идеи#

Золотая середина#

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

• Слишком мало деталей. Неоднозначность растёт, пока уже никто не может сказать, что имелось в виду.
• Слишком много деталей. Понимание снова падает. Пользователи не станут читать перегруженную спецификацию, а исполнители за деталями теряют из виду цель.

Цель — зона, где требование одновременно понятно и однозначно.

Пример с мигающей лампой#

Возьмём требование к прибору с двумя лампами: если одна из ламп перегорит, другая должна мигать раз в секунду. Звучит ясно, пока программисту не приходится выбирать рабочий цикл. Полсекунды горит и полсекунды не горит — или девять десятых секунды горит и одну десятую нет? В обоих случаях лампа мигает раз в секунду. Для простого индикатора разница никого не волнует. Но если такая же расплывчатость описывает выходную мощность хирургического инструмента, она может навредить пациенту.

Авторы делают вывод: нужная степень детализации зависит от двух вещей:

1. Последствий неверного прочтения в данном приложении.
2. Способности исполнителей самостоятельно делать правильный выбор или вовремя задать вопрос.

«Mary had a little lamb» («У Мэри был барашек»)#

Леффингуэлл и Уидриг заимствуют упражнение у Гауса и Вайнберга. Посмотрите в словаре значения двух слов из этой известной строки английского детского стишка: had и lamb. Значения had — от «владела» до «подкупила»; lamb — от «ягнёнок» до «простак, которого легко обмануть». В сочетании они дают больше десятка допустимых прочтений. Фраза, которая кажется совершенно ясной людям с общим опытом, может значить совсем другое для тех, у кого этого опыта нет, — а именно в таком положении находятся разработчики, когда читают требования пользователей.

Три эвристики для поиска неоднозначности#

Эти эвристики придумали Гаус и Вайнберг, а Леффингуэлл и Уидриг их пересказывают:

• Запоминание. Попросите нескольких человек — из разработки и из бизнеса — записать требование по памяти. Части, которые им трудно воспроизвести точно, вероятно, неоднозначны. Перепишите их.
• Ключевые слова. Выберите ключевые слова, выпишите их возможные значения из авторитетного источника, скомбинируйте прочтения и проверьте, что подразумевается ровно одно.
• Ударение. Прочитайте требование вслух несколько раз, каждый раз выделяя голосом другое слово. Каждое ударение может открыть новое прочтение. Если подразумевается только одно, перепишите требование так, чтобы оно стало явным; если верны несколько, возможно, нужны отдельные требования.

Там, где недопонимание недопустимо, переходите к формальным методам: псевдокоду, конечным автоматам или таблицам решений.

Рекомендации авторов#

• Используйте естественный язык везде, где можно.
• Добавляйте рисунки и диаграммы.
• Спрашивайте, когда сомневаетесь, — и спрашивайте, даже когда сомнений нет.
• Применяйте формальные методы там, где неверное прочтение недопустимо.
• Учите команду распознавать неоднозначность, а не только исправлять отдельные случаи.