Документирование требований. Валидация и верификация требований.

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

Шаблоны спецификаций требований

Вигерс выделяет несколько ключевых типов документов, которые играют центральную роль в документировании требований:

1. Видение и область проекта (Vision and Scope Document):

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

2. Спецификация требований к программному обеспечению (Software Requirements Specification, SRS):

Этот документ детализирует функциональные и нефункциональные требования к системе.
SRS должен включать:

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

3. Спецификации использования (Use Case Specifications):

Важнейший инструмент, который описывает взаимодействие между пользователем и системой через сценарии использования.
Каждая спецификация включает:

Основные шаги взаимодействия;
Альтернативные сценарии;
Ошибочные пути (ошибки, которые могут возникнуть).

Спецификации использования (Use Case Specification)

Проект: Мобильное приложение для фитнеса "FitTrack"

Версия: 1.0
Дата: 28 сентября 2024 года
Автор: Ирина Смирнова, менеджер проекта

1. UC01: Отслеживание физической активности

Описание:

Пользователь отслеживает свои тренировки (бег, ходьба, плавание и т.д.) с помощью носимых устройств или вручную через приложение.

Акторы:

Основной актор: Пользователь (User)
Системы: Устройства Garmin, Fitbit, Apple Watch

Предусловия:

Устройство пользователя синхронизировано с приложением.
Пользователь авторизован в приложении.

Основной поток:

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

Альтернативные потоки:

3а. Пользователь вручную вводит данные о тренировке, если синхронизация с устройством невозможна.

Постусловия:

Данные о тренировке сохранены в истории активности.
Пользователь может просмотреть статистику за день/неделю/месяц.

Исключения:

Сбой синхронизации с устройством (отправка уведомления о необходимости проверки соединения).

2. UC02: Установка и отслеживание целей

Описание:

Пользователь устанавливает цели по физической активности и отслеживает их выполнение.

Акторы:

Основной актор: Пользователь (User)

Предусловия:

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

Основной поток:

Пользователь открывает раздел "Цели".
Пользователь нажимает кнопку "Создать новую цель".
Приложение предлагает выбрать тип цели (шаги, калории, расстояние, тренировки).
Пользователь вводит данные цели (например, 10 000 шагов за день).
Приложение добавляет цель в список активных.
Приложение отслеживает прогресс пользователя по достижению цели и отправляет уведомления о промежуточных результатах.
Когда цель достигнута, приложение отправляет уведомление и предлагает установить новую цель.

Постусловия:

Цель добавлена в список активных целей.
Приложение отслеживает прогресс пользователя.

Исключения:

Пользователь может редактировать или удалить цель до её выполнения.

3. UC03: Получение персонализированных рекомендаций

Описание:

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

Акторы:

Основной актор: Пользователь (User)

Предусловия:

Пользователь авторизован в приложении.
Данные о весе, росте и активности пользователя введены в систему.

Основной поток:

Пользователь открывает раздел "Рекомендации".
Приложение анализирует собранные данные об активности, цели и личные данные пользователя (вес, возраст, уровень активности).
Приложение отображает персонализированные рекомендации по тренировкам и питанию.
Пользователь может просмотреть детализированные рекомендации и выбрать подходящие для выполнения.
Приложение периодически обновляет рекомендации на основе прогресса пользователя.

Постусловия:

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

4. UC04: Синхронизация с носимыми устройствами

Описание:

Приложение синхронизируется с носимыми устройствами для получения данных о физической активности.

Акторы:

Основной актор: Пользователь (User)
Системы: Garmin API, Fitbit API, Apple Watch API

Предусловия:

Устройство пользователя подключено через Bluetooth или Wi-Fi.
Пользователь авторизован и приложение имеет доступ к устройству.

Основной поток:

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

Альтернативные потоки:

2а. Если соединение с устройством отсутствует, приложение отображает уведомление с предложением повторить попытку позже.

Постусловия:

Данные пользователя синхронизированы и отображены в приложении.

Исключения:

Сбой подключения к носимому устройству (отправка уведомления о повторной попытке).

5. UC05: Геймификация (Достижения)

Описание:

Пользователь зарабатывает достижения за выполнение целей и активное участие в тренировках.

Акторы:

Основной актор: Пользователь (User)

Предусловия:

Пользователь авторизован в приложении.
У пользователя установлены цели и задачи.

Основной поток:

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

Постусловия:

Пользователь получает достижение и может просмотреть его в своём профиле.

Исключения:

Если пользователь не завершает тренировку, награда не присуждается.

6. UC06: Управление уведомлениями

Описание:

Пользователь настраивает уведомления о прогрессе по целям и задачам.

Акторы:

Основной актор: Пользователь (User)

Предусловия:

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

Основной поток:

