Getting Started

Goal-driven requirements analysis is a top-down process in the beginning. The stakeholders first define rather abstract system goals. While the methodology can be used for both adaptive and non-adaptive systems, it is often easier to start with defining goals for a non-adaptive, centrally controlled system and add obstacles and their resolutions later (cf. Mitigate Uncertainty Factors) to introduce adaptivity for certain aspects later on.

Alternatively, if the system to be built needs to be highly flexible, it is possible to define system goals that incorporate the adaptivity directly. In such a case, the refinement of these system goals introduces according sub-goals and requirements much more early in the process. This can have positive effects on the system design but also requires that solution mechanisms are considered rather early. If the adaptation processes are expected to be highly complex, it is therefore encouraged to work with this latter variant. If the system without adaptivity is complex enough and adaptivity plays only a minor role, the former variant is recommended.

The practice is easily embedded in iterative-incremental processes. System goals can be elaborated in different iterations, with a preference to elaborate those first that have the greatest potential impact and risk. Care should be taken not to overwrite previous versions of the requirements model that is developed in each iteration since such older versions are helpful to reconstruct the reasoning process and document design decisions.

Common Pitfalls

It is important to remember that requirements should not pre-empt the solution that will be used. Requirements analysis should be an open process in which possible solutions are left open as long as possible. Of course, as the requirements become more concrete in later iterations and with them parts of the design become stable, requirements can be refined to include design choices and specific requirements that make sense in the context of these choices. Keep in mind, however, that incorporating too many aspects of the solution into the requirements documents make it hard to revise these decisions later on.