Цель лекции: Итак, от рассмотрения типов анализа мы переходим к смежным дисциплинам. Инженерия требований является чисто прикладной сферой деятельности — она формирует и уточняет информацию, необходимую для выполнения всех типов анализа. Именно инженерия требований является мостом между теоретической и практической частями анализа, проектирования и моделирования.
После возникновения некоторые из идей начинают эволюционировать в прибыльные концепции, формализуясь и обосновывая последующие инвестиции в себя — сначала только в голове автора, а потом в виде конкретных документов, обсуждаемых и изучаемых кругом причастных лиц. Идея получает основные очертания, главные и второстепенные функции. Так появляются требования к тому:
Идея проходит жизненный цикл и перерождается в набор единиц и нулей.
 |
 |
Инженерия требований — это инженерная дисциплина для выявления, анализа и моделирования требований к системе[1]. |
Жизненный цикл работы с требованиями, которые предопределяют материальный и информационный облик первоначального замысла, запущен. Путь, по которому требования проводят реализуемый продукт, начинается от стадии низкой формализации (когда есть только облик идеи) и продолжается до момента, когда все требования классифицированы и комплексно описывают идею во всех деталях. Дисциплина, которая описывает жизненный цикл работы с требованиями, называется инженерией требований.
На своем пути требования будут:
Действия, которые совершаются над требованиями в процессе создания продукта, обеспечивают соответствие первоначального замысла получившемуся результату.
Инженерия требований — технологическая дисциплина, поэтому она может гарантировать результат при условии следования определенной технологии.
 |
 |
Инженерия требований — совокупность знаний о способах обработки материалов, изделий, методах осуществления каких-либо производственных процессов[2]. |
Инженерия требований использует имеющиеся знания, подходы, методики для того, чтобы в конкретных условиях разработки требований обеспечить наиболее эффективный результат. Она неразрывно связана с самим продуктом. Пока есть продукт, существуют и требования к нему. В зависимости от имеющихся в наличии ресурсов инженерии требований на разных стадиях жизни продукта уделяется разное внимание. Она активно развивается. Существует множество практик и стандартов, которые описывают и регламентируют само понятие требования, его окружение и работу над ним (рис. 24).
Рис.24
Оформление инженерии требований в отдельную дисциплину началось в 50-е годы прошлого века и было связано с выделением разработки информационных продуктов в отдельную сферу деятельности.
После того как информационные технологии вышли за рамки лабораторных и научных исследований, началось их применение для автоматизации различных направлений деятельности. Накапливался опыт создания информационных систем, востребованных пользователями. Постепенно это привело к оформлению инженерии требований в отдельную дисциплину. Чем больше участников процессов разработки продуктов становятся зрелыми, образованными и развитыми в области информационных технологий и способов их применения, тем сильнее возрастает ценность дисциплин по работе с требованиями.
Истоки инженерии требований отсылают нас к смежной дисциплине — системной инженерии. Основные вехи — формирование системного подхода к исследованию и созданию сложных и комплексных систем. В приложении к разработке информационных продуктов основная заслуга в популяризации работы с требованиями принадлежит Карлу Вигерсу и ряду других авторов, о которых мы поговорим далее.
Хотелось бы акцентировать внимание на том, что мы не будем рассматривать инженерию требований во всей полноте этого предмета (ISO 15288), а сосредоточимся на его прикладном использовании для создания информационных систем (ISO 24765). Инженерия требований может применяться (ISO 25010) для различных способов и видов процессов разработки цифровых продуктов (waterfall, agile). В каждом из них (ISO 26702) она может быть адаптирована под конкретные условия выполнения проекта или процесса.
В области формализации и продвижения инженерии требований сложно выделить кого-то одного. Развитие этого направления — общий труд коллективов, комитетов, групп авторов и активистов. Каждый из них на своем уровне вносит свою лепту. Заинтересованных сторон уже много — это и государственные органы, и частные компании, и межведомственные комитеты.
Создание стандартов в области инженерии требований трудно считать евангелизмом.
|
|
Евангелизм — продвижение идей и концепций[3]. |
Создание стандартов — сложная административная работа, которая собирает имеющиеся в отрасли знания, синхронизирует их между собой, анализирует статистику о том, какие из способов и подходов в работе дают наибольший эффект как в тактической перспективе, так и в стратегической работе, учитывает то, какие из них являются безопасными и помогают достигать прогнозируемого результата, и регламентирует их на уровне отрасли в целом. Стандартизация — это локомотив, который закрепляет успешные способы работы. Нам же интересны те личности, которые прокладывали путь перед этим локомотивом. Признанный инноватор, предложивший классификацию требований (рис. 25), основываясь на типичной структуре проектов разработки и внедрения информационных систем, —
Карл Вигерс.
 |
Карл Вигерс, американский инженер-программист, консультант и инструктор в области разработки программного обеспечения, управления и улучшения процессов. Известен как автор многих статей и нескольких книг, в основном посвященных требованиям к программному обеспечению |
Классификацию, приведенную на рис. 25, мы видели ранее, когда говорили об артефактах бизнес-анализа. Ценность этой классификации — в том, что в ней предложили вариант упорядочивания требований, руководствуясь их назначением для заказчика конкретного уровня представления системы. Заказчик, вовлеченный в работу над созданием системы, все более и более ясно должен представлять и, как следствие, понимать, что же конкретно он хочет получить (рис. 26). Задача инженера по требованиям — упорядочить понимание заказчика, структурировать его и держаться намеченных рамок автоматизации. Карл Вигерс дополнил свои концепции декомпозиции требований данными из SWEBOK. В частности, он предложил деление требований на две категории — функциональные и нефункциональные.
|
|
Функциональные требования определяют действия, которые система должна быть способна выполнить, а также связь входа/выхода в поведении системы [4]. |
Группа функциональных требований — это требования, которые описывают поведение системы, ее функции. Функциональные требования отвечают на главный вопрос: что система должна делать?
Рис.25
Вторая категория требований — нефункциональные.
|
 |
Нефункциональные требования — требования, определяющие свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы, — например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации[5]. |
Нефункциональные требования отвечают на вопросы о том, как должна работать система, с какими характеристиками и показателями. Нефункциональные требования еще принято называть атрибутами качества. Их основная задача — регламентировать поведение системы в рамках обозначенных функциональных требований. К работе над нефункциональными требованиями можно приступать после того, как смежные им функциональные требования будут сформулированы, понятны и согласованы. Так шаг за шагом, руководствуясь классификацией Карла Вигерса, мы станем все более точно понимать, в каком виде первоначальная идея будет воплощена на практике (рис. 26).
Рис.26
Ценные идеи несут в себе рациональное зерно. Сделать так, чтобы это зерно проросло, и добиться созревания плодов — все это требует упорного труда. Инженерия требований не сможет помочь с формулированием и выработкой идей, но поможет взрастить зерно и получить богатый урожай. Назначение инженерии требований — последовательно доносить и подтверждать истинность трактовки идеи на каждом уровне ее рассмотрения.
Чтобы довести идею до воплощения, по ходу процесса взращивания нужно использовать специализированный инструментарий — он помогает придать идее нужную форму и добиться того, что эта форма будет удовлетворять необходимым требованиям. Инструментарий инженерии требований должен поддерживать принятую структуру процесса управления и разработки требований, и при его выборе, внедрении или разработке отталкиваются от принятого процесса разработки цифровых продуктов. Цель — создать продукт по заданным критериям:
Каждое из условий влияет на инженерию требований, а она сама, в свою очередь, также влияет на каждое из этих условий. Это влияние может быть не только прямым, но и косвенным, через определенный параметр. Так, повышая качество продукта, мы будем автоматически понижать скорость разработки. Это органический процесс, в котором все параметры связаны в единую структуру, определяемую целями процесса и доступными ресурсами. Под ресурсами, применяемыми для инженерии требований, понимаются:
Наличие ресурсов — фактор, который может оптимизировать (по скорости и качеству) инженерию требований, но сделать это можно лишь до определенного порогового значения. Оно определяется выполняемой задачей, уровнем квалификации персонала и методологией (подходом) к созданию продукта. Все эти факторы влияют на то, как будет осуществляться инженерия требований. Основные структурные элементы инженерии требований складываются в общеструктурное законченное представление (рис. 27). Инженерия требований представляет собой процесс, который начинается в момент извлечения первоначальных идей, продолжается (трассируется) на протяжении всего производственного процесса и заканчивается вместе с реализацией продукта. Это функциональный процесс, выполнение которого зависит от типа методологии, по которой разрабатывается продукт. Если это традиционный подход к производству товаров и услуг (waterfall), то у него есть свое место в общей структуре процесса, если же это гибкий подход (agile), то он осуществляется параллельно со всеми другими процессами. Инженерия требований состоит из:
Это именно те структурные элементы, которые позволяют реализовать первоначальную идею. Каждая из описанных составляющих имеет границы и функции, которые реализуются по ходу выполнения инженерии требований.
В реальных проектах инженерия требований как самодостаточная область проектной деятельности часто игнорируется.
Рис.27
Отдельные части инженерии требований выполняются в ходе предпроектного обследования, формирования требований и разработки. Особое внимание следует уделить трассировке требований и извлечению требований, так как их минимизация или игнорирование будут приводить к возникновению наиболее сложных и значительных рисков.
Если сравнить количество литературы об анализе, разработке, управлении и инженерии требований в области информационных продуктов и услуг, то лидером будет сфера разработки. Немногим меньше литературы посвящено управлению, еще меньше — анализу и проектированию и совсем немного — инженерии требований. Это подчеркивает, что увеличение эффективности и результативности создаваемых и внедряемых информационных продуктов лежит в области наименее изученных дисциплин, развитие которых позволит увеличить качество создаваемых продуктов.
Понимание инженерии требований приходит от умения выделить, представить границы и взаимосвязи ее аспектов (рис. 28). Каждый аспект (структурный элемент) можно охарактеризовать ключевым вопросом, который поможет сконцентрировать внимание на сути выполняемой деятельности:
o Входят ли эти требования в границы нашего проекта?
o Сколько эти требования позволят нам потратить/сэкономить?
o На какой стадии находятся эти требования?
o Какая работа над ними производится?
o Все ли ключевые участники высказали свои пожелания к требованиям?
o Выделены ли необходимые для проработки вопросы?
o Позволяет ли уровень декомпозиции первоначальных требований начать работу над их реализацией?
Сформированы ли критерии, по которым можно судить о полноте реализации конкретного требования?
Рис.28
Структурное представление помогает сконцентрировать внимание на дисциплинах, которые в совокупности характеризуют рассматриваемую область. Выполнение каждой дисциплины по ходу процесса управления требованиями может осуществляться несколько раз. Линейную схему процесса представить сложно, так как по ходу работы с требованиями может возникнуть необходимость нескольких переходов между соседними этапами. Для использования инженерии требований необходимо соблюдать общую структуру работ и следовать ей (рис. 29). Составные инженерии требований можно разделить на два типа процессов:
o Разработка требований
o Извлечение требований
o Управление требованиями
o Трассировка требований
Процессы из группы основных отвечают за формирование требований, которые будут использоваться в процессе разработки, а обеспечивающие процессы организуют работу над основными процессами и обеспечивают их своевременное выполнение.
Рис.29
Все этапы инженерии требований, в совокупности и сами по себе, выполняют определенные функции в процессе создания продукта (рис. 30).
Рис.30
Каждый этап инженерии требований помогает в достижении конечной цели — создании понятных, ясных, эффективных требований, которые являются основанием для разработки продукта, соответствующего заложенным в него требованиям. Функции, которые выполняются стадиями инженерии требований, поддерживают общую цель и вносят дополнительный вклад благодаря специфике своих процессов. Стоит отметить, что функции основных процессов сконцентрированы именно на понятии требования, а обеспечивающие процессы направлены на организацию работ вокруг требований. Важно запомнить, что основные и обеспечивающие процессы необходимо выполнять в совокупности. Тут нет второстепенных процессов, которые можно было бы проигнорировать. Игнорирование отдельных аспектов приведет к тому, что инженерия требований не достигнет поставленных целей.
В области инженерии требований нет сформированного понимания о том, каков необходимый и полный список артефактов для эффективного применения в процессах разработки цифрового продукта. Каждый тип требований, рассмотренный нами, нашел свое отражение в конкретном документе, востребованность которого определяется структурой и назначением разрабатываемого информационного продукта. Каждая создаваемая группа требований имеет цель, назначение и свою аудиторию. Если целевая аудитория имеет определенные специфические запросы, связанные со структурой документа, в котором отражаются результаты проведенного типа анализа, то их необходимо рассмотреть на предмет изменения принятой структуры документа.
За образец основного содержания документа рекомендуется взять общепринятую структуру в соответствии с определенным стандартом деятельности цифрового продукта. Одним из документов в области разработки требований к программному обеспечению, который можно взять за основу, является стандарт IEE830, задающий контекст использования требований и предлагающий эффективную структуру. Основное внимание IEE830 уделяет функциональным требованиям, но этот стандарт можно использовать и для определения других видов требований.
Кроме использования текстовых артефактов для инженерии требований могут быть использованы диаграммы — модели, которые визуализируют отдельные аспекты требований в целях повышения их ценности для использования в заданном контексте. Об этих артефактах мы поговорим далее, когда будем рассматривать:
Каждый тип требований направлен на удовлетворение нужд определенной целевой аудитории и должен создаваться с учетом специфики восприятия информации заданной группой и их функциональными ролями. Очень важно не просто следовать определенному принятому стандарту разработки требований, а изучить основные и специфические запросы пользователей к разрабатываемому продукту и создавать документы, которые будут наиболее эффективным образом удовлетворять и воплощать их потребности. Эффективные способы представления информации:
Рис.31
На рис. 31 представлены основные аспекты, на которые должен быть ориентирован и которые должен раскрывать тот или иной создаваемый документ. Представленная классификация не является исчерпывающей, но основные типы требований, необходимые для создания информационного продукта, она отражает. Каждый документ сам по себе должен быть достаточен в плане полноты описываемого контекста. По ходу проработки и детализации требований каждая следующая группа требований должна акцентировать внимание на принимаемых решениях, которые проясняют бизнес- и технический контекст использования и развития создаваемого продукта, и обосновывать их. Предположение о том, что по ходу проработки требований мы все больше и больше будем узнавать о создаваемой системе, является ошибочным. Каждый тип требований придерживается рамок, которые были заданы целью разработки. По ходу проработки требований домысливаются, извлекаются и формализуются первоначально заданные границы автоматизации, но они должны оставаться в тех рамках, которые были согласованы на старте обсуждения между стейкхолдерами и рабочей группой. Это залог успеха инженерии требований как области деятельности. Именно необходимость держаться в рамках заданных границ автоматизации привела к созданию поддерживающей дисциплины — трассировки требований.
|
 |
