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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн

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

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

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

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

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

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

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

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

Релиз

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

Инструменты

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

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

Рекомендации

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

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

внешняя ссылка