Практика 2

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

Процесс выработки требований является частью процесса разработки ИС, который реализуется в рамках 4 основных подпроцессов [59].

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

2. Выделение и анализ требований (Requirements elicitation and analysis). Это процесс формирования списка требований посредством анализа существующих систем, общения с потенциальными пользователями. Для формирования списка требований может потребоваться разработка ряда моделей и прототипов.

3. Спецификация требований (Requirements specification). Эту активность можно определить как процесс упорядочения собранной информации о требованиях.

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

Обобщенная структура процесса формирования требований приведена на рис. 4.2.

Рис. 4.2. Обобщенная структура процесса формирования требований

4.3. Оценка реализуемости

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

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

1. В чем состоят проблемы организации, и каким образом создаваемая система поможет их решить.

2. Какова стоимость перехода на новую систему.

3. Используются ли в системе технологии, ранее не применяемые в организации.

4. Какими будут последствия для организации, если система не будет создана.

В отчете могут содержаться предложения по изменению состава требований. Обычно процесс оценки реализуемости занимает не более 2-3 недель.

4.4. Выделение и анализ требований

После того, как принято положительное решение о создании системы, переходят к процессу выделения и анализа требований. Обычно аналитики работают с потенциальными пользователями и покупателями и другим заинтересованными лицами, такими как бизнес-менеджеры, эксперты в данной предметной области, т.е. со всеми, кто прямым или косвенным образом определяет требования к системе. Этот процесс в разных организациях может быть организован по-разному, в зависимости от типа разрабатываемых ИС и традиций организации разработчика.

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

1. Выявление требований (Discovery). Процесс взаимодействия с заинтересованными сторонами с целью выявление их требований, а также формулирование доменных требований.

2. Классификация и организация требований (Сlassification and organization). Процесс упорядочения списка выявленных требований. Для упорядочения требований обычно используется архитектурная модель, применительно к которой формируются требования к отдельным подсистемам. На этом этапе разрабатывается архитектурная модель. Таким образом, можно утверждать, что процесс архитектурного проектирования и процесс разработки требований – это, по существу один и тот же процесс.

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

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

1. Заинтересованные стороны часто не могут четко сформулировать свои требования и начинают выставлять нереалистичные требования.

2. Потенциальные пользователи формулируют свои требования в терминах предметного домена и аналитикам трудно их понять.

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

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

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

Основными приемами, используемыми на данном этапе являются: интервьюирование, сценарии варианты использования.

Интервьюирование. Обычно используется 2 типа интервью: в первом случае (закрытое интервью) заинтересованное лицо отвечает на заранее определенный набор вопросов, а во втором случае (открытое интервью) – список вопросов заранее не определяется. На практике чаще всего используется некоторая смесь интервью этих двух типов. Механизм интервью хорошо работает при выявлении требований конечных пользователей, однако не всегда работает на уровне выявления доменных требований, поэтому для выявления доменных требований аналитикам приходится работать с документацией.

Сценарии. Конечному пользователю часто бывает проще объяснить свои требования на конкретных примерах. Сценарии обычно используются для уточнения деталей того, как пользователь хотел бы общаться с системой. В качестве языка описания сценариев обычно используется диаграммы вариантов использования (use case), входящих с состав UML [63] который будет описан ниже.