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

редактировать

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

СОДЕРЖАНИЕ

  • 1 Обзор
  • 2 Прослеживаемость
  • 3 Требования к деятельности
    • 3.1 Расследование
    • 3.2 Осуществимость
    • 3.3 Дизайн
    • 3.4 Конструкция и испытания
    • 3.5 Управление изменениями требований
    • 3.6 Релиз
  • 4 Инструменты
  • 5 См. Также
  • 6 Ссылки
  • 7 Дальнейшее чтение
  • 8 Внешние ссылки

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн

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

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

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

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

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

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

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

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

Релиз

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

Инструменты

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

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

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

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

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

Последняя правка сделана 2023-04-05 11:26:13
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте