Масштабы и ограничения проекта.

Объем первоначальной версии

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

Объем последующих версий

Укажите, какие из функции будут отложены и желательные сроки последующих выпусков.

Ограничения и исключения

Определение границы между тем, что входит и выходит за границы проекта.

Бизнес-контекст

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

Профили заинтересованных лиц

Заинтересованными в проекте лицами называются отдельные лица, группы или организации, которые активно вовлечены в проект, на которых влияет результат проекта и которые сами могу" влиять на этот результат (Project Management Institute, 2000; Smitr, 2000). Профили заинтересованных лиц описывают различные категории клиентов и других ключевых лиц, заинтересованных в этом проекте. В профиль каждого заинтересованного в проекте лица включается следующая информация:

- основная ценность или преимущество, которое продукт принесет заинтересованным лицам и то, как продукт удовлетворит покупателей. Ценность для заинтересованных лиц может представлять:

1. улучшенная производительность;

2. меньшее количество переделок;

3. снижение себестоимости;

4. ускорение бизнес-процессов;

5. автоматизация задач, ранее выполнявшихся вручную;

6. возможность выполнять совершенно новые задачи;

7. соответствие соответствующим стандартам и правилам;

8. лучшая, по сравнению с текущими продуктами, легкость и простота использования;

- их вероятное отношение к продукту;

- наиболее интересные функции и характеристики;

- все известные ограничения, которые должны быть соблюдены.

Приоритеты проекта

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

- ограничение — лимитирующий фактор, в рамках которого должен оперировать менеджер проекта;

- ключевой фактор — важный фактор успеха, ограниченно гибкий при изменениях;

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

Операционная среда

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

1. Пользователи расположены далеко (географически) или близко друг от друга? В скольких часовых поясах работают ваши пользователи?

2. Когда пользователям, находящимся в различных географических местоположениях, требуется доступ к системе?

3. Где данные генерируются и используются? Насколько далеко друг от друга расположены эти местоположения? Нужно ли объединять данные из разных местоположений?

4. Известно ли максимальное время отклика для получения доступа к данным, которые могут храниться удаленно?

5. Готовы ли пользователи смириться с прерыванием работы службы или непрерывный доступ к системе крайне важен для работы их компании?

6. Какие элементы управления безопасностью и требования к защите данных необходимы?

2.2. Системные требования

2.2.1. Требования пользователей описывают цели и задачи, которые пользователям позволит решить система. Они могут быть описаны с помощью вариантов использования (методология RUP), сценариев (методология SADT). Варианты использования в данном случае меняют традиционный подход к сбору информации; пользователей не спрашивают, что с их точки зрения должна делать система, а выясняют, какие задачи собирается с ее помощью решать пользователь. Цель такого подхода – описать все подобные задачи. Последовательность работ при формировании требований следующая: вначале отбираются пользователи системы (профили заинтересованных лиц), далее перечисляются для каждого пользователя варианты использования и затем описывается каждый вариант использования. При описании вариантов использования можно использовать следующий шаблон:

- уникальный идентификатор;

- имя, кратко описывающее задачи пользователя в формате «глагол + объект»;

- краткое текстовое описание на естественном языке;

- список предварительных начальных условий, которые должны быть удовлетворены до начала разработки варианта использования;

- выходные условия, описывающие состояние системы после успешного завершения разработки вариантов использования;

- пронумерованный список действий (сценарий), иллюстрирующий последовательность этапов взаимодействия лица и системы от предварительных условий до выходных условий. При этом один из сценариев считается нормальным направлением развития, другие – альтернативными направлениями;

- приоритет, частота варианта использования и другие особые требования.

2.2.2. Спецификация требования к системе. Этот итоговый документ является задокументированным соглашением между клиентом и разработчиком. В настоящее время доступны различные шаблоны спецификации, однако многие применяют шаблон, описанный в IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications» (IEEE, 1998b):

1.Введение

1.1. Назначение

1.2. Соглашения, принятые в документах

1.3. Предполагаемая аудитория и рекомендации по чтению

1.4. Границы проекта

1.5. Ссылки

2. Общее описание

2.1. Общий взгляд на продукт

2.2. Особенности продукта

2.3. Классы и характеристики пользователей

2.4. Операционная среда

2.5. Ограничения дизайна и реализации

2.6. Документация для пользователей

2.7. Предположения и зависимости

3. Функции системы

3.х Функция системы x

3.х.1. Описание и приоритеты

3.х.2. Последовательности «воздействие – реакция»

4. Требования к внешнему интерфейсу

4.1. Интерфейсы пользователя

4.2. Интерфейсы оборудования

4.3. Интерфейсы ПО

4.4. Интерфейсы передачи информации

5.Другие нефункциональные требования

5.1. Требования к производительности

5.2. Требования к охране труда

5.3. Требования к безопасности

5.4. Атрибуты качества

6. Остальные требования

7. Приложения

Введение.

Назначение

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