From: wisniews@saifr00.cfsat.honeywell.com (Joe Wisniewski)
Subject: Requirements Data Dictionary
Organization: Honeywell Air Transport Systems Division
Distribution: inet
Date: Fri, 28 Aug 92 22:57:43 GMT

There may other newsgroups for which this posting is more appropriate, but since this occurring on a
big Ada project (Boeing 777), I thought that it would be of interest.

The issue of concern has to do with requirements data dictionaries (RDD) and design and code data 
dictionaries (ADD) for application data dictionary. By the time you are through reading this it may 
not be clear what I am asking for. Please be patient. I'll get there.

The requirements analysis phase around here is pretty much the "good ol'" functional decompostion 
"method". Although a study was performed during the requirements phase to determine appropriate 
requiements analysis and design methodologies and oo techniques were the "winners", oora and ood 
techniques are for the vast majority of the project, not being done. Please, don't ask me how they 
decide to define a good package structure and not have a traceability nightmare on their hands. 
I have deep scars over those battles.


 Anyhow, there was an attempt to try and use strict Hatley/Pirbhai. but for the most part it is 
just good old functional decomp. Our small  group however was able to convince our management to 
try an object-oriented requirements analysis approach (Seidewitz and Stark method) after we had 
done a standard functional decomp approach (We are not maintaining the functional decomp approach.) 
The rest of the program pretty much used IDEs StP (with bubbles and data flows, STDs, etc.) to 
do their software requirements analysis. Data Flows represent their external and major internal 
data flows.

Now, to the point. There are those on the program who feel that there is a need to be able to 
automatically map the requirements data flows to design and code data flows. It has been very 
difficult to try and convince some people that there is not necessarily a direct algorithmic 
mapping between requirements data flows between requirements bubbles and code data flows. This 
is not just a funct. decomp vs. oo issue. If I were to implement a system using strict functional 
decomp techniques, there is still no guarantee of a direct mapping, much less than when one is 
trying to map major internal requirements data flows between "requirments bubbles" and design 
classes/code packages or whatever.

I understand the need to be able to efficiently perform regression checks due to major exteral 
data flow changes that flow into the system. A tremendous amount of time and effort is being 
spent working on this RDD/ADD issue with marginal perceived benefit.

What kind of experiences have you all had out there concerning this issue. What are lessons 
learned on this topic? Is it worth spending a lot of time and effort and mucho denaro having 
an RDD/ADD mapping? 

If anyone is interested in the merits and pitfalls of the oo approach we used/are using. 
email me directly and i'd be happy to fill you in.


Thanx ahead of time.

Joe Wisniewski
Honeywll ATSD
M/S 2M34E4
Box 21111
Phoenix, Arizona 85036-1111

<wisniews@saifr00.cfsat.honeywell.com>

"The opinins expressed are strictly my own...."
Newsgroups: comp.lang.ada