1 of 56

Процесс работы с требованиями

МСПИСТ

31.03.2017 г.

Лекция 5

2 of 56

SWEBOK: Requirement Process

  • Requirements Elicitation (Извлечение требований)
  • Requirements Analysis (Анализ требований)
  • Requirements Specification (Специфицирование требований)
  • Requirements Validation (Проверка требований)
  • Requirements Process (Процесс требований)

© Ю.A. Маглинец

2

Процесс анализа требований

3 of 56

SWEBOK: Requirement Process

  • Requirements Elicitation (Извлечение требований)
  • Requirements Analysis (Анализ требований)
  • Requirements Specification (Специфицирование требований)
  • Requirements Validation (Проверка требований)

© Ю.A. Маглинец

3

Процесс анализа требований

4 of 56

SWEBOK: Requirement Process

  • Requirements Elicitation (Извлечение требований)
  • Requirements Analysis (Анализ требований)
  • Requirements Specification (Специфицирование требований)
  • Requirements Validation (Проверка требований)

© Ю.A. Маглинец

4

Процесс анализа требований

5 of 56

Источники требований

© Ю.A. Маглинец

5

Выявление требований

Источники

требований

Документы

Описывающие

предприятие

Эталонные

модели

Результаты

наблюдений

Результаты опроса

Представители

заказчика

Внешние

эксперты

6 of 56

Стратегии выявления требований

© Ю.A. Маглинец

6

Выявление требований

7 of 56

Интервью

© Ю.A. Маглинец

7

Выявление требований

8 of 56

Анкетирование

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

© Ю.A. Маглинец

8

Выявление требований

9 of 56

Совместные семинары

© Ю.A. Маглинец

9

Выявление требований

10 of 56

Мозговой штурм

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

© Ю.A. Маглинец

10

Выявление требований

11 of 56

Участники JAD-совещания

  • Ведущий – специалист в области межличностных коммуникаций. Должен ориентироваться в предметной области, но не обязательно хорошо ориентироваться в проблемах IT.
  • Секретарь – стенографист встречи. Фиксирует её результаты на компьютере. Возможно применение CASE-средств.
  • Заказчики – пользователи или руководители, основные участники, формирующие, обсуждающие требования и принимающие решения.
  • Разработчики – аналитики и другие участники проектной команды. Работают в большей части в пассивном режиме с целью наилучшего понимания проблемной области.

© Ю.A. Маглинец

11

Выявление требований

12 of 56

Разъясняющие встречи

“Разъясняющие встречи” или “запланированный мозговой штурм” – термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п.

© Ю.A. Маглинец

12

Выявление требований

13 of 56

Выявление через прототипы.�Принципы RAD-метода

  • Эволюционное прототипирование;
  • CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;
  • Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;
  • Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;
  • Жёсткие временные рамки, как противоядие от «расползания границ» проекта: если команда не укладывается в срок – функционал сужается.

© Ю.A. Маглинец

13

Выявление требований

14 of 56

SWEBOK: Requirement Process

  • Requirements Elicitation (Извлечение требований)
  • Requirements Analysis (Анализ требований)
  • Requirements Specification (Специфицирование требований)
  • Requirements Validation (Проверка требований)

© Ю.A. Маглинец

14

Процесс анализа требований

15 of 56

SWEBOK: Requirement Process

  • Requirements Elicitation (Извлечение требований)
  • Requirements Analysis (Анализ требований)
  • Requirements Specification (Специфицирование требований)
  • Requirements Validation (Проверка требований)

© Ю.A. Маглинец

15

Процесс анализа требований

16 of 56

© Ю.A. Маглинец

16

Введение

17 of 56

Специфицирование требований

  1. Документ «Концепция»
  2. Детальное описание вариантов использования
  3. Техническое задание

​

© Ю.A. Маглинец

17

Введение

18 of 56

Специфицирование требований

  1. Документ «Концепция»
  2. Детальное описание вариантов использования
  3. Техническое задание

​

© Ю.A. Маглинец

18

Введение

19 of 56

Формирование видения (концепции)

-(от лат. conceptio - понимание - система), определенный способ понимания, трактовки каких-либо явлений, основная точка зрения, руководящая идея для их освещения; ведущий замысел, конструктивный принцип

(БЭС)�

© Ю.A. Маглинец

19

Формирование видения

20 of 56

Видение / Рамки

© Ю.A. Маглинец

20

Формирование видения

​

Концепция

​

Границы

​

Видение

​

Рамки

​

Образ

​

Контекст

21 of 56

ГОСТ 34.601-90

