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

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

Обзор [ править ]

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

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

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

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

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

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

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

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

Расследование [ править ]

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

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

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

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

Осуществимость [ править ]

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

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

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

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

Результатом этапа ТЭО является бюджет и график реализации проекта.

Дизайн [ править ]

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

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

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

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

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

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

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

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

Выпуск [ править ]

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

Инструмент [ править ]

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

См. также [ править ]

Ссылки [ править ]

^ Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения . О'Рейли Медиа. ISBN 978-0-596-00948-9 . Архивировано из оригинала 9 февраля 2015 г.
^ «Управление требованиями» . Управление государственной торговли Великобритании . Проверено 10 ноября 2009 г.
^ Руководство к своду знаний по управлению проектами (4-е изд.). Институт управления проектами. 2008. ISBN 978-1-933890-51-7 .
^ Готель О., Финкельштейн А. Анализ проблемы прослеживаемости требований Proc. Первой международной конференции по разработке требований, 1994 г., стр. 94–101.
^ Перейти обратно: ^а ^б Готель, Орлена; Клеланд-Хуанг, Джейн ; Хейс, Джейн Хаффман; Зисман, Андреа; Эгед, Александр; Грюнбахер, Пауль; Дехтяр, Алекс; Антониоль, Джулиано; Малетик, Джонатан (1 января 2012 г.). Клеланд-Хуанг, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Отслеживание программного обеспечения и систем . Спрингер Лондон. стр. 3–22 . дои : 10.1007/978-1-4471-2239-5_1 . ISBN 9781447122388 .
^ Ремпель, Патрик; Мэдер, Патрик (23 марта 2015 г.). Фрикер, Сэмюэл А.; Шнайдер, Курт (ред.). Разработка требований: Фонд качества программного обеспечения . Конспекты лекций по информатике. Международное издательство Спрингер. стр. 81–97. дои : 10.1007/978-3-319-16101-3_6 . ISBN 9783319161006 .
^ Ральф П. и Ванд Ю. Предложение по формальному определению концепции дизайна. Лютинен К., Лукопулос П., Милопулос Дж. и Робинсон В. (ред.), Разработка требований к проектированию: десятилетняя перспектива: Springer-Verlag, 2009, стр. 103–136.
^ Чемутури, М. (2013). Разработка требований и управление проектами разработки программного обеспечения . дои : 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 января 2008 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
Колин Худ, Саймон Видеманн, Стефан Фихтингер, Урте Паутц Управление требованиями: интерфейс между разработкой требований и всеми другими инженерными процессами Springer, Берлин, 2007 г., ISBN 3-540-47689-X
Управление требованиями – Практическое руководство , PMI

Внешние ссылки [ править ]

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

[Stellman05-1] Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения . О'Рейли Медиа. ISBN 978-0-596-00948-9 . Архивировано из оригинала 9 февраля 2015 г.

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

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

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

[:0-5] Перейти обратно: ^а ^б Готель, Орлена; Клеланд-Хуанг, Джейн ; Хейс, Джейн Хаффман; Зисман, Андреа; Эгед, Александр; Грюнбахер, Пауль; Дехтяр, Алекс; Антониоль, Джулиано; Малетик, Джонатан (1 января 2012 г.). Клеланд-Хуанг, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Отслеживание программного обеспечения и систем . Спрингер Лондон. стр. 3–22 . дои : 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] Ральф П. и Ванд Ю. Предложение по формальному определению концепции дизайна. Лютинен К., Лукопулос П., Милопулос Дж. и Робинсон В. (ред.), Разработка требований к проектированию: десятилетняя перспектива: Springer-Verlag, 2009, стр. 103–136.

[8] Чемутури, М. (2013). Разработка требований и управление проектами разработки программного обеспечения . дои : 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 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]