Выявление и сбор требований к ПО — ultimate guide

Фундаментальное описание требований к ПО и подходов к их выявлению и сбору от тестировщика Noveo Вадима: пост освещает все аспекты этой области знаний, структурирует информацию и не оставляет ни малейшего шанса недопониманиям и «темным» местам. Приятного прочтения!

Вадим

Noveo Test Engineer

Мы с вами как тестировщики каждый день работаем с требованиями. Суть нашей работы — выяснять, соответствует ли разрабатываемая система требованиям заказчика, рынка и отраслевым стандартам. Более того, в наши обязанности входит проверка требований на соответствие критериям качества. В идеальном мире мы с вами были бы просто гарантом качества — судьями, дающими объективную оценку. Но, к сожалению, мир не идеален, и строгое распределение участников проекта на роли чаще всего не представляется возможным. В эпоху повсеместного использования гибких методологий разработки мы с вами должны обладать знаниями, позволяющими выполнять задачи не только контроля качества.

Цели этого поста заключаются в следующем:

1. Определить, что такое требование, какие типы и уровни требований выделяют.
2. Понять, какие существуют методы сбора и выявления требований.
3. Предоставить почву для дальнейшего изучения сферы системного и бизнес-анализа.

Требования

Начнем с требований как таковых:

• Что они из себя представляют?
• Какие виды требований выделяются?
• Как они согласуются?
• Какие источники требований можно выделить?

Определение требования

Прежде чем погрузиться в теорию разработки требований к ПО, попробуйте, основываясь на своих знаниях и опыте, ответить на вопрос: как вы определяете термин «требование»?

Вопрос, что считать требованием к ПО, является сугубо дискуссионным. Но так или иначе нам с вами необходима отправная точка для изучения темы, поэтому обратимся к уже устоявшимся определениям:

Требования к ПО — это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы (Ian Sommerville и Pete Sawyer, 1997).

Требования к ПО — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению (ПО), в результате анализа требований (Википедия).

Из определений можно выделить следующие пункты, которые относятся к требованиям:

• Спецификация — документ, устанавливающий требования.
• Реализация — интерпретация требований в виде разработанной системы (одни и те же требования можно реализовать различными способами).
• Описание поведения системы (то, как система должна работать при различных входных условиях).
• Описание свойств / атрибутов / качеств системы.

Как видно выше, устоявшиеся термины не отражают всю полноту понятия «требование к ПО», поэтому также стоит отметить следующее: требования охватывают как видение пользователя, так и внешнее поведение системы, а также представление разработчика о некоторых внутренних характеристиках. Они включают как поведение системы в определенных условиях, так и свойства, которые делают систему полезной и удовлетворяющей конечных пользователей.

Термин «требование» охватывает довольно широкую предметную область. Поэтому возникает вопрос типизации и классификации требований.

Уровни и типы требований

Требования к ПО состоят из трех уровней:

1. Бизнес-требования.
2. Пользовательские требования.
3. Функциональные требования.

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

Бизнес-требования BRQ

Бизнес-требование (business requirements) — высокоуровневая бизнес-цель организации или заказчиков системы.

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

Бизнес-требования — это верхний уровень абстракции требований к системе. Они не относятся напрямую к реализации проекта, а в первую очередь отражают цели бизнеса, абстрагированные от реализации системы. В конечном итоге бизнес-требования формируют документ концепции и границ.

Если кратко, документ содержит определение следующих понятий:

• Бизнес-возможности, бизнес-проблемы — факты и события, формирующие бизнес-цели, то есть грубо — причины инициации проекта.
• Бизнес-цели — цели, которые должны быть решены разработкой и вводом в эксплуатацию системы. Являются критериями успеха проекта.
• Концепция продукта (Vision) — сжато описывает конечный продукт, который достигнет заданных бизнес-целей.
• Границы проекта (scope) — показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация.

Примеры бизнес-требований:

Сократить время обработки заказа на 50% (цель) — система должна предоставить интерфейс, упрощающий создание заказа (концепция).

Увеличить клиентскую конверсию до 35% (цель) — в системе должны быть представлены механизмы побуждения клиента к заказу (концепция).

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

Источники бизнес-требований (где искать?):

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

Стейкхолдеры (у кого спрашивать?):

• Инициатор проекта.
• Руководитель проекта (менеджер проекта).
• Руководитель структурного подразделения заказчика (коммерческий директор, директор по маркетингу).
• Бизнес-аналитик.

P.S. Список стейкхолдеров меняется от проекта к проекту, для каждого проекта необходимо отдельно определять список заинтересованных/ответственных лиц. Списки, представленные мной, являются сугубо примерами из моей практики.

QA и разработчики, как правило, не участвуют в сборе и анализе бизнес-требований. Но нам важно понимать верхнеуровневые цели, которые преследует проект, так как пользовательские и функциональные требования — это следствие выявления, анализа и декомпозиции бизнес-требований. Работая с бизнес-требованиями, вы в первую очередь погружаетесь в предметную область заказчика. На мой взгляд, это очень важно для всех участников проекта. Если член команды погружен в предметную область заказчика, существенное количество вопросов отпадет, а следовательно, сокращается и время, потраченное на коммуникации.

Пользовательские требования URQ

Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователе (Карл Вигерс, «Разработка требований к программному обеспечению»).

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

Пользовательские требования также часто именуются фичами.

Фича (функциональность) — функционально обобщенные части системы, решающие отдельные задачи пользователей или интерпретирующие бизнес-процессы (и их артефакты), которые будут реализованы в рамках системы.

Исходя из вышеописанных определений, пользовательские требования содержат:

• Цели и задачи пользователей.
• Сценарии использования — способ решения задачи пользователей.
• Как следствие, описание самих пользователей системы:
• пользовательские роли,
• уровни доступа.

В конечном итоге пользовательские требования формируют «Документ пользовательских требований». Пользовательские требования могут быть представлены в виде:

• текстового описания,
• вариантов использования, сценариев использования (Use Case),
• пользовательских историй (User Story),
• диаграммы вариантов использования.

Как правило, пользовательские требования описываются по следующему шаблону:

Пользователь должен иметь возможность + {тезис}.

Пример пользовательского требования:

Пользователь должен иметь возможность добавить объект в избранное (функциональность).

Источники пользовательских требований требований (где искать?):

• Анализ и декомпозиция бизнес-требований.
• Описание бизнес-процессов.
• Артефакты бизнес-процессов:
• документы входные/выходные,
• стандарты,
• регламенты,
• обрабатываемые данные,
• иная информация, используемая и/или производимая в бизнес-процессе.
• Отраслевые стандарты.
• Реализованные проекты, проекты конкурентов.

Стейкхолдеры (у кого спрашивать?):

• Бизнес-аналитик, системный-аналитик.
• Конечные пользователи — люди, взаимодействующие с системой напрямую.
• Косвенные пользователи — люди, использующие результаты работы системы, не взаимодействуя с ней напрямую.
• Представители пользователей.
• Менеджер проекта.
• Руководитель структурного подразделения заказчика.

Этот уровень требований напрямую входит в круг обязанностей QA-инженера. В задачи QA на этом уровне входит:

• Определение соответствия описания требований критериям качества.
• Анализ требований для проработки сценариев тестирования.
• При достаточном уровне компетенций в предметной области:
• определение соответствия требований устоявшимся отраслевым стандартам (например: системе не достаёт фичи, которая в рамках предметной области системы является обязательной);
• определение соответствия требований с утвержденными бизнес-требованиями. Ответ на вопрос: «Решает ли пользовательское требование бизнес-цели проекта и задачи пользователей?«.

Функциональные требования FRQ

Функциональные требования (functional requirements) — описание требуемого поведения системы в определенных условиях.

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

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

Пример функциональных требований:

Пользователь должен иметь возможность добавить объект в избранное (URQ):

FRQ 1 — Добавить в избранное.

FRQ 2 — Удалить из избранного.

FRQ 3 — Редактирование дополнительных атрибутов.

FRQ 4 — Обращение к объекту из меню избранного.

Источники требований (где искать?):

• Анализ пользовательских требований.
• Таски.
• Прототипы интерфейса (мокапы).
• Отраслевые стандарты.
• Внешние системы и документация к ним (интеграции).

Стейкхолдеры (у кого спрашивать?):

• Бизнес-Аналитик.
• Системный аналитик.
• Архитектор.
• Менеджер проекта.
• Разработчики.

Нефункциональные требования NFRQ

Нефункциональное требование (non-functional requirements) — описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.

На мой взгляд, это крайне исчерпывающее определение. Как вы могли заметить, нефункциональные требования не входят в основную иерархию требований. Их выделяют от других типов требований, так как нефункциональные требования:

1. Выявляются и формулируются на всех уровнях иерархии требований.
2. Напрямую или косвенно влияют на формирование каждого уровня требований.

Совет: Чаще всего нефункциональные требования отвечают на вопрос «Как? Каким образом?».

Пример нефункциональных требований, которые являются основной идеей проекта: Тик Ток.

С точки зрения разработки функциональный скоуп проекта не является уникальным:

• смотреть контент,
• предлагать ротацию контента на основе алгоритмов,
• создавать контент.

Все эти фичи так или иначе были представлены в других проектах. Ключом успеха проекта в данном случае является его UI/UX. А UI/UX сам по себе не отвечает за функции системы, а отвечает за то, каким образом будут реализованы эти функции.

SRS

В конечном итоге все требования консолидируются в одном документе «Спецификации требований к системе». Выше вы можете видеть структуру документа SRS. Ни в коем случае нельзя воспринимать её как жесткий стандарт (хотя таковой имеется: ISO/IEC/IEEE 29148:2011). Я предлагаю вам использовать эту структуру как чек-лист для определения полноты описания системы. Стоит отметить, что внутренние стандарты документирования и полноты требований меняются от проекта к проекту, но набор типов требований всегда будет идентичен. Кто-то опускает бизнес-требования, для кого-то пользовательские требования тождественны функциональным. В конечном итоге все требования — лишь абстракция, и каждая команда подбирает под себя удовлетворительный уровень детализации этой абстракции.

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

Выявление требований — итеративный процесс, состоящий из следующих этапов:

1. Подготовка к выявлению.
2. Выявление.
3. Утверждение результатов.

Подготовка к выявлению требований

В процессе подготовки к выявлению требований необходимо ответить на следующие вопросы:

1. Что необходимо выяснить? — Анализируем имеющуюся информацию о системе:

а. Анализ текущего описания требований к системе.

b. Анализ текущей реализации системы.

c. Выявление недостающих и/или недостаточно описанных требований.

2. У кого? Где? — Определить источник требований:

а. Собрать список доступных источников, таких как:.

i. Документация.

ii. Артефакты бизнес-процессов и/или текущей реализации системы.

b. Определить список стейкхолдеров, которые могут выступать источником требований к системе.

3. Каким образом? — Выбрать оптимальный метод выявления требований.

Выявление требований. Интервью

Самый популярный и, возможно, эффективный метод выявления требований. Представляет из себя беседу с заказчиком.

Подготовка к интервью

Подготовка к интервью состоит из следующих этапов:

1. Собрать информацию о собеседнике(ах):

а. Роль в проекте?

b. За какие вопросы ответственен?

2. Подготовить вопросы:

a. Сформулировать проблематику интервью.

b. Сформулировать вопросы.

c. Подготовить дополнительные вопросы.

3. Определить тайминг встречи.

