Я работал со многими командами, адаптирующими Agile в своей работе. В каждой ситуации, как правило, камнем преткновения всегда оказывались пользовательские истории, при часто задаваемом вопросе типа: “В чем заключается различие между традиционными требованиями, вариантами использования и пользовательскими историями?” Я бы хотел ответить на этот вопрос, дать определение каждому типу требования и привести примеры. Я буду использовать следующие пример на протяжении всей статьи: представьте, что вы создаете программное оборудование для фирм по трудоустройству управленческих кадров, и одна из таких фирм запросила возможность поиска кандидатов на определенную должность по специальности в пределах конкретной географической локации. Например, “Я хочу найти всех бизнес-аналитиков, специализирующихся в области закона Сарбейнса-Оксли (SOX), в пределах пятидесяти миль от Нью-Йорка”.

Традиционные требования

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

Основной сложностью при наличии системы в центре внимания, является легкость интерпретации предположений относительно истинных желаний клиента. В подобном случае, взаимодействие с бизнесом или пользователем во время разработки системы превращается в целый ряд утомительных, обговариваемых запросов на внесение изменений. Целью всей работы становится предоставление пользователю именно того, о чем он/она просили, что не всегда является тем, что пользователю в действительности нужно.

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

Согласно положениям Международного института бизнес-аналитиков (IIBA), хорошие требования определяются следующими критериями:

• Требования должны быть полными. Они должны быть как можно более полными, без неоконченных в смысловом плане частей или без возможности для интерпретации.
• Требования должны быть тестируемыми. У разработчика должна быть возможность создать тест или любое другое доказательство соответствия реализации требованию.
• Требования должны быть согласованы друг с другом.
• Требования не должны касаться дизайна. Требования к программному обеспечению должны указывать возможности и ограничения системы, но не методы, посредством которых система обеспечивает соответствие и должное исполнение этих требований; за это отвечает дизайн.
• Требования должны быть однозначными. Никаких расплывчатых утверждений, ничего (концептуального), что может быть интерпретировано в разрез с предполагаемым значением.

Как вы уже поняли, хорошие традиционные требования сложно написать и они редко встречаются. А уж если тяжело создать хорошее требование, то еще сложнее будет вписать большое требований в уже завершенную и согласованную спецификацию системы. Уровень детализации может привести ко множеству взаимозависимостей между требованиями, которые должны быть проанализированы по мере разработки требований. В то время как все спецификации требований имеют подобную трудность, традиционные требования остаются особенно уязвимыми, поскольку основное внимание нацелено на систему, а не на ее взаимодействие с пользователем.

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

Примеры традиционных требований

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

Варианты использования

--

Автор: Charles Suscheck

Оригинал статьи: http://www.agileconnection.com/print/art[...]traditional-vs-use-cases-vs-user-stories

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile