University of Toronto University of Toronto Department of Computer Science Refresher Definitions Lecture 11 Requirements Modelling Application Domain D domain properties A little refresher R requirements What are we modelling Requirements Systems Systems Thinking Why modelling is important Limitations of modelling Brief overview of modelling languages Modelling principles 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 Role of Modelling in RE Department of Computer Science 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 Abstraction Decomposition Projection Two completeness validation criteria We discovered all the important requirements We discovered all the relevant domain properties Modularity 2 Easterbrook 2004 University of Toronto Department of Computer Science 3 Easterbrook 2004 University of Toronto Refresher Systems to model Department of Computer Science Refresher Systems Thinking Maintains information about Needs information about Subject System Uses Information system Usage System builds contracts Development System Easterbrook 2004 Source Adapted from Loucopoulos Karakostas 1995 p73 4 Easterbrook 2004 5 1 University of Toronto University of Toronto Department of Computer Science Modelling RE involves a lot of modelling Modelling can guide elicitation It can help you figure out what questions to ask A model is more than just a description it has its own phenomena and its own relationships among those phenomena It can help to surface hidden requirements The model is only useful if the model s phenomena correspond in a systematic way to the phenomena of the domain being modelled i e does it help you ask the right questions Example Modelling can provide a measure of progress The application domain 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 1 n author B Book P Person R Wrote Designations for the application domain e g conflicting or infeasible requirements e g confusion over terminology scope etc e g disagreements between stakeholders ISBN title Book Completeness of the models completeness of the elicitation Department of Computer Science Modelling can help us check our understanding Common Properties Reason over the model to understand its consequences Does it have the properties we expect 0 n Book entity Person entity author relation name The modelling domain Person Designations for the model s domain For every B at least one P exists such that R P B Animate the model to help us visualize validate the requirements 6 Easterbrook 2004 University of Toronto Easterbrook 2004 University of Toronto Department of Computer Science It s only a model phenomena in the model that are not present in the application domain useful for elicitation and to annotate models for readability poor at capturing key relationships ISBN title name DOB 1 n 0 n natural language extremely expressive and flexible phenomena in the application domain that are not in the model author Department of Computer Science Choice of modelling notation There will always be Book 7 Source Adapted from Jackson 1995 p120 122 semi formal notation captures structure and some semantics Person UML fits in here can perform some reasoning consistency checking animation etc Phenomena not captured in the model ghost writers pseudonyms anonymity Common Phenomena every book has at least one author every book has a unique ISBN E g diagrams tables structured English etc Phenomena not true in the world mostly visual for rapid communication with a variety of stakeholders no two people born on same date with same name precise semantics extensive reasoning possible Underlying mathematical model e g set theory FSMs etc very detailed models may be more detailed than we need A model is never perfect RE formalisms are for conceptual modelling hence differ from most computer science formalisms If the map and the terrain disagree believe the terrain Perfecting the model is not always a good use of your time Easterbrook 2004 Source Adapted from Jackson 1995 p124 5 formal notation 8 Easterbrook 2004 Source Adapted from Loucopoulos Karakostas 1995 p72 73 9 2 University of Toronto University of Toronto Department of Computer Science Desiderata for Modelling Notations Implementation Independence does not model data representation internal organization etc Abstraction Formality Constructability can construct pieces of the model to handle complexity and size construction should facilitate communication Easterbrook 2004 Traceability Executability can animate the model to compare it to reality rich semantic theory State machine models Information flow Minimality Quality tradeoffs QFD win win AHP Specific NFRs Modelling System Qualities NFRs Timed Petri nets performance All the ilities Task models usability Usability reliability evolvability safety Probabilistic MTTF reliability No redundancy of concepts in the modelling scheme University of Toronto Timing Sequencing requirements i e no extraneous choices of how to represent something 10 Source Adapted from Loucopoulos Karakostas 1995 p77 Modelling Enterprises Organization modelling i SSM ISAC Goals objectives Goal modelling Organizational structure KAOS CREWS Tasks dependencies Information modelling E R Class Diagrams Agents roles intentionality Structured Analysis Modelling Information Behaviour SADT SSADM JSD Object Oriented Analysis Information Structure OOA OOSE OMT UML Behavioral views Formal Methods Scenarios and Use Cases SCR RSML Z Larch VDM ability to link to design implementation etc unambiguous syntax Ease of analysis ability to cross reference elements e g things not subject to frequent change Survey of Modelling Techniques ability to analyze for ambiguity incompleteness inconsistency extracts essential aspects security performance interoperability 11 Easterbrook 2004 University of Toronto Department of Computer Science the Unified Modelling Language UML Department of Computer Science
View Full Document
Unlocking...