Информационное моделирование и анализ требований

 

  
 
 
 
 
 

Л. Г. НЕХОРОШКОВА   

 
 
 
 
 
ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ  

И АНАЛИЗ ТРЕБОВАНИЙ 

 
 
 
 

Учебное пособие 

 

 
 
 
 
 
 
 
 
 
 
 
 
 

Йошкар-Ола 

2020 

 
 

УДК 004.43 
ББК  32.973-0.18.2 

Н 59  

 
 

 

Рецензенты: 

доктор технических наук, профессор, зам. директора по науке  

ИЗМИРАН  А. Г. Коробейников (г. Санкт-Петербург); 

доктор технических наук, заведующий кафедрой информационной безопасности ПГТУ И. Г. Сидоркина (г. Йошкар-Ола) 

 
 
 

Печатается по решению 

редакционно-издательского совета ПГТУ 

 
 
 
 
 
 

Нехорошкова, Л. Г. 

Н 59          Информационное моделирование и анализ требований: учебное 

пособие / Л. Г. Нехорошкова. – Йошкар-Ола: Поволжский государственный технологический университет, 2020. – 146 с. 
ISBN 978-5-8158-2209-2 

 

Пособие посвящено вопросам разработки и анализа требований к 

программным системам. Рассмотрены подходы к сбору и анализу требований наиболее популярных в IT-проектах Agile технологий. 

Для студентов направления 09.03.04 – Программная инженерия, изуча
ющих дисциплину «Информационное моделирование и анализ требований». 

УДК.004.43 

ББК 32.973-0.18.2 

 

ISBN 978-5-8158-2209-2 
© Л. Г. Нехорошкова, 2020 
© Поволжский государственный 
технологический университет, 2020 

ОГЛАВЛЕНИЕ 

 
Введение. Анализ требований ...................................................................... 5 
 
1. Требования к продукту и проекту ..................................................... 9 
Уровни требований ...................................................................................... 10 
2. Характеристики требований ............................................................ 15 
3. Этапы сбора и анализа требований ................................................. 18 

3.1. Определение концепции продукта............................................... 18 
3.2. Сбор требований ............................................................................ 20 
3.3. Анализ требований ........................................................................ 21 
3.4. Проектирование системы ............................................................. 21 
3.5. Влияние качества работ на характеристики конечного 
продукта ................................................................................................. 22 

4. Сбор требований ................................................................................. 24 

4.1. Источники требований .................................................................. 24 
4.2. Основные этапы выявления требований ..................................... 25 
4.3. Техники сбора требований............................................................ 28 
4.4. Как измерять успех проекта ......................................................... 36 

5. Бизнес-требования .............................................................................. 39 

5.1. Потребности стекхолдеров ........................................................... 39 
5.2. Бизнес-цели.................................................................................... 40 
5.3. Документ «Концепция проекта» .................................................. 42 

6. Бизнес-риски ........................................................................................ 44 

6.1. Предположения и зависимости ................................................... 44 

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

7.1. Users stories .................................................................................... 47 
7.2. Тема, эпик, история, задача. ......................................................... 49 
7.3. Построение карт историй – Story Mapping.................................. 50 
7.4. INVEST – атрибуты Users Story ................................................... 54 
7.5. Практические советы по написанию пользовательских 
историй .................................................................................................. 57 
7.6. Хорошие практики ........................................................................ 57 

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

8.1. Пользовательские истории и варианты использования ............. 60 
8.2. Диаграмма вариантов использования ......................................... 62 
8.3. Определение вариантов использования ...................................... 62 
8.4. Создание сценариев ...................................................................... 70 

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

9.1. Атрибуты качества и их числовые значения .............................. 73 

9.2. Группа runtime .............................................................................. 73 
9.3. Группа design time ........................................................................ 75 

10. Анализ требований ............................................................................. 78 

10.1. Спецификации требований ....................................................... 80 
10.2. Проверка требований ................................................................ 81 
10.3. Создание контекстной диаграммы ........................................... 82 
10.4. Создание пользовательских интерфейсов (Usabiblity) ........... 85 
10.5. Почему юзабилити – это так важно? ....................................... 85 
10.6. Usability Engineering and Usability Testing ............................... 86 

11. Прототипы ........................................................................................... 88 

11.1. Разновидности прототипов ....................................................... 89 

12. Приоритеты ......................................................................................... 92 

12.1. Определение приоритетов требований ..................................... 93 
12.2. Метод приоритизации MoSCoW .............................................. 94 

13. Создание словаря терминов .............................................................. 96 
14. Риски .................................................................................................... 97 

14.1. Подходы к управлению рисками .............................................. 99 
14.2. Основы управления рисками .................................................... 99 
14.3. Экстремальное управление рисками (Agile).......................... 100 
14.4. Управление рисками в MSF .................................................... 101 
14.5. Классификация рисков ............................................................ 102 
14.6. Анализ и приоритизация рисков ............................................. 104 

15. Управление проектом и управление требованиями .................. 107 
16. Практические задания ..................................................................... 111 
 
Список литературы .................................................................................... 113 
 
Приложение 1  ........................................................................................... 115 

UML (Unified Modeling Language) – унифицированный язык 
моделирования ..................................................................................... 115 

Приложение 2 ............................................................................................ 129 

Agile-методологии............................................................................... 129 
Scrum 
 ............................................................................................... 132 

Экстремальное программирование.................................................... 136 
KANBAN ............................................................................................. 141 

Приложение 3 ............................................................................................ 144 

Методологии и стандарты, регламентирующие работу  
с требованиями ................................................................................... 144 
 
 
 

Введение. Анализ требований 

 

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

Фредерик Брукс  

 
Управление требованиями, разработка требований и определение 

требований – краеугольные камни успеха любого IT-проекта. По результатам различных исследований причин неудач проектов в области ИТ, проблемы в области управления требованиями занимают 6080 %. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими расходы по проекту можно снизить на 20 % благодаря сокращению числа неточных, неполных и упущенных требований. 

Любой проект влечет за собой изменения, кто-то к ним готов, а 

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

Участники проекта – физические и\или юридические лица, ко
торые непосредственно вовлечены в реализацию проекта либо чьи 
интересы могут быть затронуты при осуществлении проекта. 

По степени вовлеченности в проект можно выделить три группы 

участников: 

 
основная команда – группа специалистов и организаций, 

непосредственно работающих над осуществлением проекта в тесном 
контакте друг с другом; 

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

 
заинтересованные стороны (стекхолдеры) – люди и органи
зации, оказывающие влияние на членов основной и расширенной команд и на ход работ по проекту, но не всегда вступающие с ними в 
прямое сотрудничество. Прижившийся в среде отечественных менеджеров проектов термин «стейкхолдер» (от английского stakeholder, 
буквально – «владелец доли») в официальной литературе переводится 
по-разному. PMBOK предлагает вариант «заинтересованная сторона», наш ГОСТ 51897-2002 – «причастная сторона». 

Определение требований – это нетривиальная задача и проводится, 

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

Эти особенности выражены в формальном определении требова
ния в стандарте IEEE 1990:  

 
Условие или возможность, необходимые пользователю для 

решения его задач или достижения цели.  

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

 
Документированное представление условия или возможно
сти, указанное в (1) или (2). 

Какими должны быть спецификации требований? На этот вопрос 

отвечает стандарт 830-1998 – IEEE Recommended Practice for Software 
Requirements Specifications. 

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

В IT-фирмах по разработке информационных систем разработку 

требований осуществляют специалисты-инженеры требований; иногда они составляют половину персонала.  

Требования пишутся на русском или английском языке, т.е. это 

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

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

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

Анализ требований является частью общеинженерной дисци
плины «инженерия требований» (англ. Requirements Engineering). 

Инженерия требований – междисциплинарный подход, связы
вающий стороны поставщика и заказчика для определения и поддержки требований, которым должна отвечать целевая система, продукт или услуга (ISO/IEC/IEEE 29148-2011 Systems and software 
engineering – Life cycle processes – Requirements engineering). 

Иными словами, задачи инженерии требований – перевести 

требования стекхолдеров в требования к системе. Проверить их  

целостность, непротиворечивость и полноту. Система на этом этапе 
может рассматриваться как черный ящик.  

