Re: Software requirements

[Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca>]

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: