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.

Improve this question
5
  • 3
    I didn't -1, but the answer is "Never". Also read this: en.wikipedia.org/wiki/Software_requirements Commented Jul 19, 2016 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 Commented Jul 19, 2016 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. Commented Jul 19, 2016 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. Commented Jul 19, 2016 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. Commented Jul 19, 2016 at 9:44

1 Answer 1

Reset to default
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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.