The Regenerate Web

OK! So everyone who has had received requirements for a project that were inadequate please raise your hand.  What about requirements that were difficult to determine if they were adequate without rewriting them from scratch?  What about requirements that primarily describe the current situation, and not the desired future state?  How about requirements that are written more as a functional specification (I need a report that has these data elements with this sorting grouping and formatting)?  Sometimes it is hard to distinguish the commentary about the current environment or about the proposed changes to the environment from the actual requirements.  My personal favorite is the "laundry list" or as my favorite radio station's slogan says "Everything! In no particular order."

Alright, I am done ranting now, no need to call security.  What I want to talk about is a model for organizing requirements so that the adequacy is somewhat self evident.  To my eyes, this means that they have integrity (no obvious internal conflicts or ambiguity) and they are of sufficient quality to allow us to move forward.  I am setting my scope around high level business requirements for software development projects.  There are plenty of issues here, and I think, broad applicability to other domains.

Adequate Software Requirements

What does it mean to have adequate software requirements?  Perhaps this is the starting point.  Adequacy in software requirements should be defined in terms of whether they are sufficient to allow the development of a solution proposal.  

Value Targets

When writing a solution proposal, I prefer to use the business value request to define the target of my delivery.  The primary business value target is the answer to the question, "What's in it for me?" from the perspective of the requester.  When the analyst starts sniffing around, he or she may uncover other business value targets.  The primary target should also answer the essential WHY question from the requester's point of view.  Any other targets that are identified can be considered a bonus, but there achievement should not reduce or mitigate the achievement of the primary target.

Solution Constraints or Criteria

After I have the business value target(s) defined, I need to constrain my solution.  This is not unlike the qualification process that a salesperson uses to determine which product customer is most likely do be satisfied with, or ultimately purchase.  Solution constraints or criteria define the boundaries around an acceptable solution.  These constraints can be cost, delivery schedule, but mostly should be functional, defining WHAT should be in the box.  Constraints say, if you can overcome these obstacles, I'll buy your product (implement your solution).

Context Description

It is important to define the environment in which the solution must work.  That might include how the problem fits into the overall business process, interfaces with other business units or companies, character of existing staff.  Add to this any changes in context that management is contemplating.  Software delivery almost always contemplates some change in business process - buried in the value targets, there is usually some implied change.  This needs to be teased out and made explicit (a hedge against requirements that only contemplate current context).  Moreover, for a complex software development program, involving multiple concurrent and/or sequential delivery cycles, the context is the part of the requirements that allows us to see how each piece fits into the whole.  

Separate Solution Proposal?

My primary point is that requirements are adequate without a solution proposal.  The practical implication of this is that the solution proposal can (and should) exist separate from the requirements.  This is a point of contention with projects that are managed within a single organization, and a difference between a consulting approach and typical in-house or monopolized approaches.  Why is it different?  I submit that this is because the consulting approach does not assume that it has won the business.  A project that is managed in-house is free to assume that it is not competing against other solutions, an assumption that is never valid for external projects.  If we were to prepare requirements as if we were going to farm the project out, letting the best consulting firms in the world propose solutions, we certainly would have to separate the requirements from the solution proposal.  So isn't the combination of these two steps a short-cut that we are allowed to take in internally managed projects?  

A Valid Shortcut?

As I think about this, my experience tells me that for smaller, lower risk projects, where the number of possible solutions is small, the shortcut may be valid, and combining requirements and solution proposal may save time and effort.  I think for riskier projects, with more unknown domains, especially those that contemplate significant changes to business process, that this shortcut leads to ossification that inhibits the solution from evolving in response to progressive elaboration of requirements (i.e. as we remove risk factors, solve unknowns, and the business process change becomes more apparent.)  I believe that the reasons for this are:

1. It represents an assumption that is difficult to challenge, because instead of sounding like a proposal (which you are supposed to challenge) it sounds like a requirement.  It gives extra weight to the embedded solution proposal, that causes a hardening or stiffening that impedes change.  
2. The requirements cast the shape of the solution, an image which becomes tangible over time, and as such resistant to change.  Much like the architect's rendering for a new building, it becomes ingrained in the mind of the requester.  Thus the solution (the package in which we deliver value), actually becomes part of the requirements, rather than simply a vehicle for delivery. 
3. Since we monopolize a solution (by embedding it in requirements), it becomes "THE" solution, rather than "A" solution.  It becomes difficult to remain objective about the solution and the challenges and alternatives to the approach are not evaluated as tenaciously.  I have often seen this in the context of available vended solutions that inform the requirements.  While there is nothing wrong with having outside information inform the requirements, one must be careful to abstract the requirements, so that they don't conform to the image of one particular solution. 
4. This opposes the value of context description, as it causes us to see each request as a stand-alone effort.  Especially with enhancements or extensions of existing solutions, this tendency is a trap.  The assumption that we are always extending or enhancing an existing solutions, can cause "feature displacement", that is we can move our solution away from it's core mission gradually, by following a chain of requests that implies a net movement of the solution core mission.  While the problem that this causes falls more in the domain of software product management, than requirements modeling, it is worth mentioning here because it can be a result of a requirements failure.

An Alternative!

So what can we do instead?  I recognize that adding additional steps in a sequential process necessarily causes delay.  I disagree with the need to have the process execute sequentially.  I simply believe that we can separate the documents, so that the solution proposal(s) can stand alone.  In fact, I am convinced that if we have the right people during the "discovery" phase of a project, we can contemplate many aspects of design in parallel with the elicitation of requirements.  I believe that this parallelism is healthy, because it drives us to a deeper understanding of the problem domains.  

As a software developers, systems analysts, and engineers, our mission is to provide solutions.  Our value proposition is always in the solution.  We probably can't help envisioning a series of solutions while we are immersing ourselves in the problem domain(s).  It is part of how we learn, how we build our mental maps.  For the vast majority of analysts that I know (especially those that grew out of software development), the solutions are always rattling around in the background, and one merely need to open the tap, for them to pour out.  In fact, it can require significant discipline to keep that tap closed.

Why we should

If we can refrain from embedding this in the requirements or problem description, we can decrease the initial investment in a specific solution, or solution concept.  The longer we can delay this investment, the longer we can continue to evolve the solution before we have to get buy in.  While we need to get buy in, the longer period of adaptation and evolution we can support during solution development the more likely we are to hit our value targets.  By fixing the solution early, during the requirements, we compromise our ability to adapt and evolve the solution.