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

Август 9, 2022

Главная
Информатика
Требования. Основные понятия

Содержание

2. Определение Разработка требований к ПО — процесс выявления, формулирования, анализа, документирования и верификации требований, подлежащих выполнению
3. Определение Требования – это: условия, которым должна отвечать информационная система, чтобы представлять ценность для ее Заказчика
4. Цель проработки требований В классическом техническом подходе совокупность требований используется на стадии проектирования ПО. Требования также
5. Виды требований по уровням Бизнес-требования — определяют назначение ПО, описываются в ТЗ, Концепции. Пользовательские требования (UI)
6. Виды детальных требований по характеру Функциональные детальные требования: функции, которые должна реализовывать система алгоритмы реализации функций
7. Характеристики качественных требований Какие характерискити для проверки качества проработки требования вы знаете?
8. Характеристики качественных требований
9. Анализ требований Требования склонны к проблемам: двусмысленности, неполноты, и несогласованности. Их устранение на этапе разработки требований
10. Трассировка детальных требований Существуют разные варианты матриц трассировки, но общий смысл всех их сводится к тому,
11. Пример трассировочной матрицы
12. Практика Приведите по 3 детальных DR - требования к продукту MS Outlook Приведите по 3 детальных
13. Управление требованиями. Определение Управление требованиями - это систематический подход к выявлению, организации и документированию требований к
14. Почему изменяются требования? Заказчик «Вот теперь я увидел и понял, что на самом деле надо» «Я
15. Управление требованиями определение основной версии требований; оценка вероятности воздействия каждого изменения до его принятия; включение одобренных
16. Управление требованиями Управление требованиями Управление изменениями Контроль версий Контроль состояния Контроль связей Предложение изменений Анализ влияния
17. Основное правило Любое требование должно быть описано! Сценарий использования Эскиз экрана Карточка требования И т.д. То,
18. Источник требований Источники для требований очень сильно зависят от специфики проекта: Сведения от представителей Заказчика Бизнес-требования
19. Методы выявления требований Исследования Рабочие группы – Совместная Разработка Приложений Ролевые игры Интервью Прототипы Сценарии и
20. Специфицирование требований Необходимо формализовать требования, собранные в процессе выявления пожеланий пользователей и Заказчика Самым популярным и
21. Прецеденты, функции и детальные требования Прецедент описывает взаимодействие системы с актером и дает полное представление о
22. Прецеденты, функции и детальные требования Пользовательские функции - это те функции, через которые актеры взаимодействуют с
23. Прецеденты, функции и детальные требования Условие начала Условие завершения Входные данные Выходные данные Понятие функции подразумевает
24. Прецеденты, функции и детальные требования Двигаясь по описанию потока, необходимо выявлять действия, связанные с системой и
25. Практика Приведите примеры функциональных требований мобильного телефона. Каждый по одному требованию Приведите примеры НЕ функциональных требований
26. Проблемы выявления требований Выявление – самый сложный этап процесса разработки требований. Особенно из-за того, что придется
27. Типичный перечень вопросов Типичный перечень вопросов, с которых можно начать: Что требуется? Действительно ли требуется это?
28. Поиск неучтенных требований Раскладывайте требования высокого уровня на простейшие составляющие – это позволит понять, чего же
29. СОВЕТЫ по составлению спецификаций
30. Нежелательные термины Приемлемый, адекватный Между Гибкий Улучшенный, более Необязательно Несколько Элегантный, прозрачный, Удобный Быстрый, моментальный Эффективный
31. Иерархия требований Используйте уровни абстракции для разработки древовидной структуры Группируйте по типу и моменту жизненного цикла
32. Включение в документ требований описание UI За: Обсуждение GUI во время создания спецификации способствует взаимопониманию разработчиков
34. Скачать презентацию

Слайд 2

Определение
Разработка требований к ПО — процесс выявления, формулирования, анализа, документирования и

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

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

Слайд 3

Определение
Требования – это:
условия, которым должна отвечать информационная система, чтобы представлять ценность

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

Слайд 4

Цель проработки требований
В классическом техническом подходе совокупность требований используется на стадии

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

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

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

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

Слайд 5

Виды требований по уровням
Бизнес-требования — определяют назначение ПО, описываются в ТЗ,

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

Слайд 6

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

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

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

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

