Cargando…

System requirements analysis /

This book gives professional systems engineers the tools to set up proper and effective analyses of the resources, schedules and parts needed to successfully undertake and complete large, complex projects. This fully revised text offers readers the methods for rationally breaking down a large projec...

Descripción completa

Detalles Bibliográficos
Clasificación:TA168 .G73 2014eb
Autor principal: Grady, Jeffrey O.
Formato: Electrónico eBook
Idioma:Inglés
Publicado: Boston, MA : Elsevier, [2014]
Edición:Second edition.
Colección:Elsevier insights
Tabla de Contenidos:
  • Machine generated contents note: 1. Introduction
  • 1.1. Introduction to Systems Requirements
  • 1.1.1. What Is a System?
  • 1.1.2. Types of Systems
  • 1.1.3. The Word Affordable
  • 1.1.4. Onward to a Model
  • 1.1.5. The Fundamental System Relation
  • 1.1.6. The Human Foundation
  • 1.1.7. What Is System Development?
  • 1.1.8. What Is System Requirements Analysis?
  • 1.1.9. SRA Timing Considerations
  • 1.1.10. Development Approaches
  • 1.1.11. Degree of Precedence Alternatives
  • 1.1.12.Organizational Alternatives
  • 1.1.13. Data Environment Alternatives
  • 1.1.14. Some History and References
  • 1.1.15. Overview of the Book
  • 1.1.16. How to Get the Most Out of the Book
  • 1.2. Models and the Mind
  • 1.2.1.A System Development Process
  • 1.2.2. Problem Space Modeling Fundamentals
  • 1.2.3.Organization of Models
  • 1.2.4. Problem Space Model Retention and Maintenance
  • 1.2.5. The Remaining Problem
  • 1.3. System Development Process Overview
  • 1.3.1. The Ultimate Process Step
  • The Enterprise Vision
  • 1.3.2. Product-Line Effects
  • 1.3.3. Customer-Base Effects
  • 1.3.4. Enterprise Structured Process Analysis and Process Definition Expansion
  • 1.3.5. Documentation Media
  • 1.3.6. Lower-Tier Development Functionality
  • 1.3.7. Grand Systems Synthesis, F42
  • 1.3.8. Grand Systems Verification, F44
  • 1.3.9. Grand Systems Sustainment, F48
  • 1.3.10. Use Product System, F47
  • 1.3.11. Manage Program, F49
  • 1.3.12. Assure Product and Process Quality, F46
  • 1.4. Process Variations
  • 1.4.1. The Situation
  • 1.4.2. Alternative Sequence Models
  • 1.4.3. Concentrated Versus Distributed Customer Base
  • 1.4.4. Precedented Versus Unprecedented Systems
  • 1.4.5. The Three Gross Models
  • 1.4.6. The Lowest Common Denominator
  • 1.5. An Overview of the Proposed Modeling Prescription
  • 1.5.1.A History of Descriptive Modeling
  • 1.5.2. TSA Partitioning
  • 1.5.3. During the Period of Adjustment
  • 1.5.4. Universal Specification Template
  • 1.5.5. System Engineers Aplenty
  • 1.5.6. Executable Models
  • 2. Requirements Foundation
  • 2.1. Requirements Fundamentals
  • 2.1.1. Primitive Requirements Statement
  • 2.1.2. Requirements Value Definition Methods
  • 2.1.3. Requirements Derivation
  • 2.1.4. Kinds of Requirements
  • 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. Why Traceability?
  • 2.2.3. Vertical Traceability
  • 2.2.4. Applicable Documents Traceability
  • 2.2.5. Longitudinal Traceability
  • 2.2.6. Lateral Traceability
  • 2.2.7. Requirements Traceability to Process
  • 2.2.8. Grand System Traceability
  • 2.2.9. Traceability Reporting
  • 2.2.10. Traceability Audits
  • 2.3. Requirements Allocation, Margins, and Budgets
  • 2.3.1. The Value of Values
  • 2.3.2. Requirement Value Determination
  • 2.3.3. Requirements Allocation
  • 2.3.4. Margin Management
  • 2.3.5. Budget Management
  • 2.3.6. Value Flexibility
  • 2.4. Requirements Analysis Strategies
  • 2.4.1. The Four Strategies
  • 2.4.2. Freestyle Strategy
  • 2.4.3. Cloning Strategy
  • 2.4.4. Question and Answer Strategy
  • 2.4.5. Structured Analysis or Modeling Strategy
  • 3. The Functional Problem Space Model
  • 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.5. Trade Studies
  • 3.1.6. Rigor Versus Creativity
  • 3.1.7. Precedented System Definition
  • 3.1.8. Concluding Reviews
  • 3.2. Toward a General Theory of Structured Analysis
  • 3.2.1. What Is Structured Analysis?
  • 3.2.2. Structured Analysis Goals
  • 3.2.3. Where Does it Appear in the Process?
  • 3.2.4.Comparative Overview of Approaches
  • 3.2.5. Polyfaceted 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 Ever Follows Function
  • 3.3.3. Functional Flow Analysis
  • 3.3.4. Specification Template for Functional Analysis
  • 3.4. Performance Requirements Analysis and Allocation
  • 3.4.1. Preliminaries
  • 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.8. Guidelines
  • 3.4.9. Verification Planning Analysis
  • 3.4.10. Logistics Support Analysis
  • 3.4.11. Allocation of Functionality
  • 3.4.12. Performance Requirements Analysis Preceding Function Allocation
  • 3.4.13. RAS-Centered Requirements Analysis
  • 3.4.14. Specification Template for Performance Requirements
  • 3.4.15. Process Summary
  • 3.5. Product Entity Structure Synthesis
  • 3.5.1. Introduction to Product Entity Structure
  • 3.5.2. Product Entity Block Diagramming
  • 3.5.3. Diagramming Fundamentals
  • 3.5.4. Product Entity Coding
  • 3.5.5. Sheet Cross-Referencing
  • 3.5.6. Alternative Organizational Structures
  • 3.5.7. Implementation Notes and Responsibility
  • 3.5.8. Product Entity Crossing Conditions
  • 3.5.9. Reversing TSA
  • 3.6. Interface Identification
  • 3.6.1. Introduction to Interface Analysis
  • 3.6.2. Interface Identification
  • 3.6.3. Identification Work Products
  • 3.6.4. Interface Documentation
  • 3.6.5. Interface Responsibility
  • 3.7. Functional Analysis Alternatives
  • 3.7.1. Variations Covered
  • 3.7.2. Functional Analysis Variations
  • 3.7.3. State and Event Analysis
  • 3.7.4. Mathematical Models
  • 3.7.5. Scenarios, Strings, and Threads Analysis
  • 3.7.6. Quality Function Deployment
  • 3.8. The Application of Functional Analysis to Software
  • 3.8.1. So, What Is Software?
  • 3.8.2. Emergence of Flowcharting
  • 3.8.3. The First Model Becomes the First Comprehensive Model
  • 3.8.4.A Parting of the Ways
  • 3.8.5.Come Home
  • 3.8.6. An Obvious Universality
  • 3.8.7. Affordability
  • 3.9. Physical Process Modeling
  • 3.9.1. Introduction to Process Analysis
  • 3.9.2. Process Fundamentals
  • 3.9.3. Process Analysis Applications
  • 3.9.4. Program Product-Oriented Processes
  • 3.9.5. Deployment Planning Analysis
  • 3.9.6. System Sustainment Process Analysis
  • 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 Product Entity Structure
  • 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.12. Specialty Engineering and RAS-Complete
  • 3.10.13. Verification Extension
  • 3.10.14. Conclusions
  • 3.11. Model Documentation
  • 3.11.1. The Common Failure
  • 3.11.2. SAR Content and Format
  • 3.11.3. Recommended Responsibility Pattern
  • 4.A Variety of Software Models
  • 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. Background
  • 4.2.2. Flowcharts 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 Appropriate Only for Software?
  • 4.3. Data-Oriented Analysis
  • 4.3.1. Data Augmentation of MSA
  • 4.3.2. Relational Database Development
  • 4.3.3. Transition to Specification with IDEF-1X
  • 4.3.4. DoD Architecture Framework
  • 4.4. Object-Oriented Analysis
  • 4.4.1. The Early Combined Analysis Techniques
  • 4.4.2. Early Object-Oriented Analysis
  • 4.4.3. Function-Driven Early OOA
  • 4.5. The Unified Modeling Language Model
  • 4.5.1. Unified Modeling Language
  • 4.5.2. Extension of UML to SysML
  • 4.5.3. Moving to the Specification
  • 4.6. System Modeling Using the DoD Architecture Framework
  • 4.6.1. Background
  • 4.6.2. Overview
  • 4.6.3. Framework Products
  • 4.6.4. From DoDAF to UADF
  • 5. Joint Solution Space Modeling
  • 5.1. Interface Requirements Analysis
  • 5.1.1. Modeling As the Necessary Precursor
  • 5.1.2. Top-Down Orientation
  • 5.1.3. Some Examples
  • 5.1.4.
  • Interface Requirements Specification Template
  • 5.1.5. Interface Requirements Capture in an Interface Specification
  • 5.2. Specialty Engineering Requirements Analysis
  • 5.2.1. Serial Versus Parallel Work Pattern
  • 5.2.2. The Generic Specialty Engineering Process
  • 5.2.3. Engineering Specialty Activities Overview
  • 5.2.4. Specification Template for Specialty Engineering Requirements
  • 5.3. Environmental Requirements Analysis
  • 5.3.1. Introduction to the Environment
  • 5.3.2. Definition of the System Environment
  • 5.3.3. The Environmental Classes
  • 5.3.4. Environmental Stresses as Interface Relationships
  • 5.3.5. Electromagnetic Environmental Effects (E3)
  • 5.3.6. Software Environment
  • 5.3.7. Environmental Requirements Capture
  • 5.3.8. Environmental Impact
  • 5.3.9. Correcting the Environmental Shortfall Problem
  • 6. Universal Architecture Description Frameworks
  • 6.1. Movement Toward a General Solution
  • 6.1.1. Some Theories About How to Proceed
  • 6.1.2. The Goal Is Comprehensiveness
  • 6.1.3. Inter-Model Transfers
  • 6.1.4. Precedented Inclusion
  • 6.1.5. Model Integration and Optimization
  • 6.1.6. Model-Driven Development
  • 6.1.7. Executable Modeling
  • 6.1.8. The UADF Literature
  • 6.2. Functionally Based UADF
  • 6.2.1. Out of the Box
  • 6.2.2. Functional MID Set
  • 6.2.3. Functional UADF Pattern of Behavior
  • 6.2.4. Flowcharting the Software
  • 6.2.5. Solution Space Modeling Extension
  • 6.3. MSA-PSARE-Based UADF
  • 6.3.1. Introduction to MSA-PSARE
  • 6.3.2. Problem Space Modeling
  • 6.3.3. Inter-Model Transfers
  • 6.3.4. Solution Space Modeling
  • 6.3.5. Alternative PSARE Solution Space Modeling
  • 6.3.6. MID for MSA-PSARE
  • 6.3.7. Specification Template Structure for MSA-PSARE
  • 6.4. UML-SysML-based UADF
  • 6.4.1. The Hardware-Software Gap