Software Requirements

Slides:



Advertisements
Similar presentations
Introducing User Stories
Advertisements

TDT 4242 Inah Omoronyia and Tor Stålhane Agile requirements through user stories and scenarios TDT 4242 Institutt for datateknikk og informasjonsvitenskap.
Chapter 05: Evolutionary Requirements Definition : Requirements  “Requirements are capabilities and conditions to which the system, and more broadly.
Objects First With Java A Practical Introduction Using BlueJ Designing object-oriented programs How to write code in a way that is easily understandable,
SE 555 Software Requirements & Specification Requirements Quality Attributes.
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
Slide 1 Requirements Workflow. Slide 2 The Phases/Workflows of the Unified Process Figure 3.1 l Phase is Business context of a step Workflow is Technical.
System Implementation
Chapter 1 The Systems Development Environment
Chapter 1 The Systems Development Environment
Chapter 4 Agile Development
Chapter 4 – Requirements Engineering
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1Welcome! Rational Requirements Management.
INFO 637Lecture #51 Software Engineering Process II Defining Requirements INFO 637 Glenn Booker.
Planning Game in Artifacts Tracker (AT) Project Michal Pilawski.
Question To know that quality has improved, it would be helpful to be able to measure quality. How can we measure quality?
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
Software Testing and Quality Assurance Software Quality Assurance 1.
Coming up: The Manifesto for Agile Software Development 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 3 Agile Development Software Engineering:
Software Engineering Saeed Akhtar The University of Lahore Lecture 5 Originally shared for: mashhoood.webs.com.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
AGILE XP AND SCRUM © University of LiverpoolCOMP 319slide 1.
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
Agile Requirements Introducing User Stories. Key Principles for Agile Requirements Active user involvement is imperative Agile teams must be empowered.
Software Engineering 2004 Jyrki Nummenmaa 1 Why new software methodologies The classic waterfall-model based techniques are strongly based on the.
CS 4500: Software Development Software Process. Materials Sommmerville Chapters 1, 2 and 3 Software Cycle and Models:
 System Requirement Specification and System Planning.
Embedded Systems Software Engineering
Chapter 5 Agile Development Moonzoo Kim KAIST
TK2023 Object-Oriented Software Engineering
Chapter 2 Object-Oriented Paradigm Overview
User Stories > Big and Small
Requirements Engineering Lecture 4
Appendix B Agile Methodologies
Software Engineering Process
Software & Software Engineering Pertemuan-4 Dosen :Kundang K Juman
CMPE 280 Web UI Design and Development August 29 Class Meeting
Evolutionary requirements
(Professional Business Analyst Training organisation)
Source & Courtesy: Doc. S. Dapkūnas
Software Engineering: A Practitioner’s Approach, 7/e Chapter 3 Agile Development copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Software Requirements
Software Engineering Process
Software Engineering: A Practitioner’s Approach, 6/e Chapter 4 Agile Development copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Usability engineering
Taking an Iteration Down to Code
HCI in the software process
Introduction to Software Engineering
Summarizing Our Models to Date
Chapter 2 Software Processes
Requirements Analysis
Introducing ISTQB Agile Foundation Extending the ISTQB Program’s Support Further Presented by Rex Black, CTAL Copyright © 2014 ASTQB 1.
HCI in the software process
Software Requirements
HCI in the software process
Software Engineering Process
Planning and Estimation.
Software Requirements
COMP444 Human Computer Interaction Usability Engineering
Domain Modeling.
Extreme Programming.
Human Computer Interaction Lecture 14 HCI in Software Process
Scrum in Action.
Software Requirements
Software Requirements
Cognitive Walkthrough
Software Engineering Process
Planning and Estimation.
Presentation transcript:

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