Инженерия требований

1.

Инженерия требований
Преподаватель:
Ботов Дмитрий Сергеевич
e-mail: [email protected]

2.

В чем проблема?
«Самой сложной задачей при создании
программной системы является точное
определение того, что требуется
создать… Ни одна задача не приносит
такого же вреда конечной системе в случае
ошибки. И нет ни одной задачи настолько
же сложной в исправлении последствий.»
Фредерик Брукс
2

3.

3

4.

4

5.

5

6.

Требования к ПО
пользователи
заказчик
Бизнестребования
Требования
пользователей
Аналитик требований
Функциональные
требования
6

7.

Требование к ПО
• Некое свойство ПО, необходимое
пользователю для решения проблемы при
достижении поставленной цели
• Некое свойство ПО, которым должна обладать
система или ее компонент, чтобы
удовлетворить требованиям контракта,
стандарта, спецификации либо иной
формальной документации
• Условие или характеристика, которой должна
удовлетворять система (или возможность,
которую должна обеспечивать система)
Dorfman, Thayer, 1990
7

8.

Как получаются плохие требования?
• Недостаточное вовлечение пользователей
• Постоянные изменения и «разрастание»
требований
• Двусмысленность требований
• «Золочение» продукта
• Пользователи, излагающие требования,
непредставительны
• Разработчики могут делать ошибочные
или несогласованные предположения
8

9.

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

10.

Понимание потребностей пользователей
• Примерно для ¼ испытывающих
затруднения проектов недостаточное
понимание реальных требований
заинтересованных лиц является серьезной
проблемой, влияющей на успех проекта
(Standish Group, 1994)
• Выявление требований осложняется 3
синдромами - «да, но…», «неоткрытых
руин», «пользователя и разработчика»
10

11.

Синдром «да, но…»
• «Да, но как насчет …»
• «Нельзя было бы ... ?»
• «А что будет если ... ?»
11

12.

Синдром «неоткрытых руин»
12

13.

Синдром
«пользователя и разработчика»
13

14.

Синдром
«пользователя и разработчика»
• Пользователи не знают, чего хотят, а если и
знаю, то не могут этого объяснить
• Пользователи думают, что они знаю, чего
хотят, до тех пор, пока разработчики не
предоставят им то, чего они якобы хоте ли
• Аналитики думают, что они понимают
проблему пользователя лучше его самого
• Все считают, что другие руководствуются
политическими/финансовыми/личными
мотивами
14

15.

Высокая стоимость ошибок в требованиях
0.1-0.2
Анализ требований
0.5
Проектирование
1
Кодирование
2
Тестирование компонентов
5
Приемка
20
Поддержка и обслуживание
Относительная стоимость исправления ошибки
в различных фазах жизненного цикла
Davis, 1993
15

16.

Действия для исправления ошибок
требований
Повторная спецификация
Повторное проектирование
Повторное кодирование
Повторное тестирование
Замена заказа
Отозвание дефектных версий
Выплаты по гарантийным обязательствам
Ответственность через суд
…
На устранение ошибок в определении требований может
быть истрачено 25-40% бюджета проекта
Boehm, Papaccio, 1998
16

17.

Заинтересованные лица
• Заказчики
• Менеджеры
• Пользователи
– Операторы
– Менеджеры
–…
• Разработчики
• Служба поддержки
• Другие лица
ВАЖНО: заказчик ≠пользователь
17

18.

Разные интересы
Пользователь
Администратор
Легкость в настройке
Полная готовность
к эксплуатации
Надежность
Функциональные возможности
Удобство интерфейса
Разработчик
Технологичность
Красивый код
Минимум переделок
18

19.

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

20.

Функции системы
Функция (feature) – это предоставляемое системой
обслуживание для удовлетворения одной или
нескольких потребностей заинтересованных лиц
Потребности
Функции
системы
Примеры функций:
• «Пользователь будет иметь возможность
увидеть фотографию товара»
• «Необходимо предусмотреть возможность
ввода заказов через Интернет»
• «Все документы для служебного пользования
должны быть защищены от свободного доступа»
20

21.

Требования к ПО
Потребности
Функции
Требования к ПО
Требования к ПО (software requirements)
– это конкретизированные требования,
порождаемые из функций (features)
Если система удовлетворяет этим
требованиям, то она предоставляет
соответствующие функции
21

22.

Пирамида требований
Потребности
Область проблемы
Функции
Требования к ПО
Область решения
22

23.

Свойства требований
• Корректность (correct)
• Однозначность (unambiguous)
• Полнота (complete)
• Непротиворечивость (consistent)
• Приоритезация (prioritized)
• Проверяемость (verifiable)
• Модифицируемость (modifiable)
• Отслеживаемость (traceable)
23

