On Requirements
Rather than declaring the requirements “done” at some point, define a baseline, a snapshot in time that defines an agreed-upon foundation for subsequent work and modifications. Once you’ve established a baseline, follow your change control process to modify the requirements, recognizing the implications of making changes. It’s folly to think you can freeze the requirements and allow no changes after some initial elicitation activities - Karl Wiegers
Don’t use uncertainty as an excuse for lack of precision. Acknowledge the uncertainty and find ways to address it, such as through prototyping - Karl Wiegers
The other benefit of using visual models is that it is easier to bring everyone up to speed quickly. The models will explain what is going on in the project at a very high and very low level. Models will show the context of the piece of the project that is being delegated, so it is easy to see how that part contributes to the whole. Your models should be the key tutorial tool you use when explaining the project to new resources - Jeremy Gorr
On Using a Business Objectives Model
The Business Objectives Model is a separate exercise to discovering your product concept. It begins with problems. The discussions of “What is wrong with your business?” leads to answers that assist in defining the product concept. Imagine your stakeholders tell you that they need claws, large teeth, orange and striped fur, and that they needed it to be an elephant. It means they want a Tiger instead. This, unfortunately, is the state of most businesses, and a large reason why projects fail from scope creep and budget issues – Matt Offers.
