From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Thu May 06 2004 - 22:22:52 EST
=09by marcie.it.uts.edu.au (PostfixFiltered) with ESMTP id A61BA261E7
=09for <re-online@it.uts.edu.au>; Thu, 6 May 2004 21:27:50 +1000 (EST)
Received: from hotmail.com (bay12-f88.bay12.hotmail.com [64.4.35.88])
=09by filter.it.uts.edu.au (Postfix) with ESMTP id DB5741D640B
=09for <re-online@it.uts.edu.au>; Thu, 6 May 2004 21:27:43 +1000 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
=09 Thu, 6 May 2004 04:27:42 -0700
Received: from 151.201.223.133 by by12fd.bay12.hotmail.msn.com with HTTP;
=09Thu, 06 May 2004 11:27:41 GMT
X-Originating-IP: [151.201.223.133] X-Originating-Email: [donald_firesmith@hotmail.com] X-Sender: donald_firesmith@hotmail.com
Often in this forum, I have heard the phrase "levels of requirements" used in to mean Business/Stakeholder/User requirements vs. Technical/System/Software requirements as if implying that there are ownly two sets of requirements. Sometimes, the phrase means system vs. software requirements. Sometimes, I have also heard the phrase to mean a decomposition of functional requirements or use cases.
I was wondering what experience and ideas people have with the following
situation:
Someone (typically a government agency such as the department of defense) i=
s
acquiring a very large and complex system of systems, network of systems, o=
r
family of systems. These systems are true systems (i.e., systems
engineering as opposed to software engineering) in that they consist of
hundreds of data components, hardware components (many pure hardware withou=
t
any software at all), software components, procedural components,
facilities, materials, and possibly personnel components. These systems ar=
e
so large that they are hierarchically decomposed into between 3 to 7 tiers
before individual hardware and software configuration items are found.
Thus, software requirements may be 7 tiers down and traditional system
requirements may be 5-6 tiers down in the tier structure. There is also a
significant chance of contractual separation between stakeholders,
stakeholder representatives, acquisition personnel, prime contractors,
partners of prime contractors, subcontractors, and vendors, as these
requirements are passed down and derived down through this tier structure.
In a structure this huge and contractually separated, there is essentially
zero chance that different organizations are using the same or similar
requirements engineering processes or tools, making requirements tracing
very difficult. As an example of such a system of systems, consider the
acquisition of a new fighter aircraft which consists of the aircraft itself=
,
its ground-based maintenance facilities and equipment, and its training
system. The aircraft consists of may systems (e.g., cockpit, engines,
flight surfaces, weapons systems, sensor systems, avionics, mission systems=
)
which in turn are decomposed into many subsubsystems, and so on down. Many
of the subject matter experts are experts in engines, flight surfaces,
avionics, weapons, etc. Few are systems engineers (per se) and very few
have significant software experience. Primary stakeholders/users are
pilots, maintenance personnel, and trainers.
What recommendations and observations do people have regarding:
1) How requirements should be engineered (e.g., elicited, analyzed,
specified, and managed)?
2) How tools should be integrated?
3) How should requirements be flowed down from tier to tier and organizatio=
n
to organization?
4) How should requirements related risks be managed?
5) How should requirements be evaluated?
Donald Firesmith
Senior Member of the Technical Staff
Acquisition Support Program
Software Engineering Institute (SEI)
Carnegie Mellon University (CMU)
Pittsburgh, PA 15213-3890
(412) 268-6874
dgf@sei.cmu.edu
http://www.donald-firesmith.com
This archive was generated by hypermail 2.1.6 : Mon May 10 2004 - 09:00:17 EST