That is what the role of the Business Analyst is all about, accurately specify the business requirement in a way that tells what the business is. to be able to do this, the Business Analyst together with her/ his requirement takes a Journey with a sense of discovery the business from all the available sources and the applicable elicitation techniques.

The first station in the Journey of discovery is what is called Elicitation which has various techniques, that are available for the Business Analyst to pick from or invent another that (s)he thinks is more appropriate for the business case.

The coming station in the Journey of Business analysis is to THINK, just think, put pieces together in the best way you can serve the business, pin-point what can be enhanced and how can that be done.

After the requirement becomes mature enough to be specified, you have already seen all the seeds that can make a great requirement so now it is the time to the requirement can actually speak for its business and tells its story.

When we will come to the last station in the journey that called Requirement Specification, the Business Analyst should think of the people who the specification is being made for. It should be done to all people, with different languages, the business owner who know all the business quite well, and the Technical team who may know nothing, each understand a different area, but the role of a Business Analyst, is to find the common language and the common ground that the requirement can speak its business from.

Having both in your mind, it is important to specify the business in a way that is complete, so that the Technical Team who wasn’t on the discovery journey, and may  know nothing about the business, can get the picture easily that allows him to develop the Software as it was intended to be, and the specification also, should be done in a way that the business side can understand easily, as they are the people who would verify and approve what the requirement is all about, how can they be able to do so, if the requirement was specified in a technical language that they are not familiar with or cannot understand.

In specifying the requirement, all the visual aids that may help the requirement be better understood, in Diagrams, the wireframes and all that can make the requirement more clear and easier for the intended people.

Going to share here some KPIs that I think will tell you how the requirement is well specified.

  1. It should be described without any assumptions of specific knowledge for the reader of the requirement.
  2. It should be written in a clear way that does not make any space for confusion, it should be understood by all the readers in the same way, just as was intended by the Business Analyst
  3. it should not have any redundant or contradictory information.
  4. It really should speak for its business, without having a call from the readers of the specification asking about what the requirement should have answered, or a call for clarification for what the requirement should have set clear.

Enjoy your discovery journey in the different worlds of Business, and be happy when seeing your requirement accurately and not depending or your further clarifications speak for its business.