When are requirements good enough for implementation

Question

I've been recently thinking about the following question:

When are requirements good enough for implementation?

I'm trying to create a checklist of some sort that can at least semi-objectively answer this question.

Here are some of my thoughts about methods and checks to ensure good requirements:

• Ambiguity Poll (are the requirements precise enough for the development team)
• Non-functional requirements are defined
• Exclusive use of defined ubiquitous language
• "Conditions of Statisfaction" are defined by the customer
• Business Value and Technical Value are clear and communicated

Please share your thoughts.

Answer 1

The key to writing good requirements is having a clear, unambiguous acceptance test on each individual requirement that is not subject to interpretation, so that you can declare success.

From the customer perspective, requirements are good enough when they clearly paint a picture of what the software does, what it looks like, and what business goals it accomplishes. Usually, this requires use cases, UI mockups and walkthroughs, and sample reports.

From the developer's perspective, requirements are good enough when the software developers understand clearly what they must do to build the application. So, in addition to what the customer sees, as a developer I would also like to see the overall architecture and structure, API's and interfaces, individual structural elements, business functions, and how it all talks to each other, in sufficient detail so that I can go start writing methods and classes (which each have their own specification, even if it's just in the form of unit tests).

The amount of detail that is necessary to accomplish this varies from team to team. The level of rigor in requirements specifications for offshore teams is much greater than a tightly-knit in-house scrum team, for example.