Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Which elements must a requirement contain that it can be considered complete? Or if this works better - which questions should I ask about a requirement to find out if it is complete. I am not talking about the implementation of the requirement but the requirement itself.

I am asking this from the perspective of an analyst who wants to make sure that his requirements are complete before passing them on to the design team.

share|improve this question
1  
When all acceptance tests pass? –  Oded Mar 28 '12 at 12:57
    
Oded: Thanks for the comment. I am not talking about the requirement being completely implemented but the formal documentation of the requirement is complete. I will try to make the question clearer. –  Demento Mar 28 '12 at 13:00
    
the BA might be interested in this link for processimpact.com/articles/reqtraps.html –  HLGEM Mar 28 '12 at 13:47
    
what's a "requirement", in the context of this question? –  Marty Apr 17 '12 at 0:59
add comment

8 Answers

up vote 8 down vote accepted

To be considered complete, each requirement must be (at minimum):

  • Unambiguous - each requirement can only mean one thing and can only be interpreted one way.
  • Atomic - each requirement cannot be broken down into multiple requirements.
  • Testable - each requirement can be shown to have been met or not met via some form of testing.

You'd be surprised how good your requirements turn out by just following these three guidelines at all costs.

Also, be sure to write a rationale for each requirement. This is very important and useful down the road when someone wonders why a particular requirement was created.

And remember, the requirements should describe WHAT the software will do, not HOW it will do it. The HOW should be left for the design team.

share|improve this answer
1  
I would add, the requirement isn't complete until the stakeholders have agreed to it. This includes the developement staff. Mpst bad requirements I have seen came from BAs who didn't let developers review the requirement before presenting it tothe customer where it became "set in stone". Other sources of bad requirements are BAs who only talk to managers (or worse senior managers) not users. They always miss important details that devs don't find out about until the users actually start to use the program. –  HLGEM Mar 28 '12 at 13:44
add comment

According to Karl Wiegers in Software Requirements, there are characteristics of each requirement. A high-quality, well-written requirement is:

  • Complete - it fully describes the functionality
  • Correct - it accurately describes the functionality
  • Feasible - the requirement can be implemented
  • Necessary - the capability documented must be required
  • Prioritized - an indicator of how essential the requirement is to the system or a particular release
  • Unambiguous - anyone who reads the requirement should arrive at a single interpretation of it
  • Verifiable - the system can somehow be tested to confirm that it meets the requirement
share|improve this answer
add comment

I consider a set of functional requirements complete when they can be used to link every system output to one or more system inputs. This is horizontal traceabiliy. Without it you will be missing about 30% of your total requirements. For more inf see http://www.barbarabea.com/?page_id=11

Any requirement that needs child requirements is, and must be, ambiguous. If it were unambiguous, it would not need child requirements. By this criteria, most of the requirements in a large system are ambiguous.

For functional requirements that do not have children, there is a simple test for ambiguity. Full details at http://www.barbarabea.com/?page_id=78

The simplified description of the test is that the requirements must be horizontally traceable and the processing step in each functional requirement must be an algorithm.

share|improve this answer
add comment

You should have a definition of done.

There is a decent blog post on the subject, but I usually use the definition of definition of done (yeah) from the official scrum guide.

Definition of “Done”

When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the “Definition of Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning Meeting. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current Definition of “Done.”

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.

share|improve this answer
add comment

Requirements rarely completes, usually it evolves and changes.

As is told in the famous book Pragmatic Programmer, From Journeyman to Master by Andrew Hunt, David Thomas;

The Requirements Pit

Many books and tutorials refer to requirements gathering as an early phase of the project. The word "gathering" seems to imply a tribe of happy analysts, foraging for nuggets of wisdom that are lying on the ground all around them while the Pastoral Symphony plays gently in the background. "Gathering" implies that the requirements are already there—you need merely find them, place them in your basket, and be merrily on your way.

It doesn't quite work that way. Requirements rarely lie on the surface. Normally, they're buried deep beneath layers of assumptions, misconceptions, and politics.

I am not really sure if there is any point at which you can tell that requirement are complete.

I am asking this from the perspective of an analyst who wants to make sure that his requirements are complete before passing them on to the design team.

It purely a personal or business choice, many projects starts with a high level idea of what they want, and will evolve by itself to reach the final stage. Some cases you might need to sign some contract which will state the basic set of requirements. so, it always depends.

When it comes to requirements the only important thing is that, you should be prepared to act based on the change.

share|improve this answer
add comment

there are several things that should true for requirements to be complete.

  • Does the requirement relate directly to achieving part of the business process?
  • Is the requirement verifiable when implemented?
  • Does the requirement express the idea as simply as possible?
  • Is every part of the business process defined by at least one requirement?

If all of these are true you can be fairly certain that a requirement is complete. Though you can't be 100% sure until your designers/programmers look at them and understand them the same as you do.

share|improve this answer
add comment

When it's launched to production and verified by the PM. I know that's not what you're looking for because you want to ensure the requirements are correct before design, but that's not the way it works in the real world. Requirements are missed, misunderstood by the engineers, mis-stated by product, vaguely stated by product, vaguely understood by engineers, etc. And sometimes that's not obvious until code starts getting written, or until an integration test starts failing, or until the PM sees the feature demoed and says, "This isn't the right feature."

share|improve this answer
1  
+1 and let's add that quite often the requirements just change - not because of miscommunication but simply because it stated what the customer told, rather than what he really needed, and the two is often rather different. Moreover, the world (market situation, competition, technology, ...) is constantly changing, and this may obsolete requirements too. –  Péter Török Mar 28 '12 at 14:26
add comment

Does this requirement properly & Fully capture the business needs?

But, Personally I would have the business review the requirements before passing it off to design.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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