Пользователь открывает настройки уведомлений.
Приложение предлагает варианты настройки (ежедневные уведомления, уведомления о достижении целей, напоминания о тренировках).
Пользователь выбирает типы уведомлений и частоту их получения.
Приложение сохраняет настройки пользователя.
Приложение отправляет уведомления в соответствии с заданными настройками.

Постусловия:

Настройки уведомлений сохранены и активированы.

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

Правила формировки требований

Вигерс уделяет большое внимание тому, как именно формулируются требования. Он приводит несколько ключевых правил:

Ясность:

Каждое требование должно быть настолько чётким, чтобы его нельзя было интерпретировать двояко. Вигерс подчеркивает важность использования точных терминов и избегания двусмысленных выражений.
Пример: вместо "система должна быть быстрой", следует писать "время ответа системы не должно превышать 2 секунд при запросах до 1000 пользователей одновременно".

Полнота:

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

Отсутствие двусмысленности:

Вигерс рекомендует использовать конкретные числа, показатели и метрики для точного описания требований.
Пример: вместо "удобный интерфейс" — "интерфейс должен соответствовать стандартам WCAG 2.0 по уровню AA".

Проверяемость:

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

Последовательность:

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

Важность создания согласованной и полной документации

Вигерс утверждает, что отсутствие качественной и полной документации является одной из главных причин неудач проектов. Чёткая, структурированная и согласованная документация создаёт несколько ключевых преимуществ:

Понимание целей и задач проекта:

Полная документация даёт всем участникам проекта единое представление о том, что должно быть реализовано. Это предотвращает разночтения и помогает каждому члену команды двигаться в одном направлении.

Управление изменениями:

Вигерс подчеркивает, что требования могут и должны изменяться в процессе работы над проектом. Важно, чтобы документация всегда отражала текущее состояние проекта, и все изменения были зафиксированы и согласованы между участниками.
Управление изменениями — это неотъемлемая часть процесса документирования, и Вигерс рекомендует использовать специальные инструменты для версионирования и отслеживания изменений.

Основы для тестирования и проверки:

Полная спецификация требований служит основой для создания тест-кейсов и проведения проверок. Если требования сформулированы точно и понятно, это облегчает процесс тестирования и обеспечивает высокое качество конечного продукта.

Снижение рисков:

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

Валидация и верификация требований

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

Валидация требований

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

Важными аспектами валидации являются:

Соответствие бизнес-целям: Проверяется, помогают ли требования достичь целей, поставленных перед проектом.
Актуальность для пользователей: Определяется, решают ли требования конкретные проблемы пользователей или добавляют ли ценность.

Методы валидации:

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

Верификация требований

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

Основной вопрос верификации: "Правильно ли описаны и структурированы требования для их корректной реализации?"

Методы верификации:

Ревью (обзор требований): Один из самых простых и эффективных методов. В процессе ревью команда проводит совместный анализ документации по требованиям. Это может включать как формальные встречи с детальной проверкой каждого требования, так и менее формальные обсуждения с разработчиками и тестировщиками.
Моделирование: Создание моделей системы, например, с помощью UML или диаграмм потоков данных, позволяет увидеть, как будут взаимодействовать различные компоненты системы, и выявить возможные противоречия или пробелы в требованиях.
Трассировка требований: Этот метод заключается в установлении связи между каждым требованием и соответствующими элементами системы (например, функциональными модулями или тестовыми кейсами). Трассировка помогает убедиться, что все требования учтены и могут быть реализованы.

Тестирование требований на соответствие потребностям бизнеса и пользователей

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

Сценарии использования (Use Cases):

Анализируются сценарии использования для выявления несоответствий или пробелов. Например, можно пройти через каждый шаг взаимодействия пользователя с системой и оценить, все ли требования покрывают описанные сценарии.

Обратная связь от пользователей:

В процессе тестирования требований можно использовать обратную связь от реальных пользователей, чтобы убедиться, что требования соответствуют их ожиданиям и потребностям. Это часто делается на основе прототипов или моделей системы.

Тестирование на полноту и непротиворечивость:

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

Проверка на совместимость, реализуемость и однозначность

Совместимость — это проверка на то, насколько требования соответствуют существующим системам, процессам и технологиям. Требования должны учитывать ограничение существующей архитектуры или интеграцию с другими системами.

Пример: Если новое программное обеспечение должно взаимодействовать с уже существующей ERP-системой, требования должны учитывать все ограничения, связанные с этим взаимодействием.

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

Пример: Если в требованиях указано, что система должна обрабатывать миллионы запросов в секунду, но текущая инфраструктура этого не поддерживает, необходимо пересмотреть такие требования.

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

Пример: Вместо неясных фраз типа "система должна быть удобной", необходимо использовать точные параметры: "время отклика системы не должно превышать 2 секунд при 1000 одновременных пользователей".