Слово «demand» переводится с английского языка на русский язык [N] как: а) требование, т.е.: — выраженная в решительной, категорической форме просьба, распоряжение; — правило, условие, обязательное для выполнения; — внутренние потребности, запросы; — официальный документ с просьбой о выдаче чего-нибудь, направления кого/чего-нибудь куда-нибудь; б) спрос, т.е.: — требования к тому, кто должен нести ответственность, отвечать за что-нибудь; — требование на товары со стороны покупателя [N]. Анализ приведённых выше определений позволяет сделать следующие выводы: 1) слово «требование» является ключевым, поскольку именно оно создаёт предпосылки для последующего определения понятия «спрос», поэтому в дальнейшем это слово будет использовано для раскрытия сущности и содержания бизнес-процесса «demand management» в первую очередь как «управление требованиями», а не как «управление спросом»; 2) источником требования как такового является конкретный потребитель продукции и услуг, роль которого на рынке претерпевает некоторые изменения.
Современный бизнес-анализ и управление требованиями
Например, при реализации предприятием концепции производственного менеджмента (таблица 1.5) к данному предприятию также поступает «просьба» от потребителя, но не в столь решительной и категоричной форме. Это связано с тем, что на рынке в данный момент времени доминирует и навязывает свои возможности потребителю поставщик.
В этом случае следует рассматривать следующую последовательность преобразования некоей нужды потребителя в конкретный продукт и/или услугу (рисунок 5.1). Если на рынке начинает доминировать потребитель, то следует принимать во внимание иную последовательность, представленную на рисунке 5.2; Рисунок 5.1 — Последовательность преобразования нужды потребителя в конкретный продукт и/или услугу при реализации предприятием концепции производственного менеджмента Рисунок 5.2 — Последовательность преобразования нужды потребителя в конкретный продукт и/или услугу при реализации предприятием концепции управления цепями ценности 3) требование потребителя в ряде случаев следует рассматривать как реальное отражение имеющихся у него потребностей или запросов, не всегда совпадающих с ценностями данного потребителя.
Данный аспект предполагает ситуацию, при которой реальный заказ потребителя будет несколько отличаться от его первоначального требования; 4) возможна ситуация, когда требование потребителя не может быть выполнено поставщиком по причинам ажиотажного спроса, несоответствия требования законодательным нормам или нормам морали, отсутствием необходимых ресурсов и др.; этот аспект управления требованиям целесообразно реализовывать в рамках программ демаркетинга силами маркетинговых служб звеньев цепей ценности; 5) требование может выступать в форме официального документа, предусматривающего как безусловное выполнение данного требования предприятием, которому оно направлено, так и предложение к сотрудничеству с данным предприятием; 6) требование может выставлять любое звено цепи ценности, которое является потребителем неких продуктов и/или услуг рассматриваемого предприятия, в связи с чем целесообразно вести речь о цепях требований. Основными особенностями данного объекта управления являются: — управление, в первую очередь, информационными потоками (иногда можно говорить об использовании неких макетов и образцов продукции, которые можно рассматривать как материальные потоки, но не столь значимые как реальные потоки необходимых потребителю продуктов и/или услуг); — возможное наличие звеньев, генерирующих, передающих и поглощающих информационные потоки, но по тем или иным причинам, не участвующих в последующем в создании ценности для конечного потребителя; — реальное участие в управлении требованиями субъектов управления звеньями цепей ценности. Если требование потребителя принято субъектом управления к реализации, то при использовании вытягивающих логистических концепций оформленный должным образом заказ (рисунок 5.2) может выполняться объектом управления без участия указанного выше субъекта управления звеном цепи ценности; — необходимость структуризации заказа на несколько заказов (причём заказ на один и тот же вид продуктов может быть направлен нескольким поставщикам одновременно уже в процессе их изготовления), в связи с чем целесообразно рассматривать цепи требований как единую сеть, действия звеньев которой должны быть согласованы в пространстве и во времени; 7) требования могут представлять собой потоки в различных их формах и сочетаниях с другими видами логистических потоков, т.е. их преобразование и передача могут осуществляться на принципах логистики как концепции управления предприятиями; 8) управление требованиями находится в поле зрения всех подсистем предприятия, в частности, тех, которые представлены на рисунке 1.39; исходя из этого, можно утверждать, что данный бизнес-процесс выходит за рамки управления цепями ценности и поставок (рисунок 1.23). Требования могут предъявляться к следующим объектам: 1) к системам: — к компонентам концепций управления предприятиями (рисунок 1.16); — к основным подсистемам предприятия и/или цепей поставок (рисунок 1.39); — к основным подсистемам логистической производственной системы (таблица 3.3); 2) к процессам: — к основным бизнес-процессам и процессам управления в цепях поставок (рисунок 1.24); — к основным видам деятельности предприятия, которые основаны на логистическом менеджменте (рисунок 1.29); — к функциям и операциям, выполняемым подсистемой логистического менеджмента (рисунок 1.42). Исходя из этого, можно сделать вывод о том, что требование представляет собой специфический объект управления, по своей значимости не уступающий траектории (как объекту управления цепями ценности) и цепи поставок (как объекту управления цепями поставок) и реализуемый в рамках логистики как концепции управления предприятиями, основу которой, как было показано ранее, составляет управление потоками ресурсов.
Управление требованиями к информационным системам
Источник: studfile.net
Управление требованиями
Что такое управление требованиями, как оно устроено, и почему приходится им заниматься? Уже давно стало ясно, что для преуспевания компании недостаточно просто иметь товар и продавать его. Продукт должен быть востребованным и удобным для потребителя. А позже появилось понимание, что продукт требует каких-то сервисов, что необходим переход к сервисной модели.
Более того, потребитель хочет не владеть товаром, а пользоваться им. Отсюда — арендные или подписочные модели.
Что же дальше? А дальше нас ждет «экономика впечатлений»: потребитель будет покупать не товар и даже не сервис, а некое «послевкусие» после его пользования. И об этом надо позаботиться, это важно уже сейчас. Поэтому требования относятся и к товарам, и к сервису, и к тем впечатлениям, которые мы хотим сформировать от этих товаров у потребителя.
Всем этим надо управлять. Как показывает статистика, в технологически сложных отраслях до 45% попыток вывода на рынок новых продуктов, новых изделий кончаются неудачей. Анализ причин этих неудач говорит о том, что на самом деле большинство из них были заложены еще в начале программы разработки изделия, на стадии формирования требований.
Что такое требования и в чем суть проблемы?
Для начала определимся с понятием требований. Требование – оправданный, утверждённый и документально изложенный критерий, которому должно быть обеспечено соответствие.
Требования могут исходить как из внешней среды (от заказчика, регулирующих органов и пр.), так и из внутренней среды организации (технологические ограничения, требования маркетологов и т.д.). Распространяются такие требования, прежде всего, на функции изделия, на используемые в нём материалы, на применяемые интерфейсы, протоколы и прочие свойства изделия. Кроме того, требования могут накладываться и на процессы разработки изделия, и на производственные процессы, и на последующую эксплуатацию изделия.
В чем же проблема с требованиями? Прежде всего, это неспособность понять требования заказчиков. Кроме того, количество требований к концу разработки может на порядки превышать их количество в исходном ТЗ. Т.е. на входе в разработку изделия просто невозможно определить сразу все требования к нему. Серьезное изделие масштаба самолета – это более миллиона требований.
В какой-то момент пришло осознание факта, что описать в виде требований инновационное изделие до начала его разработки просто невозможно, а все попытки ограничиться единожды составленным набором требований сводят «на нет» те самые инновационные свойства изделия. И, начиная, прежде всего, с разработки программного обеспечения, а сегодня всё шире и шире стали применяться принципы «аджайл» (Agile). Такие принципы принимают факт ущербности начальных требований и необходимости работы с ними на всем цикле разработки.
При ближайшем рассмотрении оказывается, что проблемы, связанные с ошибками разработки или производства, как правило, весьма несущественны по сравнению с тем, что заложено в требованиях. Прежде всего, это неполнота требований по составу и проработке. Не менее важно и то, в каком виде требования представляются заинтересованным лицам, которые, собственно говоря, и должны воплотить такие требования в разрабатываемом изделии. Да и заказчик далеко не всегда знает, что он «хочет», не всегда готов выразить свои требования в пригодном для дальнейшего использования виде.
В результате требования могут совершенно не совпадать с ожиданиями, а участвующие стороны часто понимают их по-своему. В довершение всего, как мы уже знаем, требования будут по ходу разработки изделия меняться и дополняться. Если этим не заниматься системно, то есть не управлять требованиями, то и результат будет соответствующим.
Многообразие требований (физические, логические, функциональные и пр.) ведет к необходимости скрупулёзного администрирования и управления. Исследователи области управления требованиями сходятся в одном – две трети ошибок, нестыковок и переделок связано либо с неполнотой требований, либо с ненадлежащим их представлением.
Соответственно, необходимо с самых ранних стадий до конца жизненного цикла изделия выявлять и анализировать требования, управлять изменениями, привязывать требования к элементам конструкции, процессам, отдельным заданиям и работам в составе проекта разработки и программы испытаний, составлять отчётные формы. Причём, чем дальше мы будем продвигаться по стадиям жизненного цикла, тем больше требований будет выявлено, потребует анализа и администрирования.
Иерархия требований
Существуют требования к материалам, интерфейсам и ко всему, из чего состоит изделие. Есть ещё требования к процессам производства, проектирования и пр. Они будут иметь десятки противоречий, разный «вес» и приоритеты. Так что картина получается довольно сложной. В процессе разработки количество и сложность требований увеличивается в разы. Причём надо следить за их изменениями.
А потом нужно ещё доказать, что все требования реализованы — встает вопрос об испытаниях.
Как правило, сначала рассматривают требования ко всему изделию, потом – к отдельным его подсистемам и элементам. Когда требования уже достаточно проработаны, приступают к разработке изделия в целом и отдельных его элементов. И чем дальше вырисовывается поэлементная структура изделия, тем глубже должна быть декомпозиция требований: от уровня целого изделия до уровня требований к отдельным элементам. Нижележащие требования должны соответствовать и не противоречить вышестоящим – сопоставление и проверка требований на такое соответствие называется «валидацией» требований.
Для организации процессов разработки сложных изделий Независимая Ассоциация системных инженеров рекомендует использование метода RFLP (Requirements — Functional — Logical – Physical). В таком методе, опираясь на управление требованиями, в первую очередь определяют функциональный состав изделия, т.е. какие функции должно выполнять разрабатываемое изделие.
Следующим шагом продумывают реализацию таких функций элементами, узлами и системами в составе конструктива изделия, тем самым, определяют логическую архитектуру разрабатываемого изделия. Лишь с полным пониманием функционального состава и логики конструктива изделия переходят к проектированию отдельных элементов, систем и составлению цифрового макета изделия.
Имитационное моделирование
Чтобы понимать, каким будет поведение системы в реальной среде, какие необходимые изменения нужно внести до перехода к дорогостоящим натурным испытаниям и изготовления для них дорогостоящих натурным прототипам, уже достаточно широко используется имитационное моделирование. Имитационное моделирование сегодня позволяет не просто «посмотреть» на виртуальный прототип системы, но и выполнить необходимый цикл испытаний и выявить несоответствия требованиям ещё в виртуальной среде, пока изменения, необходимые для достижения соответствия требованиям, носят «цифровой» характер, а значит, обходятся разработчикам системы на порядки дешевле. Связанным продуктом имитационного моделирования является возможность анализа отказоустойчивости и безопасности системы.
Часто под управлением требованиями понимают составление спецификации требований. Не умаляя значимости этого процесса на протяжении всего цикла разработки, следует отметить, что согласно статистике, рассмотренной выше, не менее важным оказывается представление требований. Объём требований, с которым приходится иметь дело разработчикам, не оставляет шанса традиционным методам. Лучше всего в современных условиях зарекомендовала себя практика привязки требований к тем элементам изделия или системы, к которым они относятся. Таким образом, на всём цикле разработки и испытаний заинтересованные лица могут не перерабатывать весь состав требований, а работать лишь с относящейся к их участку выборкой.
Неотъемлемой частью требований ещё на стадии определения должны становиться методы определения соответствия, т.е. методики испытаний, по которым будет подтверждаться соответствие требованию. Последнее время процесс подтверждения соответствия требованиям всё чаще стали называть верификацией требований. По результатам испытаний подтверждают соответствие требованиям или инициируют внесение изменений в изделие. Понятие «валидация» изделия, в свою очередь, появилось, исходя из возможного несовершенства самих требований или методов их верификации. Другими словами, валидация изделия носит более высокоуровневый характер и направлена на исключение ситуаций, когда на испытаниях подтверждено соответствие всем требованиям, но пользоваться изделием невозможно.
В результате, состав требований вкупе с методиками определения соответствия определяет программу испытаний. В современных условиях программа испытаний следует всем изменениям в составе требований и может меняться по ходу разработки. В такой программе важно не только сбалансировать необходимые доли натурных и виртуальных испытаний, но и «комплексировать» испытания, т.е. сгруппировать необходимые тесты и замеры таким образом, чтобы их можно было проводить за одну установку на стенд, на одном прототипе, за один вылет/выезд/запуск… Подобная проработка программы испытаний позволяет вдвое сократить количество испытаний и необходимых прототипов, значительно уменьшить сроки реализации программы испытаний. Однако, в условиях огромного числа требований и постоянных изменений в их составе управлять программой испытаний без применения современных цифровых инструментов становится невозможно.
Для чего нужны инструменты работы с требованиями?
Перед компаниями, разрабатывающими технически сложные изделия, стоит непростая задача. Изделия стали настолько сложными, что «на входе» проработать все требования к многокомпонентному изделию невозможно.
Компании же подчас работают по старинке, начинают проект с ТЗ, где просто перечисляются основные технические характеристики изделия, а уже по ходу разработки, руководствуясь этим техническим заданием, какими-то нормами и правилами, собственными представлениями, ищут инженерное решение, отвечающее техническому заданию. Такое решение будет гораздо более сложным, чем можно было бы описать на входе. Кроме того в процессе поиска этих решений возникает множество других вопросов, которые также выражаются в требованиях — к производственным процессам, к материалам, к самому изделию, его функциям. Удерживать всё это в голове невозможно.
Между тем в современном мире нужно быстро разрабатывать изделия и быстро выводить их на рынок. В противном случае к моменту выпуска техническое задание может устареть и станет неактуальным. Поэтому процессом необходимо управлять с самого начала. Иначе неудачи закладываются на старте разработки новых изделий.
Ненадлежащее управление требованиями — причина большинства ошибок, переделок, несоответствий, которые приводят к необходимости выпускать новые прототипы. При этом увеличиваются издержки, приходится тратить время и деньги на новые циклы разработки и испытаний. В результате откладывается выпуск изделия.
Кроме того, необходимо обеспечить сквозные процессы разработки изделия в многодисциплинарной среде, позволив специалистам из разных областей слаженно действовать в поисках инженерных решений.
Растущая сложность изделий приводит к тому, что сегодня традиционная роль главных/генеральных конструкторов как «отцов» изделия уходит в прошлое. Человеку не под силу держать в голове всю картину изделия, обеспечить его целостность.
Как уже отмечалось, требования могут быть внутренними и внешними, касаться не только самого изделия, но и материалов, из которых оно изготавливается, процесса его изготовления. Отдельно взятому человеку очень трудно разобраться во всём этом разнообразии. Требования наследуются в ходе разработки, они могут быть связаны друг с другом. Каждое требование необходимо выявить, сопоставить с другими и так далее. Нужны автоматизированные системы, которые помогают работать над таким сложным проектом.
Платформа 3DEXPERIENCE и другие средства
Платформа 3DEXPERIENCE позволяет совместно работать с требованиями и включает в себя инструменты их формализации, привязки требований к элементам состава изделия, состава проекта разработки и испытательных работ. Всё это дает возможность не просто вести учёт требований, а с целью принятия осознанных решений анализировать требования по затратам и результатам от их реализации.
Решение CATIA Magic позволяет выявить и проанализировать потребности заинтересованных сторон, участвующих в производстве, вводе в эксплуатацию, в самой эксплуатации изделия, и выводе из нее. Все это обеспечивает полноту и правильное представление требований с самого начала жизненного цикла изделия, а именно недостаточная полнота и представление требований, как мы уже знаем, являются источником 2/3 ошибок в проектировании изделия.
Решение Stimulus ещё на ранних стадиях разработки еще на уровне определения требований моделирует поведение системы и анализирует взаимозависимость и реализуемость требований. Однако для такого моделирования необходимо должным образом сформулировать требования.
Самый современный подход к разработке сложных изделий — это основанный на моделировании моделей системный инжиниринг (MBSE, Model-based System Engineering). Требования – один из «трех китов», на которых базируется MBSЕ, без реализации которого невозможен системный инжиниринг.
Платформа 3DEXPERIENCE обеспечивает прозрачность требований в связке с методиками определения соответствия, прозрачность хода испытаний и их результатов. Система построена на рекомендуемом в системном инжиниринге подходе RFLP, что дает возможность на ранних стадиях провести имитационное моделирование и расчёты, выполнить анализ систем и внести необходимые изменения ещё в цифровой среде. А цифровые изменения, как известно, на порядок-другой дешевле натурных.
Функционал платформы 3DEXPERIENCE выходит далеко за рамки учёта требований, а именно:
- Составление спецификаций требований с ранжированием;
- Составление программы испытаний;
- Планирование и управление ходом работ по программе испытаний;
- Управление результатами испытаний с корреляцией результатов виртуальных и натурных испытаний;
- Наглядное отслеживание хода выполнения программы испытаний и результатов определения соответствия требованиям.
Следует отметить, что платформа 3DEXPERIENCE одинаково хорошо справляется с управлением и виртуальными, и натурными испытаниями. Именно комплексный подход позволяет оптимизировать расходы и сроки реализации программы испытаний. В конечном счете, это позволяет убедиться, что изделие соответствует выявленным требованиям. При этом спецификаций требований бывает очень много – техническое задание, сертификационные требования, выявленные требования заинтересованных лиц, требования к поставляемым системам и подсистемам… и они между собой должны быть связаны и непротиворечивы.
Инструменты Dassault Systemes позволяют в условиях междисциплинарной разработки и широкой производственной кооперации обеспечить слаженное взаимодействие и сквозные процессы разработки изделия на основе требований. При этом управление требованиями строится на уровне жизненного цикла каждого отдельного требования, на уровне методик подтверждения соответствия, на уровне отдельных параметров в требованиях, что позволяет проводить моделирование и инженерный анализ.
Таким образом, платформа 3DEXPERIENCE комплексно управляет процессами жизненного цикла требований — от их выявления до верификации и валидации — и позволяет большим коллективам слаженно работать над моделированием, испытаниями и выводом в серию технически сложных инновационных изделий.
Подписывайтесь на новости Dassault Systèmes и всегда будьте в курсе инноваций и современных технологий.
- dassault systemes
- 3dexpirience
- mbse
- catia
- cad
- cad/cam
- cad/cam/cae/plm
- управление проектами
- управление требованиями
- 3d проектирование
- инженерные системы
- инженерные расчеты
- инженерные решения
Источник: habr.com
Управление требованиями: процессы и стадии жизненного цикла требования к ПО
Что представляет собой жизненный цикл требования, каковы его стадии и процессы, а также какие стейкхолдеры, помимо самого аналитика, принимают в них участие. Разбираемся, что должно быть в системе управления требованиями, чтобы ими можно было управлять.
Зачем нужна система управления требованиями: краткий ликбез по СУТ
Помимо разработки требований и их спецификации в виде ТЗ аналитик постоянно решает задачи управления этими пригодными для практического использования представлениями решения. Какие задачи относятся к области знаний «Управление жизненным циклом требований» в BABOK®Guide, я рассказывала здесь.
Система управления требованиями (СУТ) нужна, чтобы хранить следующую информацию:
- все виды требований (бизнес-требования, требования стейкхолдеров, а также требования к решению функциональные и нефункциональные) во всех формах их представления (Use Case, User Story, Каноническая форма);
- трассировки требований разного уровня между собой, а также их связи с бизнес-правилами, тест-кейсами, компонентами системы и задачами на реализацию в таск-трекере;
- метаданные требований, т.е. их атрибуты, включая версии и состояния жизненного цикла.
Обеспечивая управление версиями и изменениями требований, СУТ также выполняет роль общего проектного пространства, поддерживая функции навигации и поиска по набору требований (сортировки и фильтры), разные уровни доступа к данным для командной работы и связи со всеми стейкхолдерами. В настоящее время большинство компаний в качестве СУТ используют комбинацию продуктов корпорации Atlassian: Jira как таск-трекер, где отслеживается прогресса выполнения работы, т.е задачи по реализации требований, и wiki-подобная система Confluence как средство хранения требований. Однако, Confluence сам по себе не является системой управления требованиями. Поэтому, чтобы он выполнял функции СУТ, например, построение матрицы трассировок и отслеживание атрибутов, нужны специализированные плагины. К таким плагинам относятся Requirements Yogi, Mocky, Moqups.
В качестве более легковесной (и более дешевой) альтернативы Confluence можно использовать Notion – веб-сервис для создания заметок и текстовых документов, списков задач и структурирования знаний. Благодаря модульной структуре Notion, его можно настроить для хранения требований и другой информации по ИТ-проекту, включая календарный план и задачи для участников.
Этот вполне рабочий вариант отлично подходит для небольших и средних проектов. Однако, при использовании бесплатного аккаунта Notion есть ограничения на размер проектного пространства: не более 5 пользователей, а также лимитированы объемы загружаемых в сервис файлов. Кроме того, как и в любом облачном решении, есть риск утечки конфиденциальной информации. Поэтому для хранения чувствительных данных, особенно за пределами локального контура предприятия, следует очень тщательно проработать вопросы информационной безопасности, чтобы снизить риски утечки и несанкционированного доступа.
Помимо общих wiki-подобных решений также существуют специализированные системы управления требованиями, изначально разработанные именно для этого. Например, 3SL Cradle, IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner, Borland Caliber RM, Devprom ALM и пр. Эти СУТ поддерживают все процессы жизненного цикла требований, включая их спецификацию благодаря встроенным инструментам моделирования бизнес-процессов и информационных систем или за счет интеграции с внешними редакторами. Кстати, с 1 марта 2023 года я стала партнером компании Devprom, которая разрабатывает и внедряет комплексную среду управления и реализации ИТ-проектов. Это значит, что теперь в курсах нашей Школы прикладного бизнес-анализа будет еще больше практических примеров использования современных инструментов для повышения эффективности аналитической работы.
Кроме графического и текстового описания требования, СУТ также хранят метаданные о нем, т.е. его характеристики или атрибуты. Наиболее важными атрибутами требования, которые описывают его, считаются следующие:
- дата создания;
- номер текущей версии;
- автор (создатель требования в СУТ);
- приоритет, который показывает его относительную важность для стейкхолдеров;
- статус, т.е. состояние жизненного цикла;
- происхождение или источник;
- логическое обоснование;
- контактное лицо, ответственное за принятие решений по одобрению и внесению изменений;
- номер выпуска или итерации, на которую назначена реализация;
- метод проверки или критерий приемки.
Идеальным состоянием любого требования в любой системе считается, когда оно согласованно между заказчиком и исполнителем, имеет согласованную стратегию проверки и удовлетворяется требованиями более низкого уровня или спецификацией системы. Чтобы разобраться с жизненным циклом (ЖЦ) требования, далее рассмотрим его возможные состояния и процессы, которые обеспечивают переходы между ними.
Источник: babok-school.ru