Требования

1.

Требования

2. Требование

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

3. Виды требований

Бизнес-требования — описывают, зачем нужен продукт или изменение: цели и ценность
для бизнеса. Верхнеуровневые задачи системы.
Пример: У системы должна быть функция личного кабинет, чтобы пользователь мог
управлять своими данными.
Пользовательские требования — это описание потребностей и ожиданий пользователя,
сформулированное на его языке, без технических деталей.
Пример: Как пользователь, я хочу фильтровать товары, чтобы быстрее находить нужные.
Функциональные требования (НФТ) — это конкретные функции системы, которые
реализуют пользовательские требования.
Пример: Система должна обновлять список товаров при изменении фильтра.
Нефункциональные требования (НФТ) — описывают, как система должна работать:
скорость, надёжность, безопасность, удобство.
Пример: система должна обрабатывать до 5000 запросов в минуту и быть доступной
99,9% времени.
.

4.

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

Функциональные требования – это в основном пользовательские
требования и они описывают функции и операции, которые система должна
выполнять.
Отвечают на вопрос: «Что делает система?»
Примеры:
Редактирование задачи:
Зарегистрированный пользователь должен иметь право редактировать
информацию о своих задачах, включая изменение описания и срока
выполнения.
Пометка выполненных задач:
Пользователь должен иметь возможность помечать задачи, как выполненные
для отслеживания прогресса.
Фильтрация задач:
Система должна предоставлять возможность фильтрации задач по статусу
(выполнено/
не выполнено), приоритету, сроку выполнения и другим параметрам.

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

Нефункциональные требования - это в основном требования уровня
реализации, которые касаются атрибутов системы, таких как
производительность, безопасность, надежность и т. д.
Отвечают на вопрос: «Как делает система?»
Группы нефункциональных требований:
Производительность:
Система должна обеспечивать отклик на запросы пользователя не более
чем за 2 секунды, даже при одновременной работе с 100 пользователями.
Надежность:
Вероятность сбоя системы не должна превышать 0.1% в течение месяца
непрерывной работы.
Безопасность:
Вся передаваемая между клиентом и сервером информация должна быть
защищена протоколом шифрования SSL/TLS.

7. Группы нефункциональных требований

Масштабируемость:
Система должна поддерживать масштабирование для обеспечения работы с 100
000
задачами и 1000 пользователями одновременно.
Совместимость:
Веб-интерфейс системы должен быть совместим с последними версиями
популярных веб-браузеров, таких как Chrome, Firefox и Safari.
Доступность:
Система должна быть доступна пользователям не менее 99.9% времени в
течение каждого месяца, включая периоды технического обслуживания.
Управление памятью:
Приложение не должно использовать более 100 МБ оперативной
памяти на устройстве пользователя.

8. Группы нефункциональных требований

Мобильная оптимизация:
Веб-интерфейс должен быть оптимизирован для мобильных устройств,
обеспечивая удобное использование на различных размерах экранов.
Интернационализация:
Система должна поддерживать несколько языков, включая
английский, испанский и французский.
Аудит и мониторинг:
Система должна вести аудит действий пользователей и
предоставлять интерфейс для мониторинга работы приложения
администраторам.

9. «Исключения»

По своей природе это нефункциональные
требования, но кажутся функциональными,
поэтому давайте рассмотрим несколько
примеров:
Безопасность
Требование: Пользователь должен проходить
аутентификацию с использованием
двухфакторной авторизации.
Почему нефункциональное: Аутентификация
влияет на способ доступа, но не определяет
бизнес-функции системы.
Производительность
Требование: Система должна обрабатывать
не менее 1000 запросов в секунду.
Почему нефункциональное: Это требование
относится к скорости работы системы, а не к
тому,
что именно она делает.

10.

Масштабируемость
Требование: Система должна поддерживать до 10 000 активных
пользователей
одновременно.
Почему нефункциональное: Это ограничение влияет на
инфраструктуру и масштаб системы, а не на ее функции.
Доступность и отказоустойчивость
Требование: Время простоя системы не должно превышать 1 час в
месяц.
Почему нефункциональное: Это связано с надежностью
системы, а не с функциональными задачами.
Логирование и мониторинг
Требование: Все действия пользователей должны
записываться в журнал событий.
Почему нефункциональное: Логирование относится к отслеживанию
активности,
а не к бизнес-функциям системы.

