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)