1 / 7

Lecture 3: Requirements Modeling Intro

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.

erich-woodard
Download Presentation

Lecture 3: Requirements Modeling Intro

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

More Related