System Requirements Analysis |
|
|
|
|
| Jeffrey O. Grady |
| January 2006, Academic Press, Hardcover, 986 pages, ISBN 012088514X
|
|
|
|
 |
|
Systems Requirement Analysis gives the professional systems engineer the tools to set up a proper and effective analysis of the resources, schedules and parts that will be needed in order to successfully undertake and complete any large, complex project. The text offers the reader the methodology for rationally breaking a large project down into a series of stepwise questions so that a schedule can be determined and a plan can be established for what needs to be procured, how it should be obtained, and what the likely costs in dollars, manpower and equipment will be in order to complete the project at hand.
Systems Requirement Analysis is compatible with the full range of engineering management tools now popularly used, from project management to competitive engineering to Six Sigma, and will ensure that a project gets off to a good start before it’s too late to make critical planning changes. The book can be used for either self-instruction or in the classroom, offering a wealth of detail about the advantages of requirements analysis to the individual reader or the student group.
- Author is the recognized authority on the subject of Systems Engineering, and was a founding member of the International Council on Systems Engineering (INCOSE)
- Defines an engineering system, and how it must be broken down into a series of process steps, beginning with a definition of the problems to be solved
- Complete overview of the basic principles involved in setting up a systems requirements analysis program, including how to set up the initial specifications that define the problems and parameters of an engineering program
- Covers various analytical approaches to systems requirements including: structural and functional analysis, budget calculations, and risk analysis
|
 |