© Ю.A. Маглинец

21

Формирование видения

22 of 56

RUP

© Ю.A. Маглинец

22

Формирование видения

23 of 56

RUP – шаблон�для формулировки проблемы

© Ю.A. Маглинец

23

Формирование видения

Проблема

(описание проблемы)

Затрагивает

(совладельцы, затрагиваемые проблемой).

Ее следствием является

(каково влияние проблемы).

Успешное решение

​

(список некоторых ключевых преимуществ от успешного решения).

24 of 56

Идентификация совладельцев.�Определение границ системы.

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

© Ю.A. Маглинец

24

Формирование видения

25 of 56

Модель FURPS+ (ограничения)

  • Ограничения проектирования, design,
  • Ограничения разработки, implementation,
  • Ограничения на интерфейсы, interface,
  • Физические ограничения, physical.

© Ю.A. Маглинец

25

Введение

26 of 56

Классификация ограничений

© Ю.A. Маглинец

26

Формирование видения

27 of 56

Шаблон документа «Vision» RUP

  1. Введение
  2. Позиционирование
  3. Описания совладельцев и пользователей
  4. Краткий обзор изделия
  5. Возможности продукта
  1. Ограничения
  2. Показатели качества
  3. Очередность и приоритеты
  4. Другие требования к изделию
  5. Требования к документации
  6. Приложение.

© Ю.A. Маглинец

27

Формирование видения

28 of 56

Vision / Scope (MSF)

Согласно белой книге MSF,

на фазе выработки концепции (envisioning phase)

​

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

​

создание и сплочение проектной группы

​

на основе выработки единого видения.

© Ю.A. Маглинец

28

Формирование видения

29 of 56

Vision / Scope (MSF)

Согласно белой книге MSF, на фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения.

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

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

© Ю.A. Маглинец

29

Формирование видения

30 of 56

MSF – envisioning phase

  • Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка vision/scope document.
  • Видение (vision) – это ничем не ограничиваемое представление о том, каким должно быть решение
  • Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.

© Ю.A. Маглинец

30

Формирование видения

31 of 56

MSF – Vision/Scope document

  • Видение (vision) – ничем не ограничиваемое представление о том, каким должно быть решение

​

  • Рамки (scope) –дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.

© Ю.A. Маглинец

31

Формирование видения

32 of 56

Шаблон документа «Vision/Scope» MSF

  1. Бизнес-преимущества

1.1. Описание преимуществ

1.2. Формулировка видения

1.3. Анализ выгод

  • Концепция решения

2.1. Цели, задачи, предположения и ограничения

2.2. Анализ применимости

2.3. Требования

  1. Рамки

3.1. Список характеристик/функций

3.2. Вне рамок

3.3. Стратегия подготовки релизов

3.4. Критерии применимости

3.5. Эксплуатационные критерии

  • Стратегии проектирования решения

4.1. Стратегия проектирования архитектуры

4.2. Стратегия технического проектирования

© Ю.A. Маглинец

32

Формирование видения

33 of 56

Шаблон документа «Vision/Scope» MSF

  1. Бизнес-преимущества

1.1. Описание преимуществ

1.2. Формулировка видения

1.3. Анализ выгод

  • Концепция решения

2.1. Цели, задачи, предположения и ограничения

2.2. Анализ применимости

2.3. Требования

  1. Рамки

3.1. Список характеристик/функций

3.2. Вне рамок

3.3. Стратегия подготовки релизов

3.4. Критерии применимости

3.5. Эксплуатационные критерии

  • Стратегии проектирования решения

4.1. Стратегия проектирования архитектуры

4.2. Стратегия технического проектирования

© Ю.A. Маглинец

33

Формирование видения

34 of 56

Работа с требованиями

  • Формирование видения
  • Выявление требований
  • Классификация и специфицирование требований
  • Расширенный анализ требований (моделирование и прототипирование)
  • Документирование требований
  • Проверка требований
  • Управление требованиями
  • Совершенствование процесса работы с требованиями

​

© Ю.A. Маглинец

34

Процесс анализа требований

35 of 56

Специфицирование требований

  1. Документ «Концепция»
  2. Детальное описание вариантов использования
  3. Техническое задание

​

© Ю.A. Маглинец

35

Введение

36 of 56

Специфицирование требований

  1. Документ «Концепция»
  2. Детальное описание вариантов использования
  3. Техническое задание

​

© Ю.A. Маглинец

36

Введение

37 of 56

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

© Ю.A. Маглинец

37

Специфицирование требований

38 of 56

