Effective Communication Through a Requirements Document

After reading Chris LaCroix’s blog entry on Requirements gathering (see Five Things Analysts Should Always Do To Ensure Success), I was reminded of a previous assignment where two things I had learned long ago were reinforced.  The first was a mantra preached by a senior Business Systems Analyst:  “You can never have too much detail in your requirements”.  The other was “A picture is still worth a thousand words”.  They both fit together into one statement:  Requirements must be communicated effectively, in a way that is easy for everyone to understand.

I had been assigned to a new team, along with five people of Indian descent, working in a department that moved large volumes of financial data from application to application and sending data to or receiving data from external vendors.  Each of us was new to the team and as I learned, many people from India speak in different dialects.  Aside from the cultural learning opportunity this presented, my concern was ensuring that we would be able to communicate clearly and easily. 

As the BSA for the group, I compiled the requirements for all of the projects that we were assigned, which at times was up to five concurrent projects at various stages of completion, with each project consisting of multiple teams.  My documents would be relied upon by designers, coders and QA testers – both on and offshore.  If they could not be understood or were misinterpreted, then our portion of the project could fail, thus endangering the entire project.

I took the two lessons to heart.  First, there would be no assumptions in any document other than those that the overall project leadership identified up front.  It could not be assumed that a requirement could be glossed over or left at a high level because “that’s the way we always do it” or “that should be obvious based on this or that”.  The detail had to be in the document, and in a step-by-step presentation.  The documents needed to have a flow, and properly sectioned to increase clarity.  My goal was that a developer or QA person in India, working while I was asleep, would have all of his questions answered up front and not have to wait until morning for clarification of an issue.

Second, I added a flowchart of the overall process (with our team’s tasks highlighted) to the requirements document.  This seems like a simple thing to do, but it is often left out and does not seem to be mentioned or emphasized in any of the academic or theoretical discussions I have participated in.  The benefits of this became immediately clear when providing an overview of the project to the rest of the team.  My flowchart could explain the project and our tasks in about 30 seconds while a discussion may take five minutes.  And it was easier to understand.  In addition, if anyone had to do a quick check on what the project was encompassing, the flowchart provided the answer in an easy to comprehend way.  In fact, on several projects the flowchart was adopted by the project team as a whole, becoming a project artifact.

Our team was very successful, turning out projects on time with only limited minor issues.  In my case, taking a step back to review how I was communicating with my team made a real difference in the overall success of our projects.  Were the words used clear and specific?  Were the requirements open to interpretation or were they unambiguous?  No matter how much expertise the team has, without accurate, clear and understandable requirements they can’t turn out the high level of output expected. 

Ask yourself a couple of questions as your next project kicks off:

- Am I communicating effectively with the consumers of my documents?
- Am I providing a high level of detail?
- Do my requirements have a flow to them that reflects the project?
- Are my documents easy to understand?

If you can answer “Yes” to these questions, then your projects have a much higher potential for success.  In addition, your Business Customer will be able to approve a Requirements Document that clearly demonstrates that the overall objective of the project is understood, and that your requirements are accurate and well-stated.