Требования

Урок 3
План на сегодня
• Разбор ДЗ
• Требования - понятие
• Требования - виды
• Практика
• Процесс разработки требований
• Планирование БА активностей
• Домашнее задание
Разбор ДЗ
• Задание
• Взять ваш пример
• Автомат по продаже воды
• Кофейный автомат
• Банкомат
• Выбрать методологию: Waterfall or Agile
• Обосновать – почему
• Описать процесс разработки вашего проекта
в соотвествии с выбранной методологией

• Что можно улучшить:

• обосновать с точки зрения бизнеса и
прибыльности. Зачем мы это делаем?
• в процесс разработки включать только
необходимые элементы
Check-in
• Цель на курс
• Остались ли вопросы по
прошлому занятию?

• Что хотите узнать сегодня?

• Напишите 1-3 вопроса на
урок
Что такое требования?
Требования это спецификация того, что должно быть реализовано.
В них описано поведение системы, свойства системы или ее атрибуты.
Они могут служить ограничениями в процессе разработки системы.

(Ian Sommerville и Pete Sawyer, 1997г.)

Зачем нужны требования?
Цель разработки требований – накопить требования, которые позволят
проектировать приложения с приемлемым уровнем риска.

(Карл Вигерс, «Разработка требований к программному обеспечению»)

Виды требований
• Бизнес-требование
• Пользовательское требование
• Функциональное требование
• Нефункциональное требование
• Бизнес-правило
• Ограничение
• Внешнее требование к
интерфейсу
• Системное требование
• Атрибут качества
•….
Зачем? Бизнес-требование

Что? Пользовательские требования

Как? Требования к решению

Функциональные требования Нефункциональные требования

Бизнес-требование
 • aka Business requirements
• Верхний уровень требований, с них все
начинается
• Описывают цели, потребности, задачи
организации и ожидаемый бизнес-результат
• Указывают основные преимущества, которые
система даст заказчикам, клиентам или
Бизнес-требование пользователям
• Формулируются заказчиками, топ-менеджерами,
ответственными за продукт, менеджерами
отделов
• Задача бизнес-аналитика: проследить чтобы
бизнес-требования определяли правильные
заинтересованные лица, описать границы проекта
 • Увеличить объем продаж в праздники
постоянным клиентам на 30%

• Увеличить прирост новых пользователей в

2020 на 10%
Бизнес-требование

• На 30 минут повысить время, которое

пользователь проводит в приложении

• Выйти на рынок B2C

Пользовательское требование
 • aka User requirements or Stakeholder
requirements
• Находятся между бизнес-требованиями и
более детальными требованиями к решению
• Цели и задачи, которые пользователям и
другим заинтересованным лицам позволит
решить система
Пользовательские требования
• Часто представляются в виде Историй
Пользователя (User Stories), Вариантов
Использования (Use Cases), сценариев
• Могут исходить как от бизнеса и
пользователей, так и от бизнес-аналитика.
Формируется User Requirements Document
(URD, or URS, or SrRS)
 • Создать систему показа пользователям
схожих товаров с праздничной скидкой с
учетом истории их заказов

• Обновить модуль бонусов пользователей

функцией вознаграждения за приглашение
друзей
Пользовательские требования

• Показывать в ленте пользователя случайные

фотографии на основе его интересов

• Создать платформу для B2C клиентов для

получения зарплаты на личную карту
Требования к решению
 Требования к решению

Функциональные требования Нефункциональные требования

• aka Solution requirements

• Описывают поведение системы в
соответствии с бизнес и пользовательскими
требованиями
• Достаточно детализированы для
разработки
• Делятся на функциональные и
нефункциональные
• Иногда встречаются transition requirements
 • aka Functional requirements
• Описывают, что система должна делать и
какие возможности предоставлять
пользователю
• Поведение, функционал системы
Функциональные требования • Как и пользовательские, могут
записываться в виде расширенных
Вариантов Использования
• Могут записываться в отдельный документ
FRS, но чаще являются уже частью
детальной SRS
 • Сохранение истории покупок пользователя

• Начисление бонусов за каждого

