Re: Software requirements

Subject: Re: Software requirements
From: Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca>
To: Ladonna Weeks <ladonna -dot- weeks -at- comtrak -dot- com>
Date: Wed, 23 Aug 2006 22:18:55 -0400

A good working process is requirements (what the product, any product, is supposed to do to meet the needs of the market) first, then specifications (details on how the product is going to match each requirement), and finally design, which is the manifestation of the requirements according to the specifications. Test cases, i.e., QA, usually ensure that the product meets specifications. I don't think you can adequately capture such design features as you're talking about without indeed getting into the details. The thing has to become very detailed and specific at some point. Leaving requirements up to the developers to interpret is fraught with problems. Much better to hammer out the specifications which detail the design, so that all the developers have to do is build it. If they run into an implementation problem, such that they cannot build to specification without changing the design, then there should be a process for working that solution through the requirements/specifications/design process. All kinds of insanity result when developers just change things as they go along.

Making specifications afterward based on the designed product seems to me to go at things wrong way round, but a lot of companies do that to ensure their specifications are correct. Of course, you then get what the developers have decided you'll get. Hope you've at least got a business analyst and a systems analyst working with them on that.

The marketing requirements in the example you gave would be that the customer needs to be able to pre-determine a time period during which a random reboot will occur. Specifications say that this can be any time period from 1 to 24 hours, with a default of a 5 hour period. Your #3, the 10:00 a.m. local time, actually conflicts with the first two. It is not random, nor is it a period, but a fixed point in time -- but perhaps it's related to something else and not the first two points.

I'm a firm believer in detailed specifications. Very few products go wrong when the specifications are thorough, detailed, completed, and followed. It's when the specs and the design get out of sync that problems occur.

Ladonna Weeks wrote:

One of my TW duties is to help with an internal web site that contains
requirements for our new product.The requirments are stated in very general
terms in order to leave opportunity for the developers to design the
product. Here are a few examples:
1. It shall be possible to set a time period during which the [product] will
reboot at a random time during the set time period. 2. The set time period shall be from 1 to 24 hours. Default shall be 5. 3. Default time shall be 10:00 AM local time. We are writing a test case for each requirement. However, we have come to
realize that during testing we need some kind of specifications that
describe the behavior of the product as it ends up being designed so that
something in the GUI or functionality doesn't get accidentally changed after
the customer has become accustomed to it. The person writing the
requirements has come up with the notion of including design features after
the fact which describe how the product works. When we test, we would test
against the requirements _and_ the design features.
I am trying to figure out how to write these design features without getting buried
in details. Have any of you dealt with a similar problem?
Beth Agnew
Catch the Buzz:
STC Presentation archived at:

Professor, Technical Communication
Seneca College of Applied Arts & Technology
Toronto, ON 416.491.5050 x3133


WebWorks ePublisher Pro for Word features support for every major Help format plus PDF, HTML and more. Flexible, precise, and efficient content delivery. Try it today!

Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
To unsubscribe send a blank email to techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.

Software requirements: From: Ladonna Weeks

Previous by Author: Re: Microsoft optical mouse scroll wheel not functional in Framemaker 7.0
Next by Author: Re: Software requirements
Previous by Thread: Software requirements
Next by Thread: RE: Software requirements

What this post helpful? Share it with friends and colleagues:

Sponsored Ads