Лекция_2_Программная_инженерия_Сбор_и_анализ_требований

1.

ЛЕКЦИЯ 2
Сбор и анализ требований к ПО
От моделей жизненного цикла и Agile-манифеста — к интервью, спецификации,
приоритизации и управлению изменениями.
модели разработки
Agile
requirements
анализ

2.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
1. Короткое повторение первой лекции
Сначала восстановим контекст: модель разработки определяет, когда и как мы работаем с
требованиями.
В этом блоке
• Каскадная, инкрементная, итеративная и спиральная модели — не просто схемы на
картинке: они по-разному организуют обратную связь.
• Agile не является одной конкретной моделью жизненного цикла; это набор ценностей и
принципов, влияющих на организацию разработки.
• Требования существуют во всех подходах, но момент их уточнения, степень детализации и
способ фиксации различаются.
02

3.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Что именно мы повторяем
• Жизненный цикл: путь программного продукта от возникновения потребности и
разработки до эксплуатации, сопровождения и вывода из использования.
• Модель ЖЦ: способ организовать этапы и обратные связи между ними; модель задаёт
порядок работы, но не гарантирует успех сама по себе.
• Методология / подход: правила и практики организации работы команды — роли,
артефакты, ритм, способы планирования и контроля.
• Ключевой вопрос: когда мы получаем обратную связь от заказчика и насколько дорого
изменить уже принятое решение?
03

4.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Каскадная модель: логика последовательных стадий
1
2
3
4
5
Требования
Проектировани
е
Реализация
Тестирование
Ввод
Сначала стараемся
определить и
зафиксировать
основной объём
требований.
Архитектура и
решения строятся
на утверждённой
спецификации.
Команда
программирует то,
что было
спроектировано.
Готовый результат
проверяется на
соответствие
требованиям.
Продукт передаётся
в эксплуатацию и
сопровождение.
→
→
→
→
Сильная сторона — предсказуемость процесса; слабое место — поздняя обратная связь, если требования были поняты неверно.
04

5.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Каскадная модель: когда она удобна, а когда рискованна
Подходит лучше
Риски выше
• Требования относительно стабильны и хорошо
известны заранее.
• Заказчик сам ещё исследует будущий продукт.
• Есть формальные стадии согласования и
документация обязательна.
• Изменения после утверждения дороги и должны
контролироваться.
• Интерфейс и бизнес-процессы требуют ранней
проверки на пользователях.
• Рынок или нормативные условия быстро
меняются.
Waterfall не означает «никогда ничего не менять»; он делает изменения более формальными и обычно более дорогими.
05

6.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Инкрементная модель: продукт растёт частями
1
2
3
4
Инкремент 1
Инкремент 2
Инкремент 3
Дальше
Минимально полезная
часть системы становится
доступна раньше.
Добавляется следующий
набор возможностей.
Продукт расширяется без
ожидания полной
реализации всего объёма.
Каждый прирост должен
интегрироваться с уже
работающей системой.
→
→
→
Инкремент отвечает на вопрос: какую новую часть функциональности мы добавили к продукту?
06

7.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Инкрементность на примере информационной системы
• Первый релиз: авторизация, пользователи и базовый справочник.
• Второй релиз: заявки и их статусы.
• Третий релиз: уведомления, отчёты и экспорт.
• Преимущество: часть бизнес-ценности появляется раньше полного завершения проекта.
• Требование к архитектуре: новые части должны добавляться без разрушения уже
работающих инкрементов.
07

8.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Итеративная модель: решение уточняется повторениями
1
2
3
4
Версия идеи
Реализация
Обратная связь
Уточнение
Формируем
первоначальное
понимание задачи.
Создаём рабочий или
экспериментальный
вариант.
Проверяем решение на
пользователях и данных.
Меняем требования,
дизайн или реализацию и
повторяем цикл.
→
→
→
Итерация отвечает на вопрос: как мы улучшили и уточнили уже выбранное решение?
08

9.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Инкрементная и итеративная — не одно и то же
Инкрементная
Итеративная
• Продукт растёт по объёму возможностей.
• Решение уточняется повторными циклами.
• Каждый шаг добавляет новую функциональную
часть.
• Одна и та же функция может перерабатываться
несколько раз.
• Пример: сначала каталог, затем заказы, затем
отчёты.
• Пример: поиск v1 → тест → улучшенный поиск v2.
На практике подходы часто сочетаются: продукт растёт инкрементами, а каждый инкремент создаётся итеративно.
09

10.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Спиральная модель: цикл вокруг риска
1
2
3
4
5
Цели
Риски
Проверка
Разработка
План
Определяем цели
очередного витка и
возможные
альтернативы.
Выявляем наиболее
опасные
неопределённости.
Прототипируем,
моделируем или
исследуем риск.
Создаём
следующую версию
решения.
Определяем
следующий виток
спирали.
→
→
→
→
Главный отличительный признак спиральной модели — явное управление рисками на каждом витке.
10

11.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Что общего у четырёх моделей
• Во всех случаях нужно понять, какую проблему решает продукт и кому он нужен.
• Во всех случаях существуют требования — различается момент их детализации и частота
пересмотра.
• Чем позже обнаружено неверно понятое требование, тем больше уже созданных решений
приходится переделывать.
• Обратная связь — механизм уменьшения неопределённости, а не формальная «галочка»
процесса.
11

12.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПОВТОРЕНИЕ
Модели через один вопрос: когда мы узнаём, что ошиблись?
Каскадная
Инкрементная
Часто позднее: значительная часть решения уже
спроектирована или реализована.
После каждого поставленного прироста можно проверить
полезность следующей части.
Итеративная
Спиральная
Ошибка ожидаема как часть уточнения решения; цикл
специально создаёт обратную связь.
Сначала стараемся проверить наиболее опасную
неопределённость или риск.
12

13.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
2. Agile-манифест
Agile — не «работа без документов» и не «делаем что угодно каждую неделю». Это система
приоритетов.
В этом блоке
• Манифест формулирует четыре ценности: что ставится выше, когда приходится выбирать
между двумя полезными вещами.
• Правая часть каждой пары тоже важна — Agile не призывает отказаться от процессов,
документации, контрактов или планов.
• Ценности нужны для принятия решений в условиях изменений и неполной информации.
13

14.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
AGILE
Четыре ценности Agile-манифеста
Люди и взаимодействие
Работающий продукт
важнее процессов и инструментов: коммуникация
команды не заменяется системой задач.
важнее исчерпывающей документации: реальное
поведение системы даёт более сильную обратную связь.
Сотрудничество с заказчиком
Готовность к изменениям
важнее согласования условий контракта: требования
уточняются через постоянный диалог.
важнее следования первоначальному плану: план нужен,
но не должен запрещать адаптацию.
14

