Управление требованиями к архитектуре предприятия и информационным системам

1. Тема 2 Управление требованиями к архитектуре предприятия и информационным системам

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

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

3. "облако неопределенности" между организацией и обеспечивающей ее ИТ-инфраструктурой своих целей и задач

"облако неопределенности" между организацией и
обеспечивающей ее ИТ-инфраструктурой своих целей и
задач

4.

Типы требований и уровни требований
Являются
одним из
видов
Бизнес-требования
Цели
(бизнес-цели)
Направлены на выполнение
Требования заинтересованных сторон
Направлены на выполнение
Функциональные требования –
критерии приемки вариантов
использования
Требования к видам обеспечения
Нефункциональные требования
Оказывают
взаимное
влияние
Переходные требования

5.

Свойства «хорошо» написанных требований
1. Полнота
2. Ясность (недвусмысленность)
3. Корректность
4. Согласованность (непротиворечивость)
5. Верифицируемость (проверяемость)
6. Необходимость и полезность при эксплуатации
7. Осуществимость
8. Трассированность
9. Упорядоченность по важности и стабильности

6.

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

7.

2. Ясность (недвусмысленность)
Ясность (недвусмысленность) - предполагается, что все читатели
требований интерпретируют их одинаково. Требование обладает
свойством ясности, если оно сходным образом воспринимается
всеми заинтересованными сторонами. На практике ясность
требований достигается в том числе и в процессе консультаций, в
ходе
которых
происходит
«выравнивание
тезаурусов»
заинтересованных сторон и команды проекта. Хорошим подспорьем в
этом служит согласованный сторонами глоссарий ключевых понятий
предметной области.

8.

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

9.

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

10.

5. Верифицируемость (проверяемость)
Верифицируемость (проверяемость) должна
существовать
возможность проверить требование после реализации, тестировать
требование. Свойство верифицируемости существенно связано со
свойствами ясности и полноты: если требование изложено на языке,
понятном и одинаково воспринимаемым заинтересованными
сторонами, причём оно является полным, т.е. ни одна из важных для
реализации деталей не упущена – значит, это требование можно
проверить. При этом в ходе проверки у сторон (принимающей и
сдающей работу) не должно возникнуть неразрешимых противоречий в
оценках.

11.

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

12.

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

13.

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

14.

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

15. Типы и уровни требований

Функциональные
Бизнес-требования - описывают цель создания системы с точки зрения
организации, т.е. какие задачи с помощью создаваемой системы
планирует решить организация и какую пользу этот ей принесет;
Пользовательские требования - описывают цели и задачи, которые
пользователям позволит решить система;
Функциональные требования - определяют функциональность ПО,
которую разработчики должны построить, чтобы пользователи смогли
выполнить свои задачи в рамках бизнес-требований.
Системные требования - это требования которые предъявляют вашей
системе системы с которыми запланирована интеграция.
Нефункциональные
Бизнес-правила - включают корпоративные политики, правительственные постановления,
промышленные стандарты и вычислительные алгоритмы;
Атрибуты качества - представляют собой дополнительное описание функций продукта,
выраженное через описание его характеристик, важных для пользователей или разработчиков;
Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры
продукта, а так же описывают внешние взаимодействия между системой и внешним миром.

16. Типы и уровни требований

Требования заинтересованных сторон: описывают потребности заинтересованных сторон,
которые должны быть выполнены для удовлетворения бизнес-требований. Они могут служить в
качестве моста между бизнес-требованиями и требованиями к Решению.
Требования к Решению: описывают возможности и качества Решения, которые удовлетворяют
требованиям заинтересованных сторон. Обеспечивают соответствующий уровень детализации,
позволяющий вести разработку и внедрение Решения и представлены двумя подкатегориями:
Функциональные требования: описывают возможности, которые Решение должно иметь в
терминах поведения и информации, которой Решение будет управлять;
Нефункциональные требования или требования к качеству обслуживания: не относятся
непосредственно к поведению функциональности Решения, а описывают условия, при
которых Решение должно оставаться эффективным, или качества, которым Решение должно
удовлетворять.
Переходные требования: описывают возможности, которые Решение должно иметь и условия,
которым Решение должно удовлетворять, чтобы обеспечить переход от текущего состояния к
будущему состоянию, но которые будут не нужны после того, как изменения будут
осуществлены. Эти требования носят временный характер. Переходные требования относятся к
таким темам как — преобразование данных, обучение и обеспечение непрерывности бизнеса.

17.

Фаза проактивной работы с требованиями заинтересованных сторон (ЗС)
1
Первичный анализ исходных
требований ЗС
2
Сбор и фиксация требований ЗС
3
Анализ собранных требований,
переработка исходных требований ЗС
4
Уточнение вопросов у ЗС (с обязательным
оформление протокола)
5
Согласование требований ЗС
Основные документы фазы
Источники исходной информации:
• Политики, регламенты, стандарты и т.д. (см. КИП);
• Государственные и профессиональные стандарты
(при наличии);
• Пр.
Инструменты сбора требований:
• Анкетирование;
• Интервьюирование;
• Изучение существующей
документации;
• Работа «в поле» (в т.ч. Наблюдение);
• Совещание;
• Обучение;
• Мозговой штурм;
• Повторное использование
спецификаций
1. Реестр требований ЗС
2. Протоколы встреч и других форм взаимодействия с ЗС

18.

