Управление требованиями

Управление требованиями — это процесс документирования, анализа , отслеживания , приоритизации и согласования требований, а затем контроля изменений и информирования соответствующих заинтересованных сторон. Это непрерывный процесс на протяжении всего проекта. Требование — это возможность, которой должен соответствовать результат проекта (продукт или услуга).

Обзор

Целью управления требованиями является обеспечение того, чтобы организация документировала, проверяла и удовлетворяла потребности и ожидания своих клиентов и внутренних или внешних заинтересованных сторон. ^[1] Управление требованиями начинается с анализа и выявления целей и ограничений организации. Управление требованиями далее включает в себя поддержку планирования требований, интеграцию требований и организацию работы с ними (атрибуты требований), а также отношения с другой информацией, поставляемой в соответствии с требованиями, и изменения для них.

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

Управление требованиями включает в себя коммуникацию между членами команды проекта и заинтересованными сторонами, а также корректировку изменений требований в ходе проекта. ^[3] Чтобы предотвратить переопределение одного класса требований другим, постоянное общение между членами команды разработки имеет решающее значение. Например, при разработке программного обеспечения для внутренних приложений у бизнеса настолько сильные потребности, что он может игнорировать требования пользователей или полагать, что при создании вариантов использования требования пользователей учитываются.

Прослеживаемость

Прослеживаемость требований связана с документированием жизненного цикла требования. ^[4] Должна быть возможность проследить происхождение каждого требования, и поэтому каждое изменение, внесенное в требование, должно быть документировано для достижения прослеживаемости. ^[5] Даже использование требования после того, как реализованные функции были развернуты и использованы, должно быть прослеживаемым. ^[5]

Требования поступают из разных источников, например, от делового человека, заказывающего продукт, от менеджера по маркетингу и от фактического пользователя. Все эти люди предъявляют разные требования к продукту. Используя отслеживаемость требований, реализованную функцию можно отследить до человека или группы, которые хотели ее получить во время выявления требований . Это можно, например, использовать в процессе разработки для определения приоритетности требования ^[6], определяя, насколько ценно требование для конкретного пользователя. Это также можно использовать после развертывания, когда исследования пользователей показывают, что функция не используется, чтобы понять, почему она изначально требовалась.

Требования к деятельности

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

Расследование

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

В общем случае требования не могут быть полностью определены в начале проекта. Некоторые требования изменятся, либо потому, что они просто не были извлечены, либо потому, что внутренние или внешние силы влияют на проект в середине цикла.

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

В то время как многие организации по-прежнему используют только документы для управления требованиями, другие управляют своими базовыми линиями требований с помощью программных инструментов. Эти инструменты позволяют управлять требованиями в базе данных и обычно имеют функции для автоматизации прослеживаемости (например, позволяя создавать электронные ссылки между родительскими и дочерними требованиями или между тестовыми случаями и требованиями), создания электронных базовых линий, контроля версий и управления изменениями. Обычно такие инструменты содержат функцию экспорта, которая позволяет создавать документ спецификации путем экспорта данных требований в стандартное приложение для работы с документами. ^{[ необходима цитата ]}

Осуществимость

На этапе осуществимости определяются затраты на требования. Для требований пользователя текущая стоимость работы сравнивается с будущими прогнозируемыми затратами после внедрения новой системы. Задаются такие вопросы: «Сколько сейчас обходятся нам ошибки ввода данных?» или «Какова стоимость брака из-за ошибки оператора в текущем интерфейсе?» На самом деле потребность в новом инструменте часто осознается, поскольку эти вопросы попадают в поле зрения финансовых специалистов организации.

Расходы на бизнес будут включать в себя: «Какой отдел имеет бюджет на это?» «Какова ожидаемая норма прибыли от нового продукта на рынке?» «Какова внутренняя норма прибыли при снижении затрат на обучение и поддержку, если мы создадим новую, более простую в использовании систему?»

Технические расходы связаны с расходами на разработку программного обеспечения и расходами на оборудование. «Есть ли у нас нужные люди для создания инструмента?» «Нужно ли нам новое оборудование для поддержки расширенных ролей программного обеспечения?» Этот последний вопрос является важным типом. Команда должна выяснить, добавят ли новейшие автоматизированные инструменты достаточную вычислительную мощность, чтобы переложить часть нагрузки с пользователя на систему, чтобы сэкономить время людей.

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

