2

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.

  • 3
    I didn't -1, but the answer is "Never". Also read this: en.wikipedia.org/wiki/Software_requirements – BЈовић Jul 19 '16 at 8:54
  • @BЈовић I know a fair bit of requirements engineering, yet I want to create some sort of objective checklist to improve processes – Falcon Jul 19 '16 at 8:59
  • Give the requirements to the engineers who will implement them. If they don't understand anything, then they are not good, and you need to fill the gaps. – BЈовић Jul 19 '16 at 9:25
  • "For implementation", did you mean for software engineer ? Or for software architect ? For example, I don't think that non functional requirements are very helpful for a software engineer.... however for a software architect it makes a lot of sense. – AilurusFulgens Jul 19 '16 at 9:32
  • @AilurusFulgens We don't have architects, we work as a scrum team. Yet, we are interested in non-functional requirements when working on a story. – Falcon Jul 19 '16 at 9:44
3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.