Требования совладельцев

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

© Ю.A. Маглинец

38

Специфицирование требований

39 of 56

Требования совладельцев - Примеры

Требование к программе электронной почты – «Система должна позволять набирать текст сообщения с возможностью форматирования текста и вставки смайликов».

​

Система продажи «закачек»

© Ю.A. Маглинец

39

Введение

40 of 56

© Ю.A. Маглинец

40

Введение

41 of 56

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

  • Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования, предложенный И.Якобсоном.
  • Прежде, чем приступить собственно к специфицированию требований в форме вариантов использования, RUP рекомендует выявить реестр акторов (actors) и вариантов использования (use cases).

​

© Ю.A. Маглинец

41

Специфицирование требований

42 of 56

Актор

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

© Ю.A. Маглинец

42

Специфицирование требований

43 of 56

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

  • Вариант использования (прецедент) в первом приближении можно рассматривать, просто, как функцию, реализуемую системой.
  • вариант использования должен быть полезен конкретному актору.
  • вариант использования должен позволять получать ему конкретные законченные результаты

© Ю.A. Маглинец

43

Специфицирование требований

44 of 56

Глоссарий

  • Служит основой для единообразного понимания описаний требований Заказчиком и Разработчиком.

​

  • Является отправной точкой для построения
    • объектной модели (для объектно-ориентированных приложений) и
    • модели данных (для генерации схемы базы данных).

© Ю.A. Маглинец

44

Специфицирование требований

45 of 56

Глоссарий

  • Служит основой для единообразного понимания описаний требований Заказчиком и Разработчиком.
  • Является отправной точкой для построения более развёрнутых моделей проблемной области, которые, на стадии реализации информационной системы, ложатся в основу объектной модели (для объектно-ориентированных приложений) и модели данных (для генерации схемы базы данных).
  • Оформляется, как текст, состоящий из абзацев, каждый из которых определяет значение одного из терминов проблемной области. Термин обычно выделяют полужирным кеглем.
  • Иногда проблемную область целесообразно сегментировать на ряд «подобластей» (subject areas). Тогда каждой из них в глоссарии выделяется отдельный параграф.

© Ю.A. Маглинец

45

Специфицирование требований

46 of 56

Спецификации прецедента

Свободный

формат

© Ю.A. Маглинец

46

Специфицирование требований

Полный

формат

Таблица

в три

колонки

Язык

описания

алгоритма

Стиль

RUP

Таблица

в две

колонки

​

Псевдокод

Диаграмма

активности UML

Другие

графические

модели

47 of 56

Таблица в 2 колонки

© Ю.A. Маглинец

47

Специфицирование требований

Актор

Действие

Пользователь

Формирует запрос на поиск заказов

Система

Отображает список заказов

Пользователь

Выбирает требуемый заказ

Система

Показывает подробную информацию по заказу

48 of 56

Таблица в 3 колонки

© Ю.A. Маглинец

48

Специфицирование требований

№

шага

Пользователь

Система

1

Делает запрос на поиск заказов

Отображает список заказов

2

Выбирает требуемый заказ

Показывает подробную информацию по заказу

49 of 56

Полный формат

  1. Название
  2. Контекст использования
  3. Область действия
  4. Уровень
  5. Основное действующее лицо
  6. Участники и интересы
  7. Предусловие
  1. Минимальные гарантии
  2. Гарантии успеха
  3. Триггер
  4. Основной сценарий
  5. Расширения
  6. Список изменений в технологии и данных
  7. Вспомогательная информация

© Ю.A. Маглинец

49

Специфицирование требований

50 of 56

Формат RUP

  1. Наименования и краткое описание
  2. Поток событий

2.1. Основной поток

2.2. Альтернативные потоки

  1. Специальные требования
  2. Предусловия
  3. Постусловия
  4. Точки расширения

© Ю.A. Маглинец

50

Специфицирование требований

51 of 56

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

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

© Ю.A. Маглинец

51

Специфицирование требований

52 of 56

Пример спецификации прецедента

© Ю.A. Маглинец

52

Введение

53 of 56

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

​

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

​

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

© Ю.A. Маглинец

53

Специфицирование требований

54 of 56

Атрибуты требований

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

© Ю.A. Маглинец

54

Специфицирование требований

55 of 56

Атрибуты требований

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

​

  • Для каждого требования указываются значения его соответствующих атрибутов.

© Ю.A. Маглинец

55

Специфицирование требований

56 of 56

Набор атрибутов (К. Вигерс)

© Ю.A. Маглинец

56

Введение