Requirement analysis with use case
-
Upload
rapeepan-thawornwanchai -
Category
Software
-
view
1.222 -
download
1
Transcript of Requirement analysis with use case
Agenda
The Trouble with Requirement
What is Requirement
Why requirement is so important
The challenges of requirement gathering
Issues with standard approaches
Moving to Use Cases
– Traditional modes of expressing functionality to users
– Introducing Use Cases (Diagrams and Template)
Requirement Analysis Example
Workshop
What is Requirement
A software capability needed by the user to solve a
problem to achieve an objective
A software capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or other
formally imposed documentation.
WHEN FACED WITH WHAT THEY BELIEVE IS A PROBLEM, MOST OF
ENGINEERS RUSH INTO OFFERING SOLUTIONS
Alan M. Davis
Technical people often pay more attention to an entity
relationship diagram or class diagram than a
requirement list
Questions & Doubts
Is this a desire or a requirement?
Is this a nice-to-have or a must-have?
Is this a statement of the problem or a statement
of the solution?
Is this a goal of the system or a contractual
requirement?
Do we have to program in Java? Says who?
Who is it that doesn’t like the new system, and where
was that person when we visited here before?
Function Points Probability of Termination Prior to Completion
100 6%
1,000 17%
10,000 45%
100,000 80%
Probability of Project Failure
Sources: Jones, C., Applied Software Measure: Assuring Productivity and Quality,
Second ed. McGraw Hill, 1996
Root Causes of Project Success and Failure
Standish Group asked survey respondents to identify the most significant factors that contributed to projects that were rated “success”, ”late and did not meet expectations”, and “fail”, respectively are related to requirements.
The Standish Group study noted the three most commonly cited factors that caused projects :-
To be “late and did not meet expectations” :
Lack of user involvement,
Incomplete requirements and specifications,
Changing requirements and specifications,
To be “fail” :
Unrealistic schedule or time frame,
Inadequate staffing and resources,
Inadequate technology skills,
Root Causes of Project Success and Failure
The Standish Group found that
9% of the projects in large companies were delivered
on time and on budget;
16% of the projects in small companies enjoyed a
similar success.
33% of the software projects fail;
40% of the software projects come in late or over
budget.
Root Causes of Project Success and Failure
What were the primary “success factors” for those
projects?
According to the Standish study, the three most
important factors were.
User involvement
Executive management support
Clear statement of requirements
It seems clear that requirements deserve their place
as a leading root cause of software problems.
Coding issues were a “nonproblem”
Why requirement is so important
Without requirements, there is no way to
validate a program design; that is, no way to
logically connect the program to the customer’s
desires.
BENJAMIN L. KOVITZ
Why is requirement management
important?
Requirements errors top the delivered defects and
contribute approximately one third of the total
delivered defects to the defect pile.
Requirements errors are likely to be:-
the most common class of error.
the most expensive errors to fix.
The High Cost of Requirements Errors
Two reasons for requirement errors turn out to be
particularly expensive,
1. The true nature of the error may be disguised;
everyone assumes that they’re looking for design errors
during the testing or inspection activities, and
considerable time and effort may be wasted.
2. By the time the requirements-oriented error is
discovered, the development group will have invested
time and effort in building a design from those erroneous
requirements or reworked.
The High Cost of Requirements Errors
Confirming the details of the requirements error
means tracking down the user who provided the
requirements details in the first place.
These problems associated with “leakage” of
defects from one lifecycle phase to the next are fairly
obvious when you think about them, but most
organizations haven’t investigated them very
carefully.
% of discovered the
requirements-oriented defects
Phase % of
discovered
Requirement Analysis 74%
Preliminary Design 4%
Detailed Design 7%
Coding and Testing 11%
Maintenance 4%
% of discovered the
requirements-oriented defects
Requirement Analysis phase
is the formal phase during which customers and systems analysts are
discussing,
brainstorming,
negotiating, and
documenting the project requirements.
is the ideal time and place to discover such errors, and it’s likely to be the most inexpensive time and place.
Example costs to repair the defect
Respecification.
Redesign.
Recoding.
Retesting.
Change Requests.
Corrective action.
Scrap
Code, Design, Test cases that had to be thrown away when they were based on incorrect requirements.
Recall of defective versions of shrink-wrapped software and associated manuals from users.
Warranty costs.
Product liability
If the customer sues for damages caused by the defective software.
Service costs for a company representative to visit a customer’s
field location to reinstall the new software.
Documentation.
Overview of problem/solution domains
Needs
Features
Software Requirement
Problem
Domain
Solution
Domain
What
How What
How
The Problem Domain
Most successful requirement journeys begin with a trip
to the land of the problem.
Problem domain is the home of real users and other
stakeholders, people whose needs must be
addressed in order for us to build the perfect system.
Stakeholder Needs
To build systems that meet user needs, it becomes our problem
to understand
their problems
their culture and
their language.
It is our responsibility to understand the needs of users and
other stakeholders whose lives will be affected by our solution.
As we elicit those needs, we’ll stack them in a little pile called
stakeholder needs, which we represent as a pyramid.
Needs
Moving the problem domain
toward the solution domain
In this solution space, we focus on defining a solution
to the user’s problem.
This is the domain of computers, programming,
operating systems, networks, and processing nodes.
Here, we can apply the skills we have learned much
more directly
Features of the System
Features of the system as
A service that the system provides to fulfill one or more
stakeholder needs.
This is not a very long list and consists of such items
as
“The car will have power windows.”
“Defect-trending charts will provide a visual means of
assessing progress.”
“Web-enabled entry of sales order.”
Features of the System
Features of the system are
simple descriptions,
in the user’s language,
used as labels to communicate with the user how our system addresses the problem.
These labels will become part of our everyday language, and much energy will be spent in
defining them,
debating them, and
prioritizing them.
Software Requirements
After the feature set has been established gained agreement with the customer, we can move on to defining the more specific requirements that we will need to impose on the solution.
These more specific requirements are the software requirements.
We also note that these appear pretty far down on the pyramid,
If we build a system that conforms to those requirements, we can be certain that they system we develop will deliver the features we promised.
Typical Way of Getting Off Track
with Requirement
Design consideration
Vagueness
The use of computer industry language
Not relating to the business goals
Example of Requirement List
ระบบสามารถจัดเก็บขอ้มลูการท า Transaction ของลกูคา้ได ้
ระบบสามารถจ ากดัสทิธิใ์นการเรยีกดรูปูภาพและขอ้มลูผา่นระบบ dial-in
The system must maintain a list of current, open work processes and identify the
work process to be executed and the workflow queue for the process. When
particular documents are scanned, the system will determine whether there is a
process open for that SSN. If there is an open process, the system will route the
document to the appropriate workflow queue, display the work process script, and
highlight the current work process.
The Challenges of Requirements
Gathering
Finding out what the users need
Documenting users’ needs
Avoiding premature design assumptions
Resolving conflicting requirements
Eliminating redundant requirements
Reducing overwhelming volume
Ensuring requirement traceability
Moving to Use Case
M anage O rder
M anage C ustom er R egister
O rder A dm inistrator
E xecute O rder
M anage A rticles
S tore A dm inistrator
Prototype were long to be elixir for good requirements capture, but now we
realize that they can help much more with proof-of-concept
Diagrams
A diagram is a view into a model
Presented from the aspect of a particular stakeholder
Provides a partial representation of the system
Is semantically consistent with other views
In the UML, there are nine standard diagrams
Static views: use case, class, object, component,
deployment
Dynamic views: sequence, collaboration, state chart,
activity
Introducing Use Cases
Two people see a motorcycle in two ways: as the
subsystems that make up the bike and as the
things a person can do with the bike
The Goals of Use Cases
Accountant
Enter Order Details
Account Manager
View Customer Portfolio
Interactions that provide value to Actors
The Goals of Use Cases
No Implementation-Specific Language
Specific people (instead of roles)
Specific department in the organization
User Interface widget (button, menu navigation, etc.)
Assumption about where the work is being done physically
IF-THEN-ELSE statement in use case text
The use of any kind of constraint language
User-appropriate level of detail
Start in general before jumping to the details
Use case always be in user’s vocabulary
User-appropriate volume
– Very large system should have no more than 70 to 80 use cases
The Use Case Template
Use Case Name:
Summary:
Basic Course of Events:
Alternative Paths:
Exception Paths:
Triggers:
Assumptions:
Preconditions:
Postconditions:
Relate Business Rules:
Author:
Date:
Use Case Name/ID#
Use Cases are numbered according to subsystem. Use the
format XXX-###, where XXX is the subsystem acronym, and
### is always three digits and starts at 001.
Use Case Domain/Package
Actors
List the actors who require or interact with this use case.
Description
Describe the use case (1-2 paragraphs).
Preconditions
Describe the conditions assumed to be true before the use case
begins.
Postconditions
Describe the conditions assumed to be true after the use case
ends.
Relationships with other Use Cases
Include
Extend
Main Flow (Main Success Scenario)
Describe the normal flow of events for this use case. Use a
hierarchical numbering system. Do not put too many
requirements in a single numbered requirement. Always use
subject-verb-object for consistent sentence structure, as in “The
system shall verify the customer code”. Use a future tense while
describing requirements.
Alternate Flows
Describe the different ways the interaction described in the Main
Flow above can be carried out. Relate back to specific points in
the Main Flow. As well, the Main Flow should contain a
reference forward to the Alternate Flow List each variation on
the use case as a separate sub section of the Alternate Flows as
A1, A2. Don’t be too concerned if you can’t decide if something
is an Alternate or Exception Flow (below), just use your own
discretion.
Exception Flows
List each error condition as a subsection of the Exceptional Flow.
As with the Alternate Flows, exceptions may refer back to steps
within the Main Flow or they may refer to events that aren’t
specific to a single step.
Architecturally Significant
Indicate Yes or No. Architecturally significant could mean any of
the following - a lot of users using this use case, high concurrency
for users hitting this use case, data-fetching or data displaying
issues. If in doubt, indicate it as “Architecturally Significant” and
then review it with the Software Designer
Supplemental Documentation
Activity Diagram, Decision Table/Tree and State Diagrams may
be given as an easy to understand explanation of the Main,
Alternate or Exception Flows
Traceability => Clarify of linkage
between artifacts
Traceability => Provide assurance that the
software at the end of lifecycle matched
what the stakeholders stated they want
Team member
change
Stakeholder needs
change during
lifecycle
Traceability is hard
Things are passed
from team to team,
not hands-on
knowledge
Delivery cycle is too
long, and get off
track
Linkage is not easy
between artifacts
Analysis Model
Design Model Test Model
Test Plan
Test Scenario
Test Cases
User Interface
Design
Application Architecture
Project Management
Documentation
and Training
Product Marketing
Security Profiles
Release Planning
Use Cases
Classic Mistakes
Perspective
Creating inside-out use case, Including user interface details, Expanding the system boundary
Thriftiness
Skipping interview notes that don’t fit, Holding on to use case that don’t belong
Messiness
– Keeping temporary requirement lists, Grouping use cases poorly, Having use case without an owner, Having use case with too many owners, Including too many cross-reference in use case text, Not keeping use cases in database, trying to build extensive exception into basic course of events
Classic Mistakes
Over-engineering
– Neglecting useful tools within use case, Using computer terminology in use cases, Writing pseudocode for use case text, Assuming that the extend relationships between use cases dictate class inheritance in design, Confusing actors with specific people or organization positions, Putting everything into one use case diagram/one use case, Using IF-THEN-ELSE, Creating hierarchy of use cases.
Mismanagement
– Allowing an imbalance between experience and inexperience, Packaging use cases too late, Using packages to hide complexity that you’re trying to avoid.
Context
– Confusing include, extend, Confusing precondition and assumption