Software requirements

[Beth Agnew]

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: http://bethbuzz.blogspot.com
STC Presentation archived at:
http://www.301url.com/podcasting

Professor, Technical Communication
Seneca College of Applied Arts & Technology
Toronto, ON 416.491.5050 x3133
http://www.tinyurl.com/83u5u