DOC PREVIEW
Toronto CSC 302 - Lecture 14 - From Requirements to Design

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 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 9 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 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 14:From Requirements to DesignIdentifying ActorsBuilding a Domain ModelGoal modelingObstacle AnalysisScopingUse CasesUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2D - domain propertiesR - requirementsC - computersP - programsRefesherDomain Properties (assumptions):things in the application domain that are true whether or not we ever build the proposedsystem(System) Requirements:things in the application domain that we wish to be made true by delivering the proposedsystemMany of which will involve phenomena the machine has no access toA (Software) Specification: is a description of the behaviours that the program must have in order to meet therequirementsCan only be written in terms of shared phenomena!2University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3Starting PointGiven:a vague request for a new feature from users of your software1. Identify the problemwhat is the goal of the project?the “vision” of those who are pushing for it?2. Scope the problemGiven the vision, how much do we tackle?What new functionality will be needed?3. Identify solution scenariosGiven the problem, how will users interact with the software to solve it?4. Map onto the ArchitectureHow will the needed functionality be met?What new modules / classes will be needed?stakeholder goal modeling& domain modelsuse casesrobustness analysisUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Identifying ActorsAsk the following questions:Who will be a primary user of the system? (primary actor)Who will need support from the system to do her daily tasks?Who or what has an interest in the results that the system produces ?Who will maintain, administrate, keep the system working? (secondary actor)Which hardware devices does the system need?With which other systems does the system need to interact with?Look for:the users who directly use the systemalso others who need services from the system3University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5Key distinctionsidentify completewordsuggest wordsfrom dictionarypop up a menuhighlightmisspellingsThe user types text asusual. When the usercompletes each word, thesystem looks it up in thedictionary. If it is not inthe dictionary, the word isunderlined in red. Theuser can click on anyunderlined word, to see apopup menu of suggestedalternatives. Clicking anyof these alternativescauses it to replace theoriginal word.reduce the number of spelling mistakeswordspacedictionarysuggestionreplacementspelling selectionA requirement (goal) FunctionsA Use CaseDomain ConceptsUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6Domain ModelDocumentDictionaryWordmisspelling1..*Alphabeticcharactercorrect spellingSuggestion list1..*1..*11HasNon-Alphabeticcharacterends14University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Exploring Goalshave an automated spelling checkerreduce the number of spelling mistakessave time lookingup words inmy dictionaryhelp me learnto spell better+++++have custom dictionariesspot errorsas I writeallow me toignore mispellingssuggest correctspellingsandUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8Obstacle Analysishave an automated spelling checkersave time lookingup words inmy dictionary++Assumes: spell checker’s dictionaryis comparable with printed dictionaryfor completenessAssumes: auto-lookup & correction isquicker than manual lookupAssumes: user notices thehighlighted misspellingsAssumes: other information in dictionary(definitions, usage) is irrelevant fordeciding on correct spellingAssumes: user is willingto guess at a spellingAssumes: intended word is always(?) on the list of suggestions5University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9Additional Requirements“Functional Requirements”(?) User can see definitions for suggested spellingsability to add custom dictionariesability to add new words to a custom dictionaryability to declare certain words to be ignored for spell checking for the currentdocument“Quality Requirements”Dictionary should be as comprehensive as printed dictionariesChecking and suggesting should be fastHighlighted misspellings must be clearly visibleUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10Scoping decision IDecide the scope of the problem:E.g. Bookstore example:“Textbooks are often not ordered in time for the start of classes”But that’s just a symptom. (So you ask the manager “why?”)“Because we don’t receive the booklists from instructors early enough”Is that just a symptom of some other problem? (…so ask the instructors “why?”)“Because the instructors aren’t allocated to courses early enough”Is that just a symptom of some other problem? (…so ask the UG office “why?”)“Because we never know who’s available to teach until the last minute”Is that just a symptom of some other problem? (…so ask the dept chair “why?”)“Because there’s always uncertainty about who gets hired, sabbaticals, etc.”Is that just a symptom of some other problem? (…so ask the dept chair “why?”)“Because instructors we want to hire don’t accept our offers early


View Full Document

Toronto CSC 302 - Lecture 14 - From Requirements to Design

Documents in this Course
Load more
Download Lecture 14 - From Requirements to Design
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 14 - From Requirements to Design 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 14 - From Requirements to Design 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?