Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

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

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

Основная статья: Прослеживаемость требований

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Требование
  • Разработка требований
  • Анализ требований
  • Прослеживаемость требований
  • Группа специалистов по разработке требований
  • Область процесса (CMMI):
    • Разработка требований (RD)
    • Управление требованиями (REQM)
  • Документ с требованиями к продукту
  • Качество программного обеспечения

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

  1. ^ Стеллман, Эндрю; Грин, Дженнифер (2005). Управление прикладными программными проектами . O'Reilly Media. ISBN 978-0-596-00948-9. Архивировано из оригинала на 2015-02-09.
  2. ^ «Управление требованиями» . Управление государственной торговли Великобритании . Проверено 10 ноября 2009 .
  3. ^ Руководство к своду знаний по управлению проектами (4-е изд.). Институт управления проектами. 2008. ISBN 978-1-933890-51-7.
  4. ^ Готель, О., Финкельштейн, А. Анализ проблемы прослеживаемости требований Proc. Первой международной конференции по разработке требований, 1994, стр. 94-101
  5. ^ a b Готель, Орлена; Клеланд-Хуанг, Джейн; Хейс, Джейн Хаффман; Зисман, Андреа; Египетский, Александр; Грюнбахер, Пауль; Дехтяр, Алексей; Антониол, Джулиано; Малетик, Джонатан (01.01.2012). Клеланд-Хуанг, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Программное обеспечение и прослеживаемость систем . Springer London. стр.  3 -22. DOI : 10.1007 / 978-1-4471-2239-5_1 . ISBN 9781447122388.
  6. ^ Ремпель, Патрик; Мэдер, Патрик (23 марта 2015 г.). Fricker, Samuel A .; Шнайдер, Курт (ред.). Разработка требований: основа качества программного обеспечения . Конспект лекций по информатике. Издательство Springer International. С. 81–97. DOI : 10.1007 / 978-3-319-16101-3_6 . ISBN 9783319161006.
  7. ^ Ральф, П., и Ванд, Ю. Предложение по формальному определению концепции дизайна. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J. , and Robinson, W., (eds.), Design Requirements Engineering: A 10-Year Perspective: Springer-Verlag, 2009, pp. 103-136
  8. ^ Chemuturi, М. (2013). Разработка требований и управление проектами разработки программного обеспечения . DOI : 10.1007 / 978-1-4614-5377-2 . ISBN 978-1-4614-5376-5. S2CID  19818654 .
  9. ^ Готель, Орлена; Мэдер, Патрик (01.01.2012). Клеланд-Хуанг, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Программное обеспечение и прослеживаемость систем . Springer London. стр.  43 -68. DOI : 10.1007 / 978-1-4471-2239-5_3 . ISBN 9781447122388.

Дальнейшее чтение [ править ]

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

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

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