Software Requirements http://flic.kr/p/6sdZDR Software Requirements

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

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

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

XP planning practice: User stories (USs) “Plan using units of customer-visible functionality.” Quote from Kent Beck’s Extreme Programming Explained (2005). http://flic.kr/p/884GBP

Flight-Booking System Example Two parts: title and description

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

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

US-Description Examples: Who and What

Helpful US-Title Template: Verb + Noun

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

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?

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 http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

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

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

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!

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

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!)

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

What’s next? http://flic.kr/p/aCLor3

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