15.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
AGILE
Как правильно читать формулу Agile
• Манифест не говорит, что элементы справа «не нужны». В оригинальной логике ценность
признаётся у обеих частей пары.
• Смысл слова «важнее» проявляется при конфликте: например, подробный документ не
должен мешать получить работающую обратную связь.
• Agile — не отсутствие планирования. План регулярно обновляется по мере появления новой
информации.
• Agile — не отсутствие требований. Требования могут уточняться ближе к реализации и
храниться в разных формах.
15

16.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
AGILE
Agile и требования
Миф
На практике
• «В Agile требования не документируют».
• Документируют настолько подробно, насколько
это снижает риск и помогает команде.
• «Можно начать кодировать без понимания
задачи».
• «Заказчик каждый день полностью меняет
продукт».
• «User Story заменяет все остальные виды
требований».
• Требования уточняют постепенно, но цель и
ценность должны быть понятны.
• Изменения приоритизируются и управляются.
• User Story — один из форматов, а не
универсальная спецификация.
16

17.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
AGILE
Почему Agile особенно связан с требованиями
• Неопределённость: заказчик не всегда может заранее описать будущую систему во всех
деталях.
• Обратная связь: работающий инкремент помогает увидеть то, что было трудно
сформулировать словами.
• Приоритеты: не все требования одинаково ценны; команда постоянно выбирает, что
реализовать раньше.
• Изменения: новая информация может сделать старое требование неактуальным или
изменить его смысл.
17

18.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
AGILE
От Agile к теме лекции
• Независимо от выбранной модели разработки команда должна понять потребности
заинтересованных сторон.
• Проблема обычно не в том, что «требований нет», а в том, что они неполные,
противоречивые, скрытые или сформулированы разными людьми по-разному.
• Сбор требований — это не переписывание пожеланий заказчика. Это исследование
будущей системы.
• Анализ требований превращает разрозненные пожелания в согласованную и проверяемую
модель продукта.
18

19.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
3. Что такое требование
Перед интервью важно понимать, что именно мы пытаемся получить от заказчика.
В этом блоке
• Требование описывает необходимую возможность, свойство, ограничение или условие,
которому должна соответствовать система.
• Требования существуют на разных уровнях: от бизнес-цели до конкретного поведения
программной функции.
• Одно пожелание пользователя ещё не всегда является готовым требованием — его нужно
уточнить и проверить.
19

20.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ТРЕБОВАНИЯ
Три уровня: от причины к реализации
Бизнес-требование
Пользовательское
требование
Системное требование
Зачем организации вообще нужен
проект? Какую проблему или
показатель мы хотим изменить?
Что пользователь должен уметь
сделать с помощью системы для
достижения своей цели?
Какое наблюдаемое поведение или
свойство должна обеспечить
программная система?
20

21.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ТРЕБОВАНИЯ
Пример цепочки требований
• Бизнес: сократить среднее время обработки заявки с двух дней до четырёх часов.
• Пользователь: оператор должен видеть новые заявки и быстро назначать ответственного.
• Система: система должна отображать список заявок со статусом «Новая» и поддерживать
назначение ответственного сотрудника.
• Проверка связи: если системное требование не помогает ни одной пользовательской или
бизнес-цели, стоит спросить, зачем оно нужно.
21

22.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ТРЕБОВАНИЯ
Потребность, пожелание и требование
Пока ещё пожелание
После анализа
• «Хочется удобный личный кабинет».
• Определены пользователи и задачи личного
кабинета.
• «Нужно, чтобы всё работало быстро».
• «Сделайте как у известного сервиса».
• «Нужен современный дизайн».
• Указаны измеримые ограничения времени
ответа.
• Выделены конкретные функции, которые
действительно нужны.
• Зафиксированы требования к интерфейсу и
доступности.
22

23.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ТРЕБОВАНИЯ
Что может быть требованием
Функция
Качество
Ограничение
Система отправляет пользователю
ссылку для восстановления пароля.
95% запросов каталога
обрабатываются не дольше 2
секунд при заданной нагрузке.
Система должна работать с уже
используемой организацией СУБД.
Правило
Интерфейс
Интеграция
Заявку со статусом «Закрыта»
нельзя редактировать обычному
оператору.
Для обязательных полей форма
показывает явное обозначение и
сообщение при пропуске.
После оплаты система получает
подтверждение от внешнего
платёжного сервиса.
23

24.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ТРЕБОВАНИЯ
Требования описывают наблюдаемый результат
• Хорошее требование говорит, что система должна обеспечивать, а не навязывает
реализацию без необходимости.
• «Хранить пользователей в PostgreSQL» — это ограничение реализации, если технология
действительно задана проектом.
• «Хранить данные пользователей» — функциональная потребность, которую можно
реализовать разными способами.
• Необоснованные технические детали рано сужают пространство решений и могут
увеличить стоимость проекта.
24

25.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
4. Заинтересованные стороны
Требования приходят не от одного «заказчика». У продукта почти всегда несколько групп интересов.
В этом блоке
• Stakeholder — человек, группа или организация, которые влияют на систему, используют её
или испытывают последствия её работы.
• Разные заинтересованные стороны могут иметь разные цели и даже конфликтующие
требования.
• Первый риск интервью — поговорить только с самым доступным человеком и принять его
мнение за мнение всех пользователей.
25

26.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
STAKEHOLDERS
Кто может быть stakeholder
Заказчик / спонсор
Конечный пользователь
Администратор
Определяет бизнес-цель, бюджет,
сроки и ожидаемый эффект.
Выполняет реальные операции и
знает детали ежедневной работы.
Отвечает за настройку, права,
резервное копирование и
сопровождение.
Служба безопасности
Поддержка
Регулятор / аудит
Формулирует требования к доступу,
журналированию и защите данных.
Знает типовые ошибки
пользователей и стоимость
сопровождения.
Может задавать обязательные
правила, сроки хранения и
отчётность.
26

27.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
STAKEHOLDERS
Почему мнения заинтересованных сторон расходятся
• Руководителю важны показатели и контроль; оператору — скорость ежедневной работы.
• Безопасность может требовать дополнительную проверку, а пользователи — меньше
действий при входе.
• Бизнес хочет быстрее выпустить продукт, а эксплуатация — получить диагностируемую и
поддерживаемую систему.
• Аналитик не выбирает «любимую сторону», а делает конфликт явным и помогает согласовать
решение.
27

28.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
STAKEHOLDERS
Карта заинтересованных сторон
1
2
3
4
Найти
Разделить
Оценить
Спланировать
Кто использует,
оплачивает, поддерживает,
контролирует или зависит
от системы?
Какие роли и группы имеют
разные задачи и права?
У кого высокая власть над
проектом и у кого высокая
заинтересованность?
С кем интервью, кого
приглашать на воркшоп,
кого достаточно
информировать?
→
→
→
28

29.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
STAKEHOLDERS
Роли ≠ конкретные люди
• В требованиях полезно мыслить ролями: «оператор», «руководитель», «администратор», а не
фамилиями сотрудников.
• Один человек может выполнять несколько ролей; одна роль может принадлежать сотням
пользователей.
• Права, сценарии и интерфейс обычно привязываются к роли, потому что это стабильнее
персонального списка.
• Исключение: если бизнес-процесс действительно зависит от конкретного должностного
полномочия, это нужно зафиксировать явно.
29

