Визуализация, определение и управление требованиями

Каковы задачи управления требованиями?

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

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

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

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

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

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

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

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

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

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

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

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

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

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