Problem Frames Work as a Bridge from Informal Requirements to Formal Models

Main -> DEPLOY Success Stories -> Auto-2

Short description
This evidence concerns the contribution made by problem frames to bridging the gap between informal specification and formal specification. This intermediate step is useful both for structuring the requirements in preparation for formalisation and providing guidance in the formalisation process. It is also a lighter formalism, easier to validate than a detailed formal model. Furthermore, it helps to keep the necessary traceability between requirements and lower level formal models.

The ultimate goal of the evidence is to show improvements in quality and productivity.

Related FAQ
of Interest to Project and QA Manager of Interest to Engineers and Analysts
 * CIF-PQAM-1 Is it possible to hide the use of a formalism from most developers so only a few experts in an enterprise need to use and master it?
 * EM-EA-2 Is a formalism adapted to model important issues in a given application domain?

Benefits

 * Systematising and easing the formalisation process
 * Producing high quality formal models fully covering the requirements
 * Further improvements of the requirements and problem frames

Limitations

 * Uncovered requirements with Problem Frames such as timing requirements
 * Only initial experiments, not even yet fully experimented on the complete pilot project (cruise control)
 * The requirements plug-in does only allow tracing of natural language requirement. It does not support the mapping to other model based tools. It would be necessary to integrate it with a model-based requirements tool (e.g. problem frame tool).

Elaboration
To support the formalisation process, a mapping from Problem Frames to Event-B was defined and described in. It maps problem diagrams onto machines, elaboration of diagrams onto Event-B refinement, diagram projection onto Event-B decomposition, requirements onto events and/or invariants. This mapping is however currently preliminary and must yet be validated on the pilot study. A relevant issue to check is if the Event-B formalisation and the use of proof on the Event-B model will highlight further requirements problems such as too weak or too strong requirements, missing assumptions, etc.

Consolidation
Another couple of semi-formal/formal method has been experimented with the similar goal to reconcile the KAOS goal-oriented requirements engineering method and VDM++. The process is similar to the problems’ frames to Event-B approach: develop a requirements model (including requirements at different level of refinement, agents, operations with pre/post conditions traced to the requirements they enforce), mapping on VDM++. A generator is available. It generates a partial VDM++ specification. Missing elements are highlighted so that the developers can fill them in.