📄️ Декомпозиция требований и задач
Декомпозиция требований — это разбиение хотелок бизнеса на более конкретные и понятные задачи, которые можно передавать в разработку. Декомпозиция позволяет лучше понимать дальнейшие шаги по реализации, правильно расставить приоритеты и точнее давать оценку по срокам вывода функционала. Когда функционал разбивается на части и реализуется последовательно, это позволяет быстрее получить обратную связь от заказчика и сохранить гибкость к изменениям, а также быстрее вывести рабочий функционал. В общем, понятнее, что разрабатывать и рисков меньше.
📄️ Use Case. Как описывать и использовать
Use Case (синонимы: вариант использования, прецедент, сценарий) – это способ описания сценария взаимодействия пользователя с системой. Use Case помогает определить функциональные требования к системе, а также показать, как она взаимодействует с другими участниками.
📄️ User Story vs Job Story
User Story – это краткое описание функции с точки зрения пользователя и наименьшая единица работы в Agile. В среднем, команда может выполнить 2-3 user story за двухнедельный спринт.
📄️ Критерии приемки (Acceptance Criteria): краткий обзор
Критерии приемки (Acceptance Criteria, AC) — это набор условий, которым должна удовлетворять пользовательская история (User Story), чтобы её считали выполненной. Критерии приёмки уникальны для каждой User Story (US) и являются основой для тестирования.
📄️ Постановка задачи на разработку: этапы, отличие от ТЗ
Понятия постановки задачи на разработку и техническое задание часто путают между собой, но это разные вещи.
📄️ Методы трассировки требований
Трассировка требований