24.

Виды требований
• Функциональные требования
– Бизнес-требования
– Пользовательские требования
• Нефункциональные требования
– Ограничения
– Требования к качеству
– Требования к интерфейсу
– и т.д.
24

25.

25

26.

Функциональные требования
• Бизнес-требования
– Формулируются заказчиками
– Описывают цели, которые требуется достичь с
данной системой
• Требования пользователей
– Какие задачи можно решить с помощью
системы
• Собственно функциональные требования
– Определяются функциональность, которую
необходимо реализовать
26

27.

Нефункциональные требования
• Требования к характеристикам качества
– Требования к надежности
– Требования к совместимости
– Требования к эффективности
– Требования к гибкости
– Требования к эргономике
• Ограничения
– Соответствия стандартам и правилам
– Бюджет
– Сроки
– Предопределенные архитектурные решения
–…
27

28.

Бизнес-требования
• Описывают бизнес-цели, которые хочет
достичь заказчик (клиент, компания)
• Формируют каркас всего проекта: его
образ и границы
• Не предоставляют разработчикам
достаточно информации о реализации
требований
• Любые другие требования и функции
должны удовлетворять бизнестребованиям
28

29.

Требования пользователей
• Описывают цели и задачи, которые
пользователям позволит решить система
• Могут быть описаны в виде:
– Вариантов использования (Модели
прецедентов)
– Сценариев
– Таблицы «событие - отклик»
– User story
29

30.

Понимание потребностей пользователей
• Примерно для ¼ испытывающих
затруднения проектов недостаточное
понимание реальных требований
заинтересованных лиц является серьезной
проблемой, влияющей на успех проекта
(Standish Group, 1994)
• Выявление требований осложняется 3
синдромами - «да, но…», «неоткрытых
руин», «пользователя и разработчика»
30

31.

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

32.

Потребности и функции (продолжение)
Потребность заинтересованного лица –
отражение некоей личной, рабочей или
бизнес-проблемы (или возможности),
решение которой оправдывает замысел,
покупку или использование новой системы
Потребности
Функции
Функции (features) – высокоуровневые
выражения желаемого поведения
продукта или системы
Примеры функций:
Требования к ПО
-«Я хочу увеличить скорость обработки
заказов»
-«Мне нужен новый экран для
отображения деталей сделки»
32

33.

Потребности и функции тесно
взаимосвязаны
Потребность?
что
Функция?
как
Потребности
Функции
Требования к ПО
33

34.

Функции при описании возможностей
• Систему произвольной сложности можно
определить с помощью списка из 25-99 функций,
желательно <50 (рекомендация Лиффингуэлла и
Уидрига)
• Атрибуты функций (статус, приоритет,
трудоемкость, риск, стабильность, целевая версия,
назначение, обоснование и др.) – используются
для связи функций с другой информацией
проекта. Таким образом можно более успешно
управлять сложностью информации
34

35.

Методы выявления требований
• Интервьюирование и анкетирование
• Совещания, посвященные требованиям
• Мозговой штурм
• Раскадровки
• Прецеденты (Use Cases)
• Пользовательские истории (User stories)
• Обыгрывание ролей
• Создание прототипов
35

36.

Интервьюирование
• Простой и понятный метод
• Синдром «пользователя и разработчика»
• Контекстно-свободные вопросы помогают
получить свободные от предубеждений интервью
• Еще не обнаруженные требования можно искать
путем объяснения решений
• Соглашение о некоторых общих потребностях
положит начало «архиву требований», который
будет использоваться при дальнейшей разработке
проекта
36

37.

Примеры контекстно-свободных
вопросов
• Каковы ваши основные обязанности?
• Что и для кого вы в основном производите?
• Почему существует эта проблема?
• Как она решается сейчас?
• Как заказчик (пользователь) хотел бы ее решать?
• Кто такие пользователи?
• Какое у них образование?
• Имеют ли пользователи опыт работы с данным
типом приложений?
• Какой, по-вашему, должна быть
производительность?
• Существуют ли другие вопросы, которые мне
следовало бы вам задать?
37

38.

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

39.

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

40.

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

41.

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

42.

Мозговой штурм: отбор идей
• Отсечение идей, недостойных внимания
• Группировка аналогичных идей
• Определение функций
• Расстановка приоритетов
42

43.

Раскадровки
• Цель – раннее выявление реакций «да, но…»,
синдрома «чистого листа»
• Идентифицируют:
– пользователей системы (игроков)
– что с ними происходит
– как это происходит
• Преимущества:
– предельно недороги
– дружественны пользователю, неформальны и
интерактивны
– обеспечивают ранний анализ пользовательских
интерфейсов системы
– легко создаваемы и модифицируемы
43

44.

Раскадровка интерфейса пользователя
Интернет-магазин приложений Windows
44

45.

Раскадровка интерфейса пользователя
45

46.

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

47.

Применение прецедентов
• Метод является частью методологии ООП
• Прецеденты служат UML-представлением
требований к системе
• Прецеденты описывают взаимодействия
между системой и пользователем, уделяя
основное внимание тому, что система
«делает» для пользователя
• Модель прецедентов описывает
функциональное поведение системы в целом
47

48.

Актор
Актор – это находящееся вне системы нечто
(или некто), взаимодействующее системой
Г.Буч. А. Джекобсон. Дж. Рамбо.
Язык UML: Руководство
пользователя
Обозначение актора на диаграммах UML
48

49.

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

50.

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

51.

Прецедент
Прецедент - описание множества последовательных
событий (включая варианты), выполняемых
системой, которые приводят к наблюдаемому
актором результату.
Г.Буч. А. Джекобсон. Дж. Рамбо.
Язык UML: Руководство
пользователя
Обозначение прецедента на диаграммах UML
ИМЯ
Формула имени: «Глагол + Объект»
Пример: «Разместить заказ»
51

52.

Прецедент
• Какую задачу собирается решить
пользователь с помощью системы?
• Отражает типичное взаимодействие
пользователя и системы
• Охватывает некоторую очевидную для
пользователя функцию
• Может быть как небольшим, так и
достаточно крупным
• Решает некоторую дискретную задачу
пользователя
52

53.

Пример диаграммы прецедентов
53

54.

Обозначения на диаграмме
54

55.

Пример диаграммы прецедентов
55

56.

Документирование прецедентов
Текст
Выделить
1
1..*
Что делать?
Уточнить
Прецедент
1
Описание
поведения
прецедента
1
Выделить
Требования
к системе
Текст
1
1..*
Текст
Сценарии
Как делать?
56

57.

Сценарий
Сценарий - конкретная
последовательность действий,
иллюстрирующая поведение.
Г.Буч. А. Джекобсон. Дж. Рамбо.
Язык UML: Руководство пользователя
57

58.

Формы сценариев
• Простая текстовая форма
• Пользователь вставляет карточку.
Система запрашивает PIN. Пользователь
вводит PIN. Система проверяет PIN.
• Таблица из двух столбцов
Действия пользователя
Вставка карточки
Ввод PIN
Реакция системы
Считывание номера карточки
Запрос PIN
Проверка PIN
58

59.

User stories
(Пользовательские истории)
Способ описания требований к разрабатываемой
системе, сформулированных как одно или более
предложений на ежедневном или деловом языке
пользователя.
Пример:
Я как зарегистрированный и авторизованный
пользователь:
1. Могу нажать на кнопку «Сменить пароль» после
ввода нового пароля на форме «Смена пароля»
2. При этом мой пароль изменяется и я получаю
сообщение об успешной смене пароля
59

60.

60

61.

Способы сбора пользовательских
историй
Пользователь: «Вы сделали в точности то,
о чем я просил, но это не то, чего я хочу»
• Интервьюирование
• Анкетирование
• Наблюдение
• Собрания по написанию историй
– Мозговой штурм
– Черновое прототипирование
61

62.

Черновое прототипирование
Пример: сайт по поиску работы
62

63.

User story из прототипа
• Соискатель может разместить свое резюме на
сайте
• Работодатель может публиковать вакансии
• Работодатель может просмотреть
представленные резюме
• Соискатель может искать вакансии
• Соискатель может посмотреть информацию о
вакансиях с учетом критериев поиска
• Соискатель может посмотреть подробное
описание отдельной вакансии
63

64.

User stories и Use cases
• Пользовательские истории:
– это небольшое и удобное в работе представление информации
– они сформулированы на ежедневном языке пользователя
– содержат небольшие детали, таким образом оставаясь
открытыми для интерпретации
– они помогают читателю понимать что должна делать система.
• Сценарии использования, в отличие от пользовательских
историй:
– описывают процесс и его шаги подробно
– могут быть сформулированы с точки зрения формальной модели

65.

Модель предметной области
• Визуальное представление концептуальных
классов и объектов реального мира в
терминах предметной области
• Не модель программных компонентов
• Модель может отражать:
– Объекты предметной области / концептуальные
классы
– Ассоциации между концептуальными классами
– Атрибуты концептуальных классов
65

66.

Пример: концептуальная модель
для магазина
66

67.

67

68.

