🗊Презентация Требования. Основные понятия

Требования. Основные понятия для внутреннего пользования

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

Определение

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

Виды требований по уровням Бизнес-требования — определяют назначение ПО, описываются в ТЗ, Концепции. Пользовательские требования (UI) — определяют набор пользовательских задач, которые должна позволять решать программа, а также способы их решения в системе. Пользовательские требования могут выражаться в виде графического представления пользовательских форм. Описывается в документах по дизайну системы (interface requirement specification (IRS) и Interface Design Document (IDD)) Функциональные требования (DR) — определяют «что» реализовать в продукте. Описываются в SRS (system requirement specification) Требования к внутренним и внешним интерфейсам (II, EI) – регламентируют правила взаимодействия как внутри системы (т.е. между различными БП), так и правила взаимодействия с другими ИС. Описываются в IRS (interface requirement specification)

Виды детальных требований по характеру

Характеристики качественных требований

Характеристики качественных требований

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

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

Пример трассировочной матрицы

Практика Приведите по 3 детальных DR - требования к продукту MS Outlook Приведите по 3 детальных UI - требования к продукту MS Outlook Приведите по 1 детальному EI - требованию к продукту MS Outlook

Управление требованиями. Определение

Почему изменяются требования?

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

Управление требованиями

Основное правило

Источник требований Источники для требований очень сильно зависят от специфики проекта: Сведения от представителей Заказчика Бизнес-требования Сведения от потенциальных пользователей Документы, описывающие предметную область Нормативные документы отрасли Описание бизнес-процессов Нормативные документы предприятия Маркетинговые исследования и опросы пользователей Наблюдение за пользователями на рабочих местах Сценарий анализа задач пользователей

Методы выявления требований Исследования Рабочие группы – Совместная Разработка Приложений Ролевые игры Интервью Прототипы Сценарии и варианты использования

Специфицирование требований Необходимо формализовать требования, собранные в процессе выявления пожеланий пользователей и Заказчика Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования (use case) (прецедентов)

Прецеденты, функции и детальные требования

Прецеденты, функции и детальные требования

Прецеденты, функции и детальные требования

Прецеденты, функции и детальные требования

Практика

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

Типичный перечень вопросов

Поиск неучтенных требований

Нежелательные термины

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

Включение в документ требований описание UI

Практика