Semester 1, AY 2014/15
13 August 2014
- Specify what your end-product can do / what the customer wants
- Functional / non-functional requirements
- Many tools for requirement analysis
- Use whatever tools suitable for your project
- Helps to define the goals of the project
- Helps to communicate among team members and with customers
- Serve as a contract (for CS3281, can change later)
- Helps to determine test cases and evaluation criteria
- Helps to plan projects (estimate time, prioritize features)
- Helps to reduce bugs
- Leads to better software design
- Adapted from Scott Sehlhorst’s Top Ten Rules
- Correct -- of course
- Valuable — put in requirements that are of good values to the users; solve their problems; support their strategy, etc.
- prioritize the requirements (must-have, good-to-have, only-if-time-permits, etc)
- Easy to read — write for people with diff background; use figures; scannable; cross-references, etc.
- Design free — focus on what, not how
- Attainable - don't put in things you can't attain
- e.g., "analyze 100 video cameras in real-time"
- Complete - doesn't leave out anything, consider error cases, external systems
- Consistent — don’t put in impossible requirements, use consistent terms
- e.g., "device"/"phone"/"mobile" -- are they the same or not. Establish a project glossary will help.
- e.g., "only administrator can edit X", else where, "any user can edit X"
- Unambiguous - cannot be interpreted differently by different people
- e.g., avoid "the user",
- Verifiable - can be verified within your means (finite, cost-effective way to verify)
- e.g., avoid "easy to use", "should work most of the time"
- Atomic — cannot say “half of this requirement is implemented”
- e.g., "user can post text, URLs, or photos to their wall."
- Taken from past CS3281/2/3/4 projects
- AutoComPaste
- Collaborative Internet Observatory
- SoCMAS
- Project Kim Section 3.1 Game Flow