Training objective: Introduction to requirements engineering, as well as an understanding of the role and responsibilities of an engineer on demand. Familiarization with the techniques for identifying and documenting requirements. Defining approaches to validation and requirements management.

1. Инженерия требований. Лучшие практики от IREB.
Бульба Евгений, руководитель отдела валидации и дедикации, Certified
Professional for Requirements Engineering, Foundation Level.
Май 23, 2019

2. Содержание
1. Введение в инженерию требований.
2. Понятие системы и контекста.
3. Техники выявления требований.
4. Документирование требований:
4.1. с использованием естественного языка;
4.2. с использованием моделей.
5. Валидация требований.
6. Управление требованиями.
IREB, Май 23, 2019 г. 2

3. Введение в инженерию
требований
IREB, Май 23, 2019 г. 3

4. 1. Введение в инженерию требований (1 из 3)
Краткая справка об IREB.
• IREB (International Requirements Engineering Board) -
некоммерческая организация, разработавшая схему сертификации
в области системного анализа CPRE (Certified Professional for
Requirements Engineering). IREB состоит из ведущих
представителей системного анализа, которые работают в науке,
исследованиях, промышленности и консалтинге.
• IREB была создана в 2006 году. Члены коллегии объединили свои
усилия с целью создания международно признанной и
профессиональной базы в области разработки требований.
• Спустя время, IREB стал всемирно известным авторитетным
экспертным советом по индивидуальной сертификации
профессионалов в области разработки требований.
IREB, Май 23, 2019 г. 4

5. 1. Введение в инженерию требований (2 из 3)
IREB, Май 23, 2019 г. 5
Инженер по требованиям – это человек, который в
сотрудничестве с заинтересованными сторонами:
• выявляет ,
• документирует,
• проверяет и
• управляет требованиями.
IREB Словарь. V1.7

6. 1. Введение в инженерию требований (3 из 3)
IREB, Май 23, 2019 г. 6
Инженерия требований – это системный и дисциплинированный
подход к спецификации и управлению требованиями нацеленный на:
1. Знание соответствующих требований, достижение консенсуса
между заинтересованными сторонами требований,
документирование их в соответствии с данными стандартами, и
систематическое управление ими;
2. Понимание и документирование желаний заинтересованных
сторон и их потребностей;
3. Определение и управление требованиями для минимизации риска
создания системы, которая не отвечает желаниям
заинтересованных сторон и их потребностей.
IREB Словарь. V1.7

7. Понятие системы и
контекста
IREB, Май 23, 2019 г. 7

8. 2. Понятие системы и контекста (1 из 4)
IREB, Май 23, 2019 г. 8
Система – согласованный, разграниченный набор компонентов.
Инженерия требований связана со спецификацией требований к
системам.
Система
Граница системы
Граница системы – граница между системой и окружающим ее
контекстом. Граница системы отделяет разрабатываемую систему от
её среды, то есть она отделяет ту часть реальности, которая может
быть изменена в процессе разработки с учетом аспектов среды,
которая не может быть изменена или модифицирована.

9. 2. Понятие системы и контекста (2 из 4)
IREB, Май 23, 2019 г. 9
Контекст системы – часть среды системы, которая имеет
отношение к определению а также пониманию требований которые
должны быть разработаны.
Контекст системы
Система
Граница системы
Контекстная граница
Нерелевантная среда

10. 2. Понятие системы и контекста (3 из 4)
IREB, Май 23, 2019 г. 10
Серая зона включает в себя определенные аспекты среды, для
которых неясно, имеют ли они отношение к системе или нет. Серая
зона между системой и системным контекстом должна быть
разрешена в ходе разработки требований.
Контекст системы
Граница системы
Контекстная граница
Нерелевантная среда
Серая зона
Система

11. 2. Понятие системы и контекста (4 из 4)
IREB, Май 23, 2019 г. 11
Для документирования
контекста системы
используются диаграммы
потоков данных.

12. Техники выявления
требований
IREB, Май 23, 2019 г. 12

13. 3. Техники выявления требований (1 из 5)
IREB, Май 23, 2019 г. 13
Существует три вида источников требований:
1. Заинтересованные стороны. Примерами заинтересованных
сторон являются пользователи системы, операторы системы,
разработчики, архитекторы, клиенты и тестировщики.
2. Документы. Примерами документов являются универсальные
документы, такие как стандарты и правовые документы, а также
документы, относящиеся к доменной области.
3. Работающие системы. Такие системы предоставляют
заинтересованным сторонам возможность опробовать систему,
они могут получить представление о текущей системе и могут
запросить расширения или изменения, основанные на их
впечатлениях.

14. 3. Техники выявления требований (2 из 5)
IREB, Май 23, 2019 г. 14
Пример реестра заинтересованных сторон.
Не все стороны заинтересованы в успешном выполнении проекта!

15. 3. Техники выявления требований (3 из 5)
IREB, Май 23, 2019 г. 15
Классификация требований в соответствии с моделью Кано.
Модель Кано была
разработана в 1980-х
годах Норияки Кано
и используется для
создания стратегии
компании и решению
задач по
обеспечению
удовлетворенности
клиента.

16. 3. Техники выявления требований (4 из 5)
IREB, Май 23, 2019 г. 16
Цель применения модели Кано для сбора информации – выяснить
сознательные, бессознательные и подсознательные требования
заинтересованных сторон.

17. 3. Техники выявления требований (5 из 5)
IREB, Май 23, 2019 г. 17
Для различных продуктов проектирования требований необходимы
различные техники:
• техники исследования (интервью, анкетирование);
• техники креативности (мозговой штурм, 6-3-5, парадоксальный
мозговой штурм, изменение перспективы, метод аналогии);
• документо-ориентированные техники (программная археология,
чтение, основанное на точке зрения, повторно используемые
требования);
• техники наблюдения (полевые наблюдения, обучение);
• техники поддержки (ментальные карты, мастер-классы, аудио - и
видеозаписи, диаграммы вариантов использования, прототипы).
Наилучшие результаты достигаются с помощью комбинации
различных техник сбора информации.

18. Документирование
требований
IREB, Май 23, 2019 г. 18

19. 4. Документирование требований (1 из 4)
IREB, Май 23, 2019 г. 19
Спецификация требований – это систематически представляемая
совокупность требований, обычно для системы или компонента,
которая удовлетворяет заданным критериям.
Требование:
1. Условие или способность, необходимое пользователю для
решения проблемы или достижения цели.
2. Состояние или способность, которой должна соответствовать или
обладать система или системный компонент для удовлетворения
контракта, стандарта, спецификации или других официально
оформленных документов.
IEEE Std 610.12

20. 4. Документирование требований (2 из 4)
IREB, Май 23, 2019 г. 20
Общие структуры для документов
требований описаны в стандарте
ISO/IEC/IEEE 29148:2011 - International
Standard - Systems and software
engineering - Life cycle processes -
Requirements engineering.
Документы требований должны
соответствовать определенным критериям
качества:
1. Однозначность и непротиворечивость;
2. Понятную структуру;
3. Модифицируемость и расширяемость;
4. Завершенность;
5. Трассируемость.

21. 4. Документирование требований (3 из 4)
IREB, Май 23, 2019 г. 21
Каждое требование должно
удовлетворять определенным
критериям качества, в частности:
1. Согласованность;
2. Однозначность;
3. Необходимость;
4. Непротиворечивость;
5. Проверяемость;
6. Выполнимость;
7. Трассируемость;
8. Завершенность;
9. Понятность.
Помимо критериев качества
требований, существует два
основных правила стиля которые
способствуют читаемости:
1. Короткие предложения и
абзацы;
2. Одно требование в
предложении.