приглашенного по ссылке друга из записной
книги
Функциональные требования
• Авторизация пользователя через учетную
записью Google

• Определять и записывать категории

посещенных пользователем страниц

Нефункциональные требования
• aka Non-functional requirements
• Описывают не поведение системы, но
условия, в которых система должна
функционировать
• Функциональные описывают, что система
должна делать, а нефункциональные – какой
система должна быть
• Известны также как Атрибуты Качества
• illities:
• safety, security and usability
• accessibility, adaptability, testability,
maintainability, extensibility and scalability…
(look it up)
 • Система должна работать с браузерами
Safari и Chrome последних версий

• Среднее время обработки заказа

Нефункциональные требования пользователей – 5 секунд

• CVV код пользователя не должен

храниться в системе даже на время
проведения транзакции
Что получается?
Зачем?
Увеличить объем продаж в праздники
постоянным клиентам на 30%

Создать систему показа пользователям

Что? схожих товаров с праздничной скидкой
с учетом истории их заказов
Возможность заказать товар в
ближайший к дому фирменный магазин

Сохранение истории покупок Учет и формирование скидок на

Как? пользователя остатки в магазинах и складах

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

Время загрузки страницы не

более 5ти секунд
Качественные требования
Correct (Правильное) – соответствует предметной области и потребностям

Unambiguous (Однозначное) – однозначность толкования и понимания всеми

заинтересованными лицами

Complete (Полное) – полнота предоставленной информации для реализации

Consistent (Непротиворечивое) – два или несколько требований не противоречат друг другу

Testable (Проверяемое) – возможность проверки с использованием механизмов тестирования

Traceable (Прослеживаемое) – отношения между требованиям, соответствие бизнес-

требованиям

Understandable (Понимаемое) – возможность понять требования всеми заинтересованными

лицами

Atomic (Атомарное) – не может быть разбито на ряд более детальных требований без потери
завершенности

Feasible (Выполнимость) – может быть реализовано в рамках проекта

Implementation-free (Абстрактное) – не должно описывать детали технической реализации

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

Группа 3
Процесс разработки требований
Нам нужен план!
Планирование БА активностей
1. Определить заинтересованных лиц, их роли и вовлеченность
в процесс работы над требованиями

2. Определить способы и принципы взаимодействия с

заинтересованными лицами

3. Оценить временные рамки по выполнению задач бизнес-

анализа

4. Определить подход к работе с требованиями, их

приоритизации, отслеживанию, документированию и
коммуникации

5. Установить, что будет результатом работы бизнес-аналитика

6. Определить процессы, методы и инструменты бизнес-

анализа с учетом специфики проекта

7. Установить метрики для оценки работы бизнес-аналитика

 Входные данные Элементы и техники Заинтересованные лица На выходе

1. Бизнес-цели 1. Временные рамки 1. Клиент, эксперт 1. Подход к процессу

бизнес-анализа предметной области, бизнес-анализа
2. Экспертное мнение 2. Формальность и конечные
уровень детализации пользователь
3. Организационные требований 2. Эксперт со стороны
процессы 3. Техники разработки
приоритизации 3. Проджект Менеджер
требований 4. Тестировщик
4. Процесс изменений 5. Регулятор
5. Коммуникация с
заинтересованными
лицами
6. Инструменты для
анализа и управления
требованиями
7. Сложность проекта
8. Методологии
разработки
9. Моделирование
процессов
10. Анализ решений
ДЗ
• Выбрать ваше любимое мобильное
приложение
• Подумать, как его можно улучшить
• Написать:
• 1 бизнес-требование
• 2 пользовательских
• 3 функциональных
• 1 нефункциональное
Check-out
• На все ли вопросы вы
получили ответы?

• Что полезного вы сегодня

узнали?
What’s next?
Выявление требований
• Понятие стейкхолдера. Знакомство со стейкхолдерами.
• Анализ стейкхолдеров
• Процесс выявления требований: цели, задачи
• Анализ документации
• Анализ рынка и конкурентов
• Анкетирование
• Мозговой штурм
• Интервью
• Наблюдение
• Requirements workshops
• Анализ данных
• Анализ бизнес-процессов
Готовьте вопросы:)
Thank you!