
Analysis. Stakeholders Business goals System functions Technical system requirements Fundamental domain concepts and relationships Domain algorithms Domain level state behavior application behavior, look and feel. Define. Requirements Artifacts.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Business goals
System functions
Technical system requirements
Fundamental domain concepts and relationships
Domain algorithms
Domain level state behavior
application behavior, look and feel
Define
Requirements ArtifactsInformation Needed Information Representation
An actor is an external entity that interacts with the system
Decision Support
Frequency:{How often will this use of the system occur? This field is combined with the criticality field to determine the number of tests that will be used to test the functionality. It may also be used in certain design decisions.}
Criticality:{How necessary is this use to the successful functioning of the program from a user’s perspective. This field is used to assist in determining the extent to which the use will be tested.}
Risk:{The project risk associated with providing this use. This is used in project planning. Often riskier uses will be implemented early to provide sufficient recovery time.}
---------------------------------------------------------------------------------------------------------------------
Modification History -- {Follow the standard corporate document versioning template}
Owner:
Initiation date:
Date last modified:
*
Test case 1
Instance 1
Basic Course
...
...
Test case n
Instance n
Test case n+1
Instance n+1
Alternative 1
Use Case
...
...
Test case n+m
Instance n+m
Alternative 2
Test case n+m+1
Instance n+m+1
...
...
Test case n+m+j
Instance n+m+j
...
...
...
*
A use case instance is often called a scenario
Identifying a complete set of actors means I will capture
all of the user’s viewpoints
What if the actors don't understand the true business needs?
What if the development team misunderstands the use cases?
Never assume the client knows and
can articulate real business needs
UC 1
UC1.1 UC1.2 UC1.3 UC1.4 UC1.10
UC1.1.1 UC1.1.2 UC1.1.3 UC1.10.1
UC 1.1.1.1 UC1.1.1.2 UC1.1.1.3 UC1.10.1.1
UC 2 UC3
UC2.1 UC2.2 UC2.3 UC2.4 UC2.10
UC2.1.1 UC21.1.2 UC2.1.3 UC2.10.1
UC2.1.1.1 UC2.1.1.2 UC2.1.1.3 UC2.10.1.1
UC 1 - customer makes purchase
UC 1.1 - scan UPC
UC 1.2 - add tax
UC 1.3 - calculate total
UC 1.4 - accept payment
UC 1.5 - make change
1. Define course policies
1.1 Define late policy
1.2 Define category weights
Use case 1.1 is a specific, more detailed, complete use case within the
category of use cases defined by use case 1.
Most OO teams incorrectly think the first level of use cases should jump
directly to interface specifications.
1
Accept Payment
Electronic Cash
1
This is the idea of essential use cases - see bibliography
Use Cases
architecture
Interface
System
Abstract use case
Complete use case
Essential use case
Partial use case
High-level use case
System-level end-to-end use case
Functional sub-use case
Types of Use Cases1
1
Larry Constantine, p70
Sue inserts $1.00, selects and recieves a diet coke and $0.15 change
?
How does one test for extensibility?
Case Study
If use cases misused
then
Architecture team realized they would need to understand
the scope of the requirements
For
Articles Regarding Use Cases
and E-Mail Updates
register at
http://www.korson-mcgregor.com/usecase.htm
Domain
Analysis
Step
Gain initial understanding of application requirements
Determine domain limits
Identify domain actors and their basic interactions with domain
Determine the activities of interest within the domain
Identify key concepts in domain
Clarify meaning of domain key concepts
Determine static relationships between all key domain objects
Record standardized dynamic behavior
Record domain algorithms
Summarize knowledge of domain
Deliverable
Initial problem statement
Domain Dimensions and Change Cases
Use Case Diagram
Domain activities (Domain-level use-cases)
List of classes
Class description cards
Domain class diagram
State transition diagrams
Sequence diagrams
Domain digest
The biggest problems in software development
have to do with requirements, not technology!
Case Study: SEI Lecture Series – radar signal processing
Case Study: The use case calls for an accountant to be able to print a journal
Case Study: NASA, Ease of bringing new employees up to speed
.
Phases
Core Workflows
Inception Elaboration Construction Transition
Requirements
Analysis
Design
Implementation
Test
Preliminary iteration(s)
Itr. #1
Itr. #2
Itr. #n
Itr. #n+1
Itr. #n+2
Itr. #m
Itr. #m+1
Iterations
*Figure 11.2 page 296 “The United Software Development Process, Jacobson, Booch, Rumbaugh
Phases
Core Workflows
Inception Elaboration Construction Transition
Requirements
Analysis
Includes both domain analysis and use case development
Adds detail and structure to the requirements deliverables
Unfortunately, in the original RUP book, domain analysis is viewed as optional.