Who Wants to Write Requirements?

Recently, a colleague passed along a piece by Karl Wiegers. I have been meaning to do a deep dive into his website for a while now and So You Want to Be a Requirements Analyst seemed like a great place to start. I was not disappointed as Karl does an excellent job of painting an accurate portrait of the requirements expert and the project impact she can wield.

Straddling the gulf between vague customer ideas and the clear specifications that will guide the software team’s work, the analyst must first understand the users’ goals for the new system and then define functional and quality requirements that allow project managers to estimate, developers to design and build, and testers to verify the product.

I have often witnessed the multiplier effect that a Product Manager can have on a project and this is most certainly due to the interconnectedness that Karl summarizes so well. Later in the article he highlights some of the research by Barry Boehm that actually quantifies the effect an experienced and skilled Product Manager can have on a project.

...seasoned analysts can reduce a project’s required effort by one third compared to similar projects with inexperienced analysts, and projects with highly skilled analysts require half the effort of those using the least capable analysts.

The aspect of the article that I found most compelling was the manner in which Karl captured the myriad tasks that must be performend by the person responsible for requirements on a project. In particular, I thought his description of the elicitation and analysis aspect of the Product Manager's job was right on the money.

A proactive analyst helps users articulate the system capabilities they need to meet their business objectives...Look for derived requirements that are a logical consequence of the customers’ requests, as well as hunting for those implicit requirements that they expect but haven’t verbalized. Spot the vague, weak words that cause ambiguity and confusion. Point out conflicting requirements and areas that need more detail.

Far too many organizations, in my opinion, look at requirements as fruit that must simply be picked from the trees in the user community orchard. In reality, gathering requirements is a fairly trivial exercise. The real challenge lies in first eliciting requirements from users that typically have very little experience in expressing their needs. After all, most users have unfortunately never been asked to contribute to the development of the systems they have to use every day. Once a candidate pool of user requests has been elicited, the challenge becomes analyzing those requirements to ensure that they represent a complete and accurate depiction of the solution to be developed.

Although I liked the article overall, there were a couple of points where I found myself disagreeing with how Karl presented a topic.

The first, early in the article, was where he stated "Requirements analyst is a project role, not necessarily a job title." Though he goes on to quantify the positive impact that a seasoned analyst can have on a project, I wish Karl had been more forceful in stating that the requirements function should be a titled and dedicated role on projects. Almost anyone would scoff at the notion that software engineer should be just another role on a project so why should we accept any hint of a suggestion that working with requirements is a task to be simply parceled out among fungible work units (a.k.a. project team members). Of course, here requirements experts find themselves fighting for recognition of their unique skills along with other interchangeable (ha!) project roles like QA and technical writing.

Towards the end of his paper, Karl discusses the role that experience and knowledge in a given business domain should play for those working with requirements. Perhaps this doesn't quite qualify as the third rail in Product Management circles, but it certainly is a controversial topic that can inspire heated discussion. Roger Cauvin has a post where he expresses the viewpoint that "experience in a particular industry is little more than a crutch" for Product Managers who might lack the facilitation and analytical skills that represent the core competencies of the profession.

Though Karl certainly seems to pay respect to the role played by requirments expertise, I think he gives domain knowledge a little too much credit by terming it a "powerful asset." Yes, domain experience is useful and has its place. That said, I firmly believe that the value added by a good Product Manager in a domain where he has zero experience will far outweigh the likely harm that most business domain experts would inflict on a project were they to be annointed the requirements experts.