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

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

Что такое требования?

для ее Заказчика и Пользователей

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

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

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

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

В каком виде создаются требования?

Требования могут выражаться в виде текстовых утверждений и графических моделей

На каких этапах жизненного цикла используются проработанные детальные требования?

Концепции.

Пользовательские требования (UI) — определяют набор пользовательских задач, которые должна позволять решать программа, а также способы их решения в системе. Пользовательские требования могут выражаться в виде графического представления пользовательских форм. Описывается в документах по дизайну системы (interface requirement specification (IRS) и Interface Design Document (IDD))

Функциональные требования (DR) — определяют «что» реализовать в продукте. Описываются в SRS (system requirement specification)

Требования к внутренним и внешним интерфейсам (II, EI) – регламентируют правила взаимодействия как внутри системы (т.е. между различными БП), так и правила взаимодействия с другими ИС. Описываются в IRS (interface requirement specification)

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

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

К какому из двух вариантов типов требований относятся:
Бизнес требования; UI; DR; EI; II

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

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

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

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

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

Трассировки требований документируются в виде матрицы трассировок.

Для чего нужны трассировочные матрицы?

Обязательно ли разрабатывать трассировочные матрицы?

по 3 детальных UI - требования к продукту MS Outlook


Приведите по 1 детальному EI - требованию к продукту MS Outlook

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

деле надо»
«Я изменил свое мнение»
«Я забыл, что нам также надо было...»
Рынок
«Мы не можем это больше продавать, рынок требует... »
«Если мы не выпустим это завтра, то потеряем...»
Разработка
Неаккуратные определения границ проекта
Требования непонятны или плохо описаны
Мы просто их не записываем до начала проекта

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

планов
Измерение изменчивости

Определение схемы именования
Определение версии спецификации
Определение версии отдельных требований

Определение возможных состояний
Фиксирование состояния каждого требования
Отчеты о статусах всех требований

Определение связей с другими требованиями
Определение связей с другими частями системы

не описано в явном виде, не существует!

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

варианты использования

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

дает полное представление о том, как это взаимодействие осуществляется

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

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

которые актеры взаимодействуют с системой

Системные функции - это те функции, к которым актеры не имеют непосредственного доступа, но наличие которых необходимо для работы системы

Функции системы – это механизмы заложенные в систему

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

Объектом работы этого механизма является информация

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

Логика функции

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

Анализируется каждая функция с целью определения:
условий начала функции
входных данных
выходных данных
условий завершения функции
логики выполнения функции

Результат данного анализа специфицируется в виде функциональных детальных требований

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

НЕ функциональных требований мобильного телефона.
Каждый по одному требованию

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

ли требуется это?
Когда это требуется?
Как много этого требуется?
Кому это нужно и насколько это важно?
На какое время это требуется?
Насколько это будет меняться со временем?
Можно ли без этого обойтись?

позволит понять, чего же именно просят пользователи

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

Подробно документируйте, на каких пользовательских требованиях основаны требования к системе, варианты использования, списки откликов на события и бизнес-правила.

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

спецификации способствует взаимопониманию разработчиков и пользователей
Существенно способствует оценке трудозатрат и графика
Существенно способствует общению

Против:
Отвечает на вопрос «как», а не «что»
Требует затрат времени
Не заменяет функциональных требований
Неизбежны отклонения