30.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
5. Сбор требований: elicitation
Сбор требований — это активное получение знаний, а не ожидание готового ТЗ от заказчика.
В этом блоке
• Заказчик хорошо знает предметную область, но может не владеть языком требований и не
помнить редкие исключения.
• Разные техники дают разные виды информации: интервью раскрывает мотивы, наблюдение
— реальную практику, документы — формальные правила.
• Обычно используют комбинацию методов, а не одну «правильную» технику.
30

31.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
СБОР ТРЕБОВАНИЙ
Основные техники сбора требований
Интервью
Анкетирование
Наблюдение
Глубокий разговор с конкретной
ролью: цели, сценарии, проблемы,
исключения.
Быстрый сбор мнений большой
группы по заранее подготовленным
вопросам.
Изучение реальной работы
пользователя в контексте его задач.
Воркшоп
Документы
Аналог / прототип
Совместная сессия нескольких
сторон для согласования процесса
и конфликтов.
Регламенты, формы, отчёты,
инструкции, договоры,
нормативные акты.
Изучение существующей системы
или раннего макета для получения
обратной связи.
31

32.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
6. Интервью с заказчиком
Для вашей практической работы это основной инструмент: команда должна получить достаточно
информации для будущего ТЗ.
В этом блоке
• Интервью — управляемый разговор с целью раскрыть задачи, правила, данные,
ограничения и критерии успеха.
• Список вопросов нужен как план, но нельзя превращать интервью в механическое чтение
анкеты.
• Лучший вопрос часто возникает из предыдущего ответа: «почему?», «что происходит
дальше?», «а если…?».
32

33.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Подготовка интервью
1
2
3
4
Цель
Роль
Вопросы
Фиксация
Определить, какие
решения должны быть
приняты после разговора.
Понять, с кем говорим и
какую часть процесса
человек знает лучше всего.
Составить блоки: продукт,
пользователи, функции,
данные, ограничения,
качество.
Распределить роли в
команде: кто ведёт
разговор, кто записывает,
кто следит за пробелами.
→
→
→
33

34.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Хорошая структура интервью
1. Контекст
2. Пользователи
3. Сценарии
Какую проблему решаем? Что
происходит сейчас? Почему
существующий способ не
устраивает?
Кто будет работать с системой? Чем
отличаются их права и задачи?
Что пользователь делает от начала
до результата? Какие есть
альтернативы и ошибки?
4. Данные
5. Качество
6. Ограничения
Что вводится, хранится,
изменяется, импортируется и
выводится?
Какая скорость, доступность,
безопасность и удобство
действительно важны?
Сроки, платформы, интеграции,
законодательство, существующая
инфраструктура.
34

35.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Открытые и закрытые вопросы
Открытые
Закрытые
• «Как сейчас обрабатывается заявка?»
• «Нужна авторизация?»
• «Какие проблемы возникают чаще всего?»
• «Есть ли ограничение на размер файла?»
• «Что должен увидеть руководитель?»
• «Может ли оператор удалять заявку?»
• Хороши для исследования неизвестной
области.
• Хороши для подтверждения конкретного факта.
35

36.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Вопросы, которые раскрывают сценарий
• Что запускает процесс: событие, запрос пользователя, расписание, внешний сигнал?
• Какой результат считается успешным завершением?
• Какие данные пользователь должен иметь до начала работы?
• Какие шаги выполняются обычно и какие исключения встречаются?
• Что система должна делать, если нужных данных нет, сервис недоступен или пользователь
ошибся?
36

37.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Вопросы про роли и права
• Кто создаёт объект, кто может его просматривать, кто изменяет и кто утверждает?
• Есть ли действия, доступные только руководителю или администратору?
• Может ли один пользователь работать от имени нескольких подразделений?
• Что происходит при увольнении, блокировке или смене роли?
• Нужен ли журнал того, кто и когда выполнил критичное действие?
37

38.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Вопросы про данные
• Какие сущности существуют в предметной области и как они называются у пользователей?
• Какие поля обязательны, какие вычисляются автоматически, какие выбираются из
справочника?
• Откуда приходят исходные данные и кому передаются результаты?
• Нужно ли хранить историю изменений, версии документов, вложения?
• Какие объёмы данных ожидаются сейчас и через несколько лет?
38

39.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Вопросы про исключения — самые ценные
• Что происходит, если пользователь ошибся при вводе?
• Можно ли отменить уже выполненное действие? Что должно произойти с зависимыми
данными?
• Что делать, если внешний сервис не отвечает?
• Какие редкие ситуации сейчас приходится решать вручную?
• Есть ли «особые случаи», которые знает только опытный сотрудник?
39

40.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Плохие вопросы и хорошие уточнения
Проблемный вопрос
Полезнее спросить
• «Вам нужна удобная система?»
• «Какие операции сейчас занимают больше
всего времени?»
• «Сделаем современный интерфейс, хорошо?»
• «Ведь администратор должен всё видеть?»
• «Нужен экспорт в Excel?»
• «Что пользователь должен сделать за
минимальное число шагов?»
• «Какие данные администратор действительно
должен видеть и зачем?»
• «Кому, для чего и в каком формате нужен
экспорт?»
40

41.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Не подсказывайте заказчику ответ
• Наводящий вопрос незаметно превращает мнение аналитика в «требование заказчика».
• Сначала выясняем проблему и цель, затем обсуждаем возможные решения.
• Если предлагается вариант, полезно явно отделить его: «один из способов — …; решит ли он
вашу задачу?»
• Особенно опасно сразу спрашивать про конкретную технологию вместо нужной
пользователю возможности.
41

42.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Техника «пять почему» — использовать аккуратно
• Повторное «почему?» помогает дойти от желаемой функции до настоящей причины.
• Пример: нужен экспорт → отчёт отправляют руководителю → руководитель сравнивает
подразделения → нужна сводная аналитика.
• После такого разговора может оказаться, что автоматический дашборд полезнее ручного
Excel-файла.
• Не превращайте технику в допрос: формулировки должны оставаться естественными и
уважительными.
42

43.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИНТЕРВЬЮ
Как фиксировать ответы во время интервью
• Записывайте факты отдельно от предположений и собственных идей команды.
• Помечайте открытые вопросы: «уточнить у администратора», «не определён срок хранения».
• Фиксируйте термины заказчика — они пригодятся для словаря предметной области.
• После встречи быстро оформите заметки, пока контекст ещё помнится.
• Критичные договорённости нужно подтвердить у заказчика, а не полагаться на память.
43

44.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
7. Другие техники elicitation
Интервью даёт глубину, но не всегда показывает реальное поведение или мнение большой группы.
В этом блоке
• Анкетирование полезно для масштаба, наблюдение — для скрытой практики, воркшоп — для
согласования конфликтов.
• Документы дают формальные ограничения, а прототип позволяет обсуждать конкретное
будущее поведение.
• Техника выбирается по вопросу, на который мы хотим получить ответ.
44

