DOC PREVIEW
Toronto CSC 340 - Lecture 11 - Requirements Modelling

This preview shows page 1-2 out of 5 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1University of TorontoDepartment of Computer Science© Easterbrook 20042Lecture 11: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 ModularityUniversity of TorontoDepartment of Computer Science© Easterbrook 20043Refresher: Definitions Some distinctions: Domain Properties - things in the application domain that are true whether or not weever build the proposed system Requirements - things in the application domain that we wish to be made true bydelivering the proposed system A specification - a description of the behaviours the program must have in order tomeet 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 therequirements Two completeness (validation) criteria: We discovered all the important requirements We discovered all the relevant domain propertiesApplication DomainMachine DomainD - domain propertiesR - requirementsC - computersP - programsUniversity of TorontoDepartment of Computer Science© Easterbrook 20044Source: Adapted from Loucopoulos & Karakostas, 1995, p73Subject SystemInformation systemUsesbuildsMaintains informationaboutNeeds informationaboutcontractsUsage SystemDevelopment SystemRefresher: Systems to modelUniversity of TorontoDepartment of Computer Science© Easterbrook 20045Refresher: Systems Thinking2University of TorontoDepartment of Computer Science© Easterbrook 20046Modelling… 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 requirementsUniversity of TorontoDepartment of Computer Science© Easterbrook 20047Source: Adapted from Jackson, 1995, p120-122For every B, atleast one P existssuch that R(P, B)TheapplicationdomainDesignations forthe applicationdomainCommonPropertiesThemodellingdomainDesignationsfor the model’sdomainB = BookP = PersonR = WroteBook: entityPerson: entityauthor: relationRE involves a lot of modelling 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 wayto the phenomena of the domain being modelled. Example:Booktitleauthor(0,n)(1,n)nameISBNPersonUniversity of TorontoDepartment of Computer Science© Easterbrook 20048“It’s only a model” 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 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...Source: Adapted from Jackson, 1995, p124-5…every book has atleast one author……every book has aunique ISBN…CommonPhenomena…ghost writers……pseudonyms……anonymity……no two peopleborn on same datewith same name…Booktitleauthor(0,n)(1,n)nameISBNPersonDOBPhenomenanot capturedin the modelPhenomenanot truein the worldUniversity of TorontoDepartment of Computer Science© Easterbrook 20049Source: Adapted from Loucopoulos & Karakostas, 1995, p72-73UML fits in hereChoice of modelling notation natural language extremely expressive and flexible useful for elicitation, and to annotate models for readability poor at capturing key relationships semi-formal notation 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 computerscience formalisms3University of TorontoDepartment of Computer Science© Easterbrook 200410Desiderata for Modelling Notations Implementation Independence does not model data representation,internal organization, etc. Abstraction extracts essential aspectse.g. things not subject to frequentchange Formality unambiguous syntax rich semantic theory Constructability can construct pieces of the model tohandle complexity and size construction should facilitatecommunication Ease of analysis ability to analyze for ambiguity,incompleteness, inconsistency Traceability ability to cross-reference elements ability to link to design,implementation, etc. Executability can animate the model, to compare itto reality Minimality No redundancy of concepts in themodelling schemei.e. no extraneous choices of how torepresent somethingSource: Adapted from Loucopoulos & Karakostas, 1995, p77University of TorontoDepartment of Computer Science© Easterbrook 200411Survey of Modelling Techniques Modelling Enterprises Goals & objectives Organizational structure Tasks & dependencies Agents, roles, intentionality Modelling Information & Behaviour Information Structure Behavioral views Scenarios and Use Cases State machine models Information flow Timing/Sequencing requirements Modelling System Qualities (NFRs) All the ‘ilities’: Usability, reliability, evolvability, safety,security, performance, interoperability,…Organization modelling:i*, SSM, ISACGoal modelling:KAOS,


View Full Document

Toronto CSC 340 - Lecture 11 - Requirements Modelling

Documents in this Course
Scoping

Scoping

10 pages

Load more
Download Lecture 11 - Requirements Modelling
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 11 - Requirements Modelling and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 11 - Requirements Modelling 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?