|
PART 1, Introduction
1.1 Introduction to system requirements analysis
1.1.1 The Human Foundation
1.1.2 What is a System?
1.1.3 What is System Development?
1.1.4 The Fundamental System Relation
1.1.5 What is System Requirements Analysis?
1.1.6 System Requirements Analysis Timing Considerations
1.1.7 Development Approaches
1.1.8 Degree of Precedence Alternatives
1.1.9 Organizational Alternatives
1.1.10 Data Environment Alternatives
1.1.11 Some History and References
1.1.12 Overview of the Book
1.1.12.1 How it Came to Be
1.1.12.2 The Remainder of This Part
1.1.12.3 The Other Parts of This Book
1.1.13 How to Get the Most Out of the Book
1.2 System Development Process Overview
1.2.1 The Ultimate Process Step - The Enterprise Vision
1.2.2 Product Line Effects
1.2.3 Customer Base Effects
1.2.4 Structured Process Analysis and Process Definition Expansion
1.2.5 Documentation Media
1.2.6 Lower Tier Development Functionality
1.2.6.1 Grand Systems Requirements
1.2.6.1.1 Program Integration
1.2.6.1.1.1 Initial System Analysis
1.2.6.1.1.2 Publish Specifications
1.2.6.1.1.3 Traditional Structured Analysis
1.2.6.1.2 Computer Software Structured Analysis
1.2.6.1.3 Validate Requirements
1.2.7 Grand Systems Synthesis
1.2.7.1 Design Grand System
1.2.7.1.1 Item Team Preliminary Design
1.2.7.1.2 Item Team Detailed Design
1.2.7.2 Material Operations
1.2.7.3 Manufacture System
1.2.8 Grand Systems Verification
1.2.9 Grand Systems Sustainment
1.2.9.1 Logistically Support System
1.2.9.2 Deploy/Deliver Product System
1.2.9.3 Modify Product System
1.2.9.4 Dispose of System
1.2.10 Use Product System
1.2.11 Manage Program
1.2.12 Assure Product and Process Quality
1.3 Process variations
1.3.1 The Situation
1.3.1.1 The Central Model
1.3.1.2 DoD Process Rationale
1.3.1.3 Other U.S. Government Life Cycle Models
1.3.1.4 Commercial Firm Future
1.3.1.5 The JOG System Engineering Prescription For Specifications
1.3.1.5.1 Template Preparation
1.3.1.5.2 Map Templates to Functional Departments
1.3.1.5.3 Map Templates to Structured Analysis Models
1.3.1.5.4 Provide For Configuration Management of the Model Base
1.3.1.5.5 Perform Structured Analysis on Programs
1.3.1.5.6 Allocate All Requirements to Product Architecture
1.3.1.5.7 Coordinate RAS-Complete with Template Structure
1.3.1.5.8 Capture Modeling Work Products in SDD
1.3.2 Alternative Sequence Models
1.3.3 Concentrated Versus Distributed Customer Base
1.3.4 Precedented Versus Unprecedented Systems
1.3.5 The Three Gross Models
1.3.6 The Lowest Common Denominator
PART 2, Requirements Foundation
2.1 Requirements Fundamentals
2.1.1 Primitive Requirements Statement
2.1.1.1 The Essence of a Requirement
2.1.1.2 Document Style and Format
2.1.1.3 Primitive Requirement Statement Conversion
2.1.1.4 Total Effect of Changes
2.1.1.5 Variations
2.1.1.6 Document Example
2.1.2 Requirements Value Definition Methods
2.1.2.1 Why is Quantification Important?
2.1.2.2 Value Definition Methods
2.1.3 Requirements Derivation
2.1.4 Kinds of Requirements
2.1.4.1 Performance Requirements
2.1.4.2 Design Constraints
2.1.4.2.1 What is a Design Constraint
2.1.4.2.2 Design Constraints Analysis Timing
2.1.4.2.3 Major Design Constraint Categories
2.1.5 Requirements In Time
2.1.6 The Remaining Road
2.2 Requirements Traceability Relationships
2.2.1 Requirements Are Not Islands
2.2.2 Vertical Traceability
2.2.2.1 Requirements Source Traceability
2.2.2.2 Requirements Rationale Traceability
2.2.2.3 Requirements Traceability and Allocation/Flowdown
2.2.2.4 Parent-Child Requirements Traceability
2.2.2.4.1 Why Traceability?
2.2.2.4.2 Traceability Mechanism
2.2.2.4.3 Traceability Across Interfaces
2.2.2.4.4 Multiple Traceability Paths
2.2.3 Longitudinal Traceability
2.2.4 Requirements Traceability To Process
2.2.4.1 Single Sheet Traceability to Process
2.2.4.2 Specification Template Traceability
2.2.5 Grand System Traceability
2.2.6 Traceability Reporting
2.2.7 Traceability Audits
2.3 Requirements Allocation, margins and budget
2.3.1 Requirement Value Determination
2.3.2 Requirements Allocation
2.3.3 Margin Management
2.3.3.1 What Are Formal Margins?
2.3.3.2 Selection and Maintenance of Design Margin Parameters
2.3.3.3 Safety Margins
2.3.3.4 Inclusion of Margin Accounts in Requirements Data
2.3.3.5 Design Margin Account Transfers
2.3.4 Budget Management
2.4 Requirements Analysis Strategies
2.4.1 The Four Strategies
2.4.2 Freestyle Strategy
2.4.3 Cloning Strategy
2.4.3.1 Specification Standards
2.4.3.2 Like Item Approach
2.4.3.3 Parent Item, Flowdown, or Allocation Approach
2.4.3.4 Flowdown Scope Limitation
2.4.4 Question and Answer Strategy
2.3.5 Structured Analysis Strategy
PART 3, Traditional Structured Analysis
3.1 System Beginnings
3.1.1 What's In a Name?
3.1.2 In the Beginning
3.1.3 The Meaning of the Term
3.1.4 Unprecedented System Definition
3.1.4.1 Customer Interaction
3.1.4.2 Mission and Operations Analysis
3.1.4.3 MOE and Selection Criteria Development
3.1.4.4 Requirements Work
3.1.4.5 System Environmental Definition
3.1.4.6 Specialty Discipline Analyses
3.1.4.7 Concept and Program Design
3.1.4.8 Manage the Study
3.1.4.9 Program Funding Profile Requirements
3.1.5 Trade Studies
3.1.5.1 Trade Study Mechanics
3.1.5.2 Post Selection Tasks
3.1.6 Rigor Versus Creativity
3.1.7 Precedented System Definition
3.1.8 Concluding Reviews
3.2 A General Theory of Structured Analysis
3.2.1 What is Structured Analysis
3.2.2 Structured Development Goals
3.2.3 Where Does It Appear in the Process
3.2.4 Comparative Overview of Approaches
3.2.5 Poly-Faceted View of Problem Spaces
3.2.6 Entry Facet Differences
3.2.7 An Entry Continuum
3.2.8 Model Documentation
3.2.9 Completeness and Avoiding Model Madness
3.2.10 Detailed Coverage of Models
3.3 Functional Analysis
3.3.1 The Heritage of Structured Analysis
3.3.2 Form Follows Function
3.3.3 Functional Flow Analysis
3.3.3.1 Function Identification and Sequence
3.3.3.2 The Top Function
3.3.3.3 Life Cycle Master Flow Diagram
3.3.3.4 Flow Diagramming Details
3.3.3.5 Detailed Flow Diagrams
3.3.3.6 Functional N-Square Diagramming
3.3.3.7 Performance Requirements Analysis
3.3.3.8 Allocation Pacing
3.3.3.8.1 Independent Mode
3.3.3.8.2 Instant Allocation Mode
3.3.3.8.3 Progressive Allocation Mode
3.3.3.8.4 Layered Approach
3.4 Product and Process Performance Requirements, Analysis and Allocation
3.4.1 Preliminaries
3.4.1.1 Product Performance Requirements Analysis
3.4.1.2 Process Performance Requirements Analysis
3.4.2 Requirements Development Strategies
3.4.3 The General Plan
3.4.4 Transition to Process Analysis
3.4.5 Primitive Statement and Transform
3.4.6 Value Identification
3.4.7 Product Class Differences
3.4.7.1 Product Computer Software
3.4.7.2 Operational and Logistics Task Analysis
3.4.7.3 Product Facilities
3.4.7.4 Composite Product Objects
3.4.8 Guidelines
3.4.9 Verification Planning Analysis (VPA)
3.4.9.1 Overview
3.4.9.2 Development Evaluation Test Requirements Analysis
3.4.9.3 Item Qualification Verification Requirements Analysis
3.4.9.4 System Test and Evaluation Requirements Analysis
3.4.9.5 Item Acceptance Test Requirements Analysis
3.4.10 Logistics Support Analysis
3.4.11 Allocation of Functionality
3.4.11.1 Team Briefing
3.4.11.2 Review Past Allocations
3.4.11.3 Brainstorming and Analysis
3.4.11.4 Consolidation
3.4.11.5 New Architecture Identification
3.4.11.6 Engineering Review Meeting
3.4.11.7 Overall Coordination
3.4.11.8 Allocation Criteria Guidance
3.4.11.9 Additional Performance Requirements Analysis Examples
3.4.11.9.1 Performance Requirements Analysis Example 1
3.4.11.9.2 Performance Requirements Analysis Example 2
3.4.11.9.3 Performance Requirements Analysis Example 3
3.4.11.9.4 Performance Requirements Analysis Example 4
3.4.12 Performance Requirements Analysis Preceding Function Allocation
3.4.13 RAS-Centered Requirements Analysis
3.4.14 Process Summary
3.5 Architecture Synthesis
3.5.1 Introduction to Architecture
3.5.2 Architecture Block Diagramming
3.5.3 Diagramming Fundamentals
3.5.4 Architecture Element Coding
3.5.5 Sheet Cross-Referencing
3.5.6 Alternative Organizational Structures
3.5.7 Implementation Notes and Responsibility
3.5.8 Architecture Crossing Conditions
3.5.9 Reversing Traditional Structured Analysis
3.6 Interface Identification and Definition
3.6.1 Introduction to Interface Analysis
3.6.1.1 Interface Defined
3.6.1.2 The Interface Dilemma
3.6.1.3 The Solution
3.6.2 Interface Identification
3.6.2.1 Intuitive Interface Identification
3.6.2.2 A Thoroughly Disciplined Method
3.6.3 Identification Work Products
3.6.3.1 N-Square Diagramming Methods
3.6.3.2 Schematic Methods
2.6.3.3 Interface Dictionary
3.6.4 Interface Media and Requirements Definition
3.6.4.1 Electrical Power Example
3.6.4.2 Electrical Signal Example
3.6.4.3 Physical Attachment Example
3.6.4.4 Fluid Transmission Example
3.6.5 Interface Documentation
3.6.5.1 Capture in the Requirements Analysis Sheet and Database System
3.6.5.2 Interface Definition Publication
3.6.6 Interface Responsibility
3.6.6.1 Program Organization
3.6.6.2 Three Views of Interface
3.6.6.3 Interface Responsibility Model
3.6.2.3 The Special Need for External Interface Development
3.7 Specialty Engineering Requirements Analysis
3.7.1 Serial Versus Parallel Work Pattern
3.7.2 The Generic Specialty Engineering Process
3.7.2.1 Requirements Identification Responsibility Aid
3.7.2.2 Requirements Capture
3.7.2.2.1 Freestyle Approach
3.7.2.2.2 Cloning Approach
3.7.2.2.3 Question and Answer Approach
3.7.2.2.4 The Structured Strategy in Years Gone By
3.7.2.2.5 Structured Analysis in the 21st Century
3.7.2.3 Constraints Integration
3.7.2.4 Specialty Constraints Communication
3.7.2.4.1 Checklist Approach
3.7.2.4.2 Individual Person-To-Person
3.7.2.4.3 Organized Interaction Meetings
3.7.2.4.4 Decision Support
3.7.2.5 Specialty Design Assessment
3.7.2.5.1 Non-Compliance Identification
3.7.2.5.2 Non-Compliance Correction
3.7.3 Engineering Specialty Activities Overview
3.7.3.1 Reliability Engineering
3.7.3.1.1 Task 1, Reliability Program Plan
3.7.3.1.2 Task 2, Subcontractor and Supplier Control
3.7.3.1.3 Task 3, Failure Reporting, Analysis, and Corrective Action System (FRACAS)
3.7.3.1.4 Task 4, Failure Review Board (FRB)
3.7.3.1.5 Task 5, Reliability Modeling
2.7.3.1.6 Task 6, Reliability Allocations
3.7.3.1.7 Task 7, Reliability Predictions
3.7.3.1.8 Task 8, Failure Modes, Effects, and Criticality Analysis (FMECA)
3.7.3.1.9 Task 9, Reliability Critical Items & Critical Item Control Plan
3.7.3.1.10 Task 10, Reliability Development, Growth and Test (RDG&T) Plan
3.7.3.1.11 Task 11, Sneak Circuit Analysis
3.7.3.1.12 Reliability References
3.7.3.2 Parts, Materials, and Process Engineering (PMP)
3.7.3.3 Maintainability Engineering
3.7.3.3.1 Task 1 Maintainability Analysis
3.7.3.3.2 Task 2, Document Maintainability Requirements and Criteria
3.7.3.3.3 Task 3, Maintainability Quantitative Analysis to Assure Requirements are Met
3.7.3.3.4 Task 4, Design Surveillance/Assessment
3.7.3.3.5 Task 5, Participate In Design Tradeoff Studies
3.7.3.3.6 Task 6, Participate In Design Reviews
3.7.3.3.7 Task 7, Subcontractor and Supplier Control
3.7.3.3.8 Task 8, Failure Reporting, Analysis, and Corrective Action
3.7.3.3.9 Task 9, Conduct Maintainability Demonstration
3.7.3.3.10 Maintainability References
3.7.3.4 Availability
3.7.3.5 Producibility Engineering
3.7.3.6 Design To Cost/Life Cycle Cost (DTC/LCC)3.7.3.7 Human Factors Engineering
3.7.3.8 Corrosion Prevention and Control (CPC)
3.7.3.9 System Safety Engineering
3.7.3.10 Electromagnetic Compatibility (EMC) Engineering
3.7.3.11 System Security Engineering
3.7.3.12 Mass Properties Engineering
3.7.3.13 Environmental Impact Engineering
3.7.4 Science Projects and Natural Systems
3.7.4.1 The Ultimate System Diagram
3.7.4.2 Give Us the Sense to Know the Difference
3.7.4.3 Characterizing Reality
3.7.4.4 Specific Science Development Programs
3.8 Environmental Requirements Analysis
3.8.1 Overview
3.8.2 Environmental Categories
3.8.2.1 Natural Environment (QN)
3.8.2.2 Self-Induced Environment (QI)
3.8.2.3 Non-Cooperative Environment (QX)
3.8.2.4 Hostile Environment (QH)
3.8.2.5 Cooperative Environment (QC)
3.8.3 Environmental Requirements Models
3.8.3.1 System Environmental Requirements Analysis
3.8.3.2 End Item Environmental Requirements
3.8.3.3 Component Environmental Requirements
3.8.4 Time Analysis
3.8.4.1 Diagramming Fundamentals
3.8.4.2 Timeline Diagram Symbols
3.8.4.3 Variability
3.8.4.4 Selectivity
3.8.4.5 Tabular Timelines
3.8.4.6 Timeline Reporting
3.8.5 Environmental Requirements Capture
3.8.6 Environmental Impact
3.9 Functional Analysis Alternatives
3.9.1 Variations Covered
3.9.2 Functional Analysis Variations
3.9.2.1 Hierarchical Functional Analysis
3.9.2.2 Enhanced Functional Flow Block Diagramming
3.9.2.2.1 Trigger Construct
3.9.2.2.2 Multiple Exit Function
3.9.2.2.3 Iteration
3.9.2.2.4 Loop
3.9.2.2.5 Kill Branch
3.9.2.2.6 Lateral Data or Commodity Flow
3.9.2.3 Behavioral Diagramming
3.9.2.4 IDEF-0
3.9.2.5 FRAT
3.9.3 State and Event Analysis
3.9.3.1 State Transition Diagram Analysis
3.9.3.2 Finite State Machines
3.9.3.3 Petri Nets
3.9.3.4 Event Traces, Lists, and Trees
3.9.4 Mathematical Models
3.9.4.1 Mathematical Equations
3.9.4.2 Formal Methods
3.9.5 Scenarios, Strings, and Events Analysis
3.9.5.1 Scenario Depictions
3.9.5.2 Icon Flow
3.9.5.3 Descriptive Text
3.9.5.4 Strings or Threads
3.9.5.5 Synthesis of Functional Threads
3.9.6 Process Analysis
3.9.6.1 Process Fundamentals
3.9.6.1.1 Diagramming
3.9.6.1.2 Process-Resource Linkage
3.9.6.1.3 Process-Environment Linkage
3.9.6.2 Process Analysis Applications
3.9.6.2.1 Generic Enterprise and Program Planning
3.9.6.2.2 Generic Process Analysis
3.9.6.2.3 Program Specific Process
3.9.6.2.4 Continuing Cost and Schedule Requirements Analysis
3.9.6.3 Program Product-Oriented Processes
3.9.6.3.1 Specialty Engineering Integration and Concurrent Engineering
3.9.6.3.2 Program Material and Procurement Process Analysis
3.9.6.3.3 Program Manufacturing and Quality Process Analysis
3.9.6.3.4 Program Verification Process Analysis
3.9.6.3.4.1 Test Planning Analysis (TPA)
3.9.6.3.4.2 Development Test Requirements Analysis
3.9.6.3.4.3 Qualification Test Requirements Analysis
3.9.6.3.4.4 Operational Test Requirements Analysis
3.9.6.3.4.5 Acceptance Test Requirements Analysis
3.9.6.4 Deployment Planning Analysis (DPA)
3.9.6.5 System Sustainment Process Analysis
3.9.6.5.1 Logistics Support Analysis Overview
3.9.6.5.2 LSA Example
3.9.6.5.3 Product Operation Analysis
3.9.6.5.4 Modification Development
3.9.6.6 Disposal Analysis
3.9.7 Quality Function Deployment
3.9.7.1 Introduction to Quality Function Deployment (QFD)
3.9.7.2 Physical Implementation
3.9.7.3 A Problem With QFD
3.9.7.4 Linking QFD With Structured Analysis
3.9.7.5 Derived Requirements Generator
3.10 Ras-Complete and Ras-Centered Analysis
3.10.1 A System Defined
3.10.2 Descriptors of Interest
3.10.3 System Functionality
3.10.4 Performance Requirements Derivation and Allocation
3.10.5 Conventional RAS Limitations
3.10.6 The Beginning of the Complete RAS
3.10.7 System Architecture
3.10.8 Allocation Pacing Alternatives
3.10.9 System Relations
3.10.10 The System Environment
3.10.11 Environmental Relation Algorithm
3.10.11.1 System Environmental Relations
3.10.11.2 End Item Service Use Profile
3.10.11.3 Component Environmental Relations
3.10.12 Specialty Engineering and RAS Complete
3.10.13 Verification Extension
3.10.14 Conclusions
3.11 Traditional Structured Analysis Documentation
3.11.1 The Common Failure
3.11.2 SDD Content and Format
3.11.2.1 Document Main Body
3.11.2.2 Appendix A, Functional Analysis
3.11.2.3 Appendix B, System Environment Analysis
3.11.2.4 Appendix C, System Architecture Analysis
3.11.2.5 Appendix D, System Interface Analysis
3.11.2.6 Appendix E, Specialty Engineering Definition Analysis
3.11.2.7 Appendix F, System Process Analysis
3.11.2.8 Appendix G, Requirements Analysis Sheet
3.11.3 Recommended Responsibility Pattern
PART 4, Computer Software Structured Analysis
4.1 Introduction
4.1.1 Computer Software Development Environment
4.1.2 Software Development Models For Analysis
4.1.3 Model Comparisons
4.1.4 Design and Manufacturing Differences
4.1.5 Software Deficit Disorder
4.2 Computer Processing Oriented Analysis
4.2.1 A Little History
4.2.2 Flow Charts and Other Things
4.2.3 Modern Structured Analysis
4.2.4 Hatley-Pirbhai Real Time Extension
4.2.5 Transform From Models to Software Entities and Their Requirements
4.2.6 Are These Models Only Appropriate For Software?
4.3 Data Oriented Analysis
4.3.1 Data Augmentation of Modern Structured Analysis
4.3.1.1 Data Lines, Stores, and Dictionaries
4.3.1.2 Entity Relationship Diagrams
4.3.2 Relational Database Development
4.3.2.1 Relational Database Development Using Table Normalization
4.3.2.2 Relational Database Development Using IDEF 1X
4.3.3 Transition to Specification
4.3.4 DoD Architecture Framework
4.4 Object Oriented Analysis
4.4.1 The Early Combined Analysis Techniques
4.4.1.1 Input-Process-Output (IPO) Analysis
4.4.1.2 SADT and IDEF-0
4.4.2 Early Object Oriented Analysis
4.4.2.1 A Dynamic Beginning
4.4.2.2 Misplaced Beginnings
4.4.2.3 The Class and Object Model
4.4.2.4 The Dynamic Model
4.4.2.5 The Functional Model
4.4.3 Function-Driven Early OOA
4.4.4 Unified Modeling Language (Unified Modeling Language (UML))
4.4.4.1 Problem Space Entry and Continuation
4.4.4.2 Dynamic Model Elements
4.4.4.2.1 Use Case Diagram
4.4.4.2.2 Statechart Diagram
4.4.4.2.3 Activity Diagram
4.4.4.2.4 Collaboration Diagram
4.4.4.2.5 Sequence Diagram
4.4.4.3 Static Model Elements
4.4.4.3.1 Class and Object Diagrams
4.4.4.3.2 Component and Deployment Diagrams
4.4.4.4 Unprecedented Application
4.4.4.5 Precedented Application
4.4.5 Moving to Specification
4.5 System Modeling Using the DOD Architecture Framework
4.5.1 Background
4.5.2 Overview
4.5.3 Framework Products
4.5.3.1 All Views
4.5.3.1.1 Overview and Summary Information (AV-1)4.5.3.1.2 Integrated Dictionary (AV-2)
4.5.3.2 Operational Architecture Views
4.5.3.2.1 High Level Operational Concept Graphic (OV-1)
4.5.3.2.2 Operational Node Connectivity Description (OV-2)
4.5.3.2.3 Operational Information Exchange Matrix (OV-3)
4.5.3.2.4 Organizational Relationships Chart (OV-4)4.5.3.2.5 Activity Model (OV-5)
4.5.3.2.6 Operational Activity Sequence and Timing Descriptions (OV-6)
4.5.3.2.6.1 Operational Rules Model (OV-6a)
4.5.3.2.6.2 Operational State Transition Description (OV-6b)
4.5.3.2.6.3 Operational Event/Trace Description (OV-6c)
4.5.3.2.7 Logical Data Model (OV-7)
4.5.3.3 Systems View
4.5.3.3.1 System Interface Description (SV-1)
4.5.3.3.2 Systems Communications Description (SV-2)4.5.3.3.3 Systems-Systems Matrix (SV-3)
4.5.3.3.4 Systems Functionality Description (SV-4)4.5.3.3.5 Operational Activity to System Function Traceability Matrix (SV-5)
4.5.3.3.6 Systems Data Exchange Matrix (SV-6)
4.5.3.3.7 Systems Performance Parameters Matrix (SV-7)
4.5.3.3.8 Systems Evolution Description (SV-8)
4.5.3.3.9 Systems Technology Forecast (SV-9)
4.5.3.3.10 System Activity Sequence and Timing Descriptions (SV-10)
4.5.3.2.11 Physical Schema (SV-11)
4.5.3.4 Technical Standards View
4.5.3.4.1 Technical Architecture Profile (TV-1)
4.5.3.4.2 Standards Technology Forecast (TV-2)
4.5.4 Other Related Efforts
4.5.5 Architecture Product Interrelationships
4.5.5.1 Operational View Relationships
4.5.5.2 Systems View Relationships
4.5.5.3 Operations to Systems View Traceabilities
4.5.6 The Six-Step Architecture Description Process
4.5.6.1 Determine Intended Use of the Architecture
4.5.6.2 Determine Architecture Scope, Context, Environment, and Assumptions
4.5.6.3 Determine What Information the Architecture Description Needs to Capture
4.5.6.4 Determine Views and Products to be Built
4.5.6.5 Build the Requisite Products
4.5.6.6 Use the Architecture For Intended Purpose
4.6 Structured Analysis Fusion
4.6.1 Functional Flow or Die!
4.6.2 Structured Analysis Boundaries
4.6.3 Multiple Paths
4.6.3.1 Decomposition Methodology Flexibility
4.6.3.2 Functional Traceability
4.6.4 Expanding Zig Zag
4.6.5 Evolution of the Ultimate Method
4.6.6 Model Driven Development
PART 5, Specification Content Standards
5.1 Specification Development Fundamentals
5.1.1 Overview
5.1.1.1 What is a Specification?
5.1.1.2 Specification Format Control
5.1.1.3 Document Controls
5.1.1.4 The Case For Uniformity
5.1.2 DoD Specifications Under MIL-STD-490A
5.1.2.1 MIL-STD-490A Specification Types
5.1.2.1.1 Type A System/Segment Specification
5.1.2.1.2 Type B Development Specifications
5.1.2.1.2.1 Type B1 Prime Item Development Specification
5.1.2.1.2.2 Type B2 Critical Item Development Specification
5.1.2.1.2.3 Type B3 Non-Complex Item Development Specification
5.1.2.1.2.4 Type B4 Facility or Ship Development Specification
5.1.2.1.2.5 Type B5 Software Development Specification
5.1.2.1.3 Type C Product Specifications
5.1.2.1.3.1 Type C1 Prime Item Product Specifications
5.1.2.1.3.2 Type C1a Prime Item Product Function Specification
5.1.2.1.3.3 Type C1b Prime Item Product Fabrication Specification
5.1.2.1.3.4 Type C2 Critical Item Product Specifications
5.1.2.1.3.5 Type C2a Critical Item Product Function Specification
5.1.2.1.3.6 Type C2b Critical Item Product Fabrication Specification
5.1.2.1.3.7 Type C3 Non-complex Item Product Fabrication Specification
5.1.2.1.3.8 Type C4 Inventory Item Specification
5.1.2.1.3.9 Type C5 Software Product Specification
5.1.2.1.4 Type D Process Specifications
5.1.2.1.5 Type E Material Specifications
5.1.2.2 DoD Specification Forms Under MIL-S-83490
5.1.2.3 Coordinated MIL-STD-490A References
5.1.2.4 MIL-STD-490A Specification Baselines
5.1.2.4.1 Functional Configuration Identification
5.1.2.4.2 Allocated Configuration Identification
5.1.2.4.3 Product Configuration Identification
5.1.3 MIL-STD-961D Specification Standard
5.1.3.1 Specification Types
5.1.3.2 Structure and Content
5.1.4 MIL-STD-961E
5.1.5 Other Requirements Document Types
5.1.6 Coverage of Specifications
5.1.6.1 General Specification
5.1.6.2 Detail Specification
5.1.7 One and Two Part Specifications
5.1.8 A Strange Specification Format
5.2 General Specification Style guide
5.2.1 Style, Format, and Identification of Specifications
5.2.1.1 Sectional Arrangement of Specifications
5.2.1.2 Language Style
5.2.1.3 Primitive Requirement Statement
5.2.1.4 Capitalization and Spelling
5.2.1.5 Abbreviations
5.2.1.6 Symbols
5.2.1.7 Proprietary Names
5.2.1.8 Commonly Used Words and Phrasing
5.2.1.9 Use of "Shall,” "Will," "Should," and "May"
5.2.1.10 Use of "Flammable" and "Nonflammable"
5.2.2 Paragraphing Numbering and Identification
5.2.2.1 Paragraph Identification
5.2.2.2 Underlining
5.2.2.3 Cross References
5.2.2.4 Figures, Tables, and Foldouts
5.2.2.5 Location of Figures in Specification
5.2.2.6 Preparation of Figures
5.2.2.7 Location of Tables in Specifications
5.2.2.8 Preparation of Tables
5.2.2.9 Foldouts
5.2.3 Footnotes
5.2.3.1 Footnotes to Text
5.2.3.2 Footnotes to Tables and Figures
5.2.4 Contractual and Administrative Requirements
5.2.4.1 Definitions in Specifications
5.2.4.2 References to Other Documents
5.2.4.3 Limitation on References
5.2.4.4 Security Marking of Specifications
5.2.4.5 Identification of Specifications
5.2.4.6 Titling the Specification
5.3 Specification Content Guidance
5.3.1 MIL-STD-490A Content Standard
5.3.1.1 Section 1 - Scope
5.3.1.1.1 Scope
5.3.1.1.2 Classification
5.3.1.2 Section 2 - Applicable Documents
5.3.1.2.1 Kinds of Documents
5.3.1.2.1.1 Government Documents
5.3.1.2.1.2 Non-Government Documents
5.3.1.2.2 Listing of References
5.3.1.2.2.1 Government Documents
5.3.1.2.2.2 Non-Government Documents
5.3.1.3 Section 3 - Requirements
5.3.1.3.1 Definition (Paragraph 3.1)
5.3.1.3.2 Characteristics (Paragraph 3.2)
5.3.1.3.2.1 Performance Characteristics
5.3.1.3.2.2 Physical Characteristics
5.3.1.3.2.2.1 Reliability
5.3.1.3.2.2.2 Maintainability
5.3.1.3.2.2.3 Environmental Conditions
5.3.1.3.2.2.4 Environmental Conditions Transportability
5.3.1.3.2.3 Design and Construction (Paragraph 3.3)5.3.1.3.2.3.1 Materials
5.3.1.3.2.3.2 Materials Toxic Products and Formulations
5.3.1.3.2.3.3 Electromagnetic Radiation
5.3.1.3.2.3.4 Nameplates or Product Markings
5.3.1.3.2.3.5 Workmanship
5.3.1.3.2.3.6 Interchangeability
5.3.1.3.2.3.7 Safety
5.3.1.3.2.3.8 Human Engineering
5.3.1.3.2.4 Documentation (Paragraph 3.4)
5.3.1.3.2.5 Logistics (Paragraph 3.5)
5.3.1.3.2.6 Personnel and Training (Paragraph 3.6)5.3.1.3.2.7 Characteristics of Subordinate Elements (Paragraph 3.7)
5.3.1.3.2.8 Precedence (Paragraph 3.8)
5.3.1.3.2.9 Qualification (Paragraph 3.9)
5.3.1.4 Section 4 - Quality Assurance Provisions
5.3.1.4.1 General
5.3.1.4.2 Responsibility for Inspection
5.3.1.4.3 Special Tests and Examinations
5.3.1.4.4 Quality Conformance Inspections
5.3.1.5 Section 5 - Preparation For Delivery
5.3.1.5.1 General
5.3.1.5.2 Detailed Preparation
5.3.1.5.2.1 Preservation and Packaging
5.3.1.5.2.2 Packing
5.3.1.5.2.3 Marking for Shipment
5.3.1.6 Section 6 - Notes
5.3.1.6.1 Intended Use
5.3.1.6.2 Ordering Data
5.3.1.6.3 Instructions for Models and Samples
5.3.1.6.4 Qualification Provisions
5.3.1.6.5 Cross-Reference of Classifications
5.3.1.6.6 Miscellaneous Notes
5.3.1.7 Appendix and Index
5.3.1.7.1 Appendix Numbering
5.3.1.7.2 Scope
5.3.1.7.3 Headings
5.3.1.7.4 References
5.3.1.7.5 Index
5.3.2 MIL-STD-961D Content Standard
5.3.3 MIL-STD-961E Content Standard Delta
5.3.4 Software Specification Standards
5.3.4.1 Military Standards
5.3.4.1.1 Software System Specification
5.3.4.1.2 Software Requirements Specification (SRS)5.3.4.1.3 Software Product Specification (SPS)
5.3.4.1.4 Interface Requirements Specification (IRS)5.3.4.2 Commercial Standards
5.3.5 A Standard For the Ultimate Simplicity
5.3.6 An Updated Content Standard
5.4 Applicable Documents Analysis and Tailoring
5.4.1 Introduction to Applicable Documents
5.4.1.1 Applicable Documents Defined
5.4.1.2 Bi-directional Tailoring
5.4.1.3 Document Tailoring
5.4.1.4 Applicable Document Levels
5.4.1.5 DoD Policy Changes
5.4.1.6 Definitions
5.4.2 Initiation of the Program Applicable Documents List
5.4.2.1 An Enterprise Applicable Documents List (EADL)
5.4.2.2 Applicable Document Assessment Sources
5.4.3 Detailed Process Description
5.4.3.1 Create & Maintain Program Applicable Document List, F3131
5.4.3.2 Coordinate Tailoring Capture, F3132
5.4.3.3 Maintain EADL
5.4.3.4 Compare Requirements, F3134
5.4.3.5 Study Conversion Difficulty, F3135
5.4.3.6 Assemble Specifications Baseline Report, F3136
5.4.3.7 Coordinate Supplier Compliance, F3137
5.4.3.8 Accept New Requirement, F3138
5.4.3.9 Tailor Company Standards, F3139
5.4.3.10 Reject or Offer Alternative Document, F313A
5.4.3.11 Assess Customer Needs and Attitudes, F313B
5.4.3.12 Tailor Applicable Document, F313C
5.4.3.13 Study Impact of Compliance, F313D
5.4.3.14 Mark Up SOW and Top Level Specification, F313E
5.4.3.15 Change Company Practice For Program Use, F313F
5.4.3.16 Assemble and Review Assessment Recommendations, F313G
5.4.3.17 Review Assessment Report, F313H
5.4.3.18 Negotiate With Customer, F313I
5.4.4 Team Tailoring
5.4.5 System Engineering Standards Relating to Requirements Analysis
5.5 Part II Specifications
5.5.1 The Part Situation
5.5.2 Specification Timing
5.5.3 Military Standards
5.5.4 Part II Specification Content Development
5.5.4.1 Outline Suggestion
5.5.4.2 Content Development Techniques
PART 6, Requirements Management
6.1 Process Overview from a Management Perspective
6.1.1 Introduction
6.1.1.1 Overview
6.1.1.2 Total Quality Management
6.1.1.3 Buzz Words Forever
6.1.2 Program Preparation
6.1.2.1 Resource Overview
6.1.2.2 Specification Templates
6.1.2.3 Analytical Models
6.1.2.4 Model/Template Maps
6.1.2.5 Planned Writing Responsibilities
6.1.2.6 Preparation For Structured Analysis Work Product Capture
6.1.2.7 Applicable Document Action
6.1.2.8 Teaming Planning
6.1.2.9 Program Specification Library
6.1.2.9.1 Library Initiation
6.1.2.9.2 PSL Variations
6.1.2.9.3 Security
6.1.2.9.4 Availability
6.1.2.9.5 PSL Finances
6.1.2.9.6 Specification Standards Loading
6.1.2.9.7 Requirements Database Interface
6.1.2.9.8 Data Ownership
6.1.3 Program Implementation
6.1.3.1 Program Specifications Plan
6.1.3.1.1 Program-Unique Document Identification
6.1.3.1.2 Responsibility Assignment
6.1.3.1.3 Specification Scheduling and Statusing
6.1.3.1.4 Specification Baseline Identification
6.1.3.1.5 Baseline Definition Documentation
6.1.3.1.6 The Physical Baseline
6.1.3.1.7 Electronic Specification Library
6.1.3.1.8 Specification Change Management
6.1.3.2 Program Specification Standards Preparation
6.1.3.2.1 Responsibility and Content
6.1.3.2.2 Standards Availability
6.1.3.2.3 Multiple Standards Levels
6.1.3.3 Specification Tree Development
6.1.3.4 Principal Engineer Selection, Assignment, and Training
6.1.3.5 Program Specification Development Methods
6.1.3.6 Modularization of the Schedule
6.1.3.7 Regulating The Plunge
6.1.3.8 Selective Requirements Development
6.1.3.9 Requirements Risk Management
6.1.3.10 Process Controls
6.1.3.10.1 IPPT Meeting Structure
6.1.3.10.2 Requirements Traceability Audit
6.1.3.10.3 Status Tracking
6.1.3.10.4 Integration and Optimization Activity
6.1.3.11 Tailoring the Development Intensity
6.1.3.12 Development Data Package Concept
6.1.4 Program Closeout
6.2 Requirements Risk Management
6.2.1 Validation and Risk
6.2.2 The Validation Time Span
6.2.3 Avoiding a Null Solution Space
6.2.4 Validation Process Overview
6.2.4.1 Overview
6.2.4.2 Initial Screening of the Requirements For Validation
6.2.4.3 Validation Intensity Selectivity
6.2.4.4 Formal Requirements Validation Management
6.2.4.5 Validation Through Risk Management
6.2.4.6 Technical Performance Measurement
6.2.4.7 Requirements Maturation Control
6.2.5 Validation Responsibility and Leadership
6.2.6 Validation Expectations
6.2.6.1 Requirements Necessity and Completeness
6.2.6.2 Requirements Value Credibility
6.2.6.3 Synthesizability
6.2.7 Validation Methods
6.2.7.1 Development Evaluation Testing (DET)
6.2.7.2 Analysis
6.2.7.3 Technology Demonstration
6.2.7.4 Examination
6.2.7.5 Combined Methods
6.2.7.6 Validation By Review
6.2.8 Product Representations
6.2.8.1 The Many Views of the Product
6.2.8.2 Representation Identification
6.2.8.3 Representation Management
6.2.8.4 Representations Documentation
6.2.8.5 Closing the Loop on Representations
6.2.9 Whole Program Phases
6.3 Requirements Value Management
6.3.1 Requirements Value Determination
6.3.2 TBD/TBR Management
6.3.3 Margin Management
6.3.3.1 Cost Margins
6.3.3.2 Schedule Margins
6.3.3.3 Characteristics Margins
6.3.3.4 Margin Consumption
6.3.4 Budgets
6.4 Requirements Integration
6.4.1 Who's in Charge?
6.4.2 Item Process View
6.4.3 Aggregate Requirements Integration
6.4.3.1 Requirements Set Attributes
6.4.3.1.1 Consistency
6.4.3.1.2 Completeness
6.4.3.1.3 Minimized
6.4.3.1.4 Uniqueness
6.4.3.1.5 Balance
6.4.3.2 Individual Requirements Attributes
6.4.3.2.1 Traceability
6.4.3.2.2 Correctness of Style
6.4.3.2.3 Singleness of Purpose
6.4.3.2.4 Quantification
6.4.3.2.5 Verifiability
6.4.3.2.6 Unambiguity
6.4.3.2.7 Good Judgment and Good Sense
6.4.3.3 Margin Check
6.4.3.4 TPM Status Check
6.4.3.5 Specification Format Check
6.4.4 Engineering Specialty Integration Overview
6.4.5 Interface Requirements Analysis Integration
6.4.6 Environmental Requirements Analysis Integration
6.4.7 Process Requirements Integration
6.5 Interface Requirements Management
6.5.1 Internal Interface Control
6.5.2 Subcontractor Interface Control
6.5.3 Associate Contractors
6.5.3.1 Formal Contractual Coverage
6.5.3.2 Principal Integrating Contractor, SE&I Contractor, and IV&V
6.5.3.3 Interface Control Working Group (ICWG)
6.5.3.4 Interface Control Document Control
6.5.4 Interface Integration Responsibility
6.5.5 Interface Audit
6.5.6 Some Non-standard Interface Concepts
6.6 Requirements Verification Management
6.6.1 The Three-Step Process
6.6.2 The V Words
6.6.3 Verification Classes
6.6.4 Verification Methods
6.6.4.1 Test
6.6.4.2 Analysis
6.6.4.3 Demonstration
6.6.4.4 Examination.
6.6.4.5 Other Methods
6.6.4.5.1 Similarity
6.6.4.5.2 Simulation
6.6.5 Qualification Verification
6.6.5.1 Verification Requirements
6.6.5.2 Verification Plans and Procedures
6.6.5.3 Verification Implementation, Reports, and Audits
6.6.6 Acceptance Verification
6.6.7 System Test and Evaluation Verification
6.6.8 Management Matrices
6.7.2.1 Formal Review Process
6.7.2.2 Peer Review
PART 7, Computer Applications
7.1 The Computer Tool Infrastructure
7.1.1 Why Have We Waited So Long?
7.1.2 Evolution of Methods
7.1.3 Computer Tool Environment
7.1.4 Requirements and Specifications Electronic Environment
7.1.5 Networking and Workgroup Computing
7.1.6 A Basic Requirements Database
7.1.7 Traceability Hooks
7.1.8 Verification Tracking Tool
7.1.9 Requirements Management Data Fields
7.1.10 External Model Hooks
7.1.11 Traceability to Process
7.1.12 Data Integrity
7.2 Computer Tools for Requirements Analysis
7.2.1 A Little history
7.2.2 Buy or Build
7.2.3 Available Tools and Their Features
7.2.3.1 CORE
7.2.3.2 DOORS
7.2.3.3 RDD-100
7.2.3.4 SLATE
7.2.3.5 Other Requirements Tools
7.2.3.6 Software Modeling Tools
7.2.4 Features Not Generally Supported
7.2.4.1 Design Constraints Identification
7.2.4.2 Tool Linkage
7.2.4.3 Primitive Capture and Numerical Content
7.2.5 Implementation Suggestions
7.2.5.1 Overcoming Use Difficulties
7.2.5.2 Networking
PART 8, Closing
8.1 Where have we been?
8.1.1 What is the Essence of Our Story?
8.1.1.1 Teamwork and Concurrency
8.1.1.2 Development Directionality
8.1.1.3 Multiple Requirements Analysis Strategies
8.1.1.4 Demand-Driven Requirements Analysis
8.1.1.5 Progressive Requirements Writing
8.1.1.6 The Computers Are Coming!
8.1.2 Overcoming Impediments to SRA Success |
|
 |
