Спецификация требований в проектах гибкой разработки

В проектах гибкой разработки (agile) применяется ряд способов определения требований, которые отличаются от только что описанного метода.

Во многих проектах гибкой разработки в процессе выявления требований используются пользовательские истории. Каждая такая история представляет собой формулировку потребности пользователя или функциональности, которая может быть полезной пользователю или покупателю системы (Cohn, 2004; Cohn, 2010). В проектах гибкой разработки команда может начать спецификацию, записав достаточно информации по каждой пользовательской истории, чтобы заинтересованные лица получили общее представление, о чем история, и смогли определить приоритеты историй друг относительно друга. Это также позволяет команде начать планировать назначение историй на конкретные итерации. Команда может собирать связанные истории в «минимально поддающуюся для продвижения на рынке функцию», которую нужно реализовать целиком к выпуску продукта, чтобы клиент мог получить от нее пользу.

Пользовательские истории накапливаются и приоритизируются в резерве продукта (product backlog), который меняется на протяжении всего проекта. Крупные истории, которые охватывают значительную функциональность и которые нельзя реализовать в одной итерации, разбиваются на более мелкие, которые назначаются конкретным итерациям. Пользовательские истории можно записывать на чем-то простом, например на карточках каталога, а не в традиционном документе. Одни команды гибкой разработки сохраняют свои истории в средстве управления историями, другие после реализации их не сохраняют.

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

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

Аналогично нефункциональные требования могут записываться на карточках, но не как пользовательские истории, а как ограничения (Cohn, 2004). Альтернативный вариант — указывать нефункциональные требования, относящиеся к определенной пользовательской истории, в форме критериев приемки как демонстрацию достижения определенного атрибута качества. Например, тесты безопасности могут демонстрировать, что только определенным пользователям разрешен доступ к функциональности, описанной в соответствующей пользовательской истории, а остальным пользователям доступ закрыт. Команде гибкой разработки не возбраняется применять другие методы представления знаний о требованиях, такие как модели анализа или словарь данных. Они должны выбрать метод представления, который привычен и уместен в их культуре и проект.

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

«Надлежащий» уровень формальности и подробности документа требований зависит от многих факторов, в числе которых:

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

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

Просто помните, что если не определить высококачественные требования, полученный в результате продукт будет представлять собой коробку с сюрпризами — вы никогда не будете знать, что от него можно ожидать.

Что дальше?

• Проверьте набор требований проекта на предмет соответствия шаблону на рис. 10-2, чтобы определить, собраны ли все требования в разделах, относящихся к вашему проекту. Эта глава скорее не о том, как наполнять определенный шаблон, а больше о том, как гарантировать, что вы собрали всю информацию, необходимую для успеха проекта, — шаблон всего лишь напоминание.
• Если в вашей организации еще нет стандартного шаблона спецификации требований к ПО, соберите небольшую рабочую группу для того, чтобы принять такой шаблон. Начните с шаблона на рис. 10-2 и измените его так, чтоб он наилучшим образом соответствовал потребностям ваших проектов и продуктов. Выработайте стандарт именования отдельных требований.
• Если вы храните требования в форме, отличной от обычного документа, например в средстве управления требованиями, изучите шаблон спецификации требований к ПО на рис. 10-2 и определите, нет ли каких-либо категорий информации требований, которые вы сейчас не выявляете и не фиксируете. Измените свое хранилище, включив эти категории, чтобы в будущем хранилище напоминало о них при выявлении требований.