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
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.
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
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).