Результатом этапа технико-экономического обоснования является бюджет и график проекта.

Дизайн

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

Опять же, гибкость имеет первостепенное значение для успеха. Вот классическая история изменения масштаба в середине потока, которая на самом деле сработала хорошо. Дизайнеры автомобилей Ford в начале 80-х ожидали, что цены на бензин достигнут 3,18 доллара за галлон к концу десятилетия. В середине проектирования Ford Taurus цены были сосредоточены на уровне около 1,50 доллара за галлон. Команда дизайнеров решила, что они могут построить более крупный, более комфортный и более мощный автомобиль, если цены на бензин останутся низкими, поэтому они перепроектировали автомобиль. Запуск Taurus установил общенациональные рекорды продаж, когда появился новый автомобиль, в первую очередь потому, что он был очень просторным и удобным в управлении.

Однако в большинстве случаев отход от первоначальных требований в такой степени не работает. Поэтому документ с требованиями становится критически важным инструментом, который помогает команде принимать решения об изменениях в дизайне. ^[7]

Строительство и испытания

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

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

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

Вряд ли какой-либо проект по разработке программного обеспечения будет завершен без того, чтобы в проект не были внесены некоторые изменения. Изменения могут быть вызваны изменениями в среде, в которой предполагается использовать готовый продукт, изменениями в бизнесе, изменениями в регулировании, ошибками в первоначальном определении требований, ограничениями в технологиях, изменениями в среде безопасности и т. д. Действия по управлению изменениями требований включают получение запросов на изменение от заинтересованных сторон, регистрацию полученных запросов на изменение, анализ и определение желательности и процесса внедрения, внедрение запроса на изменение, обеспечение качества внедрения и закрытие запроса на изменение. Затем данные запросов на изменение собираются, анализируются, и соответствующие метрики выводятся и увязываются с организационным хранилищем знаний. ^[8]

Выпускать

Управление требованиями не заканчивается выпуском продукта. С этого момента поступающие данные о приемлемости приложения собираются и передаются на этап исследования следующего поколения или выпуска. Таким образом, процесс начинается снова.

Инструменты

Приобретение инструмента для поддержки управления требованиями — нетривиальное дело, и его необходимо осуществлять как часть более широкой инициативы по улучшению процесса. Долгое время считалось, что инструмент, приобретенный и установленный в проекте, может удовлетворить все его потребности, связанные с управлением требованиями. Однако приобретение или разработка инструмента для поддержки управления требованиями может быть дорогостоящим решением. Организации могут быть обременены дорогостоящими контрактами на поддержку, несоразмерные усилия могут быть направлены не по назначению на обучение использованию инструмента и его настройку для решения конкретных потребностей, а ненадлежащее использование может привести к ошибочным решениям. Организации должны следовать пошаговому процессу для принятия решений об инструментах для поддержки своих конкретных потребностей в более широком контексте своего процесса разработки и инструментария. ^[9] Инструменты представлены в разделе «Прослеживаемость требований» .

Смотрите также

Ссылки

