Re: Business and Technology Requirements documents

[Ruth Glaser <ruthg -at- GORETEK -dot- COM>]

Gaye,

Some too obvious advice:

Start your group thinking about what the document will be used for.
Make sure it is not documentation for the sake of documentation. It
should aid in the development process or it should not be done.

Typically in development arenas, Business Requirements (B.R.) and
Technology Requirements (T.R.) (sometimes part of a Marketing
Spec) are used to narrow the domain of the project. It is used to
facilitate definition of the problem, as opposed to define the solution to
the problem, which is what a design spec does.

At some point this document should be frozen and all appropriate
managers involved should sign off on it. This prevents a product
from shipping and the VP of Sales asking, "But where's the dinglefutz
feature? All of our neenoo customers need dinglefutzes!" You can
calmly point to the B.R. / T.R. and say that neenoos were never
defined as part of the target market, therefore dinglefutzes never
surfaced as a requirement. The VP will know long before the product
ships that your product will not include dinglefutzes.

The likely players developing this document will include marketeers,
managers, application developers (including programmers, testers,
and writers), system architects, customer implementers. Of course
you'll also have input from customers, but that should occur before
writing the document.  You may want to pass the document (or parts
of it) through a user group review to make sure you haven't overlooked
anything and to get support from your customer base.

Before you can determine the business requirements and technical
requirements of your customer and your proposed solution, you
need to answer the following questions. You will need to include all
roles capable of answering these questions:

Why are we developing a new product?
What is the general market for our product?
What is the industry environment?
What is the target market of our current product?
Are we going to try to maintain those customers? If yes,
        What is the current customer size in $'s and people?
        What are the SIC codes of current customers?
What is the future target market?
        What are the SIC codes of potential customers?
        What is the target customer size in $'s and people?
Who are our competitors?
Can we specify SIC codes in our target industry that we are
        not going to target?
Are the potential customers willing to pay to upgrade/buy new
        product?
Are there any geographical considerations? (Strictly US customers,
        or international? What considerations does this lead to?)
What business needs does the product solve?
What qualities does the product have?
Why would a customer buy this new product?
What requirements do we, the developers, have? (For example,
        do we require a short product life cycle, a specific development
        methodology, etc.)
What do we sell (from a marketing perspective)?
What do we sell (from an architectural perspective)?

The answers to these questions should be explicitly stated. They should
lead to your business and technical requirements.

Good luck.

Ruth
rglaser -at- nxtrend -dot- com

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html