Nearly "two-thirds of all IT projects fail" because of poor requirements.
This is one of the reasons why stakeholders, customers and interested parties argue over or fail to come to a consensus on the requirements or scope of a project.
In one project, requirements were being constantly rewritten, tossed out or reincorporated depending on who was in charge of the meeting.
In addition, time and budget overruns plagued the project because the parties could not agree on what each requirement really meant.
Finally, the implementation staff started resigning or asking to be transferred to other projects.
It is accurate to say that poorly written requirements can easily lead to budget or time overruns, unsatisfied stakeholders or customers and excessive staff turn-over.
As a business analyst, it is your duty to create good requirements and here are some guidelines for doing just that:
Write Feasible Requirements
Your requirement must be implementable considering the resources, capabilities, skills or knowledge available to your project. In other words, do a reality check and do not write down requirements that are impossible to achieve considering the time, money or resource pool available to your organization.
Write Verifiable Business Requirements
At the end of your project, you must be able to prove through testing, inspection, walk through or by demonstration that the requirements were implemented.
One way to make a requirement verifiable is to rewrite or word it in such a way that you can actually test it or decompose it into smaller, more testable requirements.
Write Traceable Requirements
You must be able to follow or track all the changes in your requirements back to the original, current or final form.
This will help you verify the origin of each requirement and ensure that they were not introduced by external parties in an unapproved fashion.
It is even better to have a requirements traceability document that shows the originating customer, stakeholder or business need, the high-level business case or lower level system use case incorporating the requirement and the final product feature finally that meets the requirement.
Write Consistent Requirements
Have you ever participated in a meeting where you were given a business requirement that you felt contradicted another business requirement?
That is what an inconsistent requirement looks like … a requirement that opposes, contradicts, invalidates or conflicts with another requirement making it difficult or downright impossible to achieve.
So, here is the final word on this … don’t accept inconsistent requirements!
Requirements Must Be Complete
Each requirement that you write must be complete and comprehensive and it must not depend on another requirement to explain it or provide detailed information.
That means that if you are still in the process of evaluating the full scope of a requirement with customers or stakeholders, you do not include it as a requirement until it is complete.
Requirements Must Be Unambiguous
Write each requirement in a way that removes doubt, confusion or misinterpretation.
In other words, your requirements must be written in a style that leaves little doubt as to what is intended or meant.
Each requirement must be clear and concise. It must not be vague and it should be read, understood or interpreted by every party the same way. Finally your requirements should be written in language that is free of technical jargon and in a language that the readers of the document understand.
Requirements Must Be Necessary
Include all the requirements that meet the previous rules on this post and in addition are required or mandatory for the system under observation to function as intended.
So, a requirement is necessary when the lack or absence of it will be interpreted as a defect by stakeholders, project sponsors or customers.
To summarize this post, write business requirements that are: verifiable, clear, concise, complete, consistent, feasible and necessary.
What has been your experience when it comes to writing requirements or getting a consensus from interested parties as to what constitutes a requirement and what does not.