5. Работа с требованиями

1. Работа с требованиями

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

Требования являются основой любого программного проекта. Они
определяют цели, функциональность и ограничения продукта.
Эффективная работа с требованиями позволяет минимизировать риски
недопонимания, сократить количество изменений в процессе разработки и
повысить качество конечного продукта.

3. Требования

Требования — это четкое описание характеристик, функций и ограничений
системы, которые необходимы для удовлетворения потребностей
пользователей и бизнеса.
Типы требований:
1. Бизнес-требования — высокоуровневые требования, определяющие бизнеспотребности организации.

4. Бизнес-требования

Бизнес-требования представляют собой высокоуровневое описание целей и
ожиданий организации относительно создаваемого программного продукта.
Эти требования отражают стратегию развития бизнеса, ключевые показатели
эффективности (KPI) и основные задачи, стоящие перед проектом.
Их цель — обеспечить ясность и согласие среди участников проекта
относительно общего направления развития и ключевых бизнес-задач.
Зачем нужны бизнес-требования:
1. Определение стратегических целей. Бизнес-требования помогают
установить долгосрочные цели проекта, ориентированные на достижение
конкретных бизнес-выгод.
2. Обоснование инвестиций. Они служат обоснованием для инвестирования
ресурсов в проект, показывая потенциальную выгоду и окупаемость затрат.
3. Оценка успешности проекта. Бизнес-требования позволяют оценить успех
проекта по заранее установленным критериям.
4. Связь с техническими требованиями. Они формируют основу для
разработки функциональных и нефункциональных требований, обеспечивая
взаимосвязь между бизнесом и технической реализацией.

5. Бизнес-требования

Как формулируются бизнес-требования:
Формулировка бизнес-требований должна быть простой, понятной и
конкретной. Обычно они выражаются в форме утверждений, описывающих
желаемые результаты и выгоды.
Например:
• Повышение производительности сотрудников на X%.
• Увеличение доли рынка на Y%.
• Сокращение операционных расходов на Z%.
Важно учитывать, что бизнес-требования должны быть измеримы и
достижимы, чтобы впоследствии можно было объективно оценить степень их
выполнения.

6. Бизнес-требования

Кто участвует в формировании бизнес-требований:
Основными участниками формирования бизнес-требований являются:
• Владельцы бизнеса или руководители высшего звена, устанавливающие
стратегическое направление.
• Менеджеры проектов, координирующие процесс разработки и реализацию
требований.
• Специалисты по управлению требованиями, обеспечивающие сбор, анализ
и документирование требований.
• Пользователи и клиенты, чьи пожелания и ожидания учитываются при
разработке требований.

7. Бизнес-требования

Примеры бизнес-требований
Вот несколько примеров бизнес-требований для различных типов проектов:
Проект автоматизации склада:
• Уменьшить время обработки заказов на 20% за счет внедрения
автоматизированной системы учета товаров.
• Улучшить точность инвентаризации на 80%, сократив потери продукции.
Разработка CRM-системы:
• Повысить уровень удовлетворенности клиентов на 15% благодаря
улучшению взаимодействия с ними.
• Увеличить продажи на 10% за счет повышения эффективности
маркетинговых кампаний.
Оптимизация ИТ-инфраструктуры предприятия:
• Снизить затраты на обслуживание инфраструктуры на 15% за счет
модернизации оборудования и оптимизации процессов.
• Повысить доступность критически важных сервисов до 99,9% за счет
улучшения отказоустойчивости системы.

8. Требования

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

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

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

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

Как формулируются пользовательские требования:
Формулирование пользовательских требований должно основываться на
глубоком понимании поведения и предпочтений целевой аудитории.
Часто они представлены в виде историй пользователей (User Stories),
содержащих описание сценария использования продукта:
Как <тип пользователя>, я хочу <действие>, чтобы достичь <цели>.
Например:
Как менеджер отдела продаж, я хочу видеть статистику продаж за прошлый
квартал, чтобы принять решение о стратегии продвижения продуктов.
Как клиент интернет-магазина, я хочу легко находить товары по категориям,
чтобы быстро оформить заказ.

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