11.

Удобство использования
Требование: Интерфейс должен предоставлять подсказки
пользователям
на каждом шаге процесса.
Почему нефункциональное: Это требование связано с удобством
взаимодействия с системой, а не с ее функциями.
Совместимость
Требование: Приложение должно корректно работать на устройствах
с iOS
и Android.
Почему нефункциональное: Это влияет на то, на каких платформах
система может функционировать, а не на сам функционал.
Конфиденциальность данных
Требование: Все данные пользователей должны быть зашифрованы
при передаче и хранении.
Почему нефункциональное: Это требование связано с
защитой данных, а не с функциональными возможностями
системы.

12. Качества требований

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

13.

Качества требований
Поддерживаемость: Требование должно быть стабильным в течение
жизненного цикла проекта. Изменения в требованиях могут привести к
затруднениям и дополнительным затратам.
Согласованность: Требования должны быть согласованы между собой, чтобы
избежать
противоречий. Несогласованные требования могут вызвать путаницу и
проблемы в ходе разработки.
Отслеживаемость: Каждое требование должно быть пронумеровано или
идентифицировано уникальным образом, чтобы обеспечить возможность
отслеживания его статуса в процессе разработки.
Реалистичность: Требование должно быть выполнимым в рамках ресурсов,
доступных
для проекта. Нереалистичные требования могут привести к неудачам в
реализации проекта.

14. Практическое задание по нефункциональным и функциональным требованиям

Мы делаем свой
Озон, накидайте
ФТ и НФТ

15. Методы сбора требований или «Как понять, что хочет заказчик?»

Сбор требований — это как разгадывание загадки. Задача не
проста, но если подойти с умом, можно узнать, что заказчик
действительно хочет. Вот несколько методов:
• Интервью — классика. Задавай вопросы, выслушивай ответы,
и, главное, не бойся уточняющих вопросов. Как у героя
детектива, главное
— следовать следам.
• Анкеты и опросы — Если не получается устроить встречу,
можно отправить вопросы на бумаге или по почте. Только не
перегрузи форму —
важно, чтобы ответы были конкретными.
• Прототипы и макеты — Иногда люди лучше понимают, что им
нужно, когда видят это на бумаге или экране. Создай прототип,
чтобы заказчик мог
визуализировать свои мысли.

16. Методы сбора требований или «Как понять, что хочет заказчик?»

• Анализ документации — Порой ответы
можно найти в уже существующих документах:
отчетах, бизнес-планах, стратегических
документах.
Не забывай искать там.
• Наблюдение за рабочим процессом —
Иногда
сам процесс может рассказать больше, чем
слова. Наблюдай за тем, как работают сейчас,
чтобы понять, что именно нужно улучшить.
• Техники
креативного
мышления
—
Иногда
нужно
выйти
за
рамки
стандартных вопросов.
Используй
техники
типа
"мозговой
штурм"
для
выявления неожиданных требований.
• Анализ конкурентов — Часто бывает, что
необходимо изучить конкурентов(особенно,
если это b2c), чтобы понять, как сейчас
устроен привычный для клиента процесс
взаимодействия.

17. Практическое задание по сбору требований

Сейчас у нас есть только самовывоз, хочу
доставку, распросите меня

18. User Story

User Story — это фреймворк описания требований к программному
обеспечению,
который помогает формулировать функциональность с точки зрения конечного
пользователя.
Он представляет собой краткое, структурированное описание, где акцент
делается на цели и ценности, которые пользователь хочет получить от системы.
Область использования User Story:
• Для сбора потребностей заинтересованных лиц и их приоритезации при
разработке решения.
• В качестве базы для оценки и планирования процесса внедрения решения.
• Как основа для определения сценариев приёмочного тестирования.
• Как метрика для измерения ценности продукта.
• Как элемент трассировки* требований.
• Как основа для последующего анализа.
• Как элемент для управления проектом и отчётности.
*Трассировка требований — процесс отслеживания и документирования связей
между требованиями различного уровня абстракции

19. User Story Текст US должен объяснять роль и действия пользователя в системе, его потребность и желаемый результат, который

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

20. Критерии хорошей User Story

Когда речь заходит о критериях хорошей US, то
всплывает аббревиатура I.N.V.E.S.T, вот как она
расшифровывается:
• Independent — независимая от других историй, то есть истории
могут быть реализованы в любом порядке.
• Negotiable — обсуждаемая, отражает суть, а не детали. Не
содержит конкретных шагов реализации.
• Valuable — ценная для клиентов, бизнеса и стейкхолдеров*.
• Estimable — оцениваемая по сложности и трудозатратам.
• Small — компактная, может быть сделана командой за одну
итерацию.
• Testable — тестируемая, имеет критерии приёмки.
* Стейкхолдеры — это заинтересованные в проекте люди, как
правило, «бизнесзаказчики».

21. Критерии приемки User Story

Критерии приёмки — это чётко сформулированные условия, при
которых User Story считается завершённой.
Они помогают всей команде понимать, что именно нужно
реализовать и какой результат ожидается.
• Для аналитика — это способ задать точные правила поведения
системы.
• Для разработчика — это база для реализации логики.
• Для тестировщика — это основа для написания тест-кейсов.
• Для заказчика — это прозрачность: что будет сделано и как это
проверить
Общие критерии:
1.Функциональность реализована
— Все заявленные действия работают согласно описанию User Story.
2.Ошибки при вводе обрабатываются корректно
— Есть валидация данных и сообщения об ошибках.
3.UI соответствует макету (если применимо)
— Элементы размещены правильно, шрифты, цвета, отступы
соответствуют дизайну.

22. Критерии приемки User Story

4. Бизнес-логика соответствует требованиям
— Вся логика реализована так, как описано в бизнес-требованиях.
5. Нет критических багов
— Реализация протестирована, нет ошибок, блокирующих
использование.
6. Интерфейс работает стабильно на нужных устройствах и
браузерах
(если релевантно)
7. Данные сохраняются и отображаются корректно
— Информация сохраняется в БД и правильно выводится
пользователю.
8. Приемочное тестирование пройдено
— Story протестирована вручную или через автотесты по
сценариям.
9. Обновлена документация/описание задачи (если нужно)
— Изменения зафиксированы в Confluence

23. Пример критерия приемки US

User Story:
Как пользователь,
я хочу, чтобы система формировала отчёт о контрагентах,
чтобы
отслеживать объёмы продаж по каждому контрагенту.
Критерии приёмки:
AC01: Успешное формирование отчёта
Дано: Пользователь находится в разделе "Отчёты"
Когда: Он выбирает пункт "Отчёт по контрагентам"
И: Нажимает кнопку "Сформировать"
Тогда: Система показывает таблицу с контрагентами и их
объёмами продаж за период по умолчанию (последние 30 дней)

24. Пример критерия приемки US

AC02: Выбор периода
Дано: Пользователь находится в отчёте
Когда: Он выбирает период "1 квартал 2025"
Тогда: Система обновляет отчёт и отображает данные только за
этот период
AC03: Экспорт в Excel
Дано: Пользователь открыл сформированный отчёт
Когда: Нажимает кнопку "Скачать Excel"
Тогда: Система скачивает файл отчёта в формате .xlsx
AC04: Ошибка при отсутствии данных
Дано: Пользователь выбрал период, по которому нет данных
Когда: Нажимает "Сформировать"
Тогда: Система показывает сообщение "Нет данных за
выбранный период"

25. Практическое задание по User Story

Функционал корзины,
накидайте к нему US.

26. Use case

Use case (UC) — это популярная форма представления
функциональных требований к ПО в виде пошагового сценария
взаимодействия актора (пользователя или внешнего сервиса) с
проектируемой системой, включая описание метаданных этого
взаимодействия: области применения, предусловия, триггеры,
постусловия, релевантные бизнес-правила и пр.

27. Алгоритм описания функциональных требований к системе

