Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
To be considered complete, each requirement must be (at minimum):
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.
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."
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.
According to Karl Wiegers in Software Requirements, there are characteristics of each requirement. A high-quality, well-written requirement is:
there are several things that should true for requirements to be complete.
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.
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.
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.
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.