a. Нужно стараться уложиться в один час. Чаще всего человек начинает терять концентрацию после 40 минут непрерывной беседы.

b. Для каждого вопроса определить необходимое время на обсуждение.

c. Если вы не успеете задать все вопросы в рамках одной встречи, назначьте несколько встреч.

4. Согласовать календарь встреч.

a. Если предполагается несколько встреч — то не обходимо составить график встреч.

b. Для каждой встречи указать проблематику, вопросы, которые будут обсуждаться, длительность.

От себя рекомендую подготовить файл с вопросами и планом интервью. Для примера — вот шаблон, который использую я:

Протокол интервью

Проект:{}

Дата проведения:{}

Интервьюер: {Кто проводит интервью}

Интервьюируемый:{Кому задаём вопросы}

Проблематика:{Тема интервью}

Вопрос № 1:

Тайминг вопроса:

Текст вопроса:

Таймкод:

Ответы на вопрос:

Стейкхолдер 1 —

Стейкхолдер 2 —

Проведение Интервью

Проведение интервью — сложный навык, который требует времени и практики. Но просто задавать вопросы, я думаю, будет не сложно. Итак, ниже список рекомендаций, которые помогут вам провести интервью:

1. Всегда ведем запись встречи.

a. Спрашиваем собеседника, не против ли он вести запись разговора.

b. Включаем запись после согласия собеседника.

2. Small talk для разрядки.

a. Как настроение?

b. Как погода?

c. И т.д. и т.п.

d. Но не затягиваем, пара вопросов из вежливости, не более.

3. Начинаем с объявления проблематики.

4. Стараемся следовать плану встречи. Вопросы задаём последовательно.

5. Желательно в плане указываем тайм-код, в какую минуту разговора задан вопрос, чтобы упростить дальнейшую обработку протокола.

6. Стараемся раскрывать вопросы дополнительными вопросами. Беседа должна быть живой, не должна скатываться в сухой формат вопрос-ответ, иначе проще отправить собеседнику опросник и не тратить его время на встречу.

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

a. Например: Я правильно вас понял, что необходимо реализовать функционал следующим образом {Тезис}?

Обработка результатов Интервью

После проведения интервью необходимо письменно зафиксировать полученную информацию. Рекомендую делать это сразу после интервью. Итак:

1. Заполняем протокол встречи.

a. Читать краткий протокол встречи намного проще, чем смотреть часовую запись в поисках ответов.

2. Направляем участникам встречи результаты в формате «Вопрос — Зафиксированное решение».

b. Это необходимо для получения от заказчика письменного утверждения результатов встречи.

Плюсы и минусы метода

Плюсы метода:

• Наиболее эффективный способ метод сбора требований.
• Меньшая вероятность недопонимания между собеседниками.
• Большая вероятность выявления «скрытых» требований.

Минусы метода:

• Могут возникнуть сложности согласования требований от разных стейкхолдеров.
• Высокие временные затраты.
• Качество проведения интервью напрямую зависит от интервьюера.

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

Метод анкетирования подразумевает создание анкеты (списка вопросов) и её рассылку большому количеству опрашиваемых.

Подготовка

Подготовка к анкетированию состоит из следующих этапов:

1. Собрать контакты опрашиваемых стейкхолдеров.

2. Подтвердить готовность стейкхолдеров участвовать.

3. Подготовить анкету:

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

b. Задавать можно как открытые, так и закрытые вопросы.

c. Но лично я рекомендую предоставлять опрашиваемым варианты ответа даже в формате открытого вопроса. То есть обозначаем проблематику, предлагаем варианты решения, а также оставляем за опрашиваемым возможность раскрыть свою позицию. По сути аналог варианта «Другое» в опроснике.

Проведение

1. Рассылаем анкету опрашиваемым.
2. Контролируем сроки опроса (должен быть внутренний дедлайн).
3. Ответы, по мере поступления, консолидируем в одном документе (каналы связи с опрашиваемыми могут быть разными, но место хранения требований всегда должно быть одно).