|
Systems Requirements Analysis
Jeffrey O. Grady
President of JOG Systems Engineering, Inc.
Adjunct Professor
University Of California, San Diego
Complete overview of the basic principles involved in setting up a Systems Requirements Analysis program, including how to set up the initial specifications that define both the problems and parameters of an engineering program.
Defines an engineering system and how it must be broken down into a series of process steps, beginning with a definition of the problems to be solved.
Covers various analytical approaches to systems requirements, including structural analysis and functional analysis.
Shows how to develop a requirements budget and calculate project financial margins.
Systems Requirements Analysis will give the professional systems engineer the tools to set up a proper and effective analysis of what resources, schedules, and parts that will be needed in order to successfully undertake and complete any large, complex project. The book offers a methodology for rationally breaking a large project down into a series of stepwise questions and categorical needs list to determine a schedule and establish a plan for specific provisions and tools that are required to complete the project at hand.
Systems Requirements Analysis emphasizes the need to lay out a clear technique for identifying what an engineering project is expected to accomplish, what will be needed to start and complete the project, and what is the most optimal use of those needed resources. It will enable the professional engineer to make sure a project has a successful launch before it is too late to make critical planning changes.
Contents:
Introduction; Requirements Foundation; Traditional Structured Analysis; Computer Software Structured Analysis; Specification Content Standards; Requirements Management; Computer Applications; Closing |
 |
