methods: deciding what to design in-young ko iko.at. icu.ac.kr information and communications...
TRANSCRIPT
Methods: Deciding What to DesignMethods: Deciding What to Design
In-Young Koiko .AT. icu.ac.kr
Information and Communications University (ICU)
Fall 2005Fall 2005ICE0575ICE0575
Lecture #2Lecture #2
Use Case Modeling IUse Case Modeling I
Fall 2005 2 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
AnnouncementsAnnouncements
Project Teams?Project Teams? Please start working on the EVRsPlease start working on the EVRs
TTA TTA “Plans and Situated Actions” “Plans and Situated Actions” Posdata Posdata “Making Use” “Making Use” Hyundai Hyundai “I Sing the Body Electronic” “I Sing the Body Electronic”
Fall 2005 3 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Picture of the Day: Picture of the Day: The SEI BuildingThe SEI Building
Fall 2005 4 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
ContextContext
Client RequirementsClient Requirements
Software DesignSoftware Design
Here aMiracle
Happens
Here aMiracle
Happens
Technical rqts
Technical rqts Architecture
Architecture
Biz, polic
, reg
Biz, polic
, reg
Usability
Usability
EngineeringEngineering
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 5 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Requirements AnalysisRequirements Analysis
Client RequirementsClient Requirements
Here aMiracle
Happens
Here aMiracle
Happens
Tech
nic
al rq
tsTech
nic
al rq
ts
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 6 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Challenges & EvidencesChallenges & Evidences In 1994, In 1994, $250 billion$250 billion in US in IT application in US in IT application
development; corresponds to development; corresponds to 175,000 projects175,000 projects 31% of projects are cancelled = $81 billion31% of projects are cancelled = $81 billion 52.7% with 187% cost overrun = $59 billion52.7% with 187% cost overrun = $59 billion 16 % are on time in 199416 % are on time in 1994 In 2003, 34 % are on time, a big improvementIn 2003, 34 % are on time, a big improvement
Challenged projects (most commonly cited): Challenged projects (most commonly cited): Lack of user inputLack of user input (13%) (13%) Incomplete requirementsIncomplete requirements (12%) (12%) Changing requirementsChanging requirements (12%) (12%) Lack of technical skill (7%)Lack of technical skill (7%) Lack of resource (6%)Lack of resource (6%) Inadequate time (4%)Inadequate time (4%)
[Standish Group International, 1994 and 2003 Surveys]
1/21/2
Fall 2005 7 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Largest software development problems by categoryLargest software development problems by categoryESPITI [1995 in Leffingwell andESPITI [1995 in Leffingwell and WidrigWidrig., ., 2000. Managing Software Requirements, p. 6-7]2000. Managing Software Requirements, p. 6-7]
Challenges & EvidencesChallenges & Evidences
0
5
10
15
20
25
30
35
40
45
50
Req. Spec. Documentation Project Man
Major problem
Minor problem
Never a problem
Req. Spec Manag. Reqs Docmt. Testing Project Man. Coding
2/22/2
Fall 2005 8 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Plan for This UnitPlan for This Unit 09/02 : Fundamentals09/02 : Fundamentals
Scoping the problem through use casesScoping the problem through use cases 09/06 : Structuring a well use case model09/06 : Structuring a well use case model 09/09 : 09/09 : External viewpoints reportsExternal viewpoints reports on understanding on understanding
client’s needsclient’s needs Make a 15 minute presentationMake a 15 minute presentation Send an Send an abstract descriptionabstract description of the main idea by 09/06 of the main idea by 09/06
Suchman: Plans and Situated Accidents Suchman: Plans and Situated Accidents TTA TTA Carroll: Making Use Carroll: Making Use Posdata Posdata Moody: I Sing the Body Electronic Moody: I Sing the Body Electronic Hyundai Hyundai
09/16 : 09/16 : Project presentationsProject presentations of technical requirements of of technical requirements of the studio projects through use casesthe studio projects through use cases
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 9 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Today’s PlanToday’s Plan
Requirement elicitation techniquesRequirement elicitation techniques Use case modeling as a requirement elicitation Use case modeling as a requirement elicitation
techniquetechnique Process centered versus problem centered Process centered versus problem centered
use case modelinguse case modeling FundamentalsFundamentals
Stakeholders, users, actorsStakeholders, users, actors Use casesUse cases Structuring use cases, relationshipsStructuring use cases, relationships ScenariosScenarios
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 10
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
OverviewOverview
Use case modeling is a technique for Use case modeling is a technique for requirement elicitationrequirement elicitation Facilitates early brainstorming of Facilitates early brainstorming of
functional requirementsfunctional requirements Can serve as a powerful tool for Can serve as a powerful tool for inter team inter team
and client communicationand client communication Helps Helps bridge business and domain specific bridge business and domain specific
concernsconcerns with software design requirements with software design requirements Provides mechanisms for Provides mechanisms for problem scopingproblem scoping
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 11
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
No Silver BulletNo Silver Bullet
There is no method suitable for all There is no method suitable for all problemsproblems
There may be alternative ways to apply There may be alternative ways to apply one method one method in different contextsin different contexts
ResourcesResources will affect the method of will affect the method of choice choice
Good toolsGood tools may become handy at even may become handy at even unexpected circumstancesunexpected circumstances
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 12
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Requirement Elicitation TechniquesRequirement Elicitation Techniques
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Ethnographic Observation and Protocol Analysis Ethnographic Observation and Protocol Analysis InterviewInterview Requirement WorkshopRequirement Workshop BrainstormingBrainstorming StoryboardingStoryboarding Use CasesUse Cases Role PlayingRole Playing PrototypingPrototyping Task AnalysisTask Analysis Contextual DesignContextual Design
Fall 2005 13
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Use Case Modeling as a Use Case Modeling as a Requirement Elicitation TechniqueRequirement Elicitation Technique
ProsPros Mechanisms to Mechanisms to separate business context separate business context
from system contextfrom system context A use case model can serve as a problem A use case model can serve as a problem
scoping scoping communication mediumcommunication medium between the between the client and the developersclient and the developers
ConsCons Tempts direct transformation of use cases to Tempts direct transformation of use cases to
user interfaces, function calls, user interfaces, function calls, and object decompositions of the systemand object decompositions of the system
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 14
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Process vs. ProblemProcess vs. Problem
First there were First there were use casesuse cases (Jacobsen (Jacobsen early 1990s)early 1990s)
Then there was Rational Approach which Then there was Rational Approach which combined with OOSE to form combined with OOSE to form Rational Rational ObjectoryObjectory (1996)…. (1996)….
Then there was use case driven, Then there was use case driven, architecture centric, iterative and architecture centric, iterative and incremental incremental Rational Unified ProcessRational Unified Process
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
1/21/2
Fall 2005 15
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Process vs. ProblemProcess vs. Problem
Use cases are very often used within Use cases are very often used within unified process driven software unified process driven software development managementdevelopment management
Use cases are invented in the context of Use cases are invented in the context of object-oriented methodologyobject-oriented methodology and and UMLUML
Yet, they are also very widely utilized as a Yet, they are also very widely utilized as a design tool isolated from the unified design tool isolated from the unified process driven approachesprocess driven approaches
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
2/22/2
Fall 2005 16
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
The Relationships Between The Relationships Between Stakeholders and Actors/Use CasesStakeholders and Actors/Use Cases
http://www.awprofessional.com/articles/article.asp?p=30162&rl=1
Fall 2005 17
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
StakeholdersStakeholders A stakeholder is someone who A stakeholder is someone who gets a benefitgets a benefit
from the outcome of software developmentfrom the outcome of software development
Identifying the stakeholders correctly helps Identifying the stakeholders correctly helps in in scoping the problemscoping the problem Asking the questions to the right peopleAsking the questions to the right people Negotiating the business case and requirements with Negotiating the business case and requirements with
the decision makersthe decision makers Different stakeholders will bring different constraints Different stakeholders will bring different constraints
which often times may contradict: financial, technical, which often times may contradict: financial, technical, long-term impact, privacy… long-term impact, privacy…
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
1/21/2
Fall 2005 18
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
StakeholdersStakeholders
UsersUsers have an added special impact as a have an added special impact as a stakeholder, we design for the usersstakeholder, we design for the users They They directly interactdirectly interact with the outcome with the outcome They may or may not be aware of (not to They may or may not be aware of (not to
mention careless) mention careless) other constraintsother constraints, e.g. time , e.g. time to shipto ship
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
2/22/2
Fall 2005 19
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
ActorsActors ActorsActors: an entity that interacts with the system: an entity that interacts with the system
The stakeholders that interact with the system influence how it The stakeholders that interact with the system influence how it may be designed may be designed
Software development is seldom from scratch, often there are Software development is seldom from scratch, often there are multiple interacting componentsmultiple interacting components where the new application is where the new application is the member of a larger collaborative scenario of multiple the member of a larger collaborative scenario of multiple applicationsapplications
Defining the actors helps define the Defining the actors helps define the boundaries of the boundaries of the systemsystem
Actors that interact with the system are Actors that interact with the system are rolesroles, i.e. , i.e. generally defined designationsgenerally defined designations, not specific people or , not specific people or instancesinstances
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
1/41/4
Fall 2005 20
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
ActorsActors
Who interacts with the system in what way may Who interacts with the system in what way may not always be easy to distinguishnot always be easy to distinguish Business use case modelingBusiness use case modeling
business actorsbusiness actors and and business use casesbusiness use cases Helps resolve conflicts later on as more constraints and Helps resolve conflicts later on as more constraints and
requirements start building uprequirements start building up Aids in separating business goals from system goalsAids in separating business goals from system goals
System use case modelingSystem use case modeling system actorssystem actors and and system use casessystem use cases
What we are eventually interested inWhat we are eventually interested in Focus is directly on the system to be builtFocus is directly on the system to be built
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
2/42/4
Fall 2005 21
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
ActorsActors Personality TypesPersonality Types: what is the relationship of : what is the relationship of
each actor to the overall systemeach actor to the overall system InitiatorInitiator External ServerExternal Server ReceiverReceiver Facilitator (Proxy)Facilitator (Proxy)
Abstract and Concrete ActorsAbstract and Concrete Actors As a rule of thumb As a rule of thumb any actor who does any actor who does not have a not have a
direct relationship with a use casedirect relationship with a use case is an abstract actor is an abstract actor The benefit of such categorizations is in The benefit of such categorizations is in structuring the structuring the
stakeholders domainstakeholders domain and fine-tuning the roles and and fine-tuning the roles and responsibilitiesresponsibilities
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
3/43/4
Fall 2005 22
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
ActorsActors
Identifying the stakeholdersIdentifying the stakeholders narrows down the narrows down the problem scope one stepproblem scope one step
Identifying the actorsIdentifying the actors narrows down the narrows down the problem scope even further and focuses on the problem scope even further and focuses on the technical aspectstechnical aspects of the problem of the problem Focus on how the system will be usedFocus on how the system will be used
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
4/44/4
Fall 2005 23
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Defining the System BoundaryDefining the System Boundary
Studio projects are defined by multiple possible pathsStudio projects are defined by multiple possible paths
System actors are not always as obvious System actors are not always as obvious
Their role in the system may change depending on Their role in the system may change depending on how the problem is scopedhow the problem is scoped
Possible Human ActorPossible Human Actor Possible System ActorPossible System Actor
TTATTA Software TestersSoftware Testers Test Scenario GeneratorTest Scenario Generator
PosdataPosdata Car DriversCar Drivers Automobile Information Automobile Information SystemSystem
HyundaiHyundai Car DriversCar Drivers Automobile Multimedia Automobile Multimedia UnitUnit
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 24
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Use CasesUse Cases
A use case is a story about some A use case is a story about some way of usingway of using a system to do something usefula system to do something useful Describe Describe what the system doeswhat the system does at a conceptual levelat a conceptual level
A use case is A use case is goal orientedgoal oriented Not necessarily functionality oriented, but Not necessarily functionality oriented, but
functionality covers a lot of the use casesfunctionality covers a lot of the use cases A use case outlines a A use case outlines a single goalsingle goal and all the and all the possible possible
things that can happenthings that can happen as the users tries to as the users tries to reach that goalreach that goal
Use cases are Use cases are not simply menu items or functionsnot simply menu items or functions
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 25
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Why Use Cases?Why Use Cases?
Elicit Elicit functional requirementsfunctional requirements with a with a focus on focus on the userthe user ““abuse” and “use-less” casesabuse” and “use-less” cases All the possible ways of using the systemAll the possible ways of using the system
Form a Form a conceptual modelconceptual model of the system of the system Bind analysis, design and testsBind analysis, design and tests Introduce traceabilityIntroduce traceability Devise architectureDevise architecture Aid creating user manualAid creating user manual
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 26
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Functional DecompositionFunctional Decomposition Example: Example: Order processing systemOrder processing system
The user perspective The user perspective place orderplace order All the above are All the above are alternative flowsalternative flows of the place order of the place order
use caseuse caseThe content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Customer
Delete Order
Change Order
Add Order Approve Order
Order Quantity
1/31/3
Fall 2005 27
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Functional DecompositionFunctional Decomposition
Cockburn view [Cockburn 2001]Cockburn view [Cockburn 2001] In principle they are separate if we take a In principle they are separate if we take a
goal centered approachgoal centered approach They may be carried out by They may be carried out by differentdifferent actors with actors with
differentdifferent requirements requirements Each represents a separate goalEach represents a separate goal
Initial requirement elicitationInitial requirement elicitation activities call for activities call for the bigger goalthe bigger goal
There is no general consensusThere is no general consensus
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
2/32/3
Fall 2005 28
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Functional DecompositionFunctional Decomposition
Decomposing the system into Decomposing the system into small, isolated small, isolated chunks of behaviorchunks of behavior is the most appealing is the most appealing At first it seems easier to attack problems as small At first it seems easier to attack problems as small
bits of behaviorbits of behavior The focus of use case modeling should be on The focus of use case modeling should be on what what
the system doesthe system does How the use cases fit togetherHow the use cases fit together should be apparent should be apparent
The user should not need to reassemble the The user should not need to reassemble the value the system is to bringvalue the system is to bring
List of features do not map one to one with use List of features do not map one to one with use casescases
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
3/33/3
Fall 2005 29
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Use Case ModelingUse Case Modeling Use case modelUse case model is the is the collection of diagramscollection of diagrams, ,
descriptions needed to represent the use cases descriptions needed to represent the use cases and actorsand actors
Use case modeling processUse case modeling process Defines the Defines the system boundarysystem boundary Finds the Finds the actorsactors Finds the Finds the use casesuse cases DescribesDescribes each use case each use case RefactorsRefactors the use case model the use case model PrioritizesPrioritizes use cases use cases AddAdds future requirements (s future requirements (change caseschange cases)) OrganizesOrganizes the use case model ( the use case model (packagespackages))
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
Fall 2005 30
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Describing a Use CaseDescribing a Use Case Tedious to do all, but is worth spending time Tedious to do all, but is worth spending time in in
early onearly on as a requirement elicitation tool as a requirement elicitation tool The The templatestemplates give guidance for the thinking give guidance for the thinking
processprocess Which Which actor(s)actor(s), use cases initiate the use case, use cases initiate the use case What are the What are the preconditionspreconditions of the use case of the use case How does the use case proceed, i.e. what are the How does the use case proceed, i.e. what are the
flow of eventsflow of events What happens once the use case is over, what are What happens once the use case is over, what are
the the post conditionspost conditions What are the What are the alternative sequences of events alternative sequences of events
(exceptions)(exceptions), what are the , what are the decision pointsdecision points that may that may lead the user into alternative pathslead the user into alternative paths
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
1/21/2
Fall 2005 31
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Describing a Use CaseDescribing a Use Case
Name:Actors:
Description:
Name:Actors:
Description:
Initial use case descriptions
Name:Actors:
Description:Sequence of Events:
Preconditions:Postconditions:
Assumptions:
Name:Actors:
Description:Sequence of Events:
Preconditions:Postconditions:
Assumptions:
Base use case descriptions
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
2/22/2
Broad descriptions of system behaviors initiated by actors
Name:Actors:
Description:Sequence of Events:
Preconditions:Postconditions:
Assumptions:
Name:Actors:
Description:Sequence of Events:
Preconditions:Postconditions:
Assumptions:
Elaborated use case descriptions
Detail descriptions of behaviors including condition logic and alternative flows
Fall 2005 32
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Use case Diagram – The UML Use case Diagram – The UML ContextContext
Concrete ActorsGeneralization
Relationship
Use Cases
Unidirectional Association
Abstract Actor
Student
Full time student
Register
Part time student
Enroll evening classes
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
1/31/3
Fall 2005 33
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Use case Diagram – The UML ContextUse case Diagram – The UML Context
Relationships• Communication • Generalization• Includes or uses• Extends
[Booch, Rumbaugh, Jacobsen (1999)The Unified Modeling Language Guide]
communication
generalization
Validate User
Check Password
Retinal Scan
Place Rush OrderPlace Order
set priority
<<extend>>
<<include>>Customer
Track Order
<<include>>
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
2/32/3
Fall 2005 34
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Use case Diagram – The UML ContextUse case Diagram – The UML Context
CommunicationCommunication The only relationship permissible between actors and use-The only relationship permissible between actors and use-
casescases GeneralizationGeneralization
Similar to parent/child relationshipSimilar to parent/child relationship The specific elements share structure and behavior with the The specific elements share structure and behavior with the
general elementgeneral element Includes/UsesIncludes/Uses
Used when a base use-case instance includes the behavior Used when a base use-case instance includes the behavior specified by another use-casespecified by another use-case
Models Models common behaviorcommon behavior among use-cases among use-cases ExtendsExtends
Used when one use-case Used when one use-case adds functionalityadds functionality onto another use onto another use case case
Extending use-case continues the activity of the starting Extending use-case continues the activity of the starting base use-casebase use-case
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
3/33/3
Fall 2005 35
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
ScenariosScenarios
Use cases describe Use cases describe abstract and general abstract and general behaviorbehavior
Use cases do Use cases do not describe what happensnot describe what happens when when a specific actor performs a specific action with a specific actor performs a specific action with specific valuesspecific values
Scenarios: specific executions Scenarios: specific executions also denoted also denoted as as use case instancesuse case instances Variations of input and output parametersVariations of input and output parameters Variations on flow of eventsVariations on flow of events
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
1/21/2
Fall 2005 36
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
ScenariosScenarios Scenarios carry use cases to a larger requirement Scenarios carry use cases to a larger requirement
elicitation contextelicitation context Validate requirementsValidate requirements Identify any unaddressed Identify any unaddressed nonfunctional requirementsnonfunctional requirements
Performance and usability commonlyPerformance and usability commonly Create a broader system prototypeCreate a broader system prototype Flow nicely into Flow nicely into test casestest cases Success and failure scenarios (Success and failure scenarios (primaryprimary and and secondarysecondary use use
cases)cases)
Scenarios can be used to Scenarios can be used to structure use casesstructure use cases Bottom up approachBottom up approach
Using scenarios Using scenarios ensures that the use case covers all of ensures that the use case covers all of the possible attemptsthe possible attempts to reach a goal to reach a goal
The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.
2/22/2
Fall 2005 37
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Benefits of Use Case Modeling to Benefits of Use Case Modeling to StakeholdersStakeholders
CustomersCustomers
customer requirements, system scope, schedule & customer requirements, system scope, schedule & budget, acceptance criteriabudget, acceptance criteria
UsersUsers
user requirements, user interactionsuser requirements, user interactions
Project ManagersProject Managers
schedule & budget, feasibility & risk analysis, schedule & budget, feasibility & risk analysis, tracking development progresstracking development progress
1/21/2
Fall 2005 38
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Benefits of Use Case Modeling to Benefits of Use Case Modeling to StakeholdersStakeholders
System ArchitectsSystem Architects
architectural requirements, technology selectionarchitectural requirements, technology selection
System DevelopersSystem Developers
design requirements, system documentationdesign requirements, system documentation
System MaintainersSystem Maintainers
guidance for system modification and evolutionguidance for system modification and evolution
Make the stakeholders be involved early Make the stakeholders be involved early in the system development effort!in the system development effort!
2/22/2
Fall 2005 39
ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University
Questions??Questions??