From: wisniews@saifr00.cfsat.honeywell.com (Joe Wisniewski)
Newsgroups: comp.lang.ada
Subject: Requirements Data Dictionary
Date: 28 Aug 92 22:51:44 GMT
Distribution: inet
Organization: Honeywell Air Transport Systems Division

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 th




ose 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 requireme




nts 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...."