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 13: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. 2What do Requirements Analysts do?Starting pointSome notion that there is a “problem” that needs solvinge.g. dissatisfaction with the current systeme.g. a new business opportunitye.g. a potential saving of cost, time, resource usage, etc.A Requirements Analyst is an agent of changeThe requirements analyst must:identify the “problem” / “opportunity”Which problem needs to be solved? (identify problem Boundaries)Where is the problem? (understand the Context/Problem Domain)Whose problem is it? (identify Stakeholders)Why does it need solving? (identify the stakeholders’ Goals)When does it need solving? (identify Development Constraints)What might prevent us solving it? (identify Feasibility and Risk)How might a software system help? (collect some Scenarios / Use Cases)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. 3D - 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!University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Starting 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 analysis3University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5Identifying 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 systemUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6Key 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 Concepts4University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Domain ModelDocumentDictionaryWordmisspelling1..*Alphabeticcharactercorrect spellingSuggestion list1..*1..*11HasNon-Alphabeticcharacterends1University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8Exploring 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 misspellingssuggest correctspellingsand5University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9Obstacle 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 suggestionsUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10Additional 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 visible6University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use
View Full Document
Unlocking...