Типовую последовательность разработки функциональных требований в форме
UC
можно представить следующим образом:
1. Определить Акторов — тех, кто взаимодействует с системой
2. Выявить и составить список UC — задач, которые стейкхолдеры смогут
решить
с помощью системы
3. Для каждого юскейса определить контекст применения, конечную цель
и результат
4. Описать основной поток каждого UC в виде последовательности шагов,
которая приведёт к достижению его цели — пользовательского сценария
(use case scenario)
5. Дополнить основной поток расширениями, исключениями и циклами
6. Собрать воедино результаты шагов 4−5, детально описав каждый юскейс
с высоким приоритетом, как алгоритм взаимодействия пользователя с
системой

28. 1. Определить акторов, которые взаимодействуют с системой

Актором может быть несколько разных пользовательских ролей
и/или внешние сервисы, которые будут интегрироваться с
проектируемой системой, то есть получать из неё данные или
вносить их в неё.
Например, если рассматривать мобильный телефон как систему, то
актором будет человек — пользователь мобильного телефона.
Результат этого шага можно оформить в виде таблицы или диаграммы
ролей.

29. 2. Для каждого актора составить список задач

Можно это делать в виде реестра юскейсов —с единой таблицы,
показывающей распределение юскейсов по акторам.
Рекомендуем называть UC в формате «Инфинитив + Объект», где
«Инфинитив» — это инфинитив глагол в совершенного вида с
большой буквы, а «Объект» — это существительное, обозначающее
объект управления с большой буквы.
Из названия варианта использования должно быть сразу понятно,
какую именно задачу пользователя он решает. Например,
«Подписать Документ», «Оформить Заказ», «Оплатить Товар»,
«Сделать Звонок» и так далее.

30. 3. Для каждого UC определить его приоритет

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

31. 3. Для каждого UC определить его приоритет

Самым простым методом приоритизации, который часто применяется на практике,
считается метод MoSCoW, это сокращение следующих 4 категорий:
• Must — то, что необходимо сделать в любом случае. Считается, что без
реализации этих требований решение не будет работать или при отсутствии этих
фич (плюшек, улучшений) продукт не будет нужен потребителям. Чаще всего
этот приоритет называется 1-я очередь и обозначается цифрой 1
• Should — требования 2-ой очереди, которые должны быть реализованы после
тех, что отнесены к группе Must. Это приоритет номер 2
• Could — желательные требования, которые можно сделать, если останется время
и будут ресурсы. Это приоритет номер 3
• Would — требования, которые хотелось бы реализовать, но пока их можно
проигнорировать или перенести на следующие итерации (этапы, повторы) без
вреда для продукта. Это приоритет номер 4

32. Пример приоритизированных UC

Давайте рассмотрим пример приоритизированных задач.
Потребность пользователя
UC
Приоритет
Cвязаться с другим
человеком
Сделать Звонок
Отправить СМС
1 — Must
2 — Should
Скоротать время
Поиграть в казуальную Игру
Посмотреть Фотографии
4 — Would
3 — Could
Сохранить визуальную
информацию
Сделать Фотографию
2 — Should

33. Полная структура юскейса

Давайте разберем каждый элемент этой структуры поподробнее.
Элемент
юскейса
Описание элемента
Пример юскейса
«Сделать звонок»
Имя
Пишется в формате глагол-существительное,
которое описывает достижимую цель и объясняет
смысл сценария
UC 1. Сделать Звонок
Приоритет Ранг важности относительно других юскейсов,
очерёдность реализации
Это может быть предприятие, несколько
Область
информационных систем (ИТ-инфраструктура),
действия
проектируемая система или целый программноаппаратный комплекс
Must
Контекст
Организация удалённого
голосового
взаимодействия с другим
человеком
Окружение, в котором применяется этот UC,
условия или бизнес-процесс
Мобильный телефон

34. Полная структура юскейса

Элемент
юскейса
Описание элемента
Актор
Действующее лицо, кто-то или чтоПользователь мобильного телефона,
то вне системы, влияющий на неё
Внешний абонент
или находящийся под её влиянием.
Это может быть человек, устройство,
другая система или подсистема
Цель
Краткое описание, чего актор хочет
достигнуть с этим вариантом
использования
Предусло Условия, которые должны быть
выполнены для того, чтобы
вия
выполнялся сценарий
Пример юскейса «Сделать звонок»
Поговорить с другим человеком
(внешним абонентом) по телефонной
связи
• Мобильный телефон включен
• Уровень заряда мобильного телефона
достаточен для совершения звонка
• Мобильный телефон доступен для
активных действий (не находится
в состоянии блокировки)

