{Развернуть все...}
Модель знаний о требованиях в формате ArchmateЦель обучения:
{+...}
Термины: требование, спецификация требований, инженерия требований, заинтересованная сторона, система инженер по требованиям.
Цель обучения:
{+...}
Люди и организации имеют желания и потребности для построения нового или изменения существующего. Такие потребности называются требованиями или:
{+...}
Спецификация требований — системно представленная коллекция требований, обычно для системы, удовлетворяющая заданным критериям.
Requirements Engineering — систематический и организованный подход к спецификации и управлению требованиями с целью понимания желаний и потребностей заинтересованных сторон и минимизации риска разработки системы, которая не отвечала бы желаниям и потребностям.
Система:
{+...}
Предметы для построения или развития рассматриваются как системы:
{+...}
Термин "Система" может включать продукты, сервисы, приложения или устройства.
Заинтересованные стороны — лица или организации, которое влияет на требования к системе или на которое эта система оказывает влияние.
Цель RE — определять и управлять требованиями для систем таким образом, чтобы система, будучи внедрена и установлена, удовлетворяла желания и потребности заинтересованных сторон.
В RE различаются три вида требований:
{+...}
Цель обучения:
{+...}
Адекватные требования добавляют ценность в процесс разработки и эволюции систем:
{+...}
Типичные симптомы неадекватного RE — отсутствие, неясные или некорректные требования, что особенно относится к проблемам:
{+...}
Цель обучения:
{+...}
RE может быть применим для требований любого вида систем. Однако, основное применение RE сегодня представлено системами, в которых основную роль играет программное обеспечение. Такие системы состоят из программных компонентов, физических и организационных элементов.
Различают требования (проекции требований в зависимости от точки зрения):
{+...}
{+...}
Цель обучения:
{+...}
Основные задачи RE:
{+...}
Инструменты поддержки могут помочь выполнять задачи. Анализ требований и разрешение конфликтов рассматриваются как часть выявления. Для того, чтобы выполнять активности RE надлежащим образом, подходящий процесс RE конфигурируется из набора возможностей.
Цель обучения:
{+...}
Инженер по требованиям обычно не название должности, а роль, включающая функции:
{+...}
На практике бизнес-аналитики, специалисты по приложениям, владельцы продуктов и даже разработчики выполняют роль инженера по требованиям.
Помимо технических и аналитических навыков, инженеру по требованиям так же требуются «софт» навыки:
{+...}
Цель обучения:
{+...}
Основные навыки, которые инженер по требованиям должен изучить:
{+...}
Цель обучения:
{+...}
Термины: контекст, требование, инженерия требований, заинтересованные стороны, разделяемое понимание, валидация.
Цель обучения:
{+...}
Задача - целостная часть работы, которая должна быть выполнена.
Активность - действия или набор действий, которые лицо или группа лица должны выполнять, что исполнить задачу.
Практика - проверенный способ о том, как выполнять определенные типы задач или активностией.
RE руководствуется набором фундаментальных принципов, которые применяются для всех задач, активностей и практик. Следующие девять принципов формируют основу для практик RE:
{+...}
Цель обучения:
{+...}
Принцип 1. Ориентация на ценность: требования - это средство достижения целей, а не цель сами по себе.
Ценность требований определяется как выгоды минус затраты на выявление, документирование, валидацию и управление требованиями. Выгоды требований заключаются в том, в какой степени они способствуют:
{+...}
Принцип 2. Заинтересованные стороны: RE — о том, как удовлетворить желания и потребности заинтересованных сторон.
Надлежащая работа с заинтересованными сторонами — ключевая задача RE. Каждая заинтересованная сторона имеет роль в контексте разрабатываемой системы, например: пользователь, клиент, потребитель, оператор или регулятор. Заинтересованная сторона может выполнять более одной роли в один момент времени. Для ролей заинтересованных сторон с множеством действующих лиц, или когда действующие лица неизвестны может быть определено фиктивное описание археотипа, известное как персона. Не достаточно рассматривать только требования конечных пользователей или потребителей, так как можно упустить критические требования других пользователей. Пользователи, которые могут дать обратную связь (отзывы) о системе в использование также должны рассматриваться в качестве заинтересованных сторон.
Недостаточно просто собрать требования от заинтересованных сторон. Заинтересованные стороны имеют разные точки зрения на разрабатываемую систему, в результате чего могут возникать непоследовательности и конфликты, между требованиями, которыми нужно управлять.
Вовлечение корректных лиц в релевантных ролях заинтересованных сторон является ключевым для успешного RE.
Принцип 3. Разделяемое понимание: успех разработки системы не возможен без общей основы.
RE создает, стимулирует и защищает разделяемое понимание между и среди вовлеченных участников: заинтересованных сторон, инженера по требованиям и разработчиком. Существует две формы разделяемого понимания:
{+...}
Знание предметной области, предыдущее удачное сотрудничество, разделяемая культура и ценности и взаимное доверие являются активаторами разделяемого понимания, в то время как географическая распределенность, аутсорсинг или большие команды с высокой загрузкой являются препятствиями.
Доказанные практики разделяемого понимания понимания включают:
{+...}
Практики для оценки разделяемого понимания включают:
{+...}
Наиболее важная практика для снижения влияния непонимания — использование процесса с короткими циклами обратной связи.
Принцип 4. контекст: системы не могут быть поняты в изоляции.
Системы встроены в контекст. Без понимания контекста невозможно определить систему правильно. В RE контекст системы является частью ее окружения, которое полезно для понимания системы и требований к ней. Границы системы — границы между системой и окружающим контекстом. Изначально границы системы часто не ясны и это может поменяться с течением времени.
Прояснение границ системы и определение внешних интерфейсов между системой и элементами контекста, взаимодействующими с ней, является важной задачей RE. В то же самое время рамки (scope) системы — диапазон проблем и сущностей, которые могут быть охвачены и спроектированы, когда система разрабатывается, должны быть определены. Так же рассматривается граница контекста, которая разделяет полезную для RE часть окружения системы от остального мира.
Когда определяется система не достаточно рассматривать только требования без границ системы. RE также рассматривает:
{+...}
Принцип 5. Проблема, требование, решение: неизбежно связанный треугольник.
Проблема случается когда заинтересованные стороны не удовлетворены ситуацией «как есть». В требованиях содержится, что заинтересованным сторонам требуется, чтобы избавиться от проблемы или упростить ее. Социотехнические системы, удовлетворяющие требованиям составляют решение.
Проблемы, требования и решения могут переплетаться путями:
{+...}
Проблемы, требования и решения не обязательно случаются в приведенном порядке. Идеи решений могут создавать потребности пользователей, которые должны быть проработаны как требования и реализованы в реальном решении. Как правило, это происходит при внедрении инноваций.
Последствия для процесса разработки:
{+...}
Принцип 6. Валидация: непроверенные требования не пригодны к использованию.
В конце концов мы должны подтвердить, что поставляемая система удовлетворяет желаниям и потребностям заинтересованных сторон. Для того, чтобы контролировать риск неудовлетворенности заинтересованных сторон, первоначально в процессе RE должна быть проведена валидация требований - процесс подтверждения того, что предмет (система, рабочий продукт или часть чего то) соответствует потребностям заинтересованных сторон. Должно быть проверено:
{+...}
Принцип 7. Развитие: изменение требований — не исключительная ситуация, а нормальный процесс.
Системы и требования к ним являются предметом эволюции, что означает, что они постоянно меняются. Запросы на изменения требований или наборов требований для системы могут быть вызваны:
{+...}
Дополнительно, требования могут меняться в процессе обратной связи от заинтересованных сторон, когда требования проверяются, в процессе обнаружения ошибок в ранее выявленных требованиях иди в процессе изменения потребностей.
Как следствие, инженер по требованиям должен преследовать две противоречащие цели:
{+...}
Принцип 8. Инновация: «больше того же недостаточно».
Давая заинтересованным сторонам в точности то, что они хотят, мы упускаем возможность построения систем, которые удовлетворяют потребности лучше, чем ожидается. Хороший RE прилагает усилия не только удовлетворить заинтересованные стороны, но и сделать их счастливыми, взволнованными, чувствующими безопасно. В этом, в конечном счете, и заключается суть инноваций.
RE формирует инновационные системы:
{+...}
Принцип 9. Систематическая и дисциплинированная работа: "не работать без".
Мы должны использовать подходящие процессы и практики для систематического выявления, документирования, подтверждения и управления требованиями безотносительно действующего процесса разработки. Даже, когда система разработана специальный подход, систематический и дисциплинированный подход к RE улучшает качество получаемой системы.
В RE нет одной практики или процесса, которые хороша работают в каждой конкретной ситуации или в большинстве ситуаций. Систематическая и дисциплинированная работа означает, что инженер по требованиям:
{+...}
Для каждого RE должны выбираться усилия, процессы, практики и рабочие продукты, лучше всего подходящие к конкретной ситуации.
К содержанию ...
Цель обучения:
{+...}
Термины: рабочий продукт; рабочие продукты, основанные на естественных языках; .рабочие продукты, основанные на шаблонах; рабочие продукты, основанные на моделях; словарь, критерии качества, спецификация требований.
Цель обучения:
{+...}
Рабочий продукт — записанный промежуточный или финальный результат, производимый в процессе работы. В RE существует большое разнообразие рабочих продуктов, начиная с графических эскизов, эволюционирующих коллекций пользовательских историй до формально выпускаемых спецификаций требований, закрепленных договорами, с тысячами страниц.
3.1.1. Характеристики рабочих продуктов (L1)
В RE используются различные типы рабочих продуктов. Они характеризуются:
{+...}
На практике следующие рабочие продукты часто встречаются согласно целям к продуктам (одни рабочие продукты могут включать другие):
{+...}
Рабочие продукты могут быть представлены в различных формах:
{+...}
Большинство рабочих продуктов сохраняются в электронном виде как файлы, в базах данные в инструментах RE. Неформальные временные рабочие продукты могут так же храниться на других носителях, например, на бумаге или записках на доске Канбан.
При рассмотрении жизненного цикла рабочих продуктов выделяется три категории:
{+...}
Временные рабочие продукты могут конвертироваться в эволюционирующие (путем добавления метаданных). По аналогии, временные или эволюционирующие рабочие продукты могут становиться длительными.
3.1.2. Категории и уровни абстракции (L2)
Различают системные требования, требования заинтересованных сторон, пользовательские требования, требования к предметной области и бизнес-требования. Некоторые рабочие продукты, такие как индивидуальные требования, эскизы или процессные модели используются во всех категориях. Другие рабочие продукты специализированы для определенных категорий.
Когда бизнес-требования и требования заинтересованных сторон выражены в долгосрочных рабочих продуктах, таких как спецификации бизнес-требований, спецификации требований заинтересованных сторон или концептуальные документы, они предшествуют спецификации системных требований. В других проектах бизнес-требования, требования заинтересованных сторон и системные требования могут эволюционировать совместно.
Требования обычно существуют на множестве различных уровней абстракции — от, например, высокоуровневых требований для новых бизнес-процессов до требований на очень детализированном уровне, таких как реакция конкретного компонента ПО на исключительную ситуацию.
Требования часто организованы в три уровня абстракции:
{+...}
Выбор надлежащего уровня абстракции зависит от того, что определено. Важно, однако, не смешивать требования на различных уровнях абстракции. В небольших рабочих продуктах и продуктах среднего размера требования должны быть примерно на одном уровне. В больших рабочих продуктах, таких как спецификации системных требований требования на различных уровнях должны быть собрано отдельно посредство разделения структуры спецификации.
3.1.3. Уровни детализации (L2)
Уровни детализации, на котором требования должны быть определены зависит от нескольких факторов:
{+...}
Наибольший уровень деталей в определяемых требованиях сокращает риск в итоге получить что то неожиданное или неопределенное. Однако, затраты на спецификацию детализированных требований также увеличиваются.
3.1.4. Аспекты, рассматриваемые в рабочих продуктах (L1)
При определении требований должны быть рассмотрены различные аспекты:
{+...}
{+...}
{+...}
{+...}
{+...}
{+...}
Существует множество взаимосвязей и зависимостей между упомянутыми аспектами. На пример, запрос, поставленный пользователем (контекст) может запускать переход состояния (состояние и поведение), который инициирует действия, следующей за другим действие (функции и потоки), что требует данные (структура и данные) для обеспечения результатом пользователя (контекст) в заданное время (качество).
Некоторые рабочие продукты фокусируются на определенном аспекте и абстрагируются от других аспектов. В особенности это касается моделей. Другие рабочие продукты, такие как спецификации системных требований, покрывают все аспекты. Когда различные аспекты документируются в различных рабочих продуктах или в различных разделах рабочего продукта, такие рабочие продукты или разделы должны поддерживаться целостными.
3.1.5. Общие правила документирования (L1)
Вне зависимости от используемых техник применяются следующие правила при создании рабочих продуктов:
{+...}
3.1.6. Планирование использования рабочих продуктов (L1)
Каждый проект и каждая предметная область различаются, таким образом, набор рабочих продуктов должен быть определен для каждого начинания. Поэтому следующие вопросы должны согласованы перед прежде всего:
{+...}
Рабочие продукты для использования должны быть определены на ранней стадии проекта, так как это дает несколько преимуществ:
{+...}
Цель обучения:
{+...}
С начала применения систематического RE требования на естественных языках являются ключевым способом для спецификации требований на практике.
Основные преимущества рабочих продуктов на естественных языках:
{+...}
Эти преимущества становятся проблемами, когда тексты, написанные на естественном языке интерпретируются различными способами. Дополнительно, выявление двусмысленности, упущений и непоследовательностей в таких текстах трудно и затратно.
Аспекты написания хороших требований на естественных языках:
{+...}
Когда пишутся технические документы на естественном языке, существует хорошо известные проблемы, которые необходимо избегать или использовать с осторожностью:
{+...}
{+...}
{+...}
Цель обучения:
{+...}
Рабочие продукты, основанные на шаблонах используются для преодоления некоторых недостатков продуктов на естественных языках посредством предопределенных структур для требований:
{+...}
{+...}
{+...}
{+...}
Различные шаблоны описаны в литературе, например, шаблоны для вариантов использования, документов спецификаций, описаний задач. Дополнительно потребитель может предопределить использование пользовательских шаблонов в проекте.
Преимущества рабочих продуктов, основанных на шаблонах:
{+...}
Недостатки и проблемы рабочих продуктов, основанных на шаблонах:
{+...}
Цель обучения:
{+...}
Требования, представленные на естественном языке имеют ограничения, в частности относительно обзора набора требований и понимания взаимосвязей между требованиями. Моделирование требований направлено на устранение этих ограничений.
3.4.1. Роль моделей в инженерий требований (L2)
Модель - это абстрактное представление существующей части реальности или части реальности, которую нужно создать. Понятие реальности включает любой мыслимый набор элементов, феноменов или концепций, включая другие модели. В отношении модели, моделируемая часть реальности называется оригиналом.
В RE модели помогают понять взаимосвязи и соединения между требованиями и обеспечивают обзор наборов требований. Это достигается, в основном, путем фокусирования на некоторых аспектах, например, поведение, в то время как происходит абстрагирование от других аспектов. Достижение обзора так же поддерживается графической нотацией для модели. Однако, модели могут быть также представлены не графическим способом, например, таблицы.
Язык моделирования состоит из грамматических правил и описания смысла конструкций языка. Синтаксис описывает какие элементы нотации используются а языке моделирования, а так же как эти элементы используются в комбинации. Семантика определяет значение элементов нотации и значение комбинаций элементов.
Свойства моделей:
{+...}
Преимущества моделей требований, в сравнении с требованиями, представленными на естественном языке:
{+...}
Модели имеют ограничения:
{+...}
Поэтому модели требований и требования на естественном языке часто комбинируются.
Модели используются для описания требований с определенной точки зрения (Природа системы помогает выбрать надлежащую модель). В системной разработке функциональные требования категоризируются в соответствии с точками зрения:
{+...}
В RE модели могут быть использованы для:
{+...}
Качество модели требований и элементов моделей связано с тремя критериями:
{+...}
Для выражения требований используются языки моделирования, некоторые стандартизированы, например, UML, BPMN. Когда требования определены в нестандартизированных языках моделирования, то требуется пояснение синтаксиса и семантики используемого языка.
Существует множество типов моделей, используемых в RE. Инженер по требованиям должен понимать, какой тип модели лучше подходит для определения требований в конкретной ситуации.
3.4.2. Моделирование контекста (L2)
Модели, фокусирующиеся на аспекте контекста определяют структурное встраивание системы в ее окружение и взаимодействие между системой и акторами в системном контексте.
Модели контекста определяют систему и акторов в системном контексте, которые взаимодействуют с системой. Контекстные модели также отображают эскизно интерфейсы между системой и ее контекстом (например, в терминах, какая информация обменивается).
Контекстные диаграммы используются как графический язык моделирования для представления контекстных моделей. Не существует стандартизированной нотации для контекстных диаграмм. Могут использоваться контекстные диаграммы для структурного анализа (DFD), частные диаграммы, использующие прямоугольники или линии, адаптироваться блоковые диаграммы SysML.
В UML диаграммы вариантов использования - способ моделирования системы и ее контекста в терминах системных вариантов использования и акторов в системном контексте, взаимодействующих с системой через варианты использования.
Варианты использования моделируют динамическое взаимодействие между актором в системном контексте и систем с точки зрения актора. Варианты использования в большинстве случае написаны с использованием шаблонов форм на естественном языке или с использованием диаграмм деятельности UML.
3.4.3. Моделирование структуры и данных (L3)
Модели, фокусирующихся на аспектах структуры и данных определяют требования для статических структурных свойств системы или предметной области.
Статические модели предметной области определяют (бизнес) объекты и их взаимосвязи в интересующей предметной области. Могут быть представлены диаграммами классов UML.
Модели классов в основном определяют классы в системе и их атрибуты и взаимосвязи. Классы представляют осязаемые и неосязаемые сущности реального мира, которые система должна знать для выполнения своих задач.
Примеры диаграмм моделей для моделирования структуры и данных: диаграммы "Сущность-связь" (ERP), диаграммы классов UML, блоковые диаграммы SysML, BIM.UML диаграммы классов обычно используются как язык моделирования для моделей классов. Элементы нотации:
{+...}
В системной инженерии блоковые диаграммы SysML моделируют концептуальные сущности, которые существуют в системе и взаимосвязи между ними.
Моделирование используется в различных предметных областях. В построении конструкций (BIM) элементы моделей требуются для планирования, построения и управления строениями и другими элементами конструкций.
3.4.4. Моделирование функций и потока (L3)
Модели, фокусирующиеся на аспектах функций и потока определяют требования для последовательности действий, требуемых для произведения результатов в зависимости от заданных входов, требуемых для бизнес процесса, включая поток управления и данных между действиями и определения ответственного за каждое действие.
Модели активностей используются для определения системных функций. Примеры диаграмм моделей для моделирования активностей: диаграммы вариантов использования UML, диаграммы деятельности UML, диаграммы последовательностей UML, диаграммы потоков данных DFD, модели историй предметной области.
В UML диаграммы деятельности используются для представления моделей активностей. Они обеспечивают элементы для моделирования действий и потока управления между акциями. Диаграммы деятельности могут так же выражать, кто ответственный за каждое действие. Расширенные элементы моделирования обеспечивают способы моделирования потока данных. Основные элементы нотации:
{+...}
Модели процессов используются для описания бизнес-процессов и технических процессов. Могут быть представлены диаграммами деятельности UML или специфичными языками моделирования такими как BPMN.
Модели историй предметной области определяют визуальные истории об акторах, взаимодействующих с устройствами, артефакты и другие элементы предметной области, типичные для обозначений в предметной области. Являются способом понять домен приложения в котором оперирует система.
3.4.5. Моделирование состояний и поведения (L2)
Модели, фокусирующиеся на состоянии и поведении определяют требования для поведения системы и компонента предметной области в терминах реакции, зависимых от состояний, или динамики взаимодействия компонентов.
Машины состояний моделируют события, которые вызывают переход от одного состояния к другому и действия, необходимые для выполнения, когда возникает переход. Карты состояний - машины состояний, которые декомпозируются иерархически и/или ортогонально. Машины состояний, включая карты состояний, могут представляться на языке UML с использованием диаграмм состояний. Основные элементы нотации:
{+...}
Модели взаимодействия моделируют динамические взаимодействия между объектами или акторами. Диаграммы последовательностей UML являются популярным способом для определения взаимодействий между объектами. Основные элементы нотации:
{+...}
Цель обучения:
{+...}
В каждом проекте RE, в который вовлечен более одного участника, существует риск недостатка разделяемого понимания терминологии, что означает, что каждый участник может интерпретировать один и тот же термин по разному. Для смягчения этой проблемы разделяемое понимание о полезных терминах записывается в словаре.
Словарь - центральная коллекция определений для:
{+...}
Синонимы (различные термины, обозначающие один предмет) должны быть выделены. Омонимы (один термин для обозначения разных предметов) должны избегаться или помечаться как таковой.
Следующие правила применимы для словарей:
{+...}
{+...}
{+...}
Цель обучения:
{+...}
Спецификации документов требований включают несколько рабочих продуктов RE. Поэтому важно организовать такие документы в хорошо определенную структуру, чтобы создавать последовательную и обслуживаемую коллекцию требований. Помимо требований, документы требований могут также содержать дополнительную информацию и объяснения, например, словарь, условия принятия, проектную информацию или характеристики технической реализации.
Требования могут организованы в структуры документов, отличающиеся от классических документов.
Часто используемые виды документов:
{+...}
Часто используемые альтернативные структуры документации:
{+...}
Выбор структуры документации и внутренней организации выбранной структуры зависит от:
{+...}
Шаблоны документов помогают структурировать спецификацию требований. Шаблоны доступны в литературе и стандартах. Могут также повторно использоваться от предыдущих аналогичных проектов или могут быть предложены потребителем. Организация может создать собственный шаблон как внутренний стандарт.
Цель обучения:
{+...}
Прототип это:
{+...}
В RE прототипы являются способом определения требований через примеры и валидации требований. В частности, прототипы могут быть использования, если заинтересованные стороны не хотят писать или читать рабочие продукты.
Исследовательские прототипы используются для создания разделяемого понимания, разъяснения требований или валидации требования на различных уровнях точности. Они уничтожаются после использования:
{+...}
В зависимости от степени точности, исследовательские прототипы могут быть затратными рабочими продуктами, поэтому разработка прототипов является всегда компромиссом между затратами и достигаемой ценностью.
Экспериментальные прототипы используются для объяснения концептов технического спроектированного решения, в частности относительно технической реализуемости. Уничтожаются после использования.
Эволюционные прототипы - пилотные системы, которые формируют ядро разрабатываемой системы. Финальная система эволюционирует последовательно расширяясь и улучшаясь от пилотной системы в несколько итераций.
Цель обучения:
{+...}
Требования должны отвечать определенным критериям качества, чтобы рассматриваться как хорошие требования. В новом RE с подходом, ориентированным на ценность, степень завершения для критерия качества должна соответствовать ценности, создаваемой требованием. Это означает, что требования не должны соответствовать всем критериям качества полностью, а более высокая ценность требования и большая релевантность являются критерием качества, уменьшающим риск неудачи.
Адекватность и понимаемость являются наиболее важными критериями качества для одиночных требований. Без них требования бесполезны или даже вредны, безотносительно степени завершения или другим критериям.
Критерии качества для одиночных требований:
{+...}
Требования могут обычно записываться в различных рабочих продуктах, которые покрывают одиночные или множественные требования. Критерии качества выше должны использоваться для создания хороших одиночных требований.
Для рабочих продуктов, включающих более одного требования, следующие критерии качества должны рассматриваться дополнительно:
{+...}
Цель обучения:
{+...}
Термины: источник требований, граница системы, системный контекст, выявление требований, переговоры о требованиях, валидация требований, модель Кано, конфликт.
Цель обучения:
{+...}
Качество и полнота требований сильно зависят от вовлеченных источников требований. Отсутствие полезных источников будет приводить к неполноте понимания требований или к неполноте требований. Идентификация источников требований является итеративным и рекурсивным процессом, требующего постоянного пересмотра.
Разделяемое понимание контекста системы в разработке является предпосылкой, которая делает доступным идентификацию полезных источников требований. Область между границей системы и границей контекста называется системным контекстом. Системный контекст - необходимая для понимания природа требований для разработки и, таким образом, необходим для идентификации оригинальных источников требований.
Источники требований классифицируются по трем типам:
{+...}
Заинтересованные стороны системы - основные источники требований, включают:
{+...}
Систематическая идентификация заинтересованных сторон должна присутствовать в начала проекта разработки, а результаты должны управляться в процессе разработки как постоянная активность.
Для всех систем с пользовательским интерфейсом конечные пользователи системы составляют группу заинтересованных сторон, которая представляет особый интерес для инженера по требованиям. Требуется выделять роли пользователей - разделение на роли в основном происходит в зависимости от потребностей в информации и в том, каким способом будет использоваться система, включая права доступа к функциям и данным. В случае большого числа пользователи должны быть агрегированы в группы пользователей, для того, чтобы стимулировать процесс выявления. Практический путь описания больших групп пользователей - использование понятия «персона» (фиктивная личность, описывающая типичные группы пользователей системы со сходными потребностями, целями, поведением или отношением). Существует две основных категории пользователей:
{+...}
Потенциальные источники для идентификации полезных заинтересованных сторон:
{+...}
Заинтересованные стороны должны быть задокументированы и актуальном списке с как минимум следующей информацией:
{+...}
Проблемы с заинтересованными сторонами могут возникать, если их права и обязанности не ясны или если потребности заинтересованных сторон не достаточно изучены. Управление взаимоотношениями с заинтересованными сторонами является эффективным способом решения проблем.
В большинстве системных контекстов доступно множество источников. Они должны также быть рассмотрены для успеха новой системы, так как большинство заинтересованных сторон не говорят очевидно, а выражают «подсознательные» требования.
Дополнительные источники для требований включают:
{+...}
Другие источники требований могут быть найдены просмотром сходных ситуаций в других предметных областях.
Цель обучения:
{+...}
В выявлении требований задачи инженера по требования понять желания и потребности заинтересованных сторон равно как гарантировать, что требования от всех источников собраны посредством применения соответствующих техник для выявления тиковых. Ключевой аспект выявления - перевод неявных запросов, желаний и ожиданий в явные требования.
Для выявления требований критически важно знать природу и важность каждого требования, которая может меняться от проекта к проекту и в течении времени. Модель Кано классифицирует требования в три релевантные категории:
{+...}
Существует множество различных техник для выявления этих категорий. Различают:
{+...}
Техники сбора - устанавливающие техники для сбора требований, помогающие выявить факторы удовлетворения и недовольства путем исследования различных источником. Включают четыре основных категории:
{+...}
{+...}
{+...}
{+...}
{+...}
{+...}
Техники проектирования и генерации идей фокусируются на стимулировании креативности. Такие техники используются для создания новых или инновационных требований, которые часто являются факторами восхищения. Они нацелены на создание идей и поиск решений для конкретного вопроса, цели или проблемы. Основные подкатегории техник:
{+...}
{+...}
Более широкая концепция для проектирования и генерации идей - дизайнерское мышление. Существуют различные подходы (например d.school и Designing for Growth), предлагающие большой набор техник, которые могут быть использования для выявления требований. Основные принципы дизайнерского мышления: сочуствие и креативность (чередование конвергентного и дивергентного мышления)
Техники выявления должны быть способны определять все виды требований - функциональные и требования к качеству, также как и ограничения.
Для выявления требований к качеству используются модели качества (например, стандарт ISO25010) как чеклист. Такие модели могут быть полезны для количественной оценки требований.
Ограничения могут быть выявлены путем рассмотрения возможных ограничений потенциального пространства решений, например, технические, юридические, организационные, культурные или вопросы окружения.
Выбор правильных техник выявления является критической ключевой компетенцией, которая зависит от множества различных факторов, таких как:
{+...}
Лучшие результаты обычно достигаются комбинацией различных техник выявления.
Цель обучения:
{+...}
Техники выявления сами по себе не гарантируют, что результирующий набор требований в целом последовательный, полный и соответствующий стандартам и т.д. Для финального набора требований требуется, чтобы все заинтересованные стороны понимали и быть согласны со всеми требованиями, полезными для них. Если некоторые стороны не согласны, то такая ситуация должна рассматриваться как конфликт, который должен быть разрешен соответствующим образом. Подходящие техники разрешения конфликтов выбираются на основе типов конфликтов и контекстной информации. Эти требует глубокого понимания природы конфликта требований и отношения вовлеченных заинтересованных сторон.
Задачи для идентификации и разрешения конфликтов:
{+...}
{+...}
Полезно различать различные типы конфликтов. Следующие типы конфликтов часто требуют внимания от инженера по требованиям:
{+...}
Для разрешения конфликтов применяются общие техники:
{+...}
В дополнение, существует несколько вспомогательных техник, например:
{+...}
Цель обучения:
{+...}
Валидация требований является важным шагом в направлении реализации успешной системы. Гарантия качества требований изначально уменьшается риск излишних усилий. Валидация требований означает проверку набора требований и индивидуальных требований на качество: покрытие потребностей заинтересованных сторон, степень согласия между ними, предположения относительно системного контекста.
Важные аспекты к рассмотрению в процессах валидации требований:
{+...}
Существует несколько техник валидации, классифицированных:
{+...}
{+...}
{+...}
Эти техники различаются степенью формальности и усилиями. Каждая техника выбирается в зависимости от таких факторов как:
{+...}
Цель обучения:
{+...}
Термины: процесс, процесс RE.
Процесс требуется для придания формы и структуры выполняемой работе RE в заданном контексте. Не существует одного процесса RE для всех случаев, индивидуальный процесс должен быть настроен таким образом, чтобы он соответствовал контексту разработки и системы.
Процесс RE формирует информационные потоки и модель коммуникаций между различными участниками (например, покупателями, пользователями, инженером по требованиям, разработчиками, тестерами), а также определяет рабочие продукты производимые или используемые. Таким образом процесс RE обеспечивает фреймворк для выявления, документирования, валидации и управления требованиями.
Цель обучения:
{+...}
Основные факторы, влияющие на конфигурацию процесса RE:
{+...}
Анализ влияющих факторов обеспечивает информацией о том, как конфигурировать процесс RE. Влияющие факторы также ограничивают пространство возможных конфигураций процесса. Например, когда заинтересованные стороны доступны только в начале проекта, не может быть выбран процесс, построенный на постоянной обратной связи.
Цель обучения:
{+...}
Существует три аспекта решения, которые должны рассматриваться, когда конфигурируется процесс RE.
Аспект времени: линейный и итеративный. В линейном процессе требования определяются в первую очередь в одной фазе процесса. В итеративном процессе требования определяются инкрементно, начиная с общих целей и некоторых начальных требований и затем добавляются или модифицируются требования в каждой итерации.
Критерии для выбора линейного процесса RE:
{+...}
Критерии для выбора итеративного процесса RE:
{+...}
Аспект цели: предписывающий и исследовательский. В предписывающем процессе RE спецификации требований составляют основу контракта - все требования связаны и должны быть реализованы. В исследовательском процессе только цели известны точно, в то время как конкретные требования должны быть выявлены.
Критерии для выбора предписывающего процесса RE:
{+...}
Критерии для выбора исследовательского процесса RE:
{+...}
Аспект назначения: ориентированный на покупателя или на рынок. В процессе RE, ориентированном на пользователя, система разрабатывается для поставщиком для конкретного покупателя. В процессах RE, ориентированных на рынок, система разрабатывается как продукт или сервис для рынка, ориентированного на определенные сегменты пользователей.
Критерии для выбора процесса RE, ориентированного на покупателя:
{+...}
Критерии для выбора процесса RE, ориентированного на рынок:
{+...}
Советы и предостережения:
{+...}
Цель обучения:
{+...}
В конкретном контексте разработки системы лица, ответственные за RE должны конфигурировать применяемый процесс RE. Основываясь на анализе влияющих факторов может быть использована подходящая комбинация шаблонов процессов.
Типичные комбинации процессов:
{+...}
{+...}
{+...}
{+...}
Могут существовать контексты разработки, где подходят не упомянутые выше конфигурации. Например, регуляторные ограничения могут определять использование процесса, требующего подтверждение в соответствии с заданными стандартами.
Для конфигурации процесса RE, рекомендуется процедура из пяти шагов:
{+...}
Цель обучения:
{+...}
Термины: управление требованиями, управление изменениями, прослеживаемость, атрибуты требований, жизненный цикл, приоритезация.
Цель обучения:
{+...}
Управление требованиями - это процесс управления существующими требованиями, записанными в различных рабочих продуктах. В частности, управление требованиями включает: хранение, изменение и прослеживаемость требований. Управление требованиями может выполняться различными способами и на различных уровнях в зависимости от выбранного процесса разработки и контекста. Вне зависимости от обстоятельств задача управления требованиями заключается в обслуживании требований таким путем, что все роли в проекте могут работать эффективно (должна быть уверенность, что версии корректны, требования полезны, взаимосвязи выявлены).
Управление требованиями производится на разных уровнях:
{+...}
Цель обучения:
{+...}
Жизненный цикл управления относится к процессу отслеживания всех рабочих продуктов относительно статусов в жизненном цикле. Каждое задокументированное требование и каждый рабочий продукт имеют собственный жизненный цикл: создано, оценено и доработано перед просмотром, повторно включено в работу, консолидировано, согласовано и т.д. Для того, чтобы обеспечить идентификацию, в каком состоянии находится рабочий продукт, в модели жизненного цикла требуется определить статус и переходы состояний. Актуальный статус рабочего продукта всегда должен быть ясен, включая историю переходов.
Управление жизненным циклом включает:
{+...}
Цель обучения:
{+...}
Управление версиями требований относится к процессу отслеживания всех рабочих продуктов в процессе их развития. Любое изменение рабочего продукта должно быть отражено новой версией. Версионирование позволяет проследить историю рабочего продукта от источника и сохранять предыдущие версии рабочих продуктов (для возможности вернуться к ним или включить версию в другую конфигурацию). Для этих целей стратегия версионирования состоит как минимум из:
{+...}
Версионирование должно рассматриваться для всех рабочих продуктов. Номер версии типично состоит из как минимум двух частей: версия и инкремент.
Цель обучения:
{+...}
Конфигурация требований - это целостный набор рабочих продуктов, вмещающих требования. Каждая конфигурация определена для конкретной цели и вмещает не более одной версии каждого рабочего продукта. Цель конфигураций заключается, например, для обзора рабочих продуктов, чтобы обеспечить оценку усилий разработки.
Базовая линия - стабильная, проверенная и контролируемая (изменений) конфигурация рабочих продуктов, используемая для выпуска запланированных или других поставляемых результатов в вехах проекта.
Конфигурации имеют следующие свойства:
{+...}
Конфигурации всегда имеют две размерности: размерность продукта (какие требования включены в конкретную конфигурацию) и размерность версии (каждое требование может быть представлено только одной версией).
Цель обучения:
{+...}
Атрибуты требуются для документирования важных метаданных рабочего продукта и типично используются для ответа на важные вопросы в течение проекта или жизненного цикла продукта.
Цель присвоения атрибутов требованиям заключается в обеспечении возможности членам команды и другим заинтересованным сторонам получать необходимую информацию о требованиях в любой точке в течение проекта.
Определение релевантного набора атрибутов зависит от потребностей в информации различных заинтересованных сторон в проекте. Существующие стандарты обеспечивают обзор наиболее полезных атрибутов, например ISO29148:
{+...}
Представления - выдержки из общего набора требований, которые вмещают только содержание, к которому проявляется интерес.
Существует три типа представлений:
{+...}
В большинстве случаев для формирования отчетов, представления требований являются комбинациями представлений.
Цель обучения:
{+...}
Прослеживамость - способность отследить требования обратно к источникам (например, заинтересованным лицам, документам, юридическим основам и т.д. - Какой источник? Где найден?) и вперед к последующим рабочим продуктам (например, тестовым кейсам Где используется? В каких поставляемых результатах?), а также к другим требованиям (например, между видами требований и требованиями разных уровней), от которых это требование зависит.
Прослеживаемость обеспечивает предпосылки для управления требованиями и часто явно требуется стандартами, законами и правилами. Реализация прослеживаемости в особенности означает обслуживание зависимостей между рабочими продуктами требований различного уровня, а также взаимосвязями между источниками и последователями с целью анализа, соответствия и информации. Прослеживаемость позволяет:
{+...}
Прослеживамость может документировать неявно, путем структурирования и стандартизации рабочих продуктов, или явно, путем связывания рабочих продуктов друг с другом через уникальные идентификаторы в различных формах. Общее представление форм: гиперссылки, ссылки, матрицы, таблицы или графы.
Цель обучения:
{+...}
Требования не статичны. Изменения в требованиях происходят по различным причинам и должны обрабатываться надлежащим образом, например, созданием формального запроса на изменения или добавлением нового элемента в продуктовый бэклог.
Решение для принятия, планирования и управления реализацией относительно изменения зависит от подхода к разработке и момента времени, когда эти изменения происходят. Возможность внесения изменений включает аспекты:
{+...}
Процесс управления изменениями может включать:
{+...}
В линейном подходе решение часто принимается Советом по управлению изменениями (Change control board) или наблюдательного совета (Change Advisory Board). В большинстве итеративных подходов владелец продукта включает изменение продукта в бэклог продукта и приоритезирует новый элемент соответствующим образом.
Цель обучения:
{+...}
Не все требования одинаково важны. Оценка и приоритезация используются для определения наиболее полезных требований для выпуска следующего продукта или инкремента.
Оценка требований является основной для приоритезации, часто используются множественные критерии оценки, такие как ценность для бизнеса, срочность, затраты, зависимости и другие.
Приоритет требований описывает важность одного требования в сравнении с другими согласно определенным критериям. Выполнение приоритезации само по себе основывается на одном или нескольких критериях и зависит в основном о выбранных техник.
Шаги приоритезации:
{+...}
Техники приоритезации классифицируются:
{+...}
Цель обучения:
{+...}
Термины: инструменты, инструменты RE.
Цель обучения:
{+...}
Процесс RE может поддерживаться инструментами, реализующими выделенные активности и задачи. Так как процессы RE индивидуальны, то существующие инструменты RE часто фокусируются на определенных аспектах и реже поддерживают все активности. Перед выбором инструмента инженер по требованиям должен решить, какие задачи и активности в процессе RE должны поддерживаться и как. Различается несколько видов инструментов:
{+...}
{+...}
{+...}
{+...}
Инструменты часто включают несколько видов описанных выше свойств. Для гарантии, что все задачи RE выполняются надлежащим образом может комбинироваться несколько инструментов.
Иногда другие виды инструментов (например, офис или отслеживающие инструменты) используются для документирования или управления требованиями. Эти инструменты имеют ограничения и должны использоваться только тогда, когда процесс RE под контролем и требования достаточно стабильны и ровны.
Цель обучения:
{+...}
Выбор инструмента RE не отличается от таких же процессов для других целей. Цель, контекст и требования должны быть описаны для успешного выбора инструмента.
Соответствующий инструмент может быть выбран как только вводятся процедуры и техники RE. Внедрение инструмента требует ясной ответственности и процедур для RE. В процессе внедрения инструмента RE полезны следующие аспекты:
{+...}
{+...}