Software Requirements http flic krp6 sd ZDR SWEBOK

Software Requirements http: //flic. kr/p/6 sd. ZDR

SWEBOK KAs covered so far 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Software Requirements Today’s Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Process Software Engineering Models and Methods Software Quality Software Engineering Professional Practice Software Engineering Economics Computing Foundations Mathematical Foundations Engineering Foundations topic

Iterative Development Process qu Initial Planning ire Pla men nn ts ing ion a v E t a lu An Re De aly Im sig sis pl n em en ta tio n We are here Tes ting Deployment

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. ” http: //flic. kr/p/884 GBP

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? The guidelines are necessary, but not sufficient Given the “soup” of requirements, which should be USs? How “big” should a US be?

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: //xp 123. 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!)

Putting It Together ion a v E t a lu Create domain model An De aly Im sig sis pl n em en ta tio n Initial Planning Create USs & naturallanguage specs Re qu ire Pla men nn ts ing Tes ting Deployment

What’s next? http: //flic. kr/p/a. CLor 3

Appendix: Sampling of User Stories from Recipe/Restaurant Web App Example Title: Provide Menu Description: As a restaurant manager, I want to post menus/items, so I can attract customers. 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: 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 $$$.