35. Полная структура юскейса

Элемент
юскейса
Результат
(постуслови
я)
Описание элемента
Пример юскейса «Сделать звонок»
Новый объект или
изменение состояния
существующего объекта,
который показывает, что
актор достиг своей цели
Состоялся телефонный разговор пользователя с внешним
абонентом длительностью
не менее 3-х секунд
Основной
поток
Типичный последовательный 1. Пользователь вызвал команду «Позвонить»
порядок пронумерованных
2. Система запрашивает номер телефона вызываемого
шагов
абонента
3. Пользователь сообщает номера телефона вызываемого
абонента
4. Система убеждается в корректности введённого номера
телефона вызываемого абонента
5. Система вызывает абонента по введённому номеру
телефона
6. Система дожидается ответа вызываемого абонента
7. Происходит обмен данными.

36. Полная структура юскейса

Элемент
юскейса
Описание элемента Пример юскейса «Сделать звонок»
Расширения Исключения из
4а. Номер телефона некорректен
шагов основного
потока, которые
4а.1 Система убеждается, что введённый номер
обрабатываются по телефона вызываемого абонента не соответствует
своим алгоритмам шаблону из последовательности цифр от 6 до 11
согласно бизнесцифр, содержит буквы или другие символы
логике процесса
2а.2 Система уведомляет пользователя о том, что
номер телефона указан некорректно и звонок по нему
не может быть совершён
2а.3 Возврат к шагу 2 основного потока
6а. Внешний абонент недоступен для разговора
6а.1 Внешний абонент находится вне зоны действия
сети
6а.2 Система уведомляет пользователя о том, что
внешний абонент недоступен
6а.3 Система завершает выполнение сценария

37. Полная структура юскейса

Элемент
юскейса
Описание элемента Пример юскейса «Сделать звонок»
Расширения Исключения из
6б. Внешний абонент недоступен для разговора
шагов основного
потока, которые
6б.1 Внешний абонент занят
обрабатываются по 6б.2 Система уведомляет пользователя о том, что
своим алгоритмам внешний абонент занят
согласно бизнес6б.3 Система завершает выполнение сценария
логике процесса
7а. Внешний абонент завершил разговор
7а.1 Внешний абонент вызвал команду завершения
звонка
7а.2 Система уведомляет пользователя о том, что
внешний завершил разговор
7а.3 Система завершает выполнение сценария

38. Декомпозиция и оценка задач

Декомпозиция — это процесс разбиения крупной задачи (фичи,
эпика, требования) на более мелкие, управляемые и измеримые
подзадачи.
Цель:
• Повысить прозрачность
• Упростить оценку времени и ресурсов
• Облегчить контроль выполнения
Пример:
Фича: «Отчет по регистрации пользователей»
1) Описание бизнес процесса
2) Проработка фильтра (описание полей, макета и т.п.) на основе
Бизнес
процессов
3) Проработка(описание полей, макета и т.п.) итогового отчета(данных
которые мы
выводим)
Так же будет декомпозиция для системного анализа

39. Уровни декомпозиции задач

Эпик — крупная бизнес-функциональность, объединяющая несколько
фич
Пример: Отчётность по пользователям
Фичи — логически завершённые блоки функциональности
Примеры:
• Фильтр по пользователям
• Итоговый отчёт
• Экспорт в Excel
User Story — конкретные пользовательские сценарии, которые можно
реализовать и протестировать в спринте
Примеры:
• Как менеджер, я хочу отфильтровать пользователей по дате
регистрации, чтобы видеть новых клиентов.
• Как админ, я хочу скачать отчёт в Excel, чтобы отправить его в
бухгалтерию.

40. Вопросы

1. Что такое требование?
2. Виды требований?
3. ФТ? Примеры?
4. НФТ? Примеры?
5. Качества требований?
6. Методы сбора требований?
7. Что такое US?
8. Их формат?
9. Критерии приемки? Примеры?
10.Что такое UC?
11.В каком формате обычно его используют?