22. 4. Документирование требований (4 из 4)
IREB, Май 23, 2019 г. 22
Среди всего прочего документы требований включают
функциональные требования, которые обычно представляют собой
следующие три взгляда на систему:
1. C точки зрения данных (Data perspective);
2. C точки зрения поведения (Behavioral perspective);
3. C точки зрения функциональности (Functional perspective).
Эффективно применяются следующие формы
документирования:
1. Документирование требований на естественном языке;
2. Концептуальные модели требований, такие как: диаграмма
вариантов использования (Use case diagram), диаграмма
классов (Class diagram), диаграмма деятельности (Activity
diagram) или диаграмма состояний (State diagram).

23. Документирование
требований на
естественном языке
IREB, Май 23, 2019 г. 23

24. 4.1 Документирование требований на естественном
языке (1 из 4)
IREB, Май 23, 2019 г. 24
Пять самых существенных трансформационных процессов для
проектировщика требований:
1. Номинализация;
2. Существительные без справочного указателя;
3. Универсальные квантификаторы;
4. Не полностью определенные условия;
5. Не полностью определяющие процесс слова.

25. 4.1 Документирование требований на естественном
языке (1 из 6)
IREB, Май 23, 2019 г. 25
Номинализация.
С помощью номинализации (иногда длительный) процесс
преобразуется в (единичное) событие. Вся информация, необходимая
для точного описания процесса, теряется. Примеры слов: передача,
прием, архивирование, перезагрузка и т.д.
Требование: «В случае сбоя системы необходимо выполнить
перезагрузку системы».
Термины «сбой и перезагрузка системы» описывают процесс,
который следует проанализировать более точно.

26. 4.1 Документирование требований на естественном
языке (2 из 6)
IREB, Май 23, 2019 г. 26
Существительные без справочного указателя
Как и в случае с глаголами, существительные часто указываются не
полностью. Лингвисты называют это отсутствующим или неявным
указателем. Примеры слов: пользователь, система, сообщение,
данные или функция.
Требование: Данные должны быть отображены пользователю
на терминале.
Какие именно данные? Какой именно пользователь? Какой именно
терминал?
Требование: Программа должна отобразить данные для
выставления счета зарегистрированному пользователю на
терминале, к которому он подключен.

27. 4.1 Документирование требований на естественном
языке (3 из 6)
IREB, Май 23, 2019 г. 27
Универсальные квантификаторы
Универсальные квантификаторы определяют количество или
частоту. Они группируют набор объектов и делают заключение о
поведении этого набора. Примеры слов: никогда, всегда, никто,
каждый, все, некоторые или ничего.
Требование: Система должна показать все наборы данных в
каждом подменю.
Действительно в каждом подменю? Действительно все наборы
данных?

28. 4.1 Документирование требований на естественном
языке (4 из 6)
IREB, Май 23, 2019 г. 28
Не полностью определенные условия
Требования, которые содержат условия, определяют поведение,
которое должно выполняться при выполнении условия. Кроме того,
они должны указывать, какое поведение должно иметь место, если
условие не выполняется (часто отсутствующая часть). Проверочные
слово: если… то, в случае, если и в зависимости от.
Требование: Ресторанная система должна предлагать все
напитки зарегистрированному гостю старше 20 лет.
Требование: Ресторанная система должна предлагать
безалкогольные напитки для любого зарегистрированного
пользователя младше 21 года и все напитки, включая
алкогольные, для пользователя от 21 года и старше.

29. 4.1 Документирование требований на естественном
языке (5 из 6)
IREB, Май 23, 2019 г. 29
Не полностью определяющие процесс слова
Некоторые процессные глаголы требуют более одного
существительного чтобы быть полностью определенным. Например,
глагол “передавать” требует, как минимум три дополнения: что
передается, откуда передается и куда передается.
Требование: Для входа в систему должны быть введены
входные данные.
Требование: Система должна позволять пользователю
вводить имя пользователя и пароль, используя клавиатуру
терминала.

30. 4.1 Документирование требований на естественном
языке (6 из 6)
IREB, Май 23, 2019 г. 30
Пять шагов разработки требований на основе шаблона:
1. Определить правовое обязательство;
2. Определить основу требования;
3. Охарактеризовать деятельность системы;
4. Вставить объекты;
5. Определить логические и временные условия.

