The important of requirement analysis before jump to the software solution. This can prevent project failure and increase user's satisfaction.

1. REQUIREMENT ANALYSIS WITH USE CASE
By Rapeepan Thawornwanchai
Nov 26, 2010

2. 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

3. What is Requirement
A software capability needed by the user to solve a problemto 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.

4. WHEN FACED WITH WHAT THEY BELIEVE IS A PROBLEM, MOST OF ENGINEERS RUSH INTO OFFERING SOLUTIONSAlan M. Davis
Technical people often pay more attention to an entity relationship diagram or class diagram than a requirement list

5. The Goal
To develop quality software that meets customers’ real needs.
on time and
on budget

6. 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?

7. 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

8. 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,

9. 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.

10. 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”

11. Why requirement is so importantWithout 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

12. Why is requirement managementimportant?
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.

13. 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.

14. 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.

15. % of discovered therequirements-oriented defects
Phase
% of discovered
Requirement Analysis
74%
Preliminary Design
4%
Detailed Design
7%
Coding and Testing
11%
Maintenance
4%

16. % of discovered therequirements-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.

17. 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.

18. Overview of problem/solution domains
Needs
Features
Software Requirement
Problem
Domain
Solution
Domain
What
How
What
How

19. The Problem Domain
Most successful requirement journeys begin with a trip to the land of the problem.
Problem domain is the homeof real users and other stakeholders, people whose needs must be addressed in order for us to build the perfect system.

20. 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

21. Moving the problem domaintoward 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

22. 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.”

23. 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.

24. 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.

25. Typical Way of Getting Off Track with Requirement
Design consideration
Vagueness
The use of computer industry language
Not relating to the business goals

26. 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.

27. 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

28. Moving to Use Case
Manage OrderManage Customer RegisterOrder AdministratorExecute OrderManage ArticlesStore Administrator

29. Traditional Modes

32. Prototype were long to be elixir for good requirements capture, but now we realize that they can help much more with proof-of-concept

33. 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

34. 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

35. The Goals of Use Cases
Accountant
Enter Order Details
Account Manager
View Customer Portfolio
 Interactions that provide value to Actors

36. 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

37. Use Case is SMART
Specific
Measurable
Assignable
Realistic
Testable

38. Use Case Diagram

39. Photographer
Photographer

41. 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:

42. 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.

43. 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.

44. 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.

45. 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

48. Requirement Traceability

49. Traceability => Clarify of linkage between artifacts
Traceability => Provide assurance that the software at the end of lifecycle matched what the stakeholders stated they want

50. Team member changeStakeholder needs change during lifecycleTraceability is hardThings are passed from team to team, not hands-on knowledgeDelivery cycle is too long, and get off trackLinkage is not easy between artifacts

51. Analysis ModelDesign ModelTest ModelTest PlanTest ScenarioTest CasesUser Interface DesignApplication ArchitectureProject ManagementDocumentation and TrainingProduct MarketingSecurity ProfilesRelease PlanningUse Cases

52. 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

53. Classic Mistakes
Over-engineering
–Neglecting useful tools within use case, Using computer terminology in use cases, Writing pseudocodefor 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