4. Cognitive Bias mental tendencies or shortcuts often handy, but can lead you astray keep them in mind http://en.wikipedia.org/wiki/List_of_cognitive_biases
5. Why Requirements know what you need to do know what you don’t need to do know when you’re done evaluate the cost of change part contract, part guide
6. Writing Requirements keep your audience in mind non-techy clear and unambiguous define things as needed detailed, but not too detailed identify core/key aspects include why’s as well as what’s
7. Collaborative Creation Creating the requirements is a collaborative effort between the sponsor and the developers What does the client bring? What do you bring?
8. Scope not just a mouthwash... the boundaries of the project what you do have to do what you don’t have to do be careful of scope change! scope creep : more and more features under-definition : forgot to include sequence chains : getting side-tracked
9. Specifications similar to requirements, but more technical more for internal use more of a living document a technical interpretation of the requirements usually still verified with the client transitions to a more formal project management paradigm
10. What’s in the Specs? project summary project stakeholders content description desires deliverables scope limits special workflows See the handout!
11. What do you do with the specs? keep them handy for reference keep them up to date as things change add to them as needed use them as the basis for your work plan