Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements)

Определение и обсуждение требований (Determination and Negotiation of Requirements)

Инициирование и определение содержания (Initiation and Scope Definition)

Данная секция фокусируется на наборе действий, связанных с эффективным определением требований к программному обеспечению с использованием различных методов извлечения требований, а также оценкой осуществимости проекта с различных точек зрения. Если проект признан осуществимым, следующей задачей является специфицирование процедур проверки и изменения требований (см. область знаний “Требования к программному обеспечению” – Software Requirements).

– выбор и применение методов определения (извлечения), анализа (например, моделирования сценариев use case), специфицирования и проверки (например, прототипирования) требований, принимая в внимание позицию различных заинтересованных лиц. Это является первичными работами, необходимыми для определения содержания, целей и ограничений проекта. Данные работы важны всегда, так как позволяют определить четкие границы задач, необходимых для выполнения, в частности, это особенно заметно для проектов, обладающих большой степенью “новизны” (идет ли речь о технологических аспектах проекта, его масштабах, методах и т.п.).

1.2 Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. (Feasibility Analysis. Technical, Operational, Financial, Social/Political.)

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

Учитывая неизбежность изменений, жизненно важно определить и согласовать с заинтересованными лицами процедуры (например, в контексте деятельности по управлению изменениями) в рамках которых будут проводиться оценка и пересмотр требований. Это однозначно предполагает, что требования не будут неизменны, но могут и должны корректироваться в соответствии с заданными и детализированными процессами (например, design review – оценка дизайна). Если изменения приняты, необходимо проводить анализ зависимостей (traceability analysis) и рисков (см. далее тему 2.5 “Управление рисками” – Risk Management) для оценки влияния рассматриваемых изменений. Такой анализ необходимо проводить, в общем случае, и при рассмотрении “изменения” для принятия решения о передачи его “в работу” или отклонении (например, в силу обоснованных причин, таких как проектные решения, позволяющих отметить его как реализуемое в следующей версии), и уже более детально, если изменение требования(ий) решено реализовать (в силу, например, контрактных обязательств со стороны исполнителя) и необходимо определить, как именно такое изменение повлияет на существующую систему и какие работы необходимо выполнить, чтобы удовлетворить обновленному(ым) требованиям. SWEBOK отмечает, что управление изменениями полезно и при оценке результатов проекта (программного продукта, программной системы), так как содержание и требования формируют основу оценки успешности проекта. (см. также секцию “Контроль конфигураций” области знаний Software Configuration Management).