45.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ELICITATION
Анкетирование
• Подходит, когда пользователей много и нужно быстро собрать сравнимые ответы.
• Закрытые вопросы легче анализировать статистически; открытые дают идеи, но требуют
ручной обработки.
• Анкета плохо подходит для исследования совершенно неизвестной предметной области:
нельзя спросить о том, о чём вы ещё не знаете.
• Результаты анкеты полезно дополнять интервью с представителями разных групп.
45

46.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ELICITATION
Наблюдение за пользователем
• Люди часто описывают «как должно быть», а работают немного иначе. Наблюдение
показывает фактический процесс.
• Можно увидеть обходные пути: Excel рядом с основной системой, бумажные заметки,
ручные копирования данных.
• Важно не оценивать пользователя, а понимать причины поведения: возможно, текущая
система вынуждает его так работать.
• Наблюдение особенно ценно для сложных операционных процессов.
46

47.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ELICITATION
Воркшоп / совместная сессия
• Несколько заинтересованных сторон одновременно обсуждают процесс, требования или
прототип.
• Преимущество — противоречия становятся видны сразу, а не после серии отдельных
интервью.
• Нужен модератор: иначе встреча легко превращается в спор без решения.
• Результатом должны быть зафиксированные решения, открытые вопросы и ответственные
за уточнение.
47

48.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ELICITATION
Анализ документов и существующей системы
• Регламенты и инструкции помогают найти обязательные шаги, роли и ограничения.
• Формы и отчёты показывают, какие данные реально используются.
• Логи и обращения в поддержку показывают частые ошибки и проблемные сценарии.
• Существующая система — источник знаний, но не эталон: старые ошибки не нужно
автоматически переносить в новый продукт.
48

49.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ELICITATION
Прототипирование как способ уточнить требования
• Пользователю легче реагировать на конкретный макет, чем представлять интерфейс по
абзацу текста.
• Прототип быстро выявляет недостающие поля, неверный порядок действий и непонятную
терминологию.
• Низкодетализированный прототип полезен раньше: его не жалко менять.
• Важно объяснить, что прототип — средство обсуждения, а не обещание готовой
реализации.
49

50.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
8. Функциональные требования
Теперь превращаем собранные сценарии в описание поведения системы.
В этом блоке
• Функциональное требование описывает действие, сервис или реакцию, которую должна
обеспечивать система.
• Обычно оно связано с целью пользователя, событием, входными данными и наблюдаемым
результатом.
• Функциональность нужно описывать достаточно точно, чтобы разработчик и тестировщик
поняли одно и то же.
50

51.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ТРЕБОВАНИЯ
Функциональное требование: от пожелания к проверяемому поведению
Плохо сформулировано
Уточнённый вариант
«В системе должна быть удобная регистрация».
«Система должна позволять новому пользователю
создать учётную запись по адресу электронной почты и
паролю; после успешной регистрации отправляется
письмо подтверждения».
Почему второй вариант лучше
• Определено действие пользователя и результат системы.
• Появились конкретные входные данные.
• Требование можно разложить на тестовые сценарии.
51

52.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Структура простого функционального требования
• Условие / событие: когда и при каких предпосылках функция используется.
• Действие: что пользователь или внешняя система передаёт продукту.
• Реакция системы: какое наблюдаемое поведение должно произойти.
• Результат: какое состояние или данные получаются после успешного выполнения.
• Исключения: что происходит при неверных данных, отсутствии прав или недоступности
зависимости.
52

53.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Избегаем скрытой неоднозначности
Плохо сформулировано
Уточнённый вариант
«Система должна быстро находить
пользователя».
«При поиске по ФИО или email система должна вывести
первые результаты не позднее 2 секунд для каталога до
100 000 пользователей при штатной нагрузке».
Почему второй вариант лучше
• Слово «быстро» заменено измеримым критерием.
• Указан способ поиска и масштаб данных.
• Появились условия, в которых требование проверяется.
53

54.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Гранулярность: не слишком крупно и не слишком мелко
• «Система должна управлять пользователями» слишком широко: внутри создание, поиск,
редактирование, блокировка, роли и многое другое.
• «Кнопка должна иметь ширину 128 пикселей» слишком низкоуровнево, если это не
обоснованное UI-ограничение.
• Хороший уровень позволяет связать требование с пользовательской целью и отдельными
проверками.
• Декомпозиция продолжается до тех пор, пока требование остаётся понятным и
управляемым.
54

55.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
9. Нефункциональные требования
Функции отвечают «что делает система», а НФТ задают свойства, ограничения и качество этого
поведения.
В этом блоке
• Нефункциональное требование часто действует сразу на несколько функций или на систему
в целом.
• Слова «быстро», «безопасно», «удобно», «надёжно» сами по себе не являются хорошими
требованиями.
• Качественное НФТ должно иметь измеримый или хотя бы однозначно проверяемый
критерий.
55

56.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Основные категории НФТ
Производительность
Надёжность
Безопасность
время ответа, пропускная
способность, объём параллельных
операций.
доступность, восстановление после
сбоя, допустимая потеря данных.
аутентификация, авторизация,
защита данных, аудит.
Удобство
Совместимость
Сопровождаемость
понятность, число действий,
доступность для разных
пользователей.
ОС, браузеры, форматы,
интеграционные протоколы.
диагностика, конфигурирование,
модульность, требования к
журналам.
56

57.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
НФТ: производительность
Плохо сформулировано
Уточнённый вариант
«Страницы должны загружаться быстро».
«Для 95% запросов страницы списка время ответа
серверной части не должно превышать 1,5 с при 300
одновременно активных пользователях».
Почему второй вариант лучше
• Есть измеряемая метрика.
• Определён процент запросов, а не идеальный единичный случай.
• Задана нагрузка, при которой критерий должен выполняться.
57

58.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
НФТ: доступность
Плохо сформулировано
Уточнённый вариант
«Система должна быть надёжной».
«Доступность сервиса в рабочие часы 08:00–20:00
должна составлять не менее 99,5% в месяц, исключая
согласованные окна обслуживания».
Почему второй вариант лучше
• Понятно, что именно измеряется.
• Есть период расчёта и временное окно.
• Определено, как учитывать плановое обслуживание.
58

59.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
НФТ: безопасность
Плохо сформулировано
Уточнённый вариант
«Система должна быть безопасной».
«После пяти неуспешных попыток входа за 10 минут
учётная запись блокируется на 15 минут; событие
записывается в журнал безопасности».
Почему второй вариант лучше
• Указано конкретное защищаемое поведение.
• Есть порог, время и реакция.
• Требование можно воспроизвести тестом.
59

