Why modelling requirements?
KAOS is a method advocating for a requirements modelling phase before writing the requirements document. The requirements document becomes just a derived product that draws up a structured and motivated inventory of the requirements based on the elaborated model.
Modelling information systems is not new. Contractors use to have recourse to it to specify an architecture, the information structure or the behaviour of the developed solution.
The innovation brought by the KAOS methodology is to extend modelling activities to the definiiton of the problem itself.
What are the differences between problem modelling and solution modelling? Here follow some key elements:
- problem modelling concerns the contracting authority mainly while solution modelling concerns the contractor mainly.
- the contracting authority is not primarily interested in technical considerations about the solution (the UML class diagrams or the database schema, state-transition diagrams, etc.) while it is the core business of the contractor
- modelling techniques for solutions do not address or address only informally fundamental questions, the contracting authority is concerned with:
- what are the objectives of the system and what are the requirements to set up?
- what will be the contribution of each actor to reach these objectives?
- how can we be sure to forget nothing?
Modelling a problem and modelling its solution are each one side of a same coin. Although problems and solutions can have their own structure, the structure of the solution generally extends the one of the problem to be solved.
The innovation brought by KAOS consists of a modelling technique which is positioned upstream, is complementary and in continuity with mainstream system engineering techniques (UML, MDA,...). KAOS allows one to separate clearly the problem modelling (goals to be achieved, concerned agents, domain) from the solution modelling (objects needed to design a solution, including their expected behaviours).
The main benefits of this approach are the following ones:
- the contracting authority can better be involved in the project at the business level they master with a deeper insight on their requirements and with a more rigorous and precise mean to communicate those requirements to the contractors
- a part of the modelling effort is shifted from the contractors to the contracting authority, or more precisely to requirements engineers who are often consultants working on behalf of the contracting authority; they will be in charge of modelling the problem that nobody else than the contracting authority knows better; this model will be reused in turn by the contractors in order to integrate items regarding the solution into it.
- the contractors can start their work on much solid foundations instead of being based on a very informal requirements document; it will also improve the evaluation of the project in terms of complexity, cost and duration.
- the model can be reused to address subsequent changes; those changes will be first analysed, then integrated to the requirements model by the contracting authority and finally a new version of the requirements document consistent with those changes will be generated and sent to the contractors. The requirements document therefore becomes a dynamic concept evolving during the project and maintained consistent. This feature is essential to cope with the main drawbacks observed on agile projects.