System Requirements Analysis

Jeffrey O. Grady

買這商品的人也買了...

商品描述

Description

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.

 

Table Of Contents

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 Tracibility 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 Speciality 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 Oreinted 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 (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

商品描述(中文翻譯)

描述

《系統需求分析》為專業系統工程師提供了建立適當且有效的資源、進度和零件分析工具,以成功進行和完成任何大型、複雜的專案。本書向讀者提供了一種將大型專案合理分解為一系列逐步問題的方法,以確定進度並建立採購需求、獲取方式以及完成專案所需的費用(包括金錢、人力和設備)。《系統需求分析》與目前流行的工程管理工具完全兼容,包括專案管理、競爭工程和六西格瑪,並確保在進行重要計劃更改之前,專案能夠順利啟動。本書可用於自學或課堂教學,為個人讀者或學生群體提供了關於需求分析優勢的豐富細節。

目錄

第一部分,介紹
1.1 系統需求分析介紹
1.1.1 人類基礎
1.1.2 什麼是系統?
1.1.3 什麼是系統開發?
1.1.4 基本系統關係
1.1.5 什麼是系統需求分析?
1.1.6 系統需求分析的時間考慮因素
1.1.7 開發方法
1.1.8 優先順序的程度替代方案
1.1.9 組織替代方案
1.1.10 數據環境替代方案
1.1.11 一些歷史和參考資料
1.1.12 本書概述
1.1.12.1 如何產生
1.1.12.2 本部分的其餘部分
1.1.12.3 本書的其他部分
1.1.13 如何充分利用本書

1.2 系統開發過程概述
1.2.1 最終過程步驟-企業願景
1.2.2 產品線效應
1.2.3 客戶基礎效應
1.2.4 結構化過程分析和過程定義擴展
1.2.5 文檔媒體
1.2.6 低層次開發功能
1.2.6.1 優秀系統需求
1.2.6.1.1 程式集成
1.2.6.1.1.1 初始系統分析
1.2.6.1.1.2 發布規格
1.2.6.1.1.3 傳統結構化分析
1.2.6.1.2 電腦軟體結構化分析
1.2.6.1.3 驗證需求
1.2.7 優秀系統綜合
1.2.7.1 設計優秀系統
1.2.7.1.1 項目團隊初步設計
1.2.7.1.2 項目團隊詳細設計
1.2.7.2 材料操作
1.2.7.3 製造系統
1.2.8 優秀系統驗證
1.2.9 優秀系統維護
1.2.9.1 後勤支援系統
1.2.9.2 部署/交付產品系統
1.2.9.3 修改產品系統
1.2.9.4 處理系統
1.2.10 使用產品系統
1.2.11 管理項目
1.2.12 確保產品和過程質量

1.3 過程變異
1.3.1 情況
1.3.1.1 中央模型
1.3.1.2 美國國防部過程理念
1.3.1.3 其他美國政府生命週期模型
1.3.1.4 商業公司未來
1.3.1.5 JOG系統工程規範
1.3.1.5.1 模板準備
1.3.1.5.2 將模板映射到功能部門
1.3.1.5.3 將模板映射到結構化分析模型
1.3.1.5.4 提供模型庫的配置管理