Notes on Chapter 7, Before the Project
- All about what to do before starting a project. Seems like it is pre-agile methodologies. Since the agile manifesto came out 2001 seems to fit that timeline.
- Dig for requirements, don’t gather. They are on not the surface but deep under assumptions. A requirement is a statement of something that needs to be accomplished
- Use cases help describe a particular use of the system, and should use cases be formal (use template) or informal.
- Don’t over specify in a requirements document, good ones remain abstract, simplest statement that accurately reflects the business need is best.
- Maintain a Glossary, one place that defines all the specific terms and vocabulary used in a project
- Publish project documents to internal Web sites.
- Some constraints are absolute; others are preconceived notions, honor absolute constraints.
- Listen to the voice that says “wait.” If you sit down to start typing and there’s a doubt in, listen (Good Judgment or Procrastination?)
- Tips:
- Don’t Gather Requirements—Dig for Them
- Work with a User to Think Like a User
- Abstractions Live Longer than Details
- Use a Project Glossary
- Don’t Think Outside the Box—Find the Box
- Listen to Nagging Doubts—Start When You’re Ready
- Some Things Are Better Done than Described
- Don’t Be a Slave to Formal Methods
- Expensive Tools Do Not Produce Better Designs
Questions on Chapter 7
Helpfully provided by the Dev Empathy Book Club (check it out if you are looking for an online book club to expand your reading horizons and if you want to meet of group of awesome supportive people looking to help your develop your empathy skills)
- In section 36 (“The Requirements Pit”), the authors advocate limiting requirements to be as minimal and abstract as possible. Is this always practical? Desirable?
- Also in section 36, the authors encourage you to become a user of your own system – or, in modern terms, they advocate dogfooding. Have you tried using the tools you build extensively? If so, how has it helped you understand your users and better meet their needs?
- In section 39 (“The Specification Trap”), the authors define program specification as: the process of taking a requirement and reducing it down to the point where a programmer’s skill can take over. This is cast as a mindset to avoid over-specifying a system and building in constraints that will hurt the product, and ultimately its users.
- How does the specification process work in your organization? Do you think there’s too much, or too little?
Top comments (0)