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:
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.
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.
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.
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!
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.
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.
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.