Requirements specifications are interesting to me mostly because they are meant to be in
part forecasting tools. In a fixed or unchanging environment the forecasts are both easy to make
and achieve over a projects lifetime.
Integrating an updated or new subsystem is a good example since the system is likely to
represent a 'closed' or 'fixed' environment. However, developing a Mars lander and rover is
more than mildly different. Some requirements might be:
-Don't hit the planet hard enough to damage something -Avoid landing in the wrong place -Avoid puddles of water and/or ice -Avoid the unexpected -Since this might be your first go at it avoid taking risks -Borrow a previous requirements document to get it by the reviewers
This doesn't guarentee success and it might enhance failure. Who reads this stuff after
initial approval. After this initial phase the goals are mostly concerned with realizing a
workable system (well mostly anyway; we will fix it later).
Design and development can't be made strictly dependent upon the requirements
specification, unless one likes starting over frequently.
The advanced project development environment often requires requirements specifactions
that are borderline wish lists. One can put together a requirements specification for a
global, low-cost, open-source EHR system and fail to get approval from many countries
adhering to the NIH (Not Invented Here) syndrome. Actually, one might end up waiting
for some time in individual countries for any sign that they have received the document.
The process is more important than requirements specificant for one simple reason: This
has not been done before, i.e., lacking in precedent! It puts one well outside most legal
systems in this world.
Don't mind contributing to a requirements specification as long as it does not detract from
the design/development process. The reason? When embarking upon a journey into
uncharted waters leave the map of Washington DC at home. Too much weigh to handle.
Regards!
-Thomas Clark
\Wayne Wilson wrote:
John L. Forman wrote:
http://zdnet.com.com/2100-1104_2-5135027.html
Thanks for the post. I had found the academic articles he has published, but this lay person's view is quite interesting.
This list has had a bit of tough time coming to grips with the process being more important then the design!
Here is a quote from the above article:
What are some of the differences you've found, apart from the obvious ones?
For example, in software engineering, there's a widespread view that it's necessary to elicit and capture the requirement specifications of the system to be developed so that once implemented, it's possible to pose questions as to what was implemented, compared with what was specified.
We do not see or observe or find in open-source projects any online documents that software engineers would identify as a software requirements specification. That poses the question: What problem are they solving, if they haven't written down the problem? While it's true that there's no requirements specification, what there is instead is what we've identified as a variety of software informalisms.
What do you mean by "informalism"?
That word is chosen to help compare to the practice advocated in software engineering, in which one creates a formal systems specification or design that might be delivered to the customer. Informalisms are such things as information posted on a Web page, a threaded e-mail discussion or a set of comments in source code in a project repository. It may be a set of how-tos or FAQs on how to get things accomplished. Each is a carrier of fragments of what the requirements for the system are going to be.