31. Документирование
требований с
использованием
моделей
IREB, Май 23, 2019 г. 31

32. 4.2 Документирование требований с использованием
моделей (1 из 6)
IREB, Май 23, 2019 г. 32
Модель – это абстрактное представление существующей или
создаваемой сущности, где под сущностью понимается любая часть
реальности или любой другой возможный набор элементов или
феномен, включая другие модели.
Модели обладают тремя важными свойствами:
1. Представление: модели отражают реальность;
2. Сокращение: модели сокращают представляемую реальность;
3. Назначение: модели строятся для конкретных целей.
Преимущества:
• информацию, представленную в графическом виде, проще понять;
• модели требований делают возможным целенаправленное
моделирование только с одного взгляда на требования.

33. 4.2 Документирование требований с использованием
моделей (2 из 6)
IREB, Май 23, 2019 г. 33
Диаграмма вариантов использования (Use Case Diagrams)
UML (Unified Modeling
Language) – язык
графического описания
для объектного
моделирования и
разработки ПО, для
моделирования бизнес-
процессов, системного
проектирования и
отображения
организационных
структур.

34. 4.2 Документирование требований с использованием
моделей (3 из 6)
IREB, Май 23, 2019 г. 34
Диаграмма классов
(Class Diagrams)

35. 4.2 Документирование требований с использованием
моделей (4 из 6)
IREB, Май 23, 2019 г. 35
Диаграммах потоков данных (Data Flow Diagrams)

36. 4.2 Документирование требований с использованием
моделей ( 5 из 6)
IREB, Май 23, 2019 г. 36
Диаграмма деятельности (Activity Diagrams)

37. 4.2 Документирование требований с использованием
моделей (6 из 6)
IREB, Май 23, 2019 г. 37
Диаграмма состояний (State Diagrams)

38. Валидация
требований
IREB, Май 23, 2019 г. 38

39. 5. Валидация требований (1 из 5)
IREB, Май 23, 2019 г. 39
Цель валидации требований состоит в проверке удовлетворения
требований заданным критериям качества для раннего обнаружения и
исправления ошибок при проектировании требований.
Шесть принципов валидации требований:
1. Привлечение правильных заинтересованных сторон;
2. Разделение обнаружения и исправления ошибок;
3. Валидация с различных точек зрения;
4. Адекватное изменение типа документации;
5. Структурирование артефактов разработки, основанных на
требованиях;
6. Повторная валидация.

40. 5. Валидация требований (2 из 5)
IREB, Май 23, 2019 г. 40
Существует несколько методов систематической валидации
требований, которые частично дополняют друг друга, с целью
максимально полной проверки требований в отношении конкретных
критериев оценки.
Методами валидации требований являются:
1. Комментирование (экспертное мнение);
2. Инспекции;
3. Пошаговый разбор.
Используются следующие дополнительные методы:
1. Чтение, основанное на точке зрения;
2. Валидация с помощью прототипов;
3. Использование чек-листов.

41. 5. Валидация требований (3 из 5)
IREB, Май 23, 2019 г. 41
Согласование требования направлено на создание общего
понимания требований к будущей системе всеми соответствующими
заинтересованными сторонами.
Задачами согласования требований являются:
1. Идентификация конфликта;
2. Анализ конфликта;
3. Решение конфликта;
4. Документирование решений конфликта.

42. 5. Валидация требований (4 из 5)
IREB, Май 23, 2019 г. 42
Типами конфликтов являются:
Конфликт интересов - заинтересованные стороны имеют разные
потребности или противоречивые личные интересы (этот тип
конфликта включает в себя конфликты как объективного, так и
субъективного характера.);
Конфликт данных - заинтересованные стороны по-разному
интерпретируют полученную информацию или имеют неполную
информацию;
Конфликт ценностей - заинтересованные стороны имеют
противоречивые ценности и предпочтения;
Конфликт отношений - эмоциональные проблемы в личных
отношениях между заинтересованными сторонами;
Структурный конфликт - корни конфликта в заинтересованных
сторонах, находящихся на различных уровнях иерархии и принятия
решений власти в организации.