Этапы разработки пользовательских требований:
Разработка пользовательских требований проходит через несколько основных
этапов:
1. Исследование пользователей. Изучение привычек, желаний и поведения
целевой аудитории.
2. Выявление потребностей. Сбор информации посредством интервью,
анкетирования, анализа обратной связи и тестирования прототипов.
3. Документирование. Оформление полученных данных в формализованный
вид (список требований, User Story).
4. Приоритезация. Оценка важности каждого требования и распределение
приоритетов для дальнейшего планирования разработки.
5. Проверка и утверждение. Утверждение требований заказчиком и командой
разработчиков, проверка их полноты и правильности.

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

Примеры пользовательских требований:
Рассмотрим некоторые типичные примеры пользовательских требований для
различных видов приложений:
1. Интернет-магазин:
• Возможность сортировки товаров по цене, рейтингу и популярности.
• Функция сравнения выбранных товаров.
• Легкий доступ к истории покупок и возврату товара.
2. Приложение банка:
• Простой интерфейс для перевода денег между счетами.
• Быстрый доступ к выпискам и истории операций.
• Настройка уведомлений о поступлении средств и превышении лимита трат.
3. Система бронирования отелей:
• Фильтрация гостиниц по типу номеров, наличию парковочных мест и
близости к достопримечательностям.
• Автоматический подбор оптимальных маршрутов до выбранного отеля.
• Опция предварительного просмотра фотографий помещений гостиницы.

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

Чтобы создать качественные пользовательские требования, следуйте
следующим рекомендациям:
• Используйте естественный язык, близкий пользователям.
• Старайтесь избегать технических деталей, сосредоточившись на описании
желаемого результата.
• Регулярно проверяйте и обновляйте требования, учитывая изменения в
поведении пользователей и новые технологии.
• Активно вовлекайте пользователей в процесс формирования требований,
проводите исследования и тестируйте концепции.
Таким образом, грамотное формирование и использование пользовательских
требований значительно повышает шансы на создание успешного и
востребованного программного продукта.

14. Требования

3. Функциональные требования — детальное описание функциональности
системы.
Функциональные требования детально описывают возможности и поведение
программного продукта с точки зрения выполняемых действий и
предоставляемых услуг.
Они отвечают на вопрос "Что
именно должен делать
продукт?" и включают описание
каждой отдельной функции,
которую система должна
поддерживать. Именно
функциональные требования
непосредственно влияют на
проектирование архитектуры
приложения, разработку
интерфейса и выбор
технологий.

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

Основная цель функциональных требований заключается в следующем:
1. Четкость и прозрачность:
Подробное описание каждой функции помогает участникам проекта ясно
представлять себе конечный продукт.
2. Основа проектирования:
Функциональные требования становятся отправной точкой для
проектирования архитектурных решений и выбора инструментов разработки.
3. Контроль качества:
Проверяя соответствие готового продукта указанным требованиям, команда
гарантирует выполнение запланированных функций.
4. Избежание дублирования усилий:
Полное представление функционала предотвращает двойную работу и лишние
расходы.

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

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

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

Классификация функциональных требований.
Функциональные требования классифицируют по нескольким признакам:
• Обязательные и дополнительные:
Обязательные требования обязательно должны быть выполнены, тогда как
дополнительные улучшают продукт, но не обязательны для минимальной
версии.
• Внешние и внутренние:
Внешние требования касаются внешнего поведения системы (интерфейса, API
и т.п.), тогда как внутренние относятся к внутренним механизмам
функционирования.
• Однородные и разнородные:
Однородные требования связаны с одной функцией, тогда как разнородные
охватывают разные части системы.

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

Ниже приведён пример структуры разделов, используемых при оформлении
функциональных требований:
Общая информация о проекте
Описание предметной области
Архитектура системы
Функциональные блоки и модули
Спецификация модулей
Требования к данным
Тестируемые критерии
Перечень исключительных ситуаций
Дополнительные условия эксплуатации
Каждый раздел подробно раскрывается и дополняется примерами реализации,
моделями данных и необходимыми пояснениями.

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

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

20. Требования

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

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

Можно выделить несколько категорий нефункциональных требований:
1. Производительность: определяет скорость отклика системы, нагрузку на
сервер, пропускную способность сети и другие параметры, влияющие на
быстродействие и отзывчивость программы.
2. Надёжность: характеризует устойчивость системы к сбоям,
восстановление после аварий, предотвращение потерь данных и поддержание
работоспособности в условиях высоких нагрузок.
3. Безопасность: описывает меры защиты от несанкционированного доступа,
взломов, утечек конфиденциальной информации и других угроз
информационной безопасности.
4. Удобство использования (юзабилити): охватывает простоту освоения,
навигацию, дизайн интерфейса и общую привлекательность продукта для
пользователей.
5. Совместимость: отражает способность системы интегрироваться с
существующими технологиями, оборудованием и приложениями.
6. Масштабируемость: показывает возможность расширения и увеличения
нагрузки на систему без ухудшения её характеристик.
7. Поддерживаемость: подразумевает лёгкость обслуживания, обновления и
модификации программного продукта.

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

Пример хорошего нефункционального требования:
Система должна обеспечивать отклик менее двух секунд при выполнении
операции поиска в каталоге товаров даже при пиковой нагрузке в 10 тысяч
одновременных запросов.
Такой подход обеспечивает точное определение необходимого уровня
производительности и создаёт базу для проверки выполненного продукта.
Один из главных вызовов при определении нефункциональных требований —
их качественная оценка и измеримость. Необходимо чётко указывать границы
приемлемого поведения системы, иначе возможны неопределённости и
разногласия на стадии приёмки продукта.
Ещё одна сложность связана с зависимостью некоторых свойств друг от друга
(например, повышение безопасности может снизить производительность).
Поэтому необходимо искать баланс между конкурирующими
характеристиками.

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

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

24. Процесс работы с требованиями

Процесс работы с требованиями включает несколько этапов:
1. Сбор требований
• Интервьюирование заинтересованных сторон
• Анкетирование
• Наблюдение за пользователями
• Анализ документов и отчетов
2. Анализ и документирование
• Структуризация собранных данных
• Формализация требований
• Создание документации (например, спецификации требований)
3. Приоритезация
• Определение приоритетов требований на основе важности и срочности
• Использование методов приоритизации (например, MoSCoW)
4. Утверждение
• Получение одобрения от заинтересованных сторон
• Подписание документа всеми участниками процесса
5. Мониторинг и контроль
• Отслеживание изменений требований
• Управление изменениями
• Обеспечение соответствия требованиям на всех этапах разработки

25. Методы сбора требований

Существует множество методов сбора требований, каждый из которых имеет
свои преимущества и недостатки:
1. Интервьюирование
• Проводится путем личного общения с заинтересованными сторонами
• Позволяет получить подробную информацию и разъяснения
2. Анкетирование
• Используется для массового опроса большого количества респондентов
• Экономично и эффективно при работе с удаленными пользователями
3. Наблюдение
• Включает наблюдение за действиями пользователей в реальных условиях
• Помогает выявить скрытые потребности и проблемы
4. Фокус-группы
• Групповые дискуссии с участием представителей разных групп
пользователей
• Способствуют выявлению общих проблем и предложений
5. Моделирование процессов
• Применение диаграмм потоков работ и моделей UML
• Удобно для визуализации сложных процессов и взаимодействий

26. Инструменты управления требованиями

Для эффективного управления требованиями используются специальные
инструменты, такие как:
• Jira: система отслеживания ошибок и управления проектами
• Confluence: инструмент для совместной работы над документами
• Trello: онлайн-доска для управления задачами
• Visio: средство для построения диаграмм и схем
• Axure RP: программа для прототипирования интерфейсов

27. Инструменты управления требованиями

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

28. Благодарю за внимание