Интернет магазин китайских планшетных компьютеров

Компьютеры - Управление требованиями - Задачи управления требованиями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн

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

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

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

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

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

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

Выпуск

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