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

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

для внутреннего пользования

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. Пример трассировочной матрицы

UI.RG-02.21
UI.RG-02.20
UI.RG-02.19
UI.RG-02.18
UI.RG-02.17
UI.RG-02.16
UI.RG-02.15
UI.RG-02.14
UI.RG-02.13
UI.RG-02.12
UI.RG-02.11
UI.RG-02.10
X
UI.RG-02.9
X
UI.RG-02.8
UI.RG-02.7
UI.RG-02.5
UI.RG-02.4
UI.RG-02.3
UI.RG-02.6
DR.RG.02-F-001
DR.RG.02-F-007
DR.RG.02-F-006
DR.RG.02-F-002
DR.RG.02-F-005
DR.RG.02-F-014
DR.RG.02-F-020
DR.RG.02-F-024.02
DR.RG.02-F-021
DR.RG.02-F-080
DR.RG.02-F-091
DR.RG.02-F-084
DR.RG.02-F-100
DR.RG.02-F-060.05
DR.RG.02-F-060
DR.RG.00-F-031
DR.RG.00-F-032
UI.RG-02.2
Внутренний
идентификатор
детального требования
UI.RG-00.2
UI.RG-02.1
Номер экранной формы
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

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 во время
создания спецификации
способствует
взаимопониманию
разработчиков и
пользователей
• Существенно способствует
оценке трудозатрат и
графика
• Существенно способствует
общению
Против:
• Отвечает на вопрос
«как», а не «что»
• Требует затрат
времени
• Не заменяет
функциональных
требований
• Неизбежны
отклонения

33. Практика

ДЗ
Проработать детальные функциональные и не
функциональные требования. Каждый для
своего БП.