In many ways gathering and writing requirements are like a successful first date. That may seem odd to make such a comparison between two completely opposite things…believe me, I think so as well. But if you really think about the core and the outcome both things, you’ll realize that they both require a good amount of attention in order to follow through to the success of the development process.

But enough about weird similes, let’s get technical.

So what makes a good requirements? Well to provide a deeper understanding about what comprises of good requirements, this blog will look into thoughts of three professionals (Jim Heumann, Thomas Hathaway, and Karl Wiegers) within the technology industry and some shared beliefs in GOOD requirements. And of course, I’ll share some insights based off of my limited experience with requirement gathering with my own client’s and professional experience, where poor requirements have lead me astray.

As Clear as Water

One of the most important aspect of writing good requirements is clarity. What we mean by clarity is that our goals of requirements are to essentially refine our statements to capture the business aspects of the idea more so than the technological details. As Hathway alludes to, requirements should be easily understandable to practically any developer who may be reading it, despite any barriers of communication (2008). This is something I absolutely believe in and cannot stress enough. I’ve been caught in my own experience as a front-end developer where, in many situations my product owner/project manager will write up requirements that are unclear and I’ll have no idea where to start or have an idea of what the client actually wants. This leads to a lot of back and forth among co-workers, and then back to the project manager, then eventually an email to a semi-annoyed client – and believe me no one likes an annoyed client.

But there are many ways to test how clear requirements can be. You should be constantly asking yourself as the analyst are these clear enough, and if “‘call me when you’re done” (Weigers 1999) provides a little discomfort, then you need to keep refining the requirements!

Prioritization. Prioritization. = Flexibility

One of the things that tend to be overlooked when determining good requirements is prioritization. As Heumann explains, requirements are like good code, at times you’ll have no problem with coming up with features, but you’ll always be faced with time constraints (2004). As the requirements begin to build up, and the project becomes clearer, the requirements priority becomes exceedingly important. My belief is that any successful project can adapt to any unexpected stops in the road. While you can’t perfectly account for all of them, you can limit the collateral damage by knowing ahead of time what’s more important.

Thus, Weiger suggest that assigning a implementation priority to a feature, requirement, or use-case with levels of priority is a good technique to determine a basis for product releases (1999). In my work experience, I’ve used this technique with my own clients, and within my professional experience. Working by yourself, you are forced to wear multiple hats, and being your own project manager is definitely one of them - and one I struggle with. In a meeting with my first client, I was blinded by the euphoria of starting a new project that I agreed upon the implementation of so many features and design request. Only a month down the road, I began to realize that the promises I made couldn’t be deliver within our agreed upon deadlines.

Thinking back, I felt as if I was blinded by a the diamond hanging from a rod that I didn’t see the edge of the cliff.

After a hit to my confidence, and a disappointed client, I learned that projects will need iterations before you can actually complete everything. Thus, build and write out the essential functions to be able to perform the main function of the project before being distracted by attractive features.

Breaking it all out

When writing requirement statements, you’ll be bounded by bulky initial statements. However, focus on splitting large requirement into multiple requirements, this will provide test cases and make it easier during the development process (Wieger 1998). Similarly, think of it like the process tasking out stories in a SCRUM development cycle. What is more appealing being tossed a huge 2000 page book and then having all the associated test in the last week of the term, or to be provided with a test per each few chapters? Breaking it down helps. It prevents introducing new dependencies and branches that would of not occurred originally (Neumann 2004).

Wrapping it up

I just touch the surface on some areas of good requirements. But Ideally my goal was to focus on areas that can improve requirements writing exponentially. If you are interested in reading more about particular guidelines, I would suggest looking at the references below of the authors associated articles. Even if you are a seasoned veteran in writing requirements, sometimes a refresher is what you need. Like a date, being clear and unambiguous the first time around, can save you from a world of pain and agony.

References:

• Heumann, J. (2004, July 14). Writing good requirements is a lot like writing good code. The Rational Edge.
• Wiegers, K. (1999, May 1). Writing Quality Requirements. Retrieved March 2, 2015, from http://www.processimpact.com/articles/qualreqs.html
• Hathaway, T. (2008, February 9). Business Requirements - What Is The Difference Between Good And Bad? Retrieved March 2, 2015, from http://ezinearticles.com/?Business-Requirements—What-Is-The-Difference-Between-Good-And-Bad?&id=976468