Re: Be a Requirements Expert

["Nancy Osterhout" <blubird -at- gte -dot- net>]

-----Original Message-----
On April 26, Tara Charter wrote:
<snip> WANTED: Persons interested in Requirements
Engineering, Persons with knowledge of any Requirements
education classes or seminars, or Persons interested in
teaching others what they know about Requirements
Engineering.</snip>

and Patricia Jackson wrote:
<snip> I would be interested in locating a good book about
requirements engineering -- or online-course or local course
offering. </snip>

<><><><><><><><><><><><><><><><><><><><><>

This is actually a very interesting topic to me, as well.
For writing on my current contract in a software development
group, I've learned quite a lot from these resources.  Maybe
one will be of help to you...

Source #1

**  Software Requirements:  Practical techniques for
gathering and managing requirements throughout the product
development cycle
(Karl E. Wiegers). Copyright 1999.  Published by Microsoft
Press.  ISBN 0-7356-0631-5

This book describes practical techniques to manage the
requirements engineering process all the way through the
development cycle.  It includes tools to facilitate
communication between users, developers, and management.  It
has real-world case examples and specific steps to put a
variety of process-improvement principles into practice.

The audience for this book is not only engineers but for
non-engineer types as well. The purpose is to improve folks'
understanding of the role that requirements play in the
development process.  It's simple enough that generic
inferences can be made to requirements for products other
than software and descriptive enough to educate software
development types.

Source #2

**  Practical Software Requirements:  A manual of content
and style
(Benjamin L. Kovitz).
Copyright 1999.  Published by the Manning Publications Co.,
32 Lafayette
Place, Greenwich, CT 06830 (fax 203.661.9018).  Email:
orders -at- manning -dot- com -dot- 
I ordered it from my local Barnes & Noble.

This book tells how to write a "requirements document"
(describing desired effects to be produced by the software)
and a "program specification" or "interface design"
(describing the outward behavior of the computer that
produces those effects).

The author has been a programmer, tester, system analyst,
user-interface designer, and TECH WRITER.  For electronic
browsing of this book, see
http://www.manning.com/Kovitz/index.html.

When you buy it, you get free access to a private Internet
forum where you can make comments about the book, ask
technical questions, and receive help from the author and
from other readers.

The ad on the back cover of this book is descriptive enough
to include here:

"Why don't people read requirements documents?  That's the
problem solved by this book by focusing on what belongs in
the document and how to write it so people can read,
understand, and use it.  With Practical Software
Requirements you will give programmers, testers,
user-interface designers, and tech writers all the
information they need to do their jobs... The book offers
practical advice like how to word a definition, how to name
states and events, and even how to avoid boring the reader.
.. Whether you're a programmer or a project manager writing
requirements for the first time -- or an experienced system
analyst - this book will help you do it skillfully and
effectively."

Source #3

**  Then, there's always NASA/SATC (Software Assurance
Technology Center), purely for the task of documenting the
requirements.

http://satc.gsfc.nasa.gov/support/STC_APR97/write/writert.do
c

Source #4

**  NASA even has a documentation quality measurement tool
(ARM):

http://satc.gsfc.nasa.gov/tools/index.html

Source #5

**  Requirements Engineering:  A Good Practice Guide
(Sommerville and Sawyer), John Wiley & Sons, ISBN O 471 9744
7

http://www.comp.lancs.ac.uk/computing/resources/re-gpg/

I haven't read it, but the site for the book has lots of
links to keep anyone busy.

Source #6

**  Of course, the CMM (Capability Maturity Model for
software) has much to say about Requirements Management,
which is one of the Key Practice Areas necessary to reach
Level 2 maturity for software development.

http://rbse.jsc.nasa.gov/CMM/TR25/tr25_l2a.html

Hope this helps.