43. 5. Валидация требований (5 из 5)
IREB, Май 23, 2019 г. 43
На практике причины конфликтов часто смешиваются. В
разрешении конфликта должны быть вовлечены все соответствующие
заинтересованные стороны.
Для разрешения конфликтов существует целый ряд методов
разрешения конфликтов, а именно:
• Соглашение;
• Компромисс;
• Голосование;
• Определение вариантов;
• Отмена (аннулирование);
• Рассмотрение всех фактов;
• Метод принятия решений “ПМИ”: Плюс-минус-интересно;
• Матрица решений.

44. Управление
требованиями
IREB, Май 23, 2019 г. 44

45. 5. Управление требованиями (1 из 5)
IREB, Май 23, 2019 г. 45
Для управления требованиями к системе на протяжении всего
жизненного цикла системы, важно собирать информацию о
требованиях в виде максимально структурированных атрибутов.
Атрибут Значение
Идентификатор Короткий, уникальный идентификатор артефакта требования из набора всех
рассматриваемых требований.
Наименование Уникальное, характеризующее название.
Описание Краткое описание содержания требования.
Версия Текущая версия требования.
Автор Указывает автора требования.
Источник Указывает источник требования.
Стабильность Определяет приблизительную стабильность требования. Стабильность - это
количество ожидаемых изменений с учетом требования.
Риск Определяет риск на основе оценки ущерба и вероятности возникновения.
Приоритет Определяет приоритет требования относительно выбранного свойства
приоритизации, например, «важность для принятия на рынке», «порядок
реализации», «потери / альтернативные издержки, если они не реализованы».

46. 5. Управление требованиями (2 из 5)
IREB, Май 23, 2019 г. 46
Усилия по имплементации
по релизам
Статус валидации
базиса требований
БазисТребований
Представление

47. 5. Управление требованиями (3 из 5)
IREB, Май 23, 2019 г. 47
Приоритезация требований.
Подготовка приоритетов требований основывается на простой
системе:
1. Определение целей и ограничений приоритезации;
2. Определение критериев приоритезации;
3. Определение соответствующих заинтересованных лиц;
4. Выбор артефактов приоритезации.
Различают следующие методы приоритезации:
1. Ранжирование и метод Топ-10;
2. Классификация по единому критерию;
3. Классификация по Кано;
4. Матрица приоритезации К. Вигерса.

48. 5. Управление требованиями (4 из 5)
IREB, Май 23, 2019 г. 48
Трассировка требований
Преимущества трассируемости требований включают:
• Упрощение проверяемости;
• Выявление ненужных свойств системы;
• Выявление ненужных требований;
• Поддержка анализа влияния;
• Поддержка многократного использования;
• Поддержка определения ответственности;
• Поддержка обслуживания и администрирования.
Выделяют три класса трассируемости требований:
1. Трассируемость до спецификации требований;
2. Трассируемость после спецификации требований;
3. Трассируемость между требованиями.

49. 5. Управление требованиями (5 из 5)
IREB, Май 23, 2019 г. 49
Матрица трассировки

50. 5. Управление требованиями (6 из 5)
IREB, Май 23, 2019 г. 50
Конфигурация и версионность требований.
Конфигурация требований 1 Конфигурация требований 2
Базовая линия 1
Требование Req-4
версии 1.1
Требования
Версионность

51. 5. Управление требованиями (7 из 5)
IREB, Май 23, 2019 г. 51
Требования меняются на протяжении всего жизненного цикла
продукта.
Задачи группы контроля изменениями:
• Классификация входящих запросов на изменение;
• Определение затрат на выполнение изменения;
• Оценка запросов на изменение в отношении затрат и выгод;
• Определение новых требований, основанных на входящих
запросах на изменение;
• Принятие решения о приемке или отклонении запроса на
изменение;
• Приоритезация принятых запросов на изменение;
• Назначение принятых запросов на изменение проектам для
реализации изменений.

52. Литература
IREB, Май 23, 2019 г. 52

53. Спасибо за внимание!
Вопросы?