Requirements modelling motivations: I We need a language for communicating shared perceptions of the requirements for the target system between human stakeholders We would like to perform some automated (or semi-automated) analysis of models specified in this language –Analysis can reveal inconsistencies Disagreements between stakeholders Conflicting or infeasible requirements Confusion over terminology, scope etc. –Analysis can reveal ambiguities –Analysis can test for correctness Does the model have the properties that we expect ? We can check by: –Reasoning with the model to understand its consequences (e.g., checking a formal model for its logical consequences) –Partially executing or animating a model (executable specifications)

Requirements modelling motivations: II Modelling can guide elicitation –A partially constructed model can help surface hidden (or implicit) requirements –A partially constructed model can suggest the right questions to ask Modelling can provide a measure of progress –One measure of progress is completeness of a model Measuring completeness is a difficult problem Completeness of formal theories provides one viable approach Modelling forms the basis for tool support for downstream phases of the life-cycle Can we support an automated (or semi-automated) goal- oriented decomposition: early-phase requirements -> late- phase requirements -> architectures/designs -> (possibly) code

Models: Desirable Features (From Loucopoulos and Karakostas, 1995) Implementation independence –Separation between requirements model and software design Formal semantics –We want a clear specification of meaning associated with the modelling language Ease of analysis –Ability to analyse for ambiguity, incompleteness, inconsistency Traceability –Ability to cross-reference components of a model and to link to both upstream and downstream artefacts (as well as source stakeholders) Abstraction Constructability –Ability to define and compose components of a model (divide-and- conquer modelling) Minimality –No redundancy Executability

Types of modeling languages (From Loucopoulos and Karakostas, 1995) Natural language –Highly expressive and flexible –Poorly defined semantics, making analysis difficult –Best used for elicitation and for annotating (commenting) models Semi-formal notation –Captures structure and some semantics –Can perform some analysis and reasoning over models –Examples: diagrams, tables, structured English etc. Formal notation –Precise semantics hence easy analysis and reasoning –Problem: Practitioner inaccessibility

Challenges with requirements modeling Model discovery Consistency Completeness Change management Compliance Transformation Negotiation Model merging Expressive adequacy: –Context –Rationale –Traceability –Goals –Non-functional objectives

Modeling challenges: Model discovery (1/2) The pain point: Modelling is a fundamental pre-requisite for the effective deployment of any IT system. Examples: –Business process modelling –Data modelling –Enterprise modelling –Requirements modelling –Design modelling etc Modelling is painfully hard Modelling is painfully labour intensive

Modeling challenges: Model discovery (2/2) Requirements elicitation (several techniques, separate lecture on the topic) Rapid Model Discovery toolkit: –Mines” enterprise repositories consisting of: Legacy (or “live”) text documents Legacy (or “live”) models in other notations –To obtain “quick-and-dirty” proto-models in the target notation (e.g., a process model, or an enterprise model) –Analysts edit these proto-models to obtain the final model –Analyst “edits” trigger further mining, adjustment and adaptation of proto-models