Работа с требованиями продолжается на протяжении выполнения 

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

 
Вопросы 
1. Назовите участников проекта. 
2. Дайте определение стекхолдера проекта. 
3. Что такое валидация и верификация требований? 
4. Дайте определение анализу требований. 
5. В чем цель анализа требований? 
6. Дайте определение понятию инженерия требований. 
7. Назовите задачи инженерии требований. 
 
Задание 
Выберите проект, для которого будут разрабатываться требования. 

Определите стейкхолдеров проекта. 

 
 

1 

 

ТРЕБОВАНИЯ К ПРОДУКТУ И ПРОЕКТУ 

 
 
Требования к продукту. В своей основе требования – это то, что 

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

Требования к проекту. Вопросы формулирования требований к 

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

Заказчик, вступая в договорные отношения с Разработчиком, 

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

Насколько подробно Заказчику следует регламентировать требо
вания к проекту, зависит от множества факторов, таких как ценность 
конечного продукта для Заказчика, степень доверия Заказчика к Разработчику, сумма подписанного контракта, увязка срока сдачи  

продукта в эксплуатацию с бизнес-планами Заказчика и т.д. Однако 
со всей определенностью можно сказать следующее: 

 
регламентация процесса Заказчиком позволяет снизить его 

риски; 

 
мероприятия Заказчика по регламентации процесса приводят 

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

В качестве требований к проекту может быть внесен регламент 

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

Приведем пример формулировки требования к оффшорному про
екту (Заказчик и Разработчик физически находятся в разных государствах) – в этой ситуации Заказчику требуется жесткий контроль над 
Разработчиком. 

 
Разработчик представляет Заказчику согласованный план ра
бот c детализацией (WorkBreakdownStructure – WBS) с точностью до 
конкретных исполнителей. 

 
Разработчик осуществляет ежедневные сборки, регрессион
ное тестирование компонентов разрабатываемого продукта и тестирование продукта в целом. 

 
Все управленческие и проектные артефакты, исходные коды 

и тестовые примеры размещаются в режиме online в интегрированной 
среде разработки Rational ClearCase с возможностью для Заказчика 
осуществления online-мониторинга на базе web-технологий. 

 
Вопросы 
1. Основной риск Заказчика при в договорных отношениях с Разра
ботчиком. 

2. Плюсы и минусы регламентирования разработки Заказчиком. 
3. Назовите наиболее значимые требования к проекту со стороны За
казчика.  
 

УРОВНИ ТРЕБОВАНИЙ 

Требования к программному обеспечению можно распределить 

по четырем уровням: 

 
бизнес-требования; 

 
требования пользователей; 

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

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

 
Бизнес-требования (business requirements) содержат высоко
уровневые цели организации или заказчиков системы (стейкхолдеров). Примеры бизнес-требования: система должна сократить срок 
оборачиваемости обрабатываемых на предприятии заказов в три раза. 

Бизнес-требования формулируют в документе об образе и грани
цах проекта – уставе проекта (project charter), или документе рыночных требований (market requirements document). Определение границ 
проекта представляет собой первый этап управления общими проблемами расползания границ. 

Требования пользователей (user requirements) описывают цели 

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

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

К способам представления этого вида требований относятся Us
ersStory (пользовательские истории), сценарии и таблицы «событие – 
отклик». 

Функциональные требования (functional requirements) явля
ются формализацией требований пользователей. Пример функциональных требований (или просто функций) по работе с электронным 
заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок. 

Функциональные требования определяют функциональность ПО, 

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

Нефункциональные требования 
Системные требования (system requirements) – это высокоуровне
вые требования к программному обеспечению или подсистеме ПО и 
оборудования. Люди – часть системы, поэтому определенные функции системы могут распространяться и на людей.  

Атрибуты качества (quality attributes) представляют собой допол
нительное описание функций продукта, выраженное через описание 
его характеристик, важных для пользователей или разработчиков. К 
таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают 
внешние взаимодействия между системой и внешним миром, а также 
ограничения дизайна и реализации. 

Бизнес-правила (business rules) включают корпоративные поли
тики, правительственные постановления, промышленные стандарты 
и вычислительные алгоритмы. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им 
бизнес-правил.