University of Toronto Department of Computer Science Lecture 9 Requirements Modelling A little refresher What are we modelling Requirements Systems Systems Thinking Role of Modelling in RE Why modelling is important Limitations of modelling Brief overview of modelling languages Modelling principles Abstraction Decomposition Projection Modularity 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 1 University of Toronto Department of Computer Science Refresher Definitions Application Domain D domain properties R requirements Machine Domain C computers P programs Some distinctions Domain Properties things in the application domain that are true whether or not we ever build the proposed system Requirements things in the application domain that we wish to be made true by delivering the proposed system A specification a description of the behaviours the program must have in order to meet the requirements Two correctness verification criteria The Program running on a particular Computer satisfies the Specification The Specification in the context of the given domain properties satisfies the requirements Two completeness validation criteria We discovered all the important requirements We discovered all the relevant domain properties 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 2 Department of Computer Science University of Toronto Refresher Systems to model Source Adapted from Loucopoulos Karakostas 1995 p73 Maintains information about Needs information about Subject System Uses Information system Usage System builds contracts Development System 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 3 University of Toronto Department of Computer Science Refresher Systems Thinking 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 4 Department of Computer Science University of Toronto Modelling Modelling can guide elicitation It can help you figure out what questions to ask It can help to surface hidden requirements i e does it help you ask the right questions Modelling can provide a measure of progress Completeness of the models completeness of the elicitation i e if we ve filled in all the pieces of the models are we done Modelling can help to uncover problems Inconsistency in the models can reveal interesting things e g conflicting or infeasible requirements e g confusion over terminology scope etc e g disagreements between stakeholders Modelling can help us check our understanding Reason over the model to understand its consequences Does it have the properties we expect Animate the model to help us visualize validate the requirements 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 5 Department of Computer Science University of Toronto RE involves a lot of modelling Source Adapted from Jackson 1995 p120 122 A model is more than just a description it has its own phenomena and its own relationships among those phenomena The model is only useful if the model s phenomena correspond in a systematic way to the phenomena of the domain being modelled Example ISBN title Book The application domain 1 n author Designations for the application domain B Book P Person R Wrote Common Properties 0 n Book entity Person entity author relation name The modelling Person domain Designations for the model s domain For every B at least one P exists such that R P B 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 6 Department of Computer Science University of Toronto It s only a model Source Adapted from Jackson 1995 p124 5 There will always be phenomena in the model that are not present in the application domain phenomena in the application domain that are not in the model ISBN title name DOB Book 1 n author Phenomena not captured in the model ghost writers pseudonyms anonymity 0 n Person Phenomena not true in the world Common Phenomena every book has at least one author every book has a unique ISBN no two people born on same date with same name A model is never perfect If the map and the terrain disagree believe the terrain Perfecting the model is not always a good use of your time 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 7 Department of Computer Science University of Toronto Choice of modelling notation Source Adapted from Loucopoulos Karakostas 1995 p72 73 natural language extremely expressive and flexible useful for elicitation and to annotate models for readability poor at capturing key relationships semi formal notation UML fits in here captures structure and some semantics can perform some reasoning consistency checking animation etc E g diagrams tables structured English etc mostly visual for rapid communication with a variety of stakeholders formal notation precise semantics extensive reasoning possible Underlying mathematical model e g set theory FSMs etc very detailed models may be more detailed than we need RE formalisms are for conceptual modelling hence differ from most computer science formalisms 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 8 Department of Computer Science University of Toronto Desiderata for Modelling Notations Source Adapted from Loucopoulos Karakostas 1995 p77 Implementation Independence does not model data representation internal organization etc Abstraction ability to analyze for ambiguity incompleteness inconsistency extracts essential aspects Formality unambiguous syntax rich semantic theory Constructability can construct pieces of the model to handle complexity and size construction should facilitate communication Traceability ability to cross reference elements ability to link to design implementation etc e g things not subject to frequent change Ease of analysis Executability can animate the model to compare it to reality Minimality No redundancy of concepts in the modelling scheme i e no extraneous choices of how to represent something 2004 5 Steve Easterbrook This presentation is
View Full Document
Unlocking...