Semester 1, AY 2013/14
30 August 2013
- Specify what your end-product can do / what the customer wants
- Functional / non-functional requirements
- Many tools for requirement analysis
- Use whatever tools that you want
- Serve as a contract (but can change later)
- Helps to determine test cases and evaluation criteria
- Helps to define goals, plan projects, prioritize features, etc.
- Adapted from Scott Sehlhorst’s Top Ten Rules
- Valuable — put in requirements that are of good values to the users.
- Concise — easy to understand for people with diff background.
- Design free — focus on what, not how
- Attainable - don't put in things you can't attain
- Complete - doesn't leave out anything
- Consistent — don’t put in impossible requirements
- Unambiguous - cannot be interpreted differently by different people
- Verifiable - can be verified within your means
- Atomic — cannot say “half of this requirement is implemented”
- Correct
- Taken from last academic year.
- Please read before next lecture.
- Examples
- Project Kim Section 3.1 Game Flow
- Collaborative Internet Observatory Project Requirements Specification