Documented Requirements ARE Necessary

It all started with the recent CIO article Fixing the Requirements Mess. A comment by Christopher Creel (halfway down the page) was then put on the Requirements Defined Message Board.

After reading Mr. Creel's comments, and the other postings, I think people are missing the main problem with his argument.

The rationale for holding on to written requirements, especially for business applications, is a little baffling. The entire premise for requirements is that it costs less to perform a paper exercise than to build software that is terrible, but a little less terrible with each iteration.

I just don't buy it. Not in the least little bit.

First, requirements give everyone a common framework to ensure business and developers agree on the end product. Building simulations and prototypes can only be useful if they save time for both the business and developers. I understand he says "with advances in application simulation software, prototyping technology, and modern software development tools, techniques, and technologies, many people would be shocked at how the economics really shake out these days," but he gives no supporting numbers. Has anyone seen numbers for this? I haven't.

Second, requirements give QA something to test against. Just because multiple iterations in a build environment may prove a program stable, it does not ensure it will meet all of the business needs.

Third, well-written requirements can provide the starting point for training aids and user manuals. Something every program is missing.

Fourth, and maybe most significant to me, is how he can say written requirements are not necessary "especially for business applications?" The implication here is one of the following: (a) existing documentation of the business rules is sufficient, (b) the business rules are so well known they do not need to be documented, or (c) the business rules are too complicated to write down.

Tackling these points one at a time...
(a) It is unlikely the current procedural documentation is completely up-to-date. How people do their work changes on a regular basis and I have never seen a company who could keep the documentation current with what the people are doing in their jobs. Further, in a department of 6-10 people, all with the same duties, it is easy to find the vast majority performing their tasks differently; where existing rules and procedures exist they typically leave too much room for interpretation. And significantly, the documentation for procedures is spread among too many documents in too many places for developers to grasp the big picture and all the details.

(b) ACK! This just isn't so; common sense isn't common and seldom do two different people understand the process in the same way. Counting on verbal history and common knowledge of the rules is a disaster waiting to happen.

(c) Unfortunately, I believe the belief that business rules are too complicated is the most common reason for this rationale, even if it more often whispered or unspoken than said aloud. It is my contention this reason, whether spoken or not, is the last reason why requirements should be abandoned. It hasn't always been uncommon to find a business application being pushed as a means to discover the business rules, but I submit knowing the business rules and the exceptions should come before building a business application, or even its prototype. Knowing how to optimize your business should come before building an application. And knowing your business should always come before trusting someone else to solve your problems with a new software application.

Is it just me, or is he missing the boat?

One Size Fits None

The November 15, 2005 issue of CIO Magazine leads with the headline "Rethinking Requirements" and includes an article titled Fixing the Requirements Mess.

Now, I just know someone is going to come along and burst my bubble by revealing this is a recycled story the editors run every few months, but I was pleasantly surprised to see the world of requirements front and center in a magazine that targets IT decision makers.

Although I found the article to be an interesting and worthy read, it did not quite live up to its title. This is not meant as criticism as much as it is an effort to support truth in advertising. Rather than the explicitly prescriptive discussion that the title suggests (at least to me), the article presents four case studies that reveal how different organizations chose to address their particular challenges with requirements. I don't know if this was the author's primary intent, but his approach provides an implied lesson that I believe is a key signpost on the road to better requirements.

The case studies include:

• ADP Employer Services Canada drastically cut scope down to 10% of the original plan
• Bank of Montreal Financial Group created a formal course of certification for business analysts
• Capital One adapted the precepts of Agile development
• P&G Pharmaceuticals focused on tracing every line of code back to the business process it supports

I have intentionally waited on writing this post because I was curious to see what type of comments, if any, CIO's readership would have for this article. I was not disappointed as there were 18 comments supporting perhaps 24 different opinions posted within 2 weeks of publication. My expectation had been that no consensus of any sort would arise from the pool of reader responses and this ultimately proved to be true.

Some of the more interesting (paraphrased) comments include:

• You need to do a better job of elicitation by using the classic techniques
• You need to do a better job of elicitation by using entirely new techniques
• Start coding immediately and be agile
  
• Don't start coding immediately but rather go slow to go fast

Among the many comments that are so wonderfully diametrically opposed, the post I found most interesting is the one that I feel does the best job of summarizing the key lesson I suggest readers take away from this article and its associated thread of comments -

...all the perplexities, confusion and distress surrounding IT requirements arise not from a penury of conviction or resources, nor from a paucity of our virtues, so much as playing downright ignorance on assessing "how much" of the requirements management practice is really needed in an organization for the success of IT projects. Of course, "how much" will need vary from organization to organization and project to project.

The author of this reader comment does a great job of summarizing a key tenet that we hold true at Seilevel. There is absolutely no one-size-fits-all approach to requirements. Every system and every organization faces unique challenges that require an approach tailored to that precise situation. Not recognizing this issue is one of the key factors that can lead an organization down the path towards requirements disaster.

