”A requirement is by definition a translation of business need to actionable av verifiable tasks. It is also the legal agreement set between client and supplier on what should be accomplished. ”
This means that what is defined in a requirement is what both parties agree should be built. This is rarely the way requirements are written and in many cases it becomes a wishlist from the business side instead of a defined agreement of what is to be built. Even more rare is it to get a definition of the business value of what is to be built and the thoughts behind it.
For a requirement to be efficient it is broken down into three parts: Business Need, Technical Clarification and Acceptance Verification. This breakdown is done to avoid the process of working towards failure. Working towards failure happen when all parts of the process work from the pre-conception that each step will fail in some way. This is common in misused Agile processes where the actual agile process is replaced with an ad-hoc approach.
To avoid working towards failure the requirement process need to have a proper handover process. This is because the requirement is not just a legal agreement, it is also a translation of the business need so it can be implemented. If the requirement is not properly defined to achieve that goal and handover should not be possible. This is why collaboration and a transference of ownership of a requirement is crucial for a successful project.
Recommended Comments
There are no comments to display.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now