Requirements
Outline
•
•
•
•
1
Definition
Requirements Process
Requirements Documentation
Next Steps
Definition
• Recall that Requirements is the first
step in the software engineering
process
Requirements
Design
• Requirements state the purpose of
the software system
Implementation
Testing
Deployment
2
Definition
• Requirements state the purpose of the software system
• Extremely useful for:
•
•
•
•
3
Communicating with customers
Communicating with co-workers
Keeping track of what needs to get done
Helping you and the customer decide what really needs to get done
Definition
Good requirements are:
• Correct
• Consistent
• Unambiguous
• Complete
4
• Feasible
• Relevant
• Testable
• Traceable
Standish survey (1994)
• 350 companies surveyed
• 8000 software projects
• 31% cancelled before finished
• 9% delivered on time and within budget (large companies)
• 16% delivered on time and within budget (small companies)
5
Standish survey (1994)
• Top factors for failed software projects:
1.
2.
3.
4.
5.
6.
7.
8.
6
Incomplete requirements (13.1%)
Lack of user involvement (12.4%)
Lack of resources (10.6%)
Unrealistic expectations (9.9%)
Lack of executive support (9.3%)
Changing requirements and specifications (8.7%)
Lack of planning (8.1%)
System no longer needed (7.5%)
Outline
•
•
•
•
7
Definition
Requirements Process
Requirements Documentation
Next Steps
Requirements Process
Elicitation
Analysis
Specification
Validation
Software
Requirements
Specification
(SRS)
8
Requirements Process
• Elicitation
• Collecting the user’s requirements
• Analysis
• Understanding and modeling the desired behavior
• Specification
• Documenting the behavior of the proposed software system
• Validation
• Checking that our specification matches the user’s requirements
9
Requirements Process: Elicitation
• Critical part of requirements process
• Variety of techniques to determine what customers want
• Rarely as simple as “asking the right questions”
• Communication gap between engineers and customers
• Engineers don’t know business jargon
• Customers don’t understand computer science jargon
10
Requirements Process: Elicitation
• Know your stakeholders:
• People who have something to contribute to the requirements
• Has particular view(s) of how system should work
• Example stakeholders:
•
•
•
•
•
11
Clients: paying for the software development
Customers: buy software after developed
Domain experts: familiar with problem
Software engineers: technical feasibility of problem
Market researchers, lawyers, auditors…
Requirements Process: Elicitation
• How to gather requirements:
•
•
•
•
•
Interview stakeholders (individually and in groups)
Review available documentation and standards
Observe current systems (if available)
Observe manual processes
Brainstorm with future users
• Requires interpersonal skills!!!
12
Requirements Process: Elicitation
• Robertson & Robertson model for requirement sources
stakeholder
wants and
needs
current
organizations
and systems
existing
documents
13
domain models
current
situation
model
elicit
requirements
suggested
requirements
reusable
requirements
14
Requirements Process: Analysis
• “Understanding and modeling the desired behavior”
• Transforming elicited requirements into specifications…
• Types of requirements:
• Functional requirements
• Nonfunctional requirements
15
Requirements Process: Analysis
• Functional requirements
• Required behavior of software system
• Reactions to inputs
• State before / after events
???
16
Requirements Process: Analysis
• Nonfunctional requirements
• Quality characteristic of software
• How “well” the system works
•
•
•
•
17
Ease of use
Response time
Reliability
Maintenance
Requirements Process: Analysis
• Conflict resolution is part of requirements analysis
• With multiple stakeholders, conflicts bound to occur
• Opinions on what requirements should be
• One way to resolve: prioritize requirements
1.
2.
3.
18
Essential?
Desirable?
Optional?
Requirements Process: Specification
• “Documenting the behavior of the proposed software system”
1. Requirements definition
What software system should do
2. Requirements specification
How software system will work
19
Requirements Process: Specification
• Requirement definition
•
•
•
•
•
Role of the system
External
From perspective of client, user, or business
Non-technical in nature
Treats software system as “black box”
• Inputs and outputs only
• Doesn’t care what’s inside
?
20
Requirements Process: Specification
• Requirements specification
•
•
•
•
•
21
How the system works
Internal
Perspective of software engineer
Technical in nature
Inside the “black box”
Break Time!!!
22
Outline
•
•
•
•
23
Definition
Requirements Process
Requirements Documentation
Next Steps
Requirements Documentation
• Typical parts of Requirements Document
• Functional requirements
• Behavior of the software system
• Nonfunctional requirements
• Quality characteristics of software system
• Diagrams
• (more on this next time..)
24
Functional Requirements Documentation
• Unstructured: more general
• Requirement definitions
• Requirement specifications
• Structured: more formal and precise
• Use cases describe ways to “use the system”
• Each use case “like a bundle of scenarios”
• All the same except minor details
25
Use Case
• Name: Succinct and meaningful
• Actor: Who “does” the activity?
• Preconditions: What is true before the activity?
• Postconditions: What is true after the activity?
• Flow of events: What steps to the actor and system perform
during the scenario?
26
Use Case #1: “Report Avalanche”
• Name: Report Avalanche
• Actor: backcountry skier with avalanche reporting app
• Preconditions:
• Skier has cell phone service
• Skier reports avalanche using app
• Postconditions:
• System has recorded avalanche event, location, and time of day.
27
Use Case #1: “Report Avalanche” (cont.)
• Flow of events:
• User reports avalanche using Smartphone app
• System retrieves avalanche event
• System parses avalanche location and time of day
• If location and time unknown, system asks user for more information
• (use case #2)
28
Use Case #2: “Clarify Location and Time”
• Name: Clarify Location and Time
• Actor: backcountry skier with avalanche reporting app
• Preconditions:
• Skier sent information without location and time
• Postconditions:
• System updates avalanche event’s location and time of day.
• Flow of Events:
• System contacts user, asks to update location and time of avalanche
• User estimates the location and time of reported avalanche
• System receives updated location and time, updates avy info
29
Use Case Diagrams
Use Case #1:
Report
Avalanche
Use Case #2:
Clarify Location
and Time
backcountry skier
30
Use Case #1:
Report
Avalanche
Use Case #2:
Clarify Location
and Time
backcountry skier
Use Case #3:
View Recent
Avalanche Activity
31
avalanche forecaster
Use Case #3a:
View by Time
Use Case #3b:
View by Location
Requirements Documentation
• Typical parts of Requirements Document
• Functional requirements
• Behavior of the software system
• Nonfunctional requirements
• Quality characteristics of software system
• Diagrams
• (more on this next time..)
32
Nonfunctional Requirements Documentation
• Define quality characteristics of software system
• Describe “how well” the system should function
• Can be written as unstructured text
• Often written in terms of fit criteria
• How good does the system need to be?
• Fit criteria should not be imagined, but based on client needs
33
Nonfunctional Requirements Documentation
• Typical quality characteristics:
•
•
•
•
•
34
Reliability
Efficiency
Integrity
Usability
Maintainability
•
•
•
•
•
Testability
Flexibility
Portability
Reusability
Interoperability
Requirements Documentation
• Typical parts of Requirements Document
• Functional requirements
• Behavior of the software system
• Nonfunctional requirements
• Quality characteristics of software system
• Diagrams
• (more on this next time..)
35
Diagrams (preview)
• Use case diagram
• Shows supported activities
• UML class and entity-relationship diagrams
• Shows entities, attributes, and relationships
• Dataflow diagram
• Shows flow of information
• Message sequence diagram
• Shows flow of control
• State chart
• Shows change over time
36
Outline
•
•
•
•
37
Definition
Requirements Process
Requirements Documentation
Next Steps
Next Steps…
• Meet your “customer” today
• Start with obtaining use cases
• Homework 1 is due soon…
• Next time: Notation
38