Details

Subject(s)

• Systems engineering [Browse]
• System analysis [Browse]

Series

Elsevier insights [More in this series]

Summary note

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 project into a series of stepwise questions, enabling them to determine a schedule, establish what needs to be procured, how it should be obtained, and what the likely costs in dollars, manpower, and equipment will be to complete the project at hand. It covers various analytical approaches to system requirements, including structural and functional analysis, budget calculations, and risk analysis. This resource is compatible with the full range of popular engineering management tools, 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.--Edited summary from book.

Bibliographic references

Includes bibliographical references.

Source of description

Description based on print version record.

Contents

• 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 --
• Note continued: 6.4.2.Inter-Model Transfers
• 6.4.3.Solution Space Modeling
• 6.4.4.Early OOA Alternative
• 6.4.5.The RAS and Specifications
• 6.5.UPDM Selectively Extended to a UADF
• 6.5.1.UPDM Shortfall
• 6.5.2.The UML-SysML Components
• 6.5.3.Addition of Two More Models
• 6.5.4.Coordinated Employment
• 6.6.Mixed Methods if You Must
• 6.6.1.How Do I Get There?
• 6.6.2.UADF Impediments
• 6.6.3.Model Transfer Functions
• 6.6.4.Extension in the Solution Space Modeling
• 6.6.5.Common Specification Template
• 6.6.6.Precedented Development Using the Functional UADF
• 6.6.7.Enterprise Lifeline
• 6.6.8.UADF Alternative Evaluation
• 7.Specification Content Standards
• 7.1.Specification Development Fundamentals
• 7.1.1.Overview
• 7.1.2.DoD Specifications Under MIL-STD-490A
• 7.1.3.MIL-STD-961D Specification Standard
• 7.1.4.MIL-STD-961E
• 7.1.5.Other Requirements Document Types
• 7.1.6.Coverage of Specifications
• 7.1.7.One and Two-Part Specifications
• 7.1.8.A Strange Specification Format
• 7.2.General Specification Style Guide
• 7.2.1.Style, Format, and Identification of Military Specifications
• 7.2.2.Paragraph Numbering and Identification
• 7.2.3.Footnotes
• 7.2.4.Contractual and Administrative Requirements
• 7.3.Performance Specification Content Guidance
• 7.3.1.A Basis for Concern
• 7.3.2.Author's Problem with Military Specification Content Standards
• 7.3.3.JOG System Engineering Specifications of Interest
• 7.3.4.JOG System Engineering Specification Templates
• 7.3.5.Performance Specification DID
• 7.3.6.Intended Machinery for Filling the Template
• 7.3.7.Modeling Work Sequence
• 7.4.Detail Specifications
• 7.4.1.The Part Situation
• 7.4.2.Specification Timing
• 7.4.3.Military Standards
• 7.4.4.Part 2 Specification Content Development
• 7.4.5.Part Verification Dynamics
• 7.5.Interface Specifications
• 7.5.1.The Alternatives
• 7.5.2.A Sacred Rule
• 7.5.3.The Parts
• 7.5.4.The Performance Template
• 7.5.5.The Detail Template
• 7.5.6.Management and Responsibility
• 7.6.Parts, Materials, and Processes Specifications
• 7.6.1.Where Are We in the Hierarchy?
• 7.6.2.Specification Preparation Responsibility
• 7.6.3.Standard PMP List
• 7.6.4.PMP Verification
• 7.6.5.Configuration Control for PMP
• 7.7.Applicable Document Analysis
• 7.7.1.Introduction to Applicable Documents
• 7.7.2.Initiation of the Program-Applicable Documents List
• 7.7.3.Detailed Process Description
• 7.7.4.Team Tailoring
• 7.7.5.System Engineering Standards Relating to Requirements Analysis
• 8.Requirements Management
• 8.1.Process Overview from a Management Perspective
• 8.1.1.Introduction
• 8.1.2.Program Preparation
• 8.1.3.Program Implementation
• 8.1.4.Program Closeout
• 8.2.Requirements Risk Management
• 8.2.1.Validation and Risk
• 8.2.2.Risk Measurement
• 8.2.3.The Validation Time Span
• 8.2.4.Avoiding a Null Solution Space
• 8.2.5.Validation Process Description
• 8.2.6.Validation Responsibility and Leadership
• 8.2.7.Validation Expectations
• 8.2.8.Validation Methods
• 8.2.9.Product Representations
• 8.2.10.Whole Program Phases
• 8.3.Requirements Value Management
• 8.3.1.Requirements Value Determination
• 8.3.2.TBD/TBR Management
• 8.3.3.Margin Management
• 8.3.4.Budgets
• 8.4.Requirements Integration
• 8.4.1.Who Is in Charge?
• 8.4.2.Item Process View
• 8.4.3.Aggregate Requirements Integration
• 8.4.4.Engineering Specialty Integration Overview
• 8.4.5.Interface Requirements Analysis Integration
• 8.4.6.Environmental Requirements Analysis Integration
• 8.4.7.Process Requirements Integration
• 8.5.Interface Requirements Management
• 8.5.1.The General Problem
• 8.5.2.Three Interface Management Cases
• 8.5.3.Interface Integration Responsibility
• 8.5.4.Interface Audit
• 8.5.5.Some Nonstandard Interface Concepts
• 8.6.Requirements Verification Management
• 8.6.1.The Three-Step Process
• 8.6.2.The V Words
• 8.6.3.Verification Classes
• 8.6.4.Verification Methods
• 8.6.5.Management Matrices
• 8.6.6.Documentation Alternatives
• 8.6.7.The Secret to Affordable Verification
• 8.7.Specification Development, Review, and Approval
• 8.7.1.Specification Development Controls
• 8.7.2.Publishing Media
• 8.7.3.Specification Publishing
• 8.7.4.Specification Archiving, Distribution, and Access
• 8.7.5.Specification Change Management
• 8.7.6.The Special Case of Interface Requirements Documentation
• 8.7.7.Electronic Style Guide
• 9.Computer Applications
• 9.1.The Computer Tool Infrastructure
• 9.1.1.Why Have We Waited So Long?
• 9.1.2.Evolution of Methods
• 9.1.3.The Computer Tool Environment
• 9.1.4.Requirements and Specifications Electronic Environment
• 9.1.5.Networking and Workgroup Computing
• 9.1.6.A Basic Requirements Database
• 9.1.7.Traceability Hooks
• 9.1.8.Verification Tracking Tool
• 9.1.9.Requirements Management Data Fields
• 9.1.10.External Model Hooks
• 9.1.11.Traceability to Process
• 9.1.12.Data Integrity
• 9.2.Computer Applications
• 9.2.1.A Little History
• 9.2.2.Buy or Build
• 9.2.3.Available Tools and Their Features
• 9.2.4.Features Not Generally Supported
• 9.2.5.Implementation Suggestions
• 10.Closing
• 10.1.Where Have We Been?
• 10.1.1.What Is the Essence of Our Stoiy?
• 10.1.2.Overcoming Impediments to SRA Success
• 10.2.The Future
• 10.2.1.Are You Ready for the Future?
• 10.2.2.Our Past
• 10.2.3.Onward to Model-Driven Development
• 10.2.4.Extension of UADF to Enterprise and Program Systems
• 10.2.5.Your Preparation for an Exciting Future
• 10.2.6.Enterprise Actions
• 10.2.7.Can It Be Fun and Rewarding As Well?.

Show 410 more Contents items

ISBN

• 9780124171305 ((electronic bk.))
• 0124171303 ((electronic bk.))

OCLC

861536417

Other standard number

• C20120060796
• 9780124171077

Statement on language in description

Princeton University Library aims to describe library materials in a manner that is respectful to the individuals and communities who create, use, and are represented in the collections we manage. Read more...