6 Epic – Too Complex or Big or no INVEST Functional Requirement Story (Product or Sprint) Backlog Item INVEST 100% Task – Too Easy or Too Small (or trivial technical labor)
7 a) May state what (reactions, behaviours, or services) the system should not do. b) services the system should provide, c) how the system should react to particular inputs, and d) how the system should behave in particular situations. Functional Requirement
9 § Independent – loosely coupled with one another § Negotiable – Stories are what and why , not how ( 99% ). § Valuable – for the customer! § Estimatable – Effort/Cost of design, build, and test. § Small (sized appropriately) § Testable – pass or fail INVEST in good requirements
10 § Can someone do this and integrate it later into the main project? § Do we all understand what this is? § Is this important for the customer? § Can we estimate the cost of this (complexity, LOC, effort, or time)? § Is this appropriate for a Sprint (period of time)? § Do we know how to test it and prove it is complete? INVEST in good requirements
13 § Search option given to user to search from various invoices. § User should be able to mail any report to management. § Users can be divided into groups and groups can be given separate rights. Examples What about • A video game? • Canvas? • Facebook App?
27 Reference Read: Wettel, R. & Lanza, M. (2007). Visualizing Software Systems as Cities. 2007 4th IEEE International Workshop on Visualizing Software for Understanding and Analysis, 92–99. https://doi.org/10.1109/vissof.2007.4290706
Winter 2024 Copyright. These slides can only be used as study material for the class CSC 308 at Cal Poly. They cannot be distributed or used for another purpose.