Фаза реактивной работы с требованиями заинтересованных сторон
1
Поступило новое требование ЗС или ЗС
инициирует изменение требования, ранее
принятого к проработке в проекте
2
Оценить влияние изменения на решение, сроки и
стоимость проекта. Определить зависимости и
влияние на уже принятые требования ЗС
3
Провести процедуру переработки требования,
аналогично той, которая выполняется на
проактивной фазе
4
1
Согласовать изменение с заказчиком и другими ЗС
(при наличии взаимозависимостей требований)
Возникает потребность в изменении
требования со стороны команды
проекта
Основные документы фазы
1. Лист изменения (с
внесенной отметкой об
изменении требования ЗС)
2. Обновленный реестр
требований ЗС
3. Протоколы встреч и других
форм взаимодействия с ЗС

19.

Рекомендации по работе с требованиями
Рекомендация №1 Применяйте технику "Пять почему", она позволяет перенести обсуждение из
плоскости представленного решения в плоскость четкого понимания решаемой проблемы.
Рекомендация №2 Представьте, что вы обучаетесь обязанностям пользователя (попытайтесь
поставить себя на место пользователя). Задавайте открытые вопросы, чтобы понять текущие
бизнес-процессы пользователя и понять, как система может повысить их производительность.
Рекомендация № 3 Используйте вопросы, которые приведены ниже:
• "Какие из существующих функций системы вы находите наиболее полезными?"
• "Какие функции стоит добавить?"
• "Какие функции, по вашему мнению, бесполезны?"
• "Какие особенности системы вас не устраивают?" (попытайтесь выяснить, что раздражает
пользователя в текущей работе системы)
• "С какими проблемами вы сталкиваетесь в повседневной работе?"
• "Каким образом вы решаете эту проблему?"
• "Что вам нравится в этом способе решения проблемы? а что вас не устраивает?"

20.

Материалы по работе с требованиями и системному анализу
Школа системного анализа: https://systems.education/books
System Engineering Thinking Wiki: http://sewiki.ru/
• ISO/IEC/IEEE 15288:2015 Systems and
software engineering -- System life cycle
processes
• ISO/IEC 12207:2008 Systems and software
engineering -- Software life cycle processes
• ISO/IEC/IEEE 42010:2010 - Системная и
программная инженерия. Концептуальное
https://www.ozon.ru/c
ontext/detail/id/14719
7469/
https://ridero.ru/books
/sistemnoe_myshlenie/
описание архитектуры

21.

Техники работы с требованиями
• Анкетирование;
• Интервьюирование;
• Изучение существующей документации;
• Работа «в поле» (в т.ч. наблюдение);
• Совещание;
• Обучение;
• Сбор и анализ данных (аналитика на основе данных);
• Мозговой штурм;
• Повторное использование спецификаций.
Подробнее про техники: https://habr.com/ru/company/simbirsoft/blog/307844/

22. Основные роли в процессе управления требованиями

Спец. фин.
Бизнес-аналитик
Бизнес-аналитик/
службы
Системный
аналитик
Заинтересованная
Ген. директор
сторона
Главный
Операционист
Главный архитектор
Руководитель
Спец. юр.
проекта
службы
архитектор
Владелец
Спец.
юр.
продукта
(Product
службы
owner)
Клиент
Архитектор
домена
Архитектор
Займодавец
решения

23.

Дополнительный материал

24.

Запрос на архитектурную работу
Запрос на
изменение
A
Операционист
Клиент
Детализированная
архитектура решения
Займодавец
Займодавец
Спец. юр.
службы
G
B
+
Спец. фин.
службы
Клиент
БИЗНЕСАРХИТЕКТУРА
Разработка
бизнесархитектуры
C
Управление
требованиями
Управление
реализацией
Создание
архитектурного
видения
Управление
изменениями
архитектуры
Детальная архитектура решения
(solution)
Займодавец
H
Архитектурное
видение
Архитектурное видение в соответствии
с собранными бизнес-требованиями
ОперационистСпец. фин.
службы
ИНФОРМАЦИОННАЯ АРХИТЕКТУРА
Клиент
Разработка
архитектуры
информационных систем
Спец. фин.
службы
АРХИТЕКТУРА ПРИЛОЖЕНИЙ
Концепция решения
Технические задания на
разработку
Концепция
решения
Консолидированная
архитектурная
дорожная
Дорожная
карта
карта
D
F
Планирование
изменений
E
Операционист
Клиент
Спец. фин.
службы
Разработка
технологической
архитектуры
Клиент
Спец. фин.
службы
ТЕХНОЛОГИЧЕСКАЯ
АРХИТЕКТУРА
Выявление
возможностей и
решений
Операционист
Клиент
Спец. фин.
службы
Описание архитектурных блоков
(Архитектурные модели по доменам с
привязкой к требованиям)
The Architecture Definition Document
The Architecture Requirements
Спецификации
архитектуры по доменам

25.

Ключевые итерации
Итерация:
«Сове ршенствование практики
управления архит ектурой»
Метод разработки архитектуры Architecture Development Method (ADM)
В TOGAF для ADM выделяется ряд ключевых итераций, т.е.
A
внутренних мини-циклов.
H
Создание
архитектур ног
о видения
Управление
изменениями
архитектур ы
В рамках каждой из итераций возможно повторное
выполнение определенных фаз ADM, при этом количество
подобных повторений не регламентировано.
Предваритель
ная фаза
B
Разр аботка
бизнесархитектуры
C
Управлен
ие
требовани
ями
G
Упр авление
реализацией
D
F
Планир овани
е изменений
Разр аботка
архитектуры
информацион
-ных систем
E
Выявление
возможност е
й и решений
Разр аботка
технологичес
кой
архитектуры

26.

Развитие - это…
Развитие - процесс перехода из одного состояния в другое, более совершенное,
переход от старого качественного состояния к новому качественному состоянию, от
простого к сложному, от низшего к высшему.
"Законы общественного развития"