REQUIREMENTS DESIGN
Ключевой вопрос: Какими функциями и свойствами должен обладать продукт или его части после процесса разработки?
Формализация функциональных и нефункциональных требований позволяет сократить риски того, что в результате процесса разработки получится продукт или его части, отличные от договоренностей команды на старте этого процесса разработки.
1. Артефакты и документы
Шаблоны описания требований
Стандарты, шаблоны, примеры или рекомендации по которым команда договорилась формализовывать требования для передачи в разработку и тестирование. Являются частью спецификации системы.
Нефункциональные требования
Описание требований к общим свойствам продукта или его частей, не связанных с пользовательскими функциями. Например, требования по доступности, совместимости, портируемости, надежности, масштабируемости, безопасности и т.д.
Критерии приёмки и оценки
Соглашение о перечне критериев, которые необходимо соблюсти команде, чтобы требования, результаты деятельности или условия были приняты заинтересованными сторонами. Критерии оценки позволяют сделать принятие решения о приёмке прозрачным и измеримым для всех участников.
2. Модели и инструменты
Use Case
Формат описания функциональных требований в виде пошагового сценария взаимодействия пользователей с системой по пути к цели. Стркутура use case включает: имя сценария, цель, пользователей, предусловия, триггеры, последовательность событий, результат (пост-условия). Основной фокус формата по сравнению с другими - на чётком определении последовательности действий. Эффективно применять при описании требований, в которых большое количество шагов взаимодействий и/или несколько пользователей.
User Story
Формат описания требований, в котором основной акцент стоит на получаемой от внедрения фичи ценности для конкретного сегмента клиента. Истории просты в описании и восприятии заказчиками, но в то же время неконкретны без указания критериев приёмки. Истории должны обладать балансом размерности: не быть слишком большими, чтобы была возможность решить их за одну итерацию, но и не быть слишком маленькими, чтобы своим решением принести реальную ценность для бизнеса.
Entities Analysis
Модель описания бизнес-логики продукта, представленная в виде перечня главных объектов системы (сущностей), их взаимосвязей и атрибутов. Правильный выбор сущностей и их взаимосвязей является ключевым фактором для построения масштабируемых, гибких и консистентных продуктов. Популярные типы связей между сущностями: ассоциация, генерализация, композиция, агрегация, абстракция. Для каждой связи определяется тип кратности. Для сущностей могут быть определены её атрибуты.
Test Case
Формат описания требований к тестированию продуктов в виде пошагового сценария взаимодействия пользователей с системой. Структура test case включает: наименование, предусловия среды / окружения, значения переменных / объектов для тестирования, последовательность событий, ожидаемый результат выполнения, действительный результат выполнения и вердикт. Ожидаемый и действительный результаты могут быть приведены для каждого из шагов сценария, а не для всего тест-кейса в целом.
Screen Map
Карта экранов отображает реализацию user flow продукта при помощи конкретных интерфейсных решений. Карта включает в себя перечень состояний каждого элемента интерфейса и переходы между ними, инициированные пользователем или системой. Хорошая карта экранов собрана при помощи дизайн-системы компании и используется как для постановки требований в разработку, так и в качестве артефакта документации.
Definition-of-Done
Условия готовности представляют собой перечень требований, которые необходимо выполнить, чтобы user story, sprint и/или release считались бы завершенными. Условия готовности могут быть определены свои для каждой роли участников команды. Например, могут включать указание метрик успешности, подготовку маркетинговых материалов, проведение презентации заинтересованым лицам или некоторым клиентам и т.д.
Made on
Tilda