^ Стеллман, Эндрю; Грин, Дженнифер (2005). Управление прикладными программными проектами. O'Reilly Media. ISBN 978-0-596-00948-9. Архивировано из оригинала 2015-02-09.
^ "Управление требованиями". Управление государственной торговли Великобритании . Получено 10 ноября 2009 г.
^ Руководство по своду знаний по управлению проектами (4-е изд.). Институт управления проектами. 2008. ISBN 978-1-933890-51-7.
^ Готель, О., Финкельштейн, А. Анализ проблемы прослеживаемости требований. Труды Первой международной конференции по разработке требований, 1994 г., стр. 94-101.
^ ab Готель, Орлена; Клеланд-Хуан, Джейн ; Хейс, Джейн Хаффман; Зисман, Андреа; Эгид, Александр; Грюнбахер, Пол; Дехтьяр, Алекс; Антониол, Джулиано; Малетич, Джонатан (2012-01-01). Клеланд-Хуан, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Прослеживаемость программного обеспечения и систем . Springer London. стр. 3–22. doi :10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
^ Ремпель, Патрик; Мэдер, Патрик (23 марта 2015 г.). Фрикер, Сэмюэл А.; Шнайдер, Курт (ред.). Разработка требований: Фонд качества программного обеспечения . Конспекты лекций по информатике. Международное издательство Спрингер. стр. 81–97. дои : 10.1007/978-3-319-16101-3_6. ISBN 9783319161006.
^ Ральф, П. и Ванд, Й. Предложение по формальному определению концепции дизайна. В Lyytinen, К., Loucopoulos, П., Mylopoulos, Дж . и Robinson, В., (ред.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, стр. 103-136
^ Chemuturi, M. (2013). Разработка и управление требованиями для проектов по разработке программного обеспечения . doi : 10.1007/978-1-4614-5377-2. ISBN 978-1-4614-5376-5. S2CID 19818654.
^ Готель, Орлена; Мэдер, Патрик (1 января 2012 г.). Клеланд-Хуанг, Джейн ; Готель, Орлена; Зисман, Андреа (ред.). Отслеживание программного обеспечения и систем . Спрингер Лондон. стр. 43–68. дои : 10.1007/978-1-4471-2239-5_3. ISBN 9781447122388.

Дальнейшее чтение

Группа разработчиков CMMI (август 2006 г.). "CMMI для разработки, версия 1.2" ( PDF ) . Технический отчет CMU/SEI-2006-TR-008. Институт программной инженерии . Получено 22.01.2008 . {{cite journal}}: Цитировать журнал требует |journal=( помощь )
Колин Худ, Саймон Видеманн, Стефан Фихтингер, Урте Паутц Управление требованиями: Интерфейс между разработкой требований и всеми другими инженерными процессами Springer, Берлин 2007, ISBN 3-540-47689-X
Управление требованиями — практическое руководство, PMI

Внешние ссылки

Управление государственной торговли Великобритании (OGC) — Управление требованиями (архив; веб-сайт OGC прекратил работу 1 октября 2011 г.)
Руководство по унифицированным процессам CDC — Управление требованиями
Международный совет по инжинирингу требований (IREB)
Что такое управление требованиями?

[Stellman05-1] Стеллман, Эндрю; Грин, Дженнифер (2005). Управление прикладными программными проектами. O'Reilly Media. ISBN 978-0-596-00948-9. Архивировано из оригинала 2015-02-09.

[2] "Управление требованиями". Управление государственной торговли Великобритании . Получено 10 ноября 2009 г.

[PMBOK08-3] Руководство по своду знаний по управлению проектами (4-е изд.). Институт управления проектами. 2008. ISBN 978-1-933890-51-7.

[4] Готель, О., Финкельштейн, А. Анализ проблемы прослеживаемости требований. Труды Первой международной конференции по разработке требований, 1994 г., стр. 94-101.

[:0-5] Готель, Орлена; Клеланд-Хуан, Джейн ; Хейс, Джейн Хаффман; Зисман, Андреа; Эгид, Александр; Грюнбахер, Пол; Дехтьяр, Алекс; Антониол, Джулиано; Малетич, Джонатан (2012-01-01). Клеланд-Хуан, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Прослеживаемость программного обеспечения и систем . Springer London. стр. 3–22. doi :10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.

[6] Ремпель, Патрик; Мэдер, Патрик (23 марта 2015 г.). Фрикер, Сэмюэл А.; Шнайдер, Курт (ред.). Разработка требований: Фонд качества программного обеспечения . Конспекты лекций по информатике. Международное издательство Спрингер. стр. 81–97. дои : 10.1007/978-3-319-16101-3_6. ISBN 9783319161006.

[7] Ральф, П. и Ванд, Й. Предложение по формальному определению концепции дизайна. В Lyytinen, К., Loucopoulos, П., Mylopoulos, Дж . и Robinson, В., (ред.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, стр. 103-136

[8] Chemuturi, M. (2013). Разработка и управление требованиями для проектов по разработке программного обеспечения . doi : 10.1007/978-1-4614-5377-2. ISBN 978-1-4614-5376-5. S2CID 19818654.

[9] Готель, Орлена; Мэдер, Патрик (1 января 2012 г.). Клеланд-Хуанг, Джейн ; Готель, Орлена; Зисман, Андреа (ред.). Отслеживание программного обеспечения и систем . Спрингер Лондон. стр. 43–68. дои : 10.1007/978-1-4471-2239-5_3. ISBN 9781447122388.