Требования - вещь такая... То они есть, а то их и нет. Зависит от проекта.
Ну а если они вдруг и есть, то обычно описывают те функции, которые умеет выполнять продукт.
А, казалось бы, что еще надо то?
У Алана Купера в "Психбольнице" есть замечательный пример на тему того, почему это неправильно.
Для нашего зациклившегося на функциях мира мысль, наверное, непривычная - вы не достигните своих целей, используя набор функций как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. Для доказательства этого тезиса проектировщик взаимодейтсвий Скотт Мак-Грегор на своих занятиях использует такой вот замечательный тест.
Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет:
но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя:
6. Быстро и легко срезает траву.
7. На этом удобно сидеть.
На основании 5 функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка.
Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.
Ну что, тестировщики, кто правильно угадал продукт по одним только функциям?
![Wink ;) Wink ;)](http://confluence.hflabs.ru/s/en_GB-1988229788/4226/d7686547091e645d7b0285207c0b86be721c74eb.11/5.1.3/_/images/icons/emoticons/wink.png)
Но задумываемся ли мы об этом, когда привычно изучаем техническую документацию? Там же написано, как оно должно работать - значит, именно так и должно! А вот будет ли это самое "должно" нужно пользователям, уже дело десятое. Хотя должно бы быть первое. В конце концов, не для себя стараемся, а для потребителей.
И когда мы тестируем документацию, особенно пользовательскую, надо обращать внимание именно на то, насколько она проста и понятна, а также очевидна для пользователя. Что он сразу может найти в ней свою проблему и оттуда уже перейти по ссылочке на решение. Что он сразу видит свою цель и по ссылочке уже находит пути достижения цели... Ну и т.д.
Да даже если мы тестируем свою, техническую, документацию. Все равно. Остановитесь и задумайтесь - а кто наш пользователь? А как он будет с этим работать? А что ему вообще нужно, какие проблемы он будет решать при помощи нашего ПО? Есть в доке хоть слово об этом? Уже хорошо!
Кстати, в данной ситуации очень хорошо помогают варианты использования, по Коберну. Они включают в себя и краткую цель в названии, и способ ее достижения с точки зрения пользователя, и даже реакцию системы на все эти действия. Но. опять таки, помните, что это все равно решение проблемы, а решение вторично. Чтобы протестировать логику работы программы, в первую очередь нам нужно понимать - для чего, для каких целей она создана.
Не додумывайте автомобиль, читая требования к газонокосилке!
Ну а если они вдруг и есть, то обычно описывают те функции, которые умеет выполнять продукт.
У Алана Купера в "Психбольнице" есть замечательный пример на тему того, почему это неправильно.
Для нашего зациклившегося на функциях мира мысль, наверное, непривычная - вы не достигните своих целей, используя набор функций как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. Для доказательства этого тезиса проектировщик взаимодейтсвий Скотт Мак-Грегор на своих занятиях использует такой вот замечательный тест.
Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет:
- Двигатель внутреннего сгорания.
- Четыре колеса с резиновыми покрышками.
- Трансмиссия, связывающая двигатель с ведущими колесами.
- Трансмиссия и двигатель смонтированы на ходовой части.
- Рулевое колесо.
но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя:
6. Быстро и легко срезает траву.
7. На этом удобно сидеть.
На основании 5 функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка.
Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.
Ну что, тестировщики, кто правильно угадал продукт по одним только функциям?
![Wink ;) Wink ;)](http://confluence.hflabs.ru/s/en_GB-1988229788/4226/d7686547091e645d7b0285207c0b86be721c74eb.11/5.1.3/_/images/icons/emoticons/wink.png)
Но задумываемся ли мы об этом, когда привычно изучаем техническую документацию? Там же написано, как оно должно работать - значит, именно так и должно! А вот будет ли это самое "должно" нужно пользователям, уже дело десятое. Хотя должно бы быть первое. В конце концов, не для себя стараемся, а для потребителей.
И когда мы тестируем документацию, особенно пользовательскую, надо обращать внимание именно на то, насколько она проста и понятна, а также очевидна для пользователя. Что он сразу может найти в ней свою проблему и оттуда уже перейти по ссылочке на решение. Что он сразу видит свою цель и по ссылочке уже находит пути достижения цели... Ну и т.д.
Да даже если мы тестируем свою, техническую, документацию. Все равно. Остановитесь и задумайтесь - а кто наш пользователь? А как он будет с этим работать? А что ему вообще нужно, какие проблемы он будет решать при помощи нашего ПО? Есть в доке хоть слово об этом? Уже хорошо!
Кстати, в данной ситуации очень хорошо помогают варианты использования, по Коберну. Они включают в себя и краткую цель в названии, и способ ее достижения с точки зрения пользователя, и даже реакцию системы на все эти действия. Но. опять таки, помните, что это все равно решение проблемы, а решение вторично. Чтобы протестировать логику работы программы, в первую очередь нам нужно понимать - для чего, для каких целей она создана.
Не додумывайте автомобиль, читая требования к газонокосилке!
"И когда мы тестируем документацию, особенно пользовательскую, надо обращать внимание именно на то, насколько она проста и понятна, а также очевидна для пользователя. Что он сразу может найти в ней свою проблему и оттуда уже перейти по ссылочке на решение. "
ОтветитьУдалитьНу если не поможет, то во всяком случае улыбнет)))
http://www.tdocs.su/1808
в части выделения групп пользователей.
Интересная ссылочка, спасибо!
Удалить