Слайд 7

Характеристики качественных требований
Какие характерискити для проверки качества проработки требования вы знаете?

Слайд 8

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

Слайд 9

Анализ требований
Требования склонны к проблемам:
двусмысленности,
неполноты,
и несогласованности.
Их устранение на

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

Слайд 10

Трассировка детальных требований
Существуют разные варианты матриц трассировки, но общий смысл всех

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

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

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

Слайд 11

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

Слайд 12

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

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

Слайд 13

Управление требованиями. Определение
Управление требованиями - это систематический подход к выявлению, организации

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

Слайд 14

Почему изменяются требования?
Заказчик
«Вот теперь я увидел и понял, что на самом

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

Слайд 15

Управление требованиями
определение основной версии требований;
оценка вероятности воздействия каждого изменения до

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

Слайд 16

Управление требованиями
Управление требованиями
Управление изменениями
Контроль версий
Контроль состояния
Контроль связей
Предложение изменений
Анализ влияния
Принятие решений
Обновление документации
Обновление

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

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

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

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

Слайд 17

Основное правило
Любое требование должно быть описано!
Сценарий использования
Эскиз экрана
Карточка требования
И т.д.
То, что

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

Слайд 18

Источник требований
Источники для требований очень сильно зависят от специфики проекта:
Сведения от

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

Слайд 19

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

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

Слайд 20

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

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

Слайд 21

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

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

Слайд 22

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

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

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

Слайд 23

Прецеденты, функции и детальные требования
Условие начала
Условие завершения
Входные данные
Выходные данные
Понятие функции подразумевает

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

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

Слайд 24

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

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

Слайд 25

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

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

Слайд 26

Проблемы выявления требований
Выявление – самый сложный этап процесса разработки требований. Особенно

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

Слайд 27

Типичный перечень вопросов
Типичный перечень вопросов, с которых можно начать:
Что требуется? Действительно

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

Слайд 28

Поиск неучтенных требований
Раскладывайте требования высокого уровня на простейшие составляющие – это

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

Слайд 29

СОВЕТЫ
по составлению спецификаций

Слайд 30

Нежелательные термины
Приемлемый, адекватный
Между
Гибкий
Улучшенный, более
Необязательно
Несколько
Элегантный, прозрачный,
Удобный
Быстрый, моментальный
Эффективный
Устойчивый к сбоям

Слайд 31

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

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

Слайд 32

Включение в документ требований описание UI
За:
Обсуждение GUI во время создания

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

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

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

Содержание

ОпределениеРазработка требований к ПО — процесс выявления, формулирования, анализа, документирования и

ОпределениеТребования – это:условия, которым должна отвечать информационная система, чтобы представлять ценность

Цель проработки требованийВ классическом техническом подходе совокупность требований используется на стадии

Виды требований по уровнямБизнес-требования — определяют назначение ПО, описываются в ТЗ,

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

Характеристики качественных требованийКакие характерискити для проверки качества проработки требования вы знаете?

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

Анализ требованийТребования склонны к проблемам: двусмысленности, неполноты, и несогласованности.Их устранение на

Трассировка детальных требованийСуществуют разные варианты матриц трассировки, но общий смысл всех

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

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

Управление требованиями. Определение Управление требованиями - это систематический подход к выявлению, организации

Почему изменяются требования?Заказчик«Вот теперь я увидел и понял, что на самом

Управление требованиямиопределение основной версии требований; оценка вероятности воздействия каждого изменения до

Основное правилоЛюбое требование должно быть описано!Сценарий использованияЭскиз экранаКарточка требованияИ т.д.То, что

Источник требованийИсточники для требований очень сильно зависят от специфики проекта:Сведения от

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

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

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

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

Прецеденты, функции и детальные требованияУсловие началаУсловие завершенияВходные данныеВыходные данныеПонятие функции подразумевает

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

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

Проблемы выявления требованийВыявление – самый сложный этап процесса разработки требований. Особенно

Типичный перечень вопросовТипичный перечень вопросов, с которых можно начать:Что требуется? Действительно

Поиск неучтенных требованийРаскладывайте требования высокого уровня на простейшие составляющие – это

СОВЕТЫпо составлению спецификаций

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

Включение в документ требований описание UI За: Обсуждение GUI во время создания

Похожие презентации