Cover image for System Requirements Analysis.
System Requirements Analysis.
Title:
System Requirements Analysis.
Author:
Grady, Jeffrey O.
ISBN:
9780080457857
Personal Author:
Edition:
1st ed.
Physical Description:
1 online resource (481 pages)
Contents:
Front cover -- Title page -- Copyright page -- Table of Contents -- List of Illustrations -- List of Tables -- Preface -- Acknowledgments -- 1 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, F41 -- 1.2.6.1.1 Program Integration -- 1.2.6.1.1.1 Initial System Analysis -- 1.2.6.1.1.2 Publish Specifications, F4122 -- 1.2.6.1.1.3 Traditional Structured Analysis, F4113 -- 1.2.6.1.2 Computer Software Structured Analysis, F4114 -- 1.2.6.1.3 Validate Requirements, F4121 -- 1.2.7 Grand Systems Synthesis, F42 -- 1.2.7.1 Design Grand System, F421 -- 1.2.7.1.1 Item Team Preliminary Design, F4211 -- 1.2.7.1.2 Item Team Detailed Design, F4212 -- 1.2.7.2 Material Operations, F422 -- 1.2.7.3 Manufacture System, F423 -- 1.2.8 Grand Systems Verification, F44 -- 1.2.9 Grand Systems Sustainment, F48 -- 1.2.9.1 Logistical Support System, F482 and F483 -- 1.2.9.2 Deploy/Deliver Product System, F481.

1.2.9.3 Modify Product System, F484 -- 1.2.9.4 Dispose of the System, F485 -- 1.2.10 Use Product System, F47 -- 1.2.11 Manage Program, F49 -- 1.2.12 Assure Product and Process Quality, F46 -- 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 -- 2 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/Flow Down -- 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 Budgets -- 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, Flow Down, or Allocation Approach -- 2.4.3.4 Flow Down Scope Limitation -- 2.4.4 Question and Answer Strategy -- 2.4.5 Structured Analysis Strategy -- 3 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 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 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.
Abstract:
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.
Local Note:
Electronic reproduction. Ann Arbor, Michigan : ProQuest Ebook Central, 2017. Available via World Wide Web. Access may be limited to ProQuest Ebook Central affiliated libraries.
Electronic Access:
Click to View
Holds: Copies: