Welcome to our new site version. Your web page bookmarks may have changed, please search for pages by title to update them. Having problems ? Please try clearing your web browser cache and hard-reloading your web page first before contacting our webmaster.

Deficiencies of MIL-STD-499B Draft Fig B Version: 6 May 1994

[document] Submitted on 13 January, 2010 - 05:05
Keywords defense standard
Metadata
Document identifier
PPA-XB10-001766-1
Date published
2003
Language of Attachment(s)
English
Document type
technical commentary
Pages
1
Defines standard
Referenced standards and/or methodologies
Replaced/Superseded by document(s)
Cancelled by
Amended by
File MIME type Size (KB) Language Download
DeficienciesofMIL_STD_499B.doc application/msword   21.5 KB English DOWNLOAD!
File attachments
Extract(s)

1.Makes no provision for concurrent engineering.

2.Uses the term “Functional Analysis” synonymously with “develop functional solution”, ignoring the fact that functional analysis is a technique, which has application in both requirements analysis and design.

3.Uses the term “Allocation” in an unconventional way (flow down of performance from requirements level functions to solution level functions) rather than the conventional (allocate a solution level function to a system element for the performance of that function).

4.“Requirements Loop” emphasizes iteration between functional requirements and functional design, which is an undesirable emphasis, and in any event, any iteration applies no less to physical design (synthesis). Any need for iteration between requirements and design is to be minimised through effective capture and validation (requirement analysis), not emphasized.

5.System Analysis and Control mixes up engineering management, verification and mainstream design decision-making activities in an undesirable way.

6.System Analysis advocates technical reviews for progress measurement, not design verification.

7.Verification is not shown for Functional Analysis / Allocation.

8.The diagram places effectiveness analysis / trade studies / design decision making outside of the design loop. This is neither logical nor helpful.

9.The engineering management activities list is seriously incomplete (under “Systems Analysis and Control).

10.There is no recognition of validation or product verification or integration.

11.The words “design constraint requirements”, “balanced system solutions” are used loosely.

12.The list of outputs is seriously incomplete.

Organisation(s)
Author(s)
Visit also