Документирование требований

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

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

Практическое задание №2Способы представления требований