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  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).