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

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

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

Содержание слайда: Определение

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

Содержание слайда: Виды требований по уровням Бизнес-требования — определяют назначение ПО, описываются в ТЗ, Концепции. Пользовательские требования (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

Содержание слайда: Практика