View source for Управление требованиями : Анализ исходных требований

= Анализ исходных требований =
== Обзор процесса ==
На предыдущих шагах мы выяснили stakeholder’s проекта, поняли их проблемы и подготовили себя к тому, что мы можем говорить с ними на их языке. Теперь задача – дать всем stakeholder’ам выговорится, высказать свои требования и пожелания к системе, документировать их и согласовать. Это еще не есть требования к проекту, но исходный материал, на основе которого появятся строго формальные требования.
Источниками для сбора требований являются:
* Заказчики:
** Описание проблем;
** Начальные требования к продукту;
** Бизнес планы;
** Личные цели представителей;
** Описание бизнес-процессов и бизнес-правила;
* Пользователи:
** Описание проблем;
** Запросы пользователей;
** Замечания и дефекты;
** Запросы на изменения;
* Предметная область:
** Анализ предметной области и бизнес-процессов;
** Мнение экспертов;
** Анализ решений-конкурентов;
Рекомендуется собирать все требования одного stakeholder’а в отдельный документ. Это позволит облегчить согласование требований с каждым из stakeholder’ов. Сбор требований это итеративный процесс, в ходе которого последовательно, из различных источников, проводится сбор требований, их формулировка и согласование с каждым из stakeholder’ов. 

Какие проблемы возникают на этом этапе?
* Со стороны stakeholders:
** Способны упереться на каком-то изначально предложенном собственном решении, даже если оно неверно или неоптимально;
** Не знают что они на самом деле хотят;
** Не в состоянии выразить то, что на самом деле хотят;
** Оказываются не способны узнать то решение, которое они хотят когда видят его.
* Со стороны аналитика:
** Недостаточное понимание пользователей, как следствие – не понимание их проблем, которое приводит к тому что:
** *Предлагается неверное решение;
** *Упускаются решения, которые следовало бы предложить;
* Все:
** Не готовы посмотреть на проблему со стороны собеседника;
Важная ошибка, которой следует избегать – это предложение готового решения вместо описания свойств и характеристик, которые должны быть присущи ЛЮБОМУ решению, которое БУДЕТ предложено потом, когда все пожелания будут собраны и проанализированы.

Хорошим критерием успешности этого этапа послужит соблюдение следующих условий:
* Каждый stakeholder имеет по крайней мере одну проблему;
* Каждая проблема затрагивает по крайней мере одного stakeholder’а;
* У каждой проблемы есть по крайней мере один запрос, направленный на одно решение;
* Каждый запрос (требование, requirement) направлен на решение по крайней мере одной проблемы;
На примере stakeholder’а посмотрим, почему эти вопросы важны:
* Если stakeholder не имеет ни одной проблемы – то либо stakeholder вовлечен зря, либо мы упустили проблему;
* Если у проблемы нет stakeholder’а, то либо мы его упустили (а следовательно не сможем учесть его мнение) либо проблема не входит в контекст этого проекта.
== Сбор информации ==
Изначальным источником информации служат документы, инициирующие проект, а так результат бизнес-анализа и выявления проблем. 
В дальнейшем, для уточнения используются:
* Прямое общение с заказчиком;
* Опросники;
* Ролевое моделирование;
* Обсуждение;
* Прототипирование;
На необходимость уточнения требований указывают, к примеру, следующие моменты:
* Аналитик не уверен в собственном понимании формулировки требования заказчика;
* Требование конфликтует с другими требованиями;
* Не ясна проблема, вызвавшая появление этого требования;
При общении с заказчиком всегда следует:
* Использовать язык заказчика, избегать технических терминов, которые заказчику могут быть неизвестны. 
* Формулировать вопрос по возможности так, что бы заказчику осталось на него ответить “да” или “нет”. Особенно опасны вопросы, ответ на которые “да” или “нет” не даёт никакой информации и вопросы, которые содержат в себе ДВА вопроса. Пример вопроса: “что бы открыть позицию, трейдер создаёт ордер и позиция сразу открывается по ордеру”. Первая часть правильная, вторая – нет. Но! Отвечающий на вопрос не обязан вникать, правильно ли Вы его спросили. Он может просто ответить “нет”. 
* Следует сразу обозначить глобальные области внутри неизвестной области, сразу отсечь не нужные, и только потом уточнять. Например, вопрос, “как добраться до Салехарда?”. (цепочка: “напрямую хоть чем-нибудь можно или нет”. Дальше классифицировать способ: “плыть, ехать, лететь”. И только по способам уточнять “на чём”.
* Использовать максимально простые языковые конструкции (т.е. помнить, что ответ необходим Вам, а не заказчику, и не надо его грузить сложными формулировками). Основные принципы написания простого для понимания текста:
** Следует избегать отрицательных утверждений (“не”), они хуже воспринимаются человеком, а на вопрос: “а не сделать ли нам тут вот такую вот штуку – ответить да или нет невозможно вообще.”).
** Следует отдавать предпочтение простым предложениям.
** НИКОГДА нельзя вводить новую информацию в дополнения, причастных и деепричестных оборотах. 
** Следует отдавать предпочтение существительным, глаголам – как базовым (появившимся в первую очередь и, как правило, отображающим объективные понятия) частям речи. Прилагательные, причастия и деепричастия используются (в основном) для передачи субъективных характеристик и ссылок на уже известную информацию.
* В целом – надо сделать процесс сбора информации комфортным для опрашиваемых. Никогда нелишне подчеркнуть для stakeholder’ов пользователей, что нам ВАЖНО их мнение.
Ролевое моделирование используется для воспроизведения проблем и ситуаций командой разработчиков (идеально, конечно же, если с привлечением заказчика). Основная цель – это взглянуть на ситуацию и проблему с точки зрения заказчика, т.е. преодолеть барьер собственной точки зрения. Ролевое моделирование может показать те моменты, которые упущены (вопрос: опаньки, а как они поступают в этом случае?) и/или выглядят недостаточно логичными (вопрос: хм… а зачем?).  
Цель обсуждения требований в том, что бы собрать в единое целое понимание, которое было достигнуто каждым участником сбора требований. При обсуждении полезно использовать следующие приемы:
* На начальном этапе только высказываются идеи, но не обсуждаются и не критикуются. Все идеи фиксируются. Для того, что бы избежать авторитарного давления, полезно использовать старый морской метод, когда высказываются в порядке, обратном старшинству. При высказывании идей никогда не следует упускать возникшую идею только потому, что она кажется дикой. Все идеи фиксируются. 
* В дальнейшем идеи группируются и совместно, уже в процессе обсуждения вырабатывается общее понимание требования заказчика. 
Прототипирование позволяет снять проблему, в которой заказчик испытывает затруднения при формулировании своих требований “с чистого листа”. Иногда намного проще сказать исходя из “мне это не подходит, потому что…”, чем мне “мне необходимо то, потому что”. Критиковать легче, чем делать, и эта критика тоже является источником полезной информации.
При сборе информации полезно сразу же разметить требования по следующим категориям:
* Поведение (behavior);
* Данные (data);
* Взаимодействие с другими системами (interaction);
* Ограничения (restriction);


[[Category:Управление требованиями (Курс)]]