|
This volume was originally conceived in the late 1980s as a
way to convert a series of company procedures on a process
called system requirements analysis into a textbook.
Previously, this subject had been covered extensively only in
Department of Defense and aerospace company documents
not generally available to the public at large. I had
researched many of the representations of this process and
found that, while they had in common a rigorous requirements
capture methodology, they all omitted a central
notion that left the user of the process uninformed about
where the process began and where it ended. These several
process descriptions also failed to clearly describe how it
could be applied for interface, as well as architecture, development
in a continuous top-down flow. Commonly, they also
failed to show the need for feedback from higher level functional
allocation and concept development to lower level
functional analysis. Finally, the process coverage was all too
often presented inflexibly and failed to show how the using
organization could apply it in combination with other
requirements analysis strategies across the complete time
frame of a system life cycle. Process descriptions I was
familiar with were heavy on the proper use of very stylized
forms in support of computer data collection systems and
weak on the connective tissue describing how the process
fits into the overall development process and individual
human activity.
At the time I was the Manager of Systems Development
at General Dynamics Space Systems Division (1984–1993)
and convinced that improvements in requirements analysis
and specification development were the most important contribution
to his new division’s health that the department
could mount. Convair had again in 1994 spawned a space
division after the original Astronautics that had created the
Atlas ICBM had been reabsorbed back into Convair with
only a low level of space transport work to support itself.
The principal work product of the department was specifications
and it seemed to me its weakest link.
The corporation at the time encouraged managers to hire
recent college graduates as a way of continuously feeding
new knowledge into the organization and working our way
out of an employee age hump. Few engineering managers,
especially in system engineering, are enthusiastic about hiring
recent college graduates. Many system engineering
managers believe that other organizations within the company
and other companies should act as their farm teams,
ripening good system thinkers for the plucking. But, since it
was corporate policy that was enforced, I looked for ways to
make it work. I found that breaking the department charter
down into pieces allowed documenting each of these micro
jobs in company procedures. The small jobs had to be cut
such that they covered a fulfilling task for the person performing
it while accomplishing something important on a
program. Each task had to also be small enough that new
hires could master the job fairly quickly so as not to pose a
budget burden while perfecting their skills. Over time
through some training and assignment of these new hires to
different tasks, they might become well-rounded system
engineers.
This book was adapted from procedures that were also
used as text material for the GDSS System Engineering
Institute; here engineers were provided instruction in system
engineering topics. This was another constraint on department
instructions and corresponding task granularity. It had
to be possible to describe each in a one-hour lunchtime class
session. In 1990, the Director, Dave Clemons, and I, just back
from the meeting in Seattle where we had participated in the
creation of the National Council On Systems Engineering
(then NCOSE, later INCOSE), felt so motivated that we went
to the University of California, San Diego Extension, and
encouraged the Engineering Director, Dr. John Peak, to start
a system engineering certificate program. John accepted the
encouragement and I agreed to teach the first course, system
requirements analysis.
When so enthusiastically volunteering to teach the
course, I had not thought about a textbook. About the time
this problem became apparent, a housepainting accident
resulted in two fractured arms. Wearing two slings and typing
on an Apple IIE, I converted some of the company procedures
mixed with new material into a textbook to fill a
long-standing void in the area of requirements analysis.
This manuscript matured for three years as a course text in
the UC San Diego system engineering certificate program
before its official publication as System Requirements
Analysis by McGraw-Hill in 1993.
A subsequent version was crafted by updating the material
in five books published in the 1990s into four volumes
covering the whole sweep of the system development
process from the system engineering perspective. This
series is used in a four- and six-course system engineering
certificate program offered by JOG System Engineering (see
http://www.jogse.com for details).
Years of consulting, lecture work, and experience with
many different kinds of companies in the aerospace industry
have enabled me to focus on the cause of poor system
development performance in four knowledge spaces seldom
attacked with synergy: system engineering, functional management,
domain engineering (mechanical, electrical of several
kinds, software, etc.), and program management. Many
companies have tried to improve with unipolar improvement
ventures focused on one of these, such as system engineering
performance, and all too often have come up short
of their goals. The sad story is that they all have to be
attacked together and in accordance with a grand plan. The
common career competitiveness between the people staffing
these activities has to be replaced with a common vision of
success with clear knowledge that all of these people are
inextricably linked in each other’s success and dependent on
the contributions of the others for their own success and
that of the enterprise as a whole. They are all parts of the
enterprise system with prescribed activities and interfaces
that must function well for the whole to achieve
expectations.
The functional managers must be constantly developing
and improving the resources made available to all programs
in the form of the best possible people who know what they
are doing in the context of a written process description and
Preface
a set of coordinated tools. The functional managers are the
owners of the enterprise knowledge base needed by programs
to translate customer needs into practical products
satisfying those needs. They are also the owners of pieces
of the process under the guidance of, in my view, an enterprise
process agent referred to in this book as the Enterprise
Integration Team (EIT).
Program managers must have the skill and knowledge to
lead teams of specialists toward preplanned program goals
but must also have the courage to spend program funds
early in the program to accomplish needed system engineering
work and the experience, knowledge, and self confidence
to demand that this money be spent well achieving
specific tasks leading to specific work products within time
and budget constraints. If the program manager withholds
this funding on the basis of fear of the future, his or her
worst expectations will be fulfilled later in the program
when realized risks overwhelm it. System engineering is a
grand risk abatement process that uncovers problems at the
earliest possible date, and it is well known that the earlier a
problem is uncovered, the cheaper it is to resolve.
The system engineer must be a quick practitioner as well
as a good one. The program manager must exercise a lot of
courage to spend program money early and deserves a
return on that investment with fast work well done. If this
cannot be done then fear will sweep through engineering
and program management, encouraging design being
started before the problem is fully understood and documented
in program specifications.
This book and three companion manuscripts form a
grand system development series of books coordinated
with the four fundamental sets of knowledge that must be
applied to solve complex problems through the exercise of
good engineering. We first should define the problem and
we do this by writing specifications (this book). Next, the
creative juices of the design engineers, aided by a whole
host of other specialists, must synthesize those requirements
into a preferred design solution documented well
enough to support manufacture or purchase of the system
elements. Finally, the system approach calls for proving that
the design solution satisfies the original requirements that
defined the problem we were trying to solve. The forth element
of this picture is a management infrastructure within
which these three activities must reside.
While using the original book, System Requirements
Analysis, in training courses over a period of several years
and talking with many practitioners, I found ways to expand
the set of models useful in requirements analysis, including
the many software analysis models I had earlier covered by
pointing to the many good books in that field. More importantly,
I found it possible to put the whole set of models into
a framework called a general theory of structured analysis.
The framework is admittedly a little thin; the work required
to fully describe it is beyond the domain of this book.
For this book, the new notion of RAS-Complete was
threaded through the traditional structured analysis process
linking together better the analysis work, structured analysis
models, specification template structures, and structured
analysis work product capture.
This book can be used independently as a textbook for a
one-semester/quarter course on requirements analysis in a
college system engineering extension program or equivalent
company course; used as a basis for a company requirements
analysis process description; used as a desk reference
by a professional system engineer; or simply be read by a
system engineer, system analyst, or design specialist to gain
an insight into ways to improve their professional job performance
in this very difficult but understandable activity.
The book will be used in concert with the other three volumes
it was a part of (Grand Systems Management, Grand
Systems Synthesis, and Grand Systems Verification) as the
basis for four core courses of a system engineering certificate
program for delivery through campus courses or
in-house in a company. |
|
