Creating a Project-Specific Requirements Engineering Process

Requirements Volatility. The more volatile the requirements, the more
important it becomes for the requirements process to support the quick and
easy modification and addition of requirements. The requirements process
must be agile, although that does not necessarily mean that the requirements
process needs to be superficial.

⎯ Stakeholder Involvement. The more involved that the stakeholders (e.g., user
representatives, management, subject matter experts, architects, testers,
assessors, and regulators) are in the RE process, the more important that they
both understand the RE process, that they can perform their allocated tasks in
the process, and that they can understand the resulting work products.

⎯ Process Breadth. Do you need a process framework that is restricted to RE,
or do you need a general process framework that covers all activities (e.g.,
from management, development, operation, and retirement), whereby RE is
only part of the framework? In order to ensure cross-activity consistency, RE
is best performed within the context of the entire system or software
engineering process. Selecting a general purpose process framework and
repository can avoid unnecessary duplication of work and “turf battles” that
may occur between RE and other related activities.