A lightweight technique for assessing risks in requirements analysis

Our technique uses, as an underlying framework, a requirements goal graph (Fig. 1). A goal graph represents stakeholders’ hopes for a system-to-be, which will be operated in an expected environment, in fulfilment of a contract. The graph can represent the rationale and understanding of the problem to be solved along with a set of domain assumptions and the stated requirements for a system. Goal graphs of this type are widely used in goal-based requirements engineering and most notably in the keep all objectives satisfied (KAOS) approach [3] which informs our work.

In this paper, we use the word ‘requirement’ to refer to all goals in the goal graph, not just leaf goals. A requirements goal graph is usually composed of a
number of root goals, the motivating goals, with a hierarchy of sub-goals connected by refinement relations. Sub-goals may satisfy the super-ordinate goal in conjunction (and) or as alternative realisations (or). The hierarchy has the
potential to be cross-cutting although this is beyond the scope of this paper, as is a detailed treatment of risks associated with requirements traceability. Leaf goals have no refinements but can be expressed in operational terms and
can be assigned a method by which the goal may be satisfied (i.e. implemented); this may be performed by a system component (in which case the leaf is an operationalised requirement) or by the system environment (in which case the leaf is an operationalised assumption).