Requirements & the MRD

One of the fundamental goals of developing good software is to know what you are and are not building.  In addition, it's at least as important to know you are making these decisions, as you will need to revisit them time and again during the development process.  How can this be accomplished ?  By working VERY HARD up front to understand the problem and the solution you are proposing to build.  

Many projects skip this step altogether or just write up some simple marketing requirements to get started.  This is often a fatal mistake, as every hour spent in this process will save 10 or more later - it is impossible to overstate the importance of both the Requirements and Design steps of the development process.  This is where issues get worked out and decisions made by forward-looking individuals that will save enormous time and energy later in the process.  It is simply vastly easier to make changes to systems while they are still on paper; changes incurred at later steps are increasingly costly.  Again, it is nearly impossible to spend too much time here.  

What are the the MRD ?  It is the Marketing Requirements Document and will often run 50-100 pages.  It includes the underlying assumptions of the market, what the needs are, and how they will be addressed.  One of the most important components of a good MRD is the decisions document - this is so often overlooked that few people have heard of it, but it is crucial to a successful development process.

Overview & Timing

Provide an overview of the product, including who the key players are (consumer, web site, publishers, etc.), their general needs and the phasing or timelines associated with the project.  This section should also include the competitive advantages of the product, if applicable; this will assist everyone in keeping their eye on the competitive ball as things evolve.

Performance Metrics

Include ways to measure how large and fast the system will be.  What other key elements of perceived performance are there ?  How about other constraints ?  These factors tend to drive much of the rest of the discussion, so laying out and justifying these elements up front helps avoid problems later on.

Decision Documents

The decision document describes all of the issues, questions and decisions made during the constructions of the MRD.  Why, you might ask, should you track those ?  Two reasons:  1) to drive decisions and 2) to document why something was done.

Most projects and their requirements consist of interlocking and interdependent issues, where changes in one area usually negatively affects elements of other areas.  It is usually fairly difficult to keep things moving because of all the uncertainty in the process, especially if the market is a new one.  A decision document defines which decisions are needed by when and helps make them happen.

Once a decision is made, it's documented in terms of the outcome, the alternatives and the rationale.  This is extremely useful later in the process when certain decisions need to be re-examined, as so often happens in a dynamic process.  It's often very difficult to recall why something was chosen three, six or nine months ago when another route seems much better; knowing that those routes were examined and why a choice was made will save time down the road. 

It's also important to recall the old adage: "It's more important to make a decision, right or wrong, than to to make no decision at all."  This is very true when designing systems - we all want to make the right decision, but the process has to keep moving forward (quickly), so sometimes you just have to make a WAG (wild-ass guess).  The decision document and associated timeline forces things to happen in the right sequence, speeding things along.

Product Needs & Goals

Another key component of an MRD is the product needs/goals - This should be fairly simple, as we know what we want it to do; might set goals on number of connections, basic features, etc. But, must include support, diagnostics, profiling and logging requirements, which are integral to products and at least as important as main features (not afterthoughts).  In addition, revenue streams, pricing models and general priorities need to be outlined, as these may drive feature set selection and especially the paring down of features are production looms.

The Actual Requirements 

This section talks about the detailed issues and requirements of the system, the individual features, the key user interfaces, the reports and outputs, etc.  Be as specific as possible and don't forget the non-core elements, such as administration, security, and support processes that so often get neglected.

Here is where all the high-level, marketing and customer-facing issues are worked out, in detail.  Discuss general cases, exceptions, special handling, and everything the system can do.

The Proposed Solutions 

This is how the system will address the requirements, at a high level.  How will things work from the customer's point of view ?  What are the integration points ?  What will reports and user interfaces look like, at least on a level that can be understood (as the real interfaces will change significantly during development).