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

Get Started. It's Free
or sign up with your email address
Rocket clouds
Управление требованиями by Mind Map: Управление требованиями

1. Проблема

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

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

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

2. Свойства требований

2.1. Ясность, недвусмысленность

2.2. Полнота и непротиворечивость.

2.3. Необходимый уровень детализации.

2.4. Прослеживаемость

2.5. Тестируемость и проверяемость

2.6. Модифицируемость

3. Варианты формализации требований

3.1. Неформальная постановка требований в переписке по электронной почте.

3.2. Требования в виде документа – описание предметной области и ее свойств, техническое задание как приложение к контракту, функциональная спецификация для разработчиков и т.д.

3.3. Требования в виде графа с зависимостями в одном из средств поддержки требований (IBM Rational RequisitePro, DOORS, Borland CaliberRM и нек. др.).

3.4. Формальная модель требований для верификации, модельно-ориентированного тестирования и т.д.

3.5. Некоторые ошибки при документировании требований.

3.5.1. Описание возможных решений вместо требований.

3.5.2. Нечеткие требования

3.5.3. Игнорирование аудитории, для которой предназначено представление требований

3.5.4. Пропуск важных аспектов, связанных с нефункциональными требованиями

4. Цикл работы с требованиями

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

4.2. Анализ требований

4.3. Описание требований

4.4. Валидация требований