Lecture 3: Requirements Modeling Intro Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of Wollongong

Requirements modeling 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 modeling motivations: II Modeling 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 Modeling 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 Modeling 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

Current approaches to modelling Enterprise modelling: We wish to represent –Organizational goals –Organizational structure –Activities, processes, products –Actors and their roles –Examples: Information modeling: ERD Organizational modeling: i*, SSM, ISAC Goal modeling: KAOS, CREWS Modelling functional requirements –Examples: Structured analysis: SADT, SSADM, JSD Object-oriented analysis: OOA, OOSE, OMT, UML Formal methods: SCR, RSML, Z, Larch, VDM Modelling non-functional requirements –Examples: QFD, timed Petri nets (performance), task models (usability), probabilistic MTTF (reliability)

Formal requirements modeling Important for safety- and mission-critical systems Formal modeling techniques closely tied in with verification techniques used to establish the correctness of the models Most formal methods come with: –A language for describing (behavioural) models of the proposed system –A specification language for describing the properties to be verified –A verification method to determine if a given model satisfies certain properties