Похожие презентации:
Инженерия требований
1.
Инженерия требованийПреподаватель:
Ботов Дмитрий Сергеевич
e-mail: [email protected]
2.
В чем проблема?«Самой сложной задачей при создании
программной системы является точное
определение того, что требуется
создать… Ни одна задача не приносит
такого же вреда конечной системе в случае
ошибки. И нет ни одной задачи настолько
же сложной в исправлении последствий.»
Фредерик Брукс
2
3.
34.
45.
56.
Требования к ПОпользователи
заказчик
Бизнестребования
Требования
пользователей
Аналитик требований
Функциональные
требования
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.
2526.
Функциональные требования• Бизнес-требования
– Формулируются заказчиками
– Описывают цели, которые требуется достичь с
данной системой
• Требования пользователей
– Какие задачи можно решить с помощью
системы
• Собственно функциональные требования
– Определяются функциональность, которую
необходимо реализовать
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.
6061.
Способы сбора пользовательскихисторий
Пользователь: «Вы сделали в точности то,
о чем я просил, но это не то, чего я хочу»
• Интервьюирование
• Анкетирование
• Наблюдение
• Собрания по написанию историй
– Мозговой штурм
– Черновое прототипирование
61
62.
Черновое прототипированиеПример: сайт по поиску работы
62
63.
User story из прототипа• Соискатель может разместить свое резюме на
сайте
• Работодатель может публиковать вакансии
• Работодатель может просмотреть
представленные резюме
• Соискатель может искать вакансии
• Соискатель может посмотреть информацию о
вакансиях с учетом критериев поиска
• Соискатель может посмотреть подробное
описание отдельной вакансии
63
64.
User stories и Use cases• Пользовательские истории:
– это небольшое и удобное в работе представление информации
– они сформулированы на ежедневном языке пользователя
– содержат небольшие детали, таким образом оставаясь
открытыми для интерпретации
– они помогают читателю понимать что должна делать система.
• Сценарии использования, в отличие от пользовательских
историй:
– описывают процесс и его шаги подробно
– могут быть сформулированы с точки зрения формальной модели
65.
Модель предметной области• Визуальное представление концептуальных
классов и объектов реального мира в
терминах предметной области
• Не модель программных компонентов
• Модель может отражать:
– Объекты предметной области / концептуальные
классы
– Ассоциации между концептуальными классами
– Атрибуты концептуальных классов
65
66.
Пример: концептуальная модельдля магазина
66
67.
6768.
Функциональные требования• Определяют функциональность (поведение)
программной системы, которая должна быть
создана разработчиками
• Описывают возможности системы для
выполнения бизнес-требований с описанием
действий в контексте пользовательских
требований
• Содержат положения с традиционным
«должен»: «Система должна по электронной
почте отправлять пользователю
подтверждение о заказе».
68
69.
Переход к функциональным требованиям69
70.
Принципы создания требований• Используйте полные, краткие и ясные предложения
• Используйте действительный залог при описании действия, а
затем опишите наблюдаемый результат:
– «Система сделает + глагол + наблюдаемый результат»
– «Пользователь будет + глагол + наблюдаемый результат»
– Плохой вариант: «Произойдет …»
• Используйте термины из словаря предметной области,
избегайте синонимов и слов, близких по значению
• Указывайте конкретный вид пользователя (или его роль)
вместо обобщенного «пользователь»
• Укажите инициирующие условия и действия
• Визуально представляйте информацию: списки, рисунки,
графики, таблицы
• Соблюдайте один уровень детализации требований
• Избегайте двусмысленных и субъективных терминов и
формулировок
70
71.
7172.
7273.
Пример плохо сформулированноготребования
• Пример 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