В требованиях должна быть проблема, цель, задача! Решение вторично

Требования - вещь такая... То они есть, а то их и нет. Зависит от проекта.
Ну а если они вдруг и есть, то обычно описывают те функции, которые умеет выполнять продукт.

А, казалось бы, что еще надо то?
У Алана Купера в "Психбольнице" есть замечательный пример на тему того, почему это неправильно.

Для нашего зациклившегося на функциях мира мысль, наверное, непривычная - вы не достигните своих целей, используя набор функций как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. Для доказательства этого тезиса проектировщик взаимодейтсвий Скотт Мак-Грегор на своих занятиях использует такой вот замечательный тест.

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

1. Двигатель внутреннего сгорания.
2. Четыре колеса с резиновыми покрышками.
3. Трансмиссия, связывающая двигатель с ведущими колесами.
4. Трансмиссия и двигатель смонтированы на ходовой части.
5. Рулевое колесо.

На этот момент времени каждый слушатель уже записал, что это автомобиль,

но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя:

6. Быстро и легко срезает траву.
7. На этом удобно сидеть.

На основании 5 функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка.

Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.

Ну что, тестировщики, кто правильно угадал продукт по одним только функциям?


Но задумываемся ли мы об этом, когда привычно изучаем техническую документацию? Там же написано, как оно должно работать - значит, именно так и должно! А вот будет ли это самое "должно" нужно пользователям, уже дело десятое. Хотя должно бы быть первое. В конце концов, не для себя стараемся, а для потребителей.

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

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

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

Не додумывайте автомобиль, читая требования к газонокосилке!