Функциональные требования
• Определяют функциональность (поведение)
программной системы, которая должна быть
создана разработчиками
• Описывают возможности системы для
выполнения бизнес-требований с описанием
действий в контексте пользовательских
требований
• Содержат положения с традиционным
«должен»: «Система должна по электронной
почте отправлять пользователю
подтверждение о заказе».
68

69.

Переход к функциональным требованиям
69

70.

Принципы создания требований
• Используйте полные, краткие и ясные предложения
• Используйте действительный залог при описании действия, а
затем опишите наблюдаемый результат:
– «Система сделает + глагол + наблюдаемый результат»
– «Пользователь будет + глагол + наблюдаемый результат»
– Плохой вариант: «Произойдет …»
• Используйте термины из словаря предметной области,
избегайте синонимов и слов, близких по значению
• Указывайте конкретный вид пользователя (или его роль)
вместо обобщенного «пользователь»
• Укажите инициирующие условия и действия
• Визуально представляйте информацию: списки, рисунки,
графики, таблицы
• Соблюдайте один уровень детализации требований
• Избегайте двусмысленных и субъективных терминов и
формулировок
70

71.

71

72.

72

73.

Пример плохо сформулированного
требования
• Пример 1. «Диспетчер фоновых задач
обеспечивает сообщение о состоянии
через регулярные интервалы,
составляющие не менее 60 секунд»
73

74.

Пример исправленного требования
1. Диспетчер фоновых задач (ДФЗ) отобразит
сообщения о состоянии в назначенной области
пользовательского интерфейса.
1.1 Сообщения будут обновляться каждые 60 секунд
плюс/минус 10 секунд после запуска фоновой задачи.
1.2 Сообщения должны оставаться видимыми
постоянно.
1.3 Если взаимодействие с фоновой задачей возможно,
то ДФЗ отобразит процент выполнения фоновой задачи.
1.4 По завершению фоновой задачи ДФЗ отобразит
сообщение ≪Выполнено≫.
1.5 Если выполнение фоновой задачи остановлено, ДФЗ
отобразит соответствующее сообщение.
74

75.

Пример плохо сформулированного
требования
• Пример 2. «Редактор XML должен
моментально переключаться между
режимами отображения и сокрытия
непечатаемых символов»
75

76.

Пример исправленного требования
• «Пользователь сможет переключать
отображение и сокрытие всех тэгов XML в
редактируемом документе с помощью
активации механизма определенного
триггера. Отображение должно
изменяться в течение 0,1 секунды или
менее.»
76

77.

Пример плохо сформулированного
требования
Пример 3. «Анализатор XML выведет отчет
об ошибках в разметке, с помощью которого
даже пользователи, мало знакомые с
языком XML, смогут быстро устранить
ошибки»
77

78.

Пример исправленного требования
1. После того, как анализатор XML
полностью проанализирует файл, он
генерирует отчет об ошибках, в котором
указан номер строки и текст любых XMLошибок, обнаруженных в анализируемом
файле, а также описание каждой
найденной ошибки.
2. Если никаких ошибок в разметке не было
найдено, отчет не генерируется.
78

79.

Пример плохо сформулированного
требования
• Пример 4. «Если возможно, номера счетов
следовало бы проверить по списку
корпоративных счетов»
79

80.

Пример исправленного требования
1. В момент ввода номера счета система
проверит его по основному
корпоративному списку счетов.
2. Если номер счета в списке не найден,
система отобразит сообщение об ошибке
и не примет заказ.
80

81.

Пример: функциональные требования к
библиотечной системе университета
1. Пользователь должен иметь возможность
проводить поиск необходимых ему книг и
документов или по всему множеству
доступных каталожных баз данных или по
определенному их подмножеству.
2. Система должна предоставлять
пользователю подходящее средство
просмотра библиотечных документов.
3. Каждый заказ должен быть снабжен
уникальным идентификатором (ORDER_ID),
который копируется в формуляр
пользователя для постоянного хранения.
81

82.

Способы систематизации функциональных
требований
• По функциям системы
• По вариантам использования
• По режиму работы
• По видам пользователей
• По классам объектов (сущностей)
• Комбинации этих вариантов
Цель: структурировать требования так, чтобы
пользователям и разработчикам было легче
понять предполагаемые возможности системы
82

83.

Границы проекта:
контекстная диаграмма
• Графически иллюстрирует границы
проекта
• Определяет оконечные элементы,
расположенные вне системы и
взаимодействующие с ней
• Определяет потоки информации,
элементы управления и материальные
потоки, протекающие между оконечными
элементами и системой
83

84.

Границы проекта: контекстная
диаграмма
84

85.

85