1. Software Requirements
Software Requirements

2. SWEBOK KAs covered so far
Today’s topic
Software Requirements
Software Design
Software Construction
Software Testing
Software Maintenance
Software Configuration Management
Software Engineering Management
Software Engineering Process
Software Engineering Models and Methods
Software Quality
Software Engineering Professional Practice
Software Engineering Economics
Computing Foundations
Mathematical Foundations
Engineering Foundations

3. Iterative Development Process
Requirements
Planning
Implementation
Analysis
Design
Deployment
Testing
Evaluation
Initial Planning
We are here

4. Problems Need to figure out what customer wants
Not make false/incorrect assumptions
Need to chunk work into bite-sized pieces
So work can be divided up
So system can be built incrementally
So estimates are remotely accurate

5. XP planning practice: User stories (USs)
“Plan using units of customer-visible functionality.”
Quote from Kent Beck’s Extreme Programming Explained (2005).

6. Flight-Booking System Example
Two parts: title and description

7. User Story Dos and Don’ts
USs should …
USs should not …
describe one thing that the software needs to do for the customer
be written using language that the customer understands
be written by the customer (figuratively speaking)
be short. Aim for no more than three sentences
be a long essay
use technical terms that are unfamiliar to the customer
mention specific technologies
Principle: Keep requirements customer-oriented

8. Helpful US-Description Template
Template: “As a <who>, I want <what> <why>.”
Can be rearranged as long as it includes who, what, why
Example: “As a dog, I want to order food online, so I don’t have to rely on people anymore.”
“Why” is optional, but helpful
Don’t be afraid to have multiple whos, each with their own why

9. US-Description Examples: Who and What

10. Helpful US-Title Template: Verb + Noun

11. Let’s write some user stories!
“As a <who>, I want <what> <why>.”

12. How to create “good” user stories
How to create “good” user stories? The guidelines are necessary, but not sufficient Given the “soup” of requirements, which should be USs? How “big” should a US be?

13. Independent: No US depends on another
INVEST* can help!
User stories should be
Independent: No US depends on another
Negotiable: Can be changed or rewritten
Valuable: Have value to customer
Estimable: Can estimate how long to implement
Small: Bigger = harder to estimate/plan
Testable: Must be clear how to test based on description
* Originally from

14. Recommendation: Focus on these three
Independent: No US depends on another
Valuable: Have value to customer
Small: Bigger = harder to estimate/plan
Applying these is an art – let’s discuss using your USs

15. Example US: Manage (CRUD) Quizzes
Should “Create Quiz”, “Update Quiz”, and “Delete Quiz” be separate USs?
Provide rationale based on I-V-S
Independent, Valuable, Small
I would say “yes”
Although they may seem dependent to a user, they can be implemented independently
Each is of value (I suppose)
Size seems good for estimating/planning

16. Example US: Take Quiz Should “Choose Category” be separate US?
Should “Choose Difficulty” be separate US?
Should “Earn Coins” be separate US?
Provide rationale based on I-V-S
Independent, Valuable, Small
These are pretty debatable
Are these really of value by themselves?
And do they really depend on Take Quiz?
But does putting them together make the story too big?
Making such assessments is an art!

17. Types of Requirements Functional: What does the system do?
Features and capabilities
USs mainly capture
Use Cases also capture
Non-functional: How well does the system do it?
Sometimes called the “ilities”
Record as natural language specifications

18. Common Non-Functional Requirements
Usability: learnability, efficiency (user), memorability, errors (user), satisfaction
Reliability: frequency of failure, recoverability, predictability
Performance: response times, throughput, accuracy, availability, resource usage
Supportability: adaptability, maintainability, internationalization, configurability
Functional + these = “FURPS”
(Memorize it!)

19. Create USs & natural-language specs
Putting It Together
Create USs & natural-language specs
Create domain model
Requirements
Planning
Implementation
Analysis
Design
Deployment
Testing
Evaluation
Initial Planning

20. What’s next?

21. Appendix: Sampling of User Stories from Recipe/Restaurant Web App Example
Title: Suggest Recipe
Description: As a frequent eater, I want to suggest a popular recipe so that other people can easily find a good one.
Title: Provide Menu
Description: As a restaurant manager, I want to post menus/items, so I can attract customers.
Title: Share/Like Menu Items on Facebook(R)
Description: As a user I want to share or like menu items on Facebook(R), so that my friends will get to enjoy things I think they’ll like.
As a restaurant manager, I want users to be able to share/like my menu items on Facebook(R), so I get more business $$$.