Priemy-formirovaniya-trebovanij

1.

Приемы формирования
требований
Разработка требований — многогранный процесс, включающий сбор,
анализ, документирование и управление. Рассмотрим ключевые
техники для каждого этапа.
Выполнили: ст. гр. 448,Байсалов А.Б.,Махин Ф.Б.

2.

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

3.

Фокус-группы
Ролевые игры
Управляемая дискуссия
Участники примеряют роли
небольшой группы
разных пользователей и
представителей пользователей с
проигрывают реальные сценарии
модератором.
работы.
Преимущество: выявляют
Цель: выявить восприятие
скрытые сложности и детали,
продукта, боли и ожидания
незаметные при простом опросе.
пользователей.
Пример: менеджеры по
Пример: команда разыгрывает
продажам обсуждают
сценарий «врач выписывает
неудобства текущей CRM и
рецепт» в медицинской системе.
ожидания от новой системы.

4.

Моделирование данных
Формальные методы
Словарь данных
Языки Z-notation или B-Method основаны на
Централизованный реестр каждого элемента:
математике. Описывают требования жёстко и
название, тип, допустимые значения, длина. Снижает
однозначно.
неоднозначность.
Пользовательские истории
Формат: «Как [роль], я хочу [возможность], чтобы
[выгода]»

5.

Диаграммы «Сущность –Связь» (ERD)
Визуально показывают ключевые объекты системы и
связи между ними. Основа для проектирования баз
данных.

6.

Моделирование состояний
Диаграммы состояний показывают, как объекты системы переходят из одного
состояния в другое под воздействием событий.
Создан
Начальное состояние заказа
Оплачен
После оплаты пользователем
Отправлен
Товар в пути
Доставлен
Финальное состояние

7.

Приоритизация требований
Cost of Delay
Парное сравнение
Story Mapping
Расчёт финансовых потерь от
Каждое требование
Истории раскладывают на
задержки фичи. Отношение
сравнивают с каждым другим
доске: горизонтально — этапы
бизнес-ценности к времени
по важности. Получаем
сценария, вертикально —
реализации.
ранжированный список.
приоритет. Показывает скелет
продукта.

8.

Качество ф ормулировок по INCOSE
01
02
Одно требование — одно действ ие
Актив ны й залог и ясны й субъ ект
Разделяйте множественные действия на отдельные пункты.
Показывайте, кто выполняет действие: система,
пользователь или сервис.
03
04
Чёткие измеримы е критерии
Избегайте расплы вчаты х ф ормулировок
Указывайте единицы измерения для количественных
Используйте конкретные измеримые критерии вместо
параметров.
«удобный», «гибкий».
05
06
Утвердительная ф орма
Не в ключайте проектны е решения
Отрицания запутывают и создают двусмысленность.
Описывайте ЧТО нужно достичь, а не КАК реализовать.

9.

Примеры правильных
формулировок
❌ Неправильно
«Система должна формировать отчёт и отправлять его по почте»
«Отчёт должен быть сформирован»
«Система должна быстро открывать страницу»
✓ Правильно
«Система должна формировать отчёт» + «Система должна отправлять
отчёт по email»
«Система должна сформировать отчёт»
«Система должна открывать страницу не более чем за 3 секунды»

10.

Типичны е проблемы и решения
«Золотая пуля»
Паралич анализа
Попытка решать все задачи одним приёмом. Разные ситуации
Увлечение постоянным уточнением требований. Нужен баланс
требуют разных инструментов.
и своевременный переход к реализации.
Неяв ны е знания
«Ползучие» требования
Пользователи делают многое интуитивно. Помогают
Новые потребности без контроля. Решение: чёткий процесс
наблюдения, прототипы и ролевые игры.
управления изменениями и фокус на MVP.

11.

Спасибо за внимание!