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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

исследованием, анализом осуществимости, дизайном, разработкой и тестированием и выпуском.

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

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

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

е

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

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

е

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

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

е

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

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

е

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн

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

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

Дизайн

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

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

Дизайн

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

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

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

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

Выпуск

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

Выполнил :Гардей О.С.ВитГТК 2014