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

Разработка программного обеспечения

Процесс разработки ПО
Шаги процесса
Анализ • Проектирование • Программирование • Документирование • Тестирование
Модели
Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model
Методологии
Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD
Сопутствующие дисциплины
Конфигурационное управление • Управление проектами • Управление требованиями

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

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

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

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

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

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

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

Задачи управления требованиями

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

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

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

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

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

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

Анализ осуществимости

На стадии анализа осуществимости определяется стоимость требований.

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

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

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

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

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

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

Дизайн

Предположение, что стоимость точно определена и преимущества, которые будут получены, являются достаточно большими, проект может перейти к стадии проектирования.

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

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

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

Разработка и тестирование

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

Выпуск

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

Инструменты

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

Есть как коммерческие пакеты: IBM Rational RequisitePro, Borland CaliberRM, Sybase PowerDesigner, так и бесплатные (например, OSRMT — Open Source Requirements Management Tool).

См. также

• Бизнес-анализ
• Требования к программному обеспечению
• BABOK Руководство к Своду знаний по бизнес-анализу

Примечания

Литература

• Davis, Alan M. Just Enough Requirements Management: Where Software Development Meets Marketing. — Dorset House, 2005. — 240 p. — ISBN 978-0932633644

Ссылки

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