Обработка результатов

1. Анализируем ответы.
2. Фиксируем требования.
3. Утверждаем требования с ответственными лицами.

Плюсы и минусы метода

Плюсы:

• Большой охват опрашиваемых.
• Сравнительно небольшие временные затраты.
• Возможность повторного использования анкеты (бриф на стандартизированный проект).

Минусы:

• Не подходит для выявления «неявных» требований.
• Невозможно заранее учесть все необходимые вопросы.

Выявление требований. Мозговой штурм

Мозговой штурм предполагает сбор команды разработки и представителей заказчика на совместную встречу. Этот метод позволяет собрать множество идей от различных заинтересованных лиц (стейкхолдеров) в кратчайшие сроки и практически бесплатно. Во время мозгового штурма участники «накидывают» любые идеи, касающиеся решения проблемы. С помощью этой методики можно проработать несколько различных вариантов решения заданной проблемы, а также разрешить конфликты требований.

Подготовка

1. Формулируем проблематику:

а. Необходима краткая и емкая формулировка, которая оставит поле для размышления экспертов.

b. Проблематика озвучивается экспертам заранее, чтобы у них было время «на подумать».

2. Подготавливаем дополнительные материалы для отработки идей — например, макеты системы.

3. Формируем группу экспертов.

4. Согласовываем дату и время.

Проведение

1. Ведем запись-протокол. Уведомляем участников о том, что ведется запись.

2. Озвучиваем регламент встречи:

a. Тема,

b. Тайминги,

c. Правила.

3. Эксперты озвучивают идеи по очереди.

4. Эксперты должны озвучивать любые идеи, касающиеся проблематики.

5. Каждая идея фиксируется и обсуждается.

6. В некоторых источниках утверждается, что нужен полный запрет на критику. На мой взгляд, это приводит только к сбору сырых идей, без их отработки. «В споре рождается истина».

7. Коллективное комбинирование собранных идей.

Обработка результатов

1. Анализируем идеи.
2. Формализуем и описываем (то есть готовим развернутое описание).
3. Утверждаем идеи с ответственными.

Плюсы и минусы метода

Плюсы:

• Большая вероятность выявить WOW-требования (придумать крутую фичу).
• При наличии на мозговом штурме специалистов, ответственных за разные аспекты системы, увеличивается глубина проработки отдельных требований. То есть низка вероятность придумать нереализуемую фичу.

Минусы:

• Ограниченный круг стейкхолдеров, которых можно привлечь.
• Необходима жесткая модерация. При отсутствии контроля за проведением встречи мозговой штурм быстро превращается в неэффективный балаган.
• Необходима высокая вовлеченность участников в проект (грубо говоря — необходима инициатива со стороны экспертов).

Другие методы выявления требований

• Анализ документации — изучение и анализ существующей документации, которая напрямую или косвенно касается разрабатываемой системы.
• Анализ системных интерфейсов, API и базы данных — анализ систем, которые будут взаимодействовать с разрабатываемой системой.
• Анализ пользовательского интерфейса — анализ интерфейсов, функционально похожих (или идентичных) на разрабатываемую систему (отраслевые стандарты UI/UX). Также к этому относится анализ интерфейсов систем, входящих в IT-экосистему заказчика.
• Моделирование процессов, поведения системы и пользователей — моделирование процессов и схем данных помогает структурировать и упорядочивать информацию о проекте.
• Повторное использование требований — многие элементы систем имеют стандарты исполнения. Например: регистрация — авторизация пользователей.
• Вовлечение представителя заказчика в команду разработки — вовлечение заказчика в работу над проектом является одним из постулатов Agile. В целом наличие представителя заказчика в команде разработки экономит уйму времени на коммуникации.
• Презентации, демо и т.п. — представление требований/реализации системы заказчику. Данный способ помогает уточнить требования, а также выявить скрытые и/или избыточные требования. Пример: демонстрация мокапов будущей системы пользователям.
• Работа в «Поле» (наблюдение) — наблюдение за деятельностью и процессами будущих пользователей.
• Обучение — процесс, в котором заказчик или любой другой человек из организации заказчика, знающий процесс, обучает аналитика по принципу «учитель — ученик».

Очевидный факт:

Только комбинируя методы, возможно добиться сбора требований, максимально отвечающих ожиданиям заказчика.

Материалы для самостоятельного изучения

Блоки знаний:

• Бизнес-анализ — раздел знаний, отвечающий за описание и формализацию бизнес-процессов. Прежде чем интерпретировать бизнес-процессы в виде ПО, необходимо их «правильно» описать и формализовать.
• Моделирование бизнес-процессов — изучение различных нотаций описания бизнес-процессов. Неразрывно связан с бизнес-анализом.
• Системный-анализ — раздел знаний, отвечающий за анализ процессов непосредственно в самом ПО.
• Моделирование систем — изучение нотаций описания систем ПО. Неразрывно связан с системным анализом.
• Документирование требований — изучение различных сред документирования информации о проекте и системе.
• Управление требованиями (согласование, управление изменениями, трассировка требований) — отдельный процесс в системе знаний об анализе в ИТ. Является одним из самых сложных процессов на долгосрочных проектах с большим количеством итераций.
• Прототипирование — изучение различных инструментов для моделирования интерфейсов и архитектуры ПО. Например: Figma для верстки макетов интерфейсов.

Книги:

• Вигерс, Карл: Разработка требований к программному обеспечению. 3-е издание, дополненное / Карл Вигерс, Джой Битти. — Санкт-Петербург : БХВ-Петербург, 2019. — 736 с.
• Ильяхов М., Сарычева Л. Пиши, сокращай. Как создавать сильный текст — 2017.
• Гэртнер, Маркус: ATDD — разработка программного обеспечения через приемочные тесты. — ДМК-Пресс, 2013. — ISBN 978-5-457-42706-8.
• Gojko Adzic, David Evans — Fifty Quick Ideas to Improve Your User Stories — 2014.
• Майкл Мескон, Майкл Альберт, Франклин Хедоури — Основы менеджмента

• Хоп, Грегор Шаблоны интеграции корпоративных приложений (Signature Series) / Грегор Хоп, Бобби Вульф. — Москва : Вильямс, 2019. — 672 с.

• Кон, Майк Пользовательские истории. Гибкая разработка программного обеспечения / Майк Кон. — Москва : Вильямс, 2018. — 256 с.

• Паттон, Джефф Пользовательские истории. Искусство гибкой разработки ПО / Джефф Паттон — Санкт-Петербург : Питер, 2019. — 288 с.

• Cockburn, Alistair Writing Effective Use Cases / Alistair Cockburn. — Addison-Wesley, 2001.

• USE-CASE 2.0

• Фаулер, Мартин UML. Основы. Краткое руководство по стандартному языку объектного моделирования / Мартин Фаулер. — Москва : Символ-Плюс, 2018. — 192 с.

• Гойко, Аджич Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке / Аджич Гойко. — Москва : Альпина Паблишер, 2017. — 86 с.

• Коберн, Алистер Быстрая разработка программного обеспечения/ Алистер Коберн. — Москва: Лори, 2002. — 336 с.

• Корнипаев, Илья Требования для программного обеспечения: рекомендации по сбору и документированию / Илья Корнипаев. — Книга по требованию, 2013. — 118 с. Книга

• Ми, Роберт Шаблоны корпоративных приложений / Роберт Ми, Мартин Фаулер. — Москва : Вильямс, 2018. — 544 с.

• Мартин, Роберт Чистая архитектура. Искусство разработки программного обеспечения / Роберт Мартин. — Санкт-Петербург : Питер, 2018. — 352 с.

• BABOK 3.0

• SWEBOK 3.0