🚀 go-pugleaf

The idea of reusing analysis and design components of software development
efforts is very interesting to me.  In fact, as someone who has been
involved primarily with the analysis and design "phases" of projects for a
number of years, it may rank as one of my *major* interests. :-)

Here's my problem. The information associated with the analysis and design
must somehow be documented, or it can only be reused by the people who were
around when the original analysis and design were done.  Typically we have
'encoded' some of this information in specifications either in English (or
other native language) or by using some diagraming technique. Actually,
what we have recorded is the *results* of the analysis and design. The
analysis and design effort took place in meetings, discussions, etc. which
may or may not have been documented through letters, meeting notes,
technical notes, etc.

As an individual, I have maintained analysis and design information from
past projects, and have made use of (some of) it on new projects.  The
information (handwritten papers, meeting notes, letters, faxs, paper
napkins with preliminary design diagrams on them, etc.) is currently
organized in chronological order, by project. As such, *I* can (sometimes)
find the information which I need when it comes time to reuse it, because I
was responsible for storing it. However, just having kept the information
doesn't mean it is reusable.  At times I can't find information I know is
there, and worse, other people (even when given access to the "paper")
haven't the foggiest idea where to start, or whether the information is event
there.

Now a few questions:

  What would analysis and design information look like if I wanted that
  information to be reusable by someone other than me? (freeform text?
  structured text? defined by a specific methodology? up to the
  originator?)

  How can it be made accessible? (Linear search through 15+ binders of
  paper organized in chronological order and associated with a single
  project doesn't work!)

  Is there enough reuse possible to justify the (apparently) extra effort
  required to document more than just the results of analysis or design?
  (That is, how do I convince people who don't even want to write down the
  *results* of analysis and design (in specifications) that they should
  somehow document the information they used to produce the analysis and
  design specs?)

I hope the orignal poster will forgive me if this has gotten off of his
topic somewhat. But I believe there is at least some relationship involved.

KC Burgess Yakemovic
NCR Corporation, RSD Atlanta
email: kcby@Atlanta.ncr.com    
phone: 404-441-8135