Трассировка требований — это взаимосвязь между двумя требованиями, которая предполагает взаимосвязь происхождения, порождения или зависимости между артефактами[6]. |
Трассировка требований устанавливает связь между различными типами создаваемых требований и показывает их зависимость друг от друга. Часто трассировка требований игнорируется из-за сложности организации и проведения данного типа деятельности. Ценность трассировки заключается в том, что именно этот тип деятельности позволяет сосредоточиться на основных и наиболее востребованных частях цифрового продукта, полнота реализации которых составляет ядро успеха его разработки. Эти части, выраженные в конкретных требованиях разного уровня, а впоследствии — в виде кода программного обеспечения, позволяют принимать решения о полноте реализации задуманного и, как следствие, о достижении той ценности, которая была зафиксирована в бизнес-требованиях или более высокоуровневых документах.
Цель создания и развития артефактов инженерии требований заключается в том, что по ходу процесса разработки нового продукта мы, как команда, вовлеченная в процесс создания определенной бизнес-ценности, должны концентрироваться на том, что принесет нашему заказчику наибольшую пользу. Польза, для ее последующей декомпозиции, должна быть выражена в виде каких-то параметров, которые будут учитываться как целевые параметры, по которым выполняется разбиение (анализ) и последующий сбор (синтез) программного продукта в инструмент, используемый для того, чтобы реализовать потребности и ожидания пользователей. Основными параметрами пользы являются:
Эти целевые параметры адаптируются для конкретного продукта в виде конкретного показателя деятельности:
Это отправная точка в процессе создания требований. Параметры, которые являются ключевыми для разработки продукта, фиксируются и после этого параметризуются по определенной шкале. Есть много подходов к параметризации пользы, начиная от слабоформальных, основанных на мнениях и экспертных оценках (матрица Эйзенхауэра, методика MOSCOW) и заканчивая строгоформальными, в основе которых лежит какая-то шкала (технико-экономическое обоснование, NPS). Техника, используемая для выявления наиболее важных параметров, а как следствие, требований, выбирается в зависимости от имеющихся в наличии на проекте или в организации данных и предпочтений стейкхолдеров.
Зафиксированный параметр декомпозируется на набор более низкоуровневых (более конкретных) показателей, которые достигаются за счет реализации конкретного требования:
Так, шаг за шагом, мы более детально описываем решение проблемы нашего пользователя и в этом описании фиксируем те моменты, которые будут ключевыми для развития нашего продукта.
Список артефактов и их подробность должны быть обоснованы структурой процесса разработки и принятым подходом к реализации продуктов. Артефакты инженерии требований должны утверждаться, основываясь на:
Если в инженерии требований попытаться выделить документ, который запускает процесс осознанного отношения к требованиям как важной части процесса разработки эффективных информационных продуктов, то это будут бизнес-требования. Они задают контекст создания и использования каждой системы или ее части. Без бизнес-требований, в которых обязательно должны быть собраны и формализованы назначение создаваемой системы, планируемая ценность и границы автоматизации, разработка информационных продуктов станет напоминать блуждание с завязанными глазами в комнате с выключенным светом ночью. Команда разработки будет постоянно что-то делать без понимания цели того, что она делает. Но бывают ситуации и условия, в которых бизнес-требования отходят на второй план и уступают свое первенство пользовательским требованиям. Это обосновано только в тех случаях, когда команда разработки берет на себя обязанность сопровождать и доносить контекст автоматизации от начала и до конца процесса разработки. Как правило, это весьма эпизодические и непродолжительные проекты по развитию информационных продуктов и систем. Таким положением дел не стоит злоупотреблять с точки зрения ее повсеместного применения в процессах создания информационных продуктов. Функциональные требования как документ обоснованы и необходимы тогда, когда вам с самого начала необходимо регламентировать рамки и подход к разработке модулей информационной системы; когда вы не можете влиять на состав, уровень квалификации и лояльность команды разработки и встраиваете свой информационный продукт в строгие стандартизированные рамки бизнес-функций. C атрибутами качества (нефункциональными требованиями) дело обстоит немного сложнее. Атрибуты качества задают параметры функционирования системы, которые сами по себе в процессе пользовательской работы неинтересны до того момента, пока они не начинают влиять на комфортный, привычный, целевой бизнес-процесс. Формулировка и разработка нефункциональных требований — процесс, связанный с разработкой функциональных требований, но в своей основе он оперирует не тем, что пользователи будут делать в информационной системе, а тем, как должны быть выстроены информационные потоки, чтобы поддерживать и обеспечивать такие параметры функционирования системы, как:
На практике необходимым минимумом для запуска процессов разработки являются задачи, описанные в коротком и понятном виде (пользовательские требования), оформленные в виде задач на разработку и трассируемые к бизнес-требованию, которое в целом описывает границы того, что мы автоматизируем и какую ценность этим можно принести.
Инженерия требований — прикладная область деятельности, которую использует в работе каждый аналитик. Проводя свою работу, он выбирает и обосновывает требования, необходимые для конкретного процесса или проекта, и работает с ними. Инженерия требований не существует сама по себе, как отдельный этап процессов разработки программ, — она применяется в процессах разработки продуктов и услуг, но как именно она будет использоваться, определяется условиями и ситуацией, в которых разрабатывается цифровой продукт. Такая междисциплинарность приводит к тому, что само по себе рассмотрение инженерии требований как отдельной сферы деятельности лишено смысла.
|
|
Междисциплинарность — это когда исследования подразумевают объединение двух или более академических дисциплин в одно мероприятие. [7] |
Инженерия требований — важный навык, которым должен обладать каждый специалист, выполняющий аналитические виды работ. Такая ситуация предоставляет инженеру по требованиям богатую почву для выбора направлений развития. Он постоянно находится в контексте выполнения аналитических работ и может выбрать более привлекательные для себя направления развития (бизнес-анализ, системный анализ, анализ данных).
Кроме этого, инженер по требованиям при работе с ними выступает в разных ролях:
Чтобы эффективно выполнять каждую из вышеизложенных стадий, специалисту желательно изучить суть каждой роли и разбираться не только в тех активностях, выполнение которых предполагает конкретная рабочая ситуация, но и в базовых аспектах, из которых складывается суть каждой профессиональной личности.
Проведем калибровку и самопроверку по инженерии требований (рис. 31.1).
Рис.31.1
[1] http://www.cs.vsu.ru/~svv/se/lec5.pdf
[2]https://kartaslov.ru/%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%BB%D0%BE%D0%B2%D0%B0/%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F
[3] https://www.itweek.ru/ecm/blog/ecm/3588.php?commentId=18068
[4] https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B9
[5]https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B9
[6] https://www.ibm.com/docs/ru/rsm/7.5.0?topic=requirements-lesson-23-view-traceabilty
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.