Writing good requirements is frequently portrayed as a unique skill to business analysts, it’s not, it’s a unique skill to good writers. Requirements are simply a condition or capability needed by a stakeholder (user) to solve a problem or achieve an objective. Identifying requirements is a unique skill to business analysts; however, writing good requirements has more to do with what you learned in high school English class. Remember your English teachers? They would spend a semester teaching you to know your topic, be thorough and concise, eliminate ambiguity, and organize your writing to create a smooth flow for the reader.
We all can relate to this story: Your teacher gives you an assignment to write a convincing article on a popular debate in current events. Your first draft is due next week so you select and research a topic. You put the first draft together, review it, make changes several times, and hand it in. Your teacher reads it over the weekend and marks it up. She hands back the bloody red draft and asks you to address her comments. You can’t believe she marked it up so much. You spend the next few days rewriting it and hand it in for another review and it comes back with more red marks. You get incredibly frustrated. All you want is to be done with this assignment. You wish it wasn’t so hard.
Times haven’t changed much. Many business analysts find it hard to write good requirements. When they get assigned to a project there is a sense of excitement and anticipation. They start researching and interviewing stakeholders to find out what they need to be successful at their jobs. After compiling all the information, they begin writing the requirements. They work hard and put in a lot of hours, resulting in a cherished first draft. They send it out to the users and developers for review. When the comments start coming in they feel hurt and frustrated. They make changes and send it out once more for review. Again, comments come back announcing dissatisfaction and more work. At this point all a business analyst wants is to be done with this particular task.
If you can relate to the above scenario it may be because you struggle with writing in general or you are a little rusty at it. Let’s review what makes a good set of requirements:
- First of all, you have to know in detail what the problem and solution is. You can’t have a casual understanding. If you do, it will sink you for sure.
- Next, each requirement needs to be specific and concise. You are creating an image of the solution in the minds of your users and developers, one grain of sand at a time. Choose your words wisely, each one matters. Eliminate ambiguity by looking at what you have written from different points of view.
- Lastly, organize your work so it flows smoothly for the reader. You are taking them on a journey, there should not be any holes in the image you are creating. Be thorough in describing all the facets of the solution.
If writing is not one of your strengths, work on it. Take a couple of English classes at a local junior college at night. You may not become John Grisham, but you will get better. Besides, what gave you trouble in English classes when you were younger most likely won’t materialize for you now. Life has a funny way of changing us without us even recognizing it.
Writing good requirements is hard and takes a lot of effort. It’s much harder than any writing assignment you received in high school. Of course, the consequences of writing bad requirements are far greater than any you encountered in high school too.
I find this situation very similar to one we have experienced in project management. In project management we‘ve learned when planning a project that the earlier portions of a project’s Work Breakdown Structure will always be in greater detail than latter portions when you first start a project. That is because we came to realize that projects have horizon lines: points in a project where more information becomes available, giving us a new context to plan the next section of the project in more detail. In the classic waterfall methodology these horizon lines tend to line up with the starting points of each phase. The only reason we came to this conclusion is because project managers banged their heads against the wall trying to plan the whole project in detail as though they could see perfectly into the future. It was repeated failures and frustrations that led to the understanding of horizon lines.
Project managers and business analysts are responsible for defining a single vision for the project. A vision with little ambiguity that can be realistically accomplished and accepted by all parties involved. I’m not talking about detailed requirements here. I’m talking about the description of the project’s scope that is created for the project plan at the beginning of the project. It’s what points the project in a direction and provides boundaries to contain future activities.
