Рабочий поток анализа требований

Процесс анализа требований

Верифицируемость (пригодность к проверке).

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

 

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

Для его обозначения в англоязычной литературе, как правило, используется понятие "Requirement Process". В отечественной практике, наряду с обобщающим термином "анализ требований", принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также такие термины, как "поток работ "требования", "работа с требованиями", "определение требований" и т.д., что вносит изрядную путаницу. Для того, чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK, и введем терминологию, которой будем придерживаться на протяжении лекционного курса.

SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:

  • Requirements Elicitation (Извлечение требований),
  • Requirements Analysis (Анализ требований в узком смысле),
  • Requirements Specification (Специфицирование требований),
  • Requirements Validation (Проверка требований).

В качестве примера альтернативной декомпозиции потока работ можно рассмотреть взгляд, предложенный в RUP [4.1]. RUP предлагает выделить в основном потоке анализа требований такие компоненты, как:

  • Analyze the Problem (Анализ проблемы),
  • Understand Stakeholder Needs (Понимание потребностей совладельцев),
  • Define the System (Определение системы),
  • Manage the Scope of the System (Управление контекстом системы),
  • Refine the System Definition (Уточнение определения системы).

Обобщая указанные выше декомпозиции, а также подходы, описанные в [4.4,4.5-4.7], далее будем придерживаться следующей, более удобной в методическом плане схемой декомпозиции потока работ "Работа с требованиями":

  • Формирование видения;
  • Выявление требований;
  • Классификация и спецификация требований;
  • Расширенный анализ требований (моделирование и прототипирование);
  • Документирование требований;
  • Проверка требований;
  • Управление требованиями;
  • Совершенствование процесса работы с требованиями.

Первые 6 работ в лекционном курсе рассматриваются, как компоненты процесса анализа требований.

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

Найти ответ на первый вопрос может помочь общая классификация задач, работ и операций программной инженерии, представленная в ГОСТ Р ИСО/МЭК 12207-99. Другая, более поздняя по времени классификация, присутствует в SWEBOK. Однако нужно отметить, что данные руководящие документы рассматривают общий случай, а в частном проекте может быть задействован далеко не весь арсенал работ.

Сложнее - с решением второго вопроса. На сегодня существуют и имеют примеры успешного применения десятки и сотни различных методологий (процессов), среди наиболее известных - MSF, RUP, Oracle PJM, XP, FDD, SCRUM, PSP, Crystal, DSDM. Методологии подразделяются на 3 "волны": каскадные (исторически первые), прогнозирующие (например, RUP) и "быстрые" (agile), вошедшие в широкую практику на рубеже тысячелетий [4.3].

Описания методологий существенно разнятся объемом (от десятков до тысяч страниц текста), наборами базовых работ и рабочих квалификаций, акцентами (работа с моделями, управление рисками, построение команды и пр.). Но авторы их описаний обычно сходятся в одном: лучшая из методологий, которой нужно следовать, чтобы добиться успеха - именно та, которую предлагает (описывает, рекламирует) автор. Редким исключением являются работы А. Коберна, автора группы методологий Crystal (см., в частности, [4.3]), где он предлагает брать за основу не "самый лучший" из процессов, а тот, который, во-первых, наилучшим образом соответствует проектной задаче, а во вторых - команде, которая будет его реализовывать. В [4.3] вводится несколько метрик, позволяющих частично формализовать процесс подбора методологии.

1.7.2 Почему нужно анализировать требования?

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

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

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

Анализ требований - это процесс (бизнес-процесс) и, следовательно, к нему подходят методы и средства процессного подхода к управлению (см., например, [1]).

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

Другой важный вопрос - какие цели преследует процесс.

RUP предлагает следующие цели для потока работ АТ:

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