60.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Почему НФТ обнаруживаются поздно
• Пользователь естественно рассказывает о функциях: «создать», «найти», «отправить».
Качество он часто считает само собой разумеющимся.
• НФТ становятся заметны при проблеме: система тормозит, недоступна, теряет данные или
неудобна.
• Поэтому аналитик должен задавать отдельные вопросы про нагрузку, безопасность,
доступность и эксплуатацию.
• Позднее НФТ может потребовать архитектурной переделки, поэтому критичные свойства
нужно выявлять рано.
60

61.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
10. Ограничения и бизнес-правила
Не всё требование описывает функцию. Иногда проект обязан работать внутри заданных рамок.
В этом блоке
• Ограничение сужает допустимые способы реализации: платформа, технология, срок,
нормативное требование, интеграция.
• Бизнес-правило существует в предметной области независимо от интерфейса конкретной
программы.
• Важно не смешивать эти понятия с пожеланиями разработчика или случайными привычками
старой системы.
61

62.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ОГРАНИЧЕНИЯ
Примеры ограничений
Технологическое
Интеграционное
Правовое
Развёртывание только в
инфраструктуре организации;
использование существующей
СУБД.
Обмен с внешней системой через
утверждённый API и формат
данных.
Хранение и обработка данных
должны соответствовать
применимым нормативным
требованиям.
Организационное
Платформенное
Ресурсное
Ввод в эксплуатацию до начала
приёмной кампании.
Работа в поддерживаемых
организацией версиях браузеров.
Система должна функционировать
на существующем оборудовании
без его замены.
62

63.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ОГРАНИЧЕНИЯ
Бизнес-правило: логика предметной области
• «Заявку со статусом “Утверждена” может отменить только руководитель подразделения».
• «Скидка более 20% требует дополнительного согласования».
• «Студент не может быть записан на две группы одного занятия одновременно».
• Правило может реализовываться в разных экранах и сервисах, поэтому его полезно хранить
отдельно от конкретной кнопки.
63

64.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
11. Качество требований
После сбора требования нужно проверить: можно ли по ним одинаково понять и проверить будущую
систему?
В этом блоке
• Качественное требование не обязано быть длинным; оно должно быть однозначным,
необходимым и проверяемым.
• Требования образуют систему: даже хорошие отдельные пункты могут противоречить друг
другу.
• Анализ — это поиск пробелов, конфликтов, неопределённостей и лишних решений.
64

65.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
КАЧЕСТВО ТРЕБОВАНИЙ
Признаки хорошего требования
Однозначное
Проверяемое
Необходимое
ключевые термины определены;
разные читатели не получают
разные смыслы.
можно определить тест, измерение,
демонстрацию или инспекцию
результата.
есть stakeholder, цель или
ограничение, которое объясняет
существование требования.
Согласованное
Реализуемое
Трассируемое
не конфликтует с другими
утверждёнными требованиями и
правилами.
может быть выполнено в заданных
технологических и ресурсных
условиях.
понятно происхождение и связи с
целями, сценариями и проверками.
65

66.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
КАЧЕСТВО ТРЕБОВАНИЙ
Слова-маркеры неопределённости
• быстро, удобно, современно, интуитивно, надёжно, максимально, эффективно;
• при необходимости, по возможности, обычно, желательно, и так далее;
• «поддерживать все форматы», «работать на любых устройствах», «обрабатывать большие
объёмы» без границ;
• Такие слова не всегда запрещены в разговоре, но перед фиксацией требования их нужно
раскрыть конкретикой.
66

67.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
КАЧЕСТВО ТРЕБОВАНИЙ
Одно требование — одна проверяемая мысль
Плохо сформулировано
Уточнённый вариант
«Система должна создавать пользователя,
отправлять письмо, вести журнал, быстро
работать и быть безопасной».
Разделить на несколько требований: создание учётной
записи; отправка подтверждения; журналирование
события; критерий времени ответа; требования
безопасности.
Почему второй вариант лучше
• Проще назначать приоритет и статус.
• Каждый пункт можно отдельно тестировать.
• Изменение одного требования не заставляет переписывать огромный составной пункт.
67

68.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
КАЧЕСТВО ТРЕБОВАНИЙ
Полнота — это не максимальный объём текста
• Полное описание охватывает необходимые сценарии, данные, ограничения и исключения
для выбранного уровня детализации.
• Сотни страниц не гарантируют полноту, если забыта важная роль или исключительный
сценарий.
• Полноту проверяют вопросами: кто? что запускает? какие данные? какой результат? что при
ошибке?
• Уровень детализации зависит от риска и стадии проекта: ранний backlog и формальная
спецификация имеют разную глубину.
68

69.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
12. Анализ требований
Собранные ответы нужно структурировать, проверить и превратить в согласованную модель системы.
В этом блоке
• Анализ начинается с классификации и декомпозиции, затем ищутся зависимости, пробелы и
конфликты.
• Нужно отделить проблему от предложенного решения и понять приоритеты.
• Результат анализа — не только документ, а общее понимание будущего поведения продукта.
69

70.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
АНАЛИЗ
Что делаем после интервью
1
2
3
4
5
Очистить
Классифициров
ать
Связать
Найти пробелы
Согласовать
Переписать
заметки, убрать
дубли, отделить
факты от гипотез.
Роли, функции, НФТ,
данные, правила,
ограничения,
вопросы.
Показать, какие
требования
поддерживают цели
и сценарии.
Исключения, права,
ошибки,
интеграции,
качество.
Вернуть спорные и
критичные пункты
stakeholder-ам.
→
→
→
→
70

71.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
АНАЛИЗ
Декомпозиция требования
• Крупное пожелание «управление заявками» раскладывается на создание, просмотр, поиск,
изменение, назначение, изменение статуса и закрытие.
• Каждая функция затем уточняется по ролям, данным, предусловиям и исключениям.
• Декомпозиция помогает оценивать объём и находить забытые случаи.
• Но слишком мелкая нарезка создаёт сотни бессмысленных микропунктов — нужен баланс.
71

72.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
АНАЛИЗ
Поиск противоречий
• Оператор говорит: «после отправки заявку нельзя менять»; руководитель просит
возможность исправить данные.
• Безопасность требует короткую сессию; пользователи хотят никогда не входить повторно.
• Бизнес хочет хранить всю историю; инфраструктура ограничивает объём хранения.
• Конфликт не нужно скрывать формулировкой. Его фиксируют и выносят на решение
ответственных сторон.
72

73.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
АНАЛИЗ
Отделяем требование от решения
• «Нужна кнопка Excel» может скрывать потребность регулярно передавать руководителю
сводные данные.
• «Нужен чат» может означать, что пользователям не хватает статуса и комментариев по
заявке.
• «Сделайте мобильное приложение» может быть попыткой решить доступ к системе вне
рабочего места.
• Сначала фиксируем цель, затем сравниваем варианты реализации по стоимости и
ограничениям.
73

74.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
13. Приоритизация требований
Когда требований больше, чем можно реализовать сразу, нужен прозрачный способ выбора.
В этом блоке
• Приоритет — не характеристика «нравится / не нравится», а решение о ценности, срочности,
риске и зависимости.
• Приоритизация особенно важна в инкрементной и Agile-разработке.
• Метод должен быть понятен stakeholder-ам, иначе каждый пункт превращается в «самый
важный».
74

75.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРИОРИТИЗАЦИЯ
MoSCoW
Must have
Should have
Без требования релиз не решает ключевую задачу,
нарушает обязательное правило или становится
неприемлемым.
Очень важно и желательно в релизе, но существует
временный обходной путь.
Could have
Won’t have now
Полезное улучшение, которое можно исключить первым
при нехватке ресурсов.
Осознанно не входит в текущий объём; это не означает
«никогда».
75

76.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРИОРИТИЗАЦИЯ
Ошибка MoSCoW: всё становится Must
• Если 90% требований получили Must, метод перестал помогать принимать решения.
• Для Must полезно задать вопрос: «что конкретно произойдёт, если этого не будет в текущем
релизе?»
• Should может быть очень ценным, но релиз всё ещё возможен без него.
• Won’t now фиксирует границу объёма и защищает команду от бесконечного расширения
scope.
76

77.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРИОРИТИЗАЦИЯ
Кроме MoSCoW учитываем зависимости и риск
• Функция может иметь среднюю бизнес-ценность, но быть технической основой для пяти
других функций.
• Рискованное требование иногда полезно исследовать раньше, чтобы не обнаружить
невозможность в конце проекта.
• Обязательное нормативное требование имеет высокий приоритет независимо от
пользовательской популярности.
• Приоритет должен пересматриваться при изменении целей, сроков и новой информации.
77

78.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
14. Use Case — сценарий взаимодействия
Use Case помогает описать цель пользователя и последовательность взаимодействия с системой.
В этом блоке
• Актор — внешняя роль, которая взаимодействует с системой для достижения цели.
• Use Case описывает не устройство интерфейса, а поведение системы в ответ на действия
актора.
• Основной и альтернативные потоки особенно полезны для поиска исключений.
78

79.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
USE CASE
Состав текстового Use Case
Название
Актор
Предусловия
Глагол + цель: «Создать заявку»,
«Назначить ответственного».
Кто инициирует сценарий и
получает результат.
Что должно быть истинно до начала
сценария.
Основной поток
Альтернативы
Постусловия
Нормальная последовательность
шагов актор система.
Ошибки, исключения, другие
допустимые ветви.
Какое состояние системы
гарантируется после завершения.
79

80.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
USE CASE
Пример: «Создать заявку»
• Актор: оператор.
• Предусловие: оператор авторизован и имеет право создавать заявки.
• Основной поток: открывает форму → вводит данные → отправляет → система проверяет →
сохраняет → присваивает номер → показывает результат.
• Альтернатива: обязательное поле не заполнено — система не сохраняет заявку и
показывает ошибки.
• Постусловие: создана заявка со статусом «Новая», действие записано в журнал.
80

81.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
USE CASE
Use Case не должен превращаться в описание пикселей
• «Пользователь нажимает синюю кнопку справа» связывает сценарий с текущим макетом
интерфейса.
• Лучше: «пользователь отправляет заполненную форму».
• Детали UI можно хранить в прототипе или дизайн-спецификации.
• Исключение — когда конкретный способ взаимодействия сам является требованием,
например доступность с клавиатуры.
81

82.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
15. User Story и критерии приёмки
В гибких подходах требования часто хранятся компактнее, но компактная карточка не отменяет
обсуждение деталей.
В этом блоке
• User Story фокусируется на пользователе, его потребности и ценности.
• Она служит поводом для разговора, а не полной заменой спецификации.
• Критерии приёмки фиксируют границы ожидаемого поведения конкретной истории.
82

83.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
USER STORY
Классический шаблон User Story
• Как <роль>, я хочу <возможность>, чтобы <ценность / цель>.
• «Как оператор, я хочу фильтровать заявки по статусу, чтобы быстрее находить те, которые
требуют обработки».
• Роль объясняет контекст, возможность — действие, ценность — зачем оно нужно.
• Если часть «чтобы» невозможно сформулировать, стоит проверить, действительно ли
функция кому-то нужна.
83

84.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
USER STORY
INVEST как проверка User Story
Independent
Negotiable
Valuable
по возможности минимально
зависит от других историй.
детали обсуждаемы, история не
является жёстким контрактом.
даёт понятную ценность
пользователю или бизнесу.
Estimable
Small
Testable
команда понимает историю
достаточно, чтобы оценить объём.
достаточно мала для управляемой
реализации.
имеет проверяемый результат и
критерии приёмки.
84

85.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
USER STORY
Критерии приёмки
• Уточняют, при каких условиях история считается реализованной правильно.
• Описывают наблюдаемое поведение и важные границы, а не внутренний код.
• Помогают разработчику, тестировщику и заказчику одинаково понимать результат.
• Для сложного поведения удобно использовать форму Given / When / Then.
85

86.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
USER STORY
Given / When / Then — пример
• Given: пользователь авторизован и находится на странице заявок.
• When: он выбирает фильтр «Новая».
• Then: список содержит только заявки со статусом «Новая» и отображает количество
найденных записей.
• Граница: если подходящих заявок нет, система показывает пустое состояние, а не ошибку.
86

87.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
МОДЕЛИРОВАНИЕ
Use Case и User Story
Use Case
User Story
• Подробно описывает сценарий
взаимодействия.
• Компактно фиксирует потребность и ценность.
• Хорошо показывает основной и альтернативные
потоки.
• Детали раскрываются через разговор и
acceptance criteria.
• Удобна как единица backlog и планирования.
• Удобен для сложных процессов и формальной
фиксации.
Это не взаимоисключающие инструменты: один сложный процесс может быть описан Use Case, а реализация разбита на несколько User Stories.
87

88.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
16. Валидация и верификация требований
До начала разработки выгодно найти ошибки в требованиях, а не в готовой системе.
В этом блоке
• Верификация: требования записаны качественно и согласованы между собой?
• Валидация: если реализовать именно эти требования, получим ли мы нужный пользователю
продукт?
• Проверка требований — совместная работа аналитика, stakeholder-ов, разработчиков и
тестировщиков.
88

89.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРОВЕРКА ТРЕБОВАНИЙ
Verification vs Validation
Верификация требований
Валидация требований
• Однозначны ли формулировки?
• Решают ли требования реальную проблему?
• Нет ли противоречий и дублей?
• Не пропущены ли важные сценарии?
• Можно ли проверить выполнение?
• Понимают ли пользователи будущий результат
одинаково?
• Есть ли необходимые атрибуты и связи?
• Подходит ли прототип для реальной работы?
89

90.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРОВЕРКА ТРЕБОВАНИЙ
Способы проверить требования до разработки
• Ревью спецификации с заказчиком и представителями разных ролей.
• Проигрывание Use Case шаг за шагом: «что происходит дальше?»
• Прототип интерфейса и пользовательская проверка сценария.
• Раннее участие тестировщика: если невозможно придумать проверку, формулировка часто
недостаточно точна.
• Техническая оценка разработчиков: реализуемость, интеграции, риски и скрытые
зависимости.
90

91.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
17. Трассируемость требований
По мере роста проекта важно понимать происхождение и последствия каждого требования.
В этом блоке
• Traceability связывает цели, требования, дизайн, реализацию и тесты.
• Связи помогают ответить: зачем нужен этот пункт и что сломается, если его изменить?
• Трассируемость особенно полезна в крупных, регулируемых и долгоживущих системах.
91

92.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ТРАССИРУЕМОСТЬ
Пример цепочки трассировки
1
2
3
4
5
Бизнес-цель
Требование
Use Case
Компонент
Тест
Сократить время
обработки заявки.
Автоматически
назначать заявку по
правилам.
Назначить
ответственного.
Сервис
распределения
заявок.
Проверка
назначения по
подразделению и
нагрузке.
→
→
→
→
92

93.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ТРАССИРУЕМОСТЬ
Зачем нужна матрица трассируемости
• Показывает требования без тестов — потенциальный пробел проверки.
• Показывает тесты без требований — возможно, проверяется лишняя или
незафиксированная функция.
• Помогает оценить impact change: какие сценарии, компоненты и тесты затронет изменение.
• Не обязательно начинать с огромной таблицы: связи можно хранить в issue tracker или
специализированной системе.
93

94.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
18. Управление требованиями и изменениями
Требования меняются. Профессиональный процесс не запрещает изменения, а делает их
контролируемыми.
В этом блоке
• Причины изменений: новая бизнес-информация, обратная связь, законодательство,
технические ограничения, ошибка первоначального анализа.
• Важно различать «требование изменилось» и «мы только сейчас поняли, что оно всегда было
другим».
• Изменение должно иметь автора, причину, оценку влияния и решение.
94

95.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИЗМЕНЕНИЯ
Жизненный цикл изменения требования
1
2
3
4
5
Запрос
Анализ
Решение
Обновление
Коммуникация
Фиксируем, что
предлагается
изменить и почему.
Определяем
затронутые
требования,
архитектуру, сроки и
тесты.
Принять, отклонить,
отложить или
изменить
приоритет.
Меняем
спецификацию/back
log и связанные
артефакты.
Участники получают
актуальную версию
решения.
→
→
→
→
95

96.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИЗМЕНЕНИЯ
Baseline требований
• Baseline — согласованное состояние набора требований, относительно которого
контролируются дальнейшие изменения.
• Это не означает, что после baseline ничего менять нельзя.
• Смысл — понимать, что именно было согласовано на определённый момент и какие
изменения произошли после.
• В Agile аналогичную роль частично выполняют версии backlog, цели релиза и история
изменений задач.
96

97.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИЗМЕНЕНИЯ
Scope creep: незаметное расширение объёма
• «Раз уж делаем отчёт, добавьте ещё пять форматов»; «эта маленькая кнопка ведь быстро».
• Каждое отдельное дополнение кажется небольшим, но сумма меняет сроки и стоимость
проекта.
• Защита — фиксировать границы релиза, приоритеты и последствия изменения.
• Правильный ответ не обязательно «нет»: это может быть «да, но тогда переносим другую
функцию или срок».
97

98.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
19. Документирование требований
Формат документа зависит от проекта, но структура должна помогать команде принимать решения.
В этом блоке
• Не существует магического шаблона, который автоматически делает требования хорошими.
• Документ должен быть понятен тем, кто его согласует, реализует, тестирует и сопровождает.
• Для учебной работы важнее логическая структура и проверяемые формулировки, чем объём
страниц.
98

99.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ДОКУМЕНТИРОВАНИЕ
Что может входить в спецификацию
Контекст
Stakeholders
Функции
назначение системы, цели,
границы, термины.
роли пользователей и внешние
участники.
структурированный перечень
функциональных требований.
Качество
Данные и правила
Сценарии
нефункциональные требования и
измеримые критерии.
сущности, справочники, бизнесправила, ограничения.
Use Cases, acceptance criteria,
исключения, интеграции.
99

100.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ДОКУМЕНТИРОВАНИЕ
Идентификаторы требований
• Устойчивый ID вроде FR-012 удобнее фразы «третий пункт на пятой странице».
• Идентификатор помогает ссылаться на требование из теста, задачи и обсуждения.
• Номер не должен кодировать слишком много смысла: структура документа может
измениться.
• После удаления требования ID лучше не переиспользовать для другого смысла, чтобы не
путать историю.
100

101.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ДОКУМЕНТИРОВАНИЕ
Атрибуты требования
• ID и краткое название.
• Текст требования и источник / stakeholder.
• Приоритет и статус согласования.
• Версия или дата изменения.
• Связи: бизнес-цель, Use Case, тест, зависимые требования.
• Комментарий или rationale — почему требование существует, если это неочевидно.
101

102.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
20. Типичные ошибки начинающего аналитика
Большинство проблем требований возникает не из-за отсутствия сложной нотации, а из-за слабой
коммуникации.
В этом блоке
• Начинающий аналитик часто слишком рано предлагает решение, забывает исключения и
считает первое мнение заказчика окончательным.
• Другая крайность — пытаться задокументировать абсолютно всё до начала любого
обсуждения реализации.
• Цель анализа — уменьшить риск неправильного продукта, а не произвести максимальное
количество текста.
102

103.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ОШИБКИ
Шесть типичных ошибок
Сразу к интерфейсу
Один stakeholder
Только happy path
обсуждаем кнопки до понимания
задачи и процесса.
не замечаем другие роли и
конфликтующие интересы.
нет ошибок, отмен, недоступных
сервисов и редких случаев.
Слова без метрик
Всё Must
Нет подтверждения
«быстро», «надёжно», «удобно»
остаются непроверяемыми.
приоритизация перестаёт отличать
критичное от желательного.
команда уверена, что поняла
заказчика, но не возвращает
результат на согласование.
103

104.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ОШИБКИ
Ошибка: «заказчик сказал — значит это требование»
• Stakeholder сообщает потребность, проблему, правило или идею решения — аналитик
должен понять, к какой категории относится сказанное.
• Разные люди могут дать несовместимые ответы.
• Некоторые пожелания противоречат цели проекта или ограничениям.
• Роль аналитика — не спорить с заказчиком, а задавать вопросы, выявлять последствия и
фиксировать согласованное решение.
104

105.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ОШИБКИ
Ошибка: забыть нефункциональные требования
• Прототип может идеально выполнять функции на ноутбуке разработчика и оказаться
непригодным под реальной нагрузкой.
• Без требований безопасности права доступа начинают придумывать во время реализации.
• Без требований эксплуатации неизвестно, какие журналы и диагностические данные
понадобятся поддержке.
• Критичные НФТ должны обсуждаться вместе с архитектурой, а не после завершения
функций.
105

106.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ОШИБКИ
Ошибка: смешать разные уровни детализации
• В одном списке оказываются «повысить продажи», «пользователь оформляет заказ» и «цвет
кнопки #22AAFF».
• Такие пункты трудно сравнивать, приоритизировать и связывать.
• Полезно разделять бизнес-цели, пользовательские сценарии, системные требования и
детали UI.
• Связи между уровнями сохраняются, но каждый уровень отвечает на свой вопрос.
106

107.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
21. Связь с вашей практической работой
Первая ПЗ по программной инженерии — это упрощённый реальный цикл elicitation → analysis →
specification.
В этом блоке
• Команда 4–5 человек готовит вопросы и приходит к преподавателю как к заказчику.
• Задача — не получить готовый список функций, а полно исследовать желаемый продукт.
• После интервью ответы нужно структурировать: назначение, роли, ФТ и НФТ — это уже этап
анализа.
107

108.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРАКТИКА
Как команде провести интервью на ПЗ
1
2
3
4
5
До встречи
На встрече
После
Структурироват
ь
Проверить
Согласовать
продуктовый
контекст и
подготовить блоки
вопросов.
Один ведёт
разговор, остальные
фиксируют и задают
уточнения.
Объединить
заметки, убрать
дубли, отметить
противоречия и
пробелы.
Назначение → роли
→ функциональные →
нефункциональные
требования.
Вернуться с
точечными
вопросами, если без
ответа нельзя
сформулировать
требование.
→
→
→
→
108

109.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРАКТИКА
Что должно быть выяснено до конца интервью
• Какой продукт нужен и какую проблему он решает.
• Какие роли существуют в системе и чем различаются их права.
• Какие основные пользовательские сценарии обязательны.
• Какие данные создаются, изменяются и просматриваются.
• Какие ошибки, ограничения и альтернативные сценарии критичны.
• Какие нефункциональные свойства действительно важны для продукта.
109

110.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРАКТИКА
Распределение ролей внутри команды интервью
Интервьюер
Секретарь
Контролёр полноты
держит структуру разговора и
задаёт основные вопросы.
фиксирует факты, термины,
решения и открытые вопросы.
следит, чтобы не забыли роли,
исключения, данные и НФТ.
Уточняющий
Таймкипер
Все участники
ловит неоднозначные ответы и
задаёт «что если…?» / «кто
именно?».
следит за временем и помогает
завершить ключевые блоки.
после встречи участвуют в
структурировании и согласовании
результата.
110

111.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРАКТИКА
Шаблон функционального требования для отчёта
• Краткое название: «Создание заявки».
• Формулировка: «Система должна позволять оператору создать заявку с указанием
категории, описания и приоритета».
• При необходимости: добавить важные условия, права, результат или ссылку на сценарий.
• Не писать: «сделать страницу заявок» — это название элемента интерфейса, а не описание
поведения.
• Проверка: может ли другой студент по формулировке понять, что именно нужно
реализовать и протестировать?
111

112.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРАКТИКА
Шаблон нефункционального требования для отчёта
• Категория: производительность / безопасность / надёжность / совместимость / usability.
• Формулировка: конкретное свойство системы.
• Критерий: по возможности число, диапазон, поддерживаемая среда или однозначное
условие проверки.
• Контекст: при какой нагрузке, для какой роли или в каком режиме действует требование.
• Проверка: можно ли объективно сказать «выполнено / не выполнено»?
112

113.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ПРАКТИКА
После ПЗ1 требования станут основой следующих работ
• Роли и функциональные требования переходят в Use Cases.
• Сценарии помогают проектировать интерфейс и архитектуру.
• Нефункциональные требования влияют на технологические решения и тестирование.
• Изменение требования должно отражаться в связанных сценариях и проектных решениях.
• Поэтому качественное интервью — не отдельная формальность, а фундамент дальнейшего
проекта.
113

114.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
РАЗДЕЛ
22. Итог лекции
Сбор требований — это исследование проблемы; анализ — превращение результатов исследования
в согласованную модель продукта.
В этом блоке
• Модель разработки влияет на момент и частоту уточнения требований, но не отменяет саму
работу с ними.
• Agile ценит сотрудничество и готовность к изменениям, поэтому требования
рассматриваются как развивающееся знание о продукте.
• Хорошие требования связаны с целями, понятны, проверяемы, приоритизированы и
управляемы при изменениях.
114

115.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИТОГ
Что важно унести с лекции
Сначала проблема
Несколько источников
ФТ + НФТ
не начинайте интервью с кнопок и
технологий.
заказчик — не единственный
stakeholder и не единственный
источник знаний.
функции без требований качества
могут дать непригодный продукт.
Проверяемость
Исключения
Изменения нормальны
избегайте «быстро», «удобно»,
«надёжно» без критериев.
ошибки и альтернативные
сценарии часто важнее очевидного
happy path.
но должны иметь причину, оценку
влияния и согласованное решение.
115

116.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИТОГ
Мини-чеклист перед сдачей требований
• У каждого требования понятен источник или цель?
• Определены все основные роли и их различия?
• Есть ли функциональные требования для основных сценариев?
• Проверены ли ошибки, исключения и альтернативные потоки?
• Есть ли критичные НФТ и ограничения?
• Можно ли объективно проверить формулировки?
• Нет ли противоречий, дублей и «всего самого важного»?
116

117.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИТОГ
Контрольные вопросы: модели и Agile
• Чем инкрементная модель отличается от итеративной?
• Почему спиральную модель связывают прежде всего с рисками?
• Назовите четыре ценности Agile-манифеста и объясните смысл слова «важнее».
• Почему Agile не означает отказ от документации и требований?
• Как частая обратная связь влияет на стоимость ошибки в требованиях?
117

118.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИТОГ
Контрольные вопросы: требования
• Чем бизнес-требование отличается от пользовательского и системного?
• Приведите пример функционального и нефункционального требования к одной системе.
• Почему слова «быстро» и «удобно» опасны в спецификации?
• Какие техники elicitation дополняют интервью и зачем?
• В чём различие верификации и валидации требований?
118

119.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИТОГ
Контрольные вопросы: практика
• Какие блоки вопросов нужно подготовить к интервью с преподавателем-заказчиком?
• Как обнаружить, что заказчик описывает решение вместо потребности?
• Какие вопросы помогут найти альтернативные и ошибочные сценарии?
• Как команда должна фиксировать спорные или неясные ответы?
• Какие признаки показывают, что требование уже можно переносить в отчёт?
119

120.

ПРОГРАММНАЯ ИНЖЕНЕРИЯ
ИСТОЧНИКИ
Источники и ориентиры для дальнейшего чтения
• Agile Manifesto — четыре ценности и двенадцать принципов гибкой разработки.
• ISO/IEC/IEEE 29148 — процессы и содержание инженерии требований для систем и ПО.
• Karl Wiegers, Joy Beatty — Software Requirements: практики выявления, анализа и управления
требованиями.
• IIBA BABOK Guide — техники бизнес-анализа, elicitation, stakeholder analysis и управление
требованиями.
• UML / Use Case — как средство моделирования взаимодействия акторов с системой.
120