Информационная система «Склад»

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

Version <1.0>

История изменений

Дата	Версия	Описание	Автор
26.09.2010	1.0		Дозоренко И. Калюжный А.

Содержание

1. Введение 3

1.1 Цель 3

1.2 Контекст 3

1.3 Определения и сокращения 3

1.4 Ссылки 3

1.5 Краткое содержание 3

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

2.1 Устройство, обязанности и интерфейсы 4

2.1.1 Клиент (заказчик) 4

2.1.2 Пользователь 4

2.1.3 Заинтересованные лица 4

2.1.4 Менеджер проекта 4

2.1.5 Гарантия качества 4

2.1.6 Разработчик 4

2.1.7 Лидер группы 4

2.1.8 Менеджер конфигурации 4

2.1.9 Установщик требований 5

2.2 Таблица контактов 5

2.3 Инструменты, среда, и инфраструктура 5

3. Артефакты требований 6

3.1 Определение артефактов 6

3.1.1 Типы документов 6

3.1.2 Типы требований 6

3.1.3 Атрибуты 6

3.1.4 Список значений 10

3.2 Критерии отслеживаемости для типов требования 12

3.3 Отчёты и измерения 12

4. Этапы 15

4.1 Начало 15

4.1.1 Оценочные критерии 15

4.1.2 Артефакты 15

4.2 Развитие 15

4.2.1 Оценочные критерии 15

4.2.2 Артефакты 16

4.3 Конструирование 16

4.4 Передача 17

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

1.Введение

1.1Цель

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

1.2Контекст

Этот проект предусматривает руководящие указания для менеджера информационной системы «Склад».

1.3Определения и сокращения

Общий словарь данного проекта содержится в Глоссарии.

1.4Ссылки

1. Kruchten, Philippe. The Rational Unified Process / Kruchten, Philippe - Menlo Park, CA: Addison Wesley, 1999

2. Leffingwell, D. Managing Software Requirements / Leffingwell, D., Don Widrig - Menlo Park, CA: Addison Wesley, 2000.

3. Spence, I. Traceability Strategies for Managing Requirements with Use Cases / Spence, I., L. Probasco - Cupertino, CA: Rational Software Corporation, 1998.

4. Rational Unified Process®, Version 2003 Copyright © 1987 – Rational Software Corporation, 2003.

5. Дик Леффингуэл. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. / Дик Леффингуэл, Дон Уидринг - М.: Вильямс, 2002. – 448с.

1.5Краткое содержание

Этот документ содержит специфические детали и стратегии для управления требованиями к Информационной системе «Склад». Документ подробно описывает, как организованы требования в данном проекте и как они контролируется. Он также описывает, как требования будут идентифицированы, назначены атрибуты, установлены, и изменены.

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

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

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

2.1Устройство, обязанности и интерфейсы

ЗНТУ, кафедра программных средств, ИВТ-446м

2.1.1Клиент (заказчик)

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

2.1.2Пользователь

Особа, которая будет использовать разработанную систему.

2.1.3Заинтересованные лица

Личность или организация, которая материально зависит от результата (исхода/выхода) работы системы.

2.1.4Менеджер проекта

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

2.1.5Гарантия качества

Функция гарантии качества является ответственностью (обязанностью) менеджера проекта. Является гарантией того, что штат служащих корректно и контролируемо придерживается стандартов проекта.

2.1.6Разработчик

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

2.1.7Лидер группы

Лидер группы - посредник между управлением проектом и разработчиками. Лидер группы ответственен за гарантирование, что задача размещена и контролируется до завершения. Лидер группы ответственен за то, что штат разработчиков следует за проектными стандартами, и придерживается проектных списков.

2.1.8Менеджер конфигурации

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

2.1.9Установщик требований

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