Управление требованиями
by kreator 91
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. Пропуск важных аспектов, связанных с нефункциональными требованиями