How many Product Managers out there have been sent by senior management on a mission to find "the answer" for their organization's requirements problems only to come back frustrated. Why is this? Because the simple fact is that there is no single answer but rather a whole host of solutions that a Product Manager must be skilled and knowledgeable enough to pick and choose from. Rather than snipe hunting for the silver bullet, the most successful Product Managers realize that successful requirements strategies fall along a normal distribution that ranges from informal, lightweight techniques to formal, ironclad processes. From this distribution they must pick and choose the tools and techniques that will best solve the problem at hand. Now, I have to say that I believe too many organizations have picked too often from the informal end of the distribution, but that is a discussion for another post...

The Most Important Thing

Last night I was interviewing a candidate and I asked him to tell me the value of a recent project for which he was the lead business analyst. He asked me what I meant and I clarified by asking him to tell me why was the project being done at all. He quickly replied "To facilitate the transfer of data between systems". Now I don't know what comes to mind when you first hear that, but I still had no idea of the value of the system. I mentioned that all enterprise software systems facilitate the transfer of data between systems. He thought for a moment, then went on to explain that the new system was going to be easier to use and would be easier to maintain than the legacy system that it was replacing. In fact it had the same functionality of the original system, it was a new easier to use platform. At this point I moved on, but it started me thinking about a topic that has come up recently in the office that I like to call "the most important thing".

What is "the most important thing"? Well if you have an MBA or if you are pretentious you might want to call it the primary user enhancement, killer functionality or crititical strategic functionality. I simply call it the most important thing. The most important thing is the key reason for why the software or software release exists.

On a recent project, the most important thing was to get a stable alpha release of development tools into the hands of client software developers ('the client") so that they could begin building on top of it. The most important thing implied a set of minimum functionality that had to work to allow the client to compile and debug their software. During the lifecycle of this first phase, many team members kept trying to add functionality such as nifty features to manipulate the hardware in various ways or code optimization features. Those features would eventually be important, just not for this first release. Keeping focus on the very simply stated purpose of this release allowed us to easily determine if something was in or out of scope and after much repetition, eventually people on the team were able to have this same focus. Based on this we managed to prevent a radical increase in scope.

On another project I was on a few years ago, we sat down with the client team and began discussing their complete list of features that "had to be done". Once the high level list was complete, we ran them through some estimating excercises to get a view of how long it would take. The developers kept saying they could implement 100% of the functionality on the list by the deadline, so the business team was delighted and was ready to go. We didn't think it was possible for them to complete even 50% of the functionality, so rather than try to figure out the maximum that could be done given the time constraints, we began having them cut scope by focusing on the most important thing. In this particular case it was key functionality that would allow the client to significantly reduce the time their call center reps spent on the phone with each customer. By the end of planning, we had cut 80% of the original scope. As it turns out, the development team struggled to finish even 20% of the functionality before the cutoff date, but they did deploy on time. Imagine what would have happened if they tried to deploy the original functionality.

We see this all the time, especially from very smart people. They get excited by the infinite possibilities of what could be and forget about what is really important.

My interviewee was actually very smart and seemed to have good consulting skills, so he wasn't hopeless, but if we bring him on board, we will definitely be teaching him to always think about the most important thing.

Cnotxet is ciritacl

I came across this the other day. It is a meme that has been making its way around the net for the past couple of years and purports to show how the mind is able to make sense out of jumbled words as long as the first and last letters are correct. Here is an excerpt –

Cdnuolt blveiee taht I cluod aulaclty uesdnatnrd waht I was rdanieg. The phaonmneal pweor of the hmuan mnid. Aoccdrnig to rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoatnt tihng is taht the frist and lsat ltteer be in the rghit pclae.

Regardless of whether the post accurately represents the science, I think it touches on something about human cognition that is critical in the world of requirements - context is key. In the excerpt above, it was an understanding of the context that allowed you to parse "cluod" in the first sentence as "could" rather than "cloud."

Where this subject falls into the realm of requirements is as it pertains to use cases. Conversations between business users and developers will too often have a low signal to noise ratio. Each group has a different lens through which they view the world, a difference in perception that can get in the way of understanding those who do not share the same vantage point. Use cases, when done right, provide the necessary context within which business users and developers can effectively discuss a system under development. By distilling a problem to its essence and stripping away jargon and other unclear language, well-written use cases can act as the common reference point needed for development of a shared understanding among a diverse population of stakeholders.

Of course, the creation of use cases most assuredly doesn't mean that you can randomly start swapping letters in your requirements documents. Their presence will give you a significant advantage however when downstream consumers of the specifications are able to place your intent within the proper business context. Although they are certainly not the panacea that some may claim, the context that use cases provide makes them a powerful weapon within the overall requirements arsenal nonetheless.

Everybody's Favorite Topic, Software Requirements

Don't blame me if the title of this seems a bit sarcastic; it's the opening line Karl Weigers gives for his webinar, Software Requirements: 10 Traps to Avoid.

Personally, I enjoyed the webinar. I thought his introduction, covering the hierarchy of software requriements (scope--use cases--functional requirements) was a good introduction that too many analysts and developers are still missing. And maybe it's because of a recent project I was on, but I also appreciated his emphasis on getting actual users (and not just managers or self-proclaimed experts) involved.

Here is a description of the talk:

Successful software projects are built on a foundation of well-understood requirements. However, many development organizations get caught in traps that prevent them from effectively collecting, documenting, or managing their requirements. This presentation describes ten typical requirements problems that can sabotage your project. Several symptoms that indicate you might be getting caught in each trap are described, along with suggestions for avoiding or escaping from the trap. The requirements traps discussed are:

• Confusion about what a requirement is
• Inadequate customer involvement
• Vague and ambiguous requirements
• Unprioritized requirements
• Building functionality no one uses
• Analysis paralysis
• Scope creep
• Inadequate requirements change process
• Insufficient change impact analysis
• Inadequate requirements version control

Karl Wiegers is Principal Consultant with Process Impact and is considered an expert in the field of software requirements, in part due to the books he has authored. The webinar was sponsored by MKS.

A story about usability

Earlier this morning I was working on my first blog post. If I can ever find it again, the topic will be "the most important thing". Unfortunately you will have to wait on that posting and instead read this, my second blog post, first. All of this probably sounds a little confusing, because it is. And that is a nice segue into the topic of this posting, use cases and usability.

As product managers, in the rush to get a product out the door, we often times simply create a checklist of features against which we measure our success. The marketing department may even put that checklist of features on the product box, demonstrating the obvious superiority of your product against the competition. This may get users to buy your product, but the rubber meets the road when it comes time for the user to test drive your product for the first time. If novice users can't easily figure out how to access the features, the features might as well not be there.

This is where use cases and usability come into play. A use case focuses on the steps required to solve a particular problem. Usability focuses on making it obvious how to solve the problem.

From the time your users swipe their credit card to buy your software, to the time when they retire your software for the next great version, their contact with your software can be described by a series of use cases. As a product manager, your job is to understand who will use your software and what problems they have. Then based on your understanding, design the software to solve those problems. With use cases you do this by analyzing the specific steps that your users will take without concern for the interface, it is the essence of the user's job.

There are an infinite set of interfaces that could implement a given use case. Usability testing validates that the interface that you have designed allows easy access to the use case. Something as simple as mixing a clickable graphic with clickable text can throw a user off but you probably wouldn't even realize that it is an issue unless you tested your interface.

So back to my lost post. This morning I started my post then I had to rush off to a meeting, so I selected the save as draft button planning to finish it later. I thought to myself, hey that’s nice; I don't have to write my post all at once. This afternoon, I had a few spare moments, so I thought I would add a little bit more to the posting. I selected http://seilevel.blogspot.com from my favorites and was presented with the Seilevel blog. Looking at the website, along the top I was conveniently given the following options, "search this blog", "search all blogs", "Blog This", "Get Your Own Blog", "Flag", "Next Blog". Down the right hand side, I was given the option to select the various names associated with the blog, links to the Seilevel home page and the archives of old postings. The first thought that came to me was "How the hell do I edit my old post??". I selected every single option and not a single one of them did what I needed, so I selected blog this and started to write this post.

Right around the time that I was listing out all the selectable options in the last paragraph, my mouse hovered over the "I power blogger" graphic in the lower right corner. The status bar indicated that the link would take me to http://www.blogger.com. I thought, that's not helpful either.

I got lucky and clicked it anyway and lo, it didn’t take me to http://www.blogger.com, but to http://www.blogger.com/home and a page where it was obvious that I could edit my posts. As an experienced user I will never have this problem again, but you must remember that all your users are novices in the beginning.

It is fine to want to focus on the features of your system. But if you fail to focus on how the user will interact with your software, not only will your users need a lot of luck, but so will you.

Is it possible to overemphasize functional requirements?

Roger Cauvin had an interesting post the other day where he stated that "most organizations place too much emphasis on functional requirements." The following day he expanded on this position by concluding that the overemphasis on functional requirements is detrimental to product development because "it shows the product manager dipped into design and failed to document true requirements."

Although I think Roger raises an interesting question that begs further exploration, I must say that he absolutely failed to sell me on his primary thesis. I would parse his conclusion, as quoted above, into its two component assertions:

A) Creating functional requirements must involve dipping into design
B) Creating functional requirements must involve a failure to document true requirements

Perhaps this boils down to a question of semantics with Roger's terminology, but it doesn't seem that way to me. Yes, the boundary between requirements and design can be hazy and many a Product Manager has strayed too far, but I have seen examples too numerous to count of well-written requirements that held firm to "what not how." At the same time, and most certainly not by coincidence, these well-written functional requirements were the direct outgrowth of a solid documentation of the underlying true business/user requirements. I would suggest that the former naturally flows from the latter, at least in the hands of a skilled Product Manager.

Having seen this question raised, I most certainly feel it is one that deserves a more extensive discussion at some point in the future. We'll put it into the blog hopper with a plan to tackle it a little later on.