دسترسی نامحدود
برای کاربرانی که ثبت نام کرده اند
برای ارتباط با ما می توانید از طریق شماره موبایل زیر از طریق تماس و پیامک با ما در ارتباط باشید
در صورت عدم پاسخ گویی از طریق پیامک با پشتیبان در ارتباط باشید
برای کاربرانی که ثبت نام کرده اند
درصورت عدم همخوانی توضیحات با کتاب
از ساعت 7 صبح تا 10 شب
دسته بندی: تحلیل و بررسی ویرایش: 1 نویسندگان: Jeffrey O. Grady سری: ISBN (شابک) : 012088514X, 9780080457857 ناشر: Academic Press سال نشر: 2006 تعداد صفحات: 481 زبان: English فرمت فایل : PDF (درصورت درخواست کاربر به PDF، EPUB یا AZW3 تبدیل می شود) حجم فایل: 15 مگابایت
در صورت تبدیل فایل کتاب System Requirements Analysis به فرمت های PDF، EPUB، AZW3، MOBI و یا DJVU می توانید به پشتیبان اطلاع دهید تا فایل مورد نظر را تبدیل نمایند.
توجه داشته باشید کتاب تجزیه و تحلیل سیستم مورد نیاز نسخه زبان اصلی می باشد و کتاب ترجمه شده به فارسی نمی باشد. وبسایت اینترنشنال لایبرری ارائه دهنده کتاب های زبان اصلی می باشد و هیچ گونه کتاب ترجمه شده یا نوشته شده به فارسی را ارائه نمی دهد.
تجزیه و تحلیل نیازمندی های سیستم به مهندس سیستم های حرفه ای ابزارهایی را می دهد تا تجزیه و تحلیل مناسب و موثری از منابع، برنامه ها و قطعات مورد نیاز برای انجام موفقیت آمیز و تکمیل هر پروژه بزرگ و پیچیده را تنظیم کند. این متن روشی را برای تجزیه منطقی یک پروژه بزرگ به مجموعهای از سؤالات گام به گام به خواننده ارائه میکند تا بتوان یک برنامه زمانبندی تعیین کرد و برنامهای برای آنچه باید تهیه شود، چگونه باید به دست آورد و احتمال آن وجود دارد، تعیین کرد. هزینه ها به دلار، نیروی انسانی و تجهیزات به منظور تکمیل پروژه در دست خواهد بود. تجزیه و تحلیل نیاز سیستم ها با طیف کاملی از ابزارهای مدیریت مهندسی که اکنون به طور رایج مورد استفاده قرار می گیرند، از مدیریت پروژه گرفته تا مهندسی رقابتی تا شش سیگما، سازگار است و تضمین می کند که یک پروژه قبل از اینکه خیلی دیر شود برای ایجاد تغییرات اساسی برنامه ریزی، شروع خوبی داشته باشد. این کتاب را می توان برای خودآموزی یا در کلاس استفاده کرد و جزئیات زیادی را در مورد مزایای تجزیه و تحلیل نیازمندی ها به خواننده یا گروه دانش آموز ارائه می دهد. * نویسنده مرجع شناخته شده در موضوع مهندسی سیستم ها است، و یکی از اعضای موسس شورای بین المللی مهندسی سیستم ها (INCOSE) است * یک سیستم مهندسی را تعریف می کند، و چگونه باید آن را به یک سری مراحل فرآیند تقسیم کرد، که با شروع تعریفی از مسائلی که باید حل شوند * مروری کامل بر اصول اساسی مربوط به راه اندازی یک برنامه تحلیل نیازمندی های سیستم، از جمله نحوه تنظیم مشخصات اولیه که مسائل و پارامترهای یک برنامه مهندسی را تعریف می کند * رویکردهای تحلیلی مختلف به سیستم ها را پوشش می دهد. الزامات شامل: تجزیه و تحلیل ساختاری و عملکردی، محاسبات بودجه، و تجزیه و تحلیل ریسک
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
front cover......Page 1
copyright......Page 5
Table of Contents......Page 6
List of Illustrations......Page 16
List of Tables......Page 20
Preface......Page 22
Acknowledgments......Page 24
1 PART 1, INTRODUCTION......Page 26
1.1 Introduction to System Requirements Analysis......Page 28
1.1.2 What Is a System?......Page 29
1.1.3 What Is System Development?......Page 30
1.1.4 The Fundamental System Relation......Page 31
1.1.5 What Is System Requirements Analysis?......Page 32
1.1.6 System Requirements Analysis Timing Considerations......Page 34
1.1.7 Development Approaches......Page 35
1.1.9 Organizational Alternatives......Page 36
1.1.11 Some History and References......Page 38
1.1.12.2 The Remainder of This Part......Page 39
1.1.12.3 The Other Parts of This Book......Page 40
1.1.13 How to Get the Most Out of the Book......Page 42
1.2 System Development Process Overview......Page 43
1.2.1 The Ultimate Process Step —The Enterprise Vision......Page 44
1.2.3 Customer-Base Effects......Page 45
1.2.4 Structured Process Analysis and Process Definition Expansion......Page 46
1.2.6.1 Grand Systems Requirements, F41......Page 49
1.2.6.1.1.1 Initial System Analysis......Page 51
1.2.6.1.1.3 Traditional Structured Analysis, F4113......Page 53
1.2.6.1.3 Validate Requirements, F4121......Page 55
1.2.8 Grand Systems Verification, F44......Page 57
1.2.11 Manage Program, F49......Page 61
1.2.12 Assure Product and Process Quality, F46......Page 62
1.3 Process Variations......Page 63
1.3.1.2 DoD Process Rationale......Page 64
1.3.1.4 Commercial Firm Future......Page 65
1.3.1.5 The JOG System Engineering Prescription for Specifications......Page 66
1.3.4 Precedented Versus Unprecedented Systems......Page 67
1.3.5 The Three Gross Models......Page 68
1.3.6 The Lowest Common Denominator......Page 69
2 PART 2, REQUIREMENTS FOUNDATION......Page 70
2.1 Requirements Fundamentals......Page 72
2.1.1.2 Document Style and Format......Page 73
2.1.1.5 Variations......Page 75
2.1.2.2 Value Definition Methods......Page 76
2.1.3 Requirements Derivation......Page 78
2.1.4.2.2 Design Constraints Analysis Timing......Page 79
2.1.5 Requirements in Time......Page 80
2.1.6 The Remaining Road......Page 81
2.2 Requirements Traceability Relationships......Page 82
2.2.2.1 Requirements Source Traceability......Page 83
2.2.2.3 Requirements Traceability and Allocation/Flow Down......Page 84
2.2.2.4.1 Why Traceability?......Page 85
2.2.2.4.3 Traceability Across Interfaces......Page 86
2.2.3 Longitudinal Traceability......Page 87
2.2.4 Requirements Traceability to Process......Page 88
2.2.4.1 Single Sheet Traceability to Process......Page 89
2.2.5 Grand System Traceability......Page 90
2.2.6 Traceability Reporting......Page 91
2.2.7 Traceability Audits......Page 93
2.3 Requirements Allocation, Margins, and Budgets......Page 94
2.3.3.1 What Are Formal Margins?......Page 95
2.3.3.3 Safety Margins......Page 97
2.3.4 Budget Management......Page 98
2.4 Requirements Analysis Strategies......Page 99
2.4.3 Cloning Strategy......Page 100
2.4.3.1 Specification Standards......Page 101
2.4.3.3 Parent Item, Flow Down, or Allocation Approach......Page 102
2.4.5 Structured Analysis Strategy......Page 103
3 PART 3, TRADITIONAL STRUCTURED ANALYSIS......Page 106
3.1 System Beginnings......Page 108
3.1.4 Unprecedented System Definition......Page 109
3.1.4.1 Customer Interaction......Page 111
3.1.4.3 MOE and Selection Criteria Development......Page 112
3.1.4.5 System Environmental Definition......Page 113
3.1.4.7 Concept and Program Design......Page 114
3.1.4.9 Program Funding Profile Requirements......Page 115
3.1.5.1 Trade Study Mechanics......Page 116
3.1.7 Precedented System Definition......Page 118
3.1.8 Concluding Reviews......Page 119
3.2 A General Theory of Structured Analysis......Page 120
3.2.3 Where Does It Appear in the Process?......Page 121
3.2.5 Polyfaceted View of Problem Spaces......Page 124
3.2.6 Entry Facet Differences......Page 125
3.2.8 Model Documentation......Page 126
3.2.9 Completeness and Avoiding Model Madness......Page 127
3.2.10 Detailed Coverage of Models......Page 129
3.3 Functional Analysis......Page 130
3.3.2 Form Follows Function......Page 131
3.3.3.1 Function Identification and Sequence......Page 133
3.3.3.2 The Top Function......Page 136
3.3.3.3 Life-Cycle Master Flow Diagram......Page 137
3.3.3.4 Flow Diagramming Details......Page 138
3.3.3.5 Detailed Flow Diagrams......Page 139
3.3.3.6 Functional N-Square Diagramming......Page 141
3.3.3.8.4 Layered Approach......Page 142
3.4 Product and Process Performance Requirements Analysis and Allocation......Page 143
3.4.1.1 Product Performance Requirements Analysis......Page 144
3.4.3 The General Plan......Page 145
3.4.4 Transition to Process Analysis......Page 146
3.4.7.2 Operational and Logistics Task Analysis......Page 148
3.4.8 Guidelines......Page 149
3.4.9.1 Overview......Page 150
3.4.9.4 System Test and Evaluation Requirements Analysis......Page 151
3.4.10 Logistics Support Analysis......Page 152
3.4.11 Allocation of Functionality......Page 153
3.4.11.3 Brainstorming and Analysis......Page 156
3.4.11.4 Consolidation......Page 157
3.4.11.8 Allocation Criteria Guidance......Page 158
3.4.11.9.1 Performance Requirements Analysis Example 1......Page 159
3.4.11.9.4 Performance Requirements Analysis Example 4......Page 160
3.4.14 Process Summary......Page 161
3.5 Architecture Synthesis......Page 163
3.5.2 Architecture Block Diagramming......Page 164
3.5.3 Diagramming Fundamentals......Page 165
3.5.4 Architecture Element Coding......Page 166
3.5.6 Alternative Organizational Structures......Page 167
3.5.8 Architecture Crossing Conditions......Page 168
3.5.9 Reversing Traditional Structured Analysis......Page 170
3.6 Interface Identification and Definition......Page 173
3.6.1.1 Interface Defined......Page 174
3.6.2.1 Intuitive Interface Identification......Page 175
3.6.2.2 A Thoroughly Disciplined Method......Page 176
3.6.3 Identification Work Products......Page 177
3.6.3.1 N-Square Diagramming Methods......Page 178
3.6.3.2 Schematic Methods......Page 179
2.6.3.3 Interface Dictionary......Page 182
3.6.4 Interface Media and Requirements Definition......Page 184
3.6.5.1 Capture in the Requirements AnalysisSheet and Database System......Page 186
3.6.6.2 Three Views of Interface......Page 187
3.6.6.3 Interface Responsibility Model......Page 188
3.6.6.4 The Special Need for External Interface Development......Page 190
3.7 Specialty Engineering Requirements Analysis......Page 193
3.7.2.1 Requirements Identification Responsibility Aid......Page 194
3.7.2.2.2 Cloning Approach......Page 195
3.7.2.2.5 Structured Analysis in the Twenty-First Century......Page 196
3.7.2.4.1 Checklist Approach......Page 197
3.7.2.4.3 Organized Interaction Meetings......Page 198
3.7.2.5.2 Non-Compliance Correction......Page 199
3.7.3.1.3 Task 3, Failure Reporting, Analysis, and Corrective Action System (FRACAS)......Page 200
3.7.3.1.8 Task 8, Failure Modes, Effects, and Criticality Analysis (FMECA)......Page 201
3.7.3.2 Parts, Materials, and Process Engineering (PMP)......Page 202
3.7.3.3 Maintainability Engineering......Page 203
3.7.3.3.2 Task 2, Document Maintainability Requirements and Criteria......Page 204
3.7.3.3.8 Task 8, Failure Reporting, Analysis, and Corrective Action......Page 205
3.7.3.5 Producibility Engineering......Page 206
3.7.3.7 Human Factors Engineering......Page 207
3.7.3.12 Mass Properties Engineering......Page 208
3.7.4.1 The Ultimate System Diagram......Page 209
3.7.4.2 Give Us the Sense to Know the Difference......Page 210
3.7.4.4 Specific Science Development Programs......Page 211
3.8 Environmental Requirements Analysis......Page 212
3.8.2.1 Natural Environment (QN)......Page 213
3.8.2.3 Non-Cooperative Environment (QX)......Page 214
3.8.3.2 End Item Environmental Requirements......Page 215
3.8.3.3 Component Environmental Requirements......Page 219
3.8.4.2 Timeline Diagram Symbols......Page 220
3.8.4.4 Selectivity......Page 221
3.8.4.5 Tabular Timelines......Page 222
3.8.4.6 Timeline Reporting......Page 223
3.8.6 Environmental Impact......Page 224
3.9 Functional Analysis Alternatives......Page 225
3.9.2.1 Hierarchical Functional Analysis......Page 226
3.9.2.2.5 Kill Branch......Page 227
3.9.2.3 Behavioral Diagramming......Page 228
3.9.2.4 IDEF-0......Page 229
3.9.2.5 FRAT......Page 230
3.9.3.1 State Transition Diagram Analysis......Page 231
3.9.3.2 Finite State Machines......Page 233
3.9.3.3 Petri Nets......Page 234
3.9.4.1 Mathematical Equations......Page 235
3.9.5.4 Strings or Threads......Page 236
3.9.6.1.1 Diagramming......Page 237
3.9.6.1.3 Process-Environment Linkage......Page 239
3.9.6.2.2 Generic Process Analysis......Page 240
3.9.6.3.2 Program Material and Procurement Process Analysis......Page 241
3.9.6.3.4.1 Test Planning Analysis (TPA)......Page 242
3.9.6.3.4.2 Development Test Requirements Analysis......Page 243
3.9.6.4 Deployment Planning Analysis (DPA)......Page 244
3.9.6.5.2 LSA Example......Page 245
3.9.6.5.4 Modification Development......Page 248
3.9.6.6 Disposal Analysis......Page 251
3.9.7.1 Introduction to Quality Function Deployment (QFD)......Page 252
3.9.7.2 Physical Implementation......Page 253
3.9.7.4 Linking QFD with Structured Analysis......Page 254
3.9.7.5 Derived Requirements Generator......Page 255
3.10 RAS-Complete and RAS-Centered Analysis......Page 256
3.10.3 System Functionality......Page 257
3.10.6 The Beginning of the Complete RAS......Page 259
3.10.8 Allocation Pacing Alternatives......Page 260
3.10.9 System Relations......Page 261
3.10.10 The System Environment......Page 262
3.10.11.2 End Item Service Use Profile......Page 263
3.10.11.3 Component Environmental Relations......Page 265
3.10.12 Specialty Engineering and RAS Complete......Page 266
3.10.14 Conclusions......Page 267
3.11 Traditional Structured Analysis Documentation......Page 268
3.11.2.8 Appendix G, Requirements Analysis Sheet......Page 269
3.11.3 Recommended Responsibility Pattern......Page 271
4 PART 4, COMPUTER SOFTWARE STRUCTURED ANALYSIS......Page 274
4.1 Introduction......Page 276
4.1.2 Software Development Models for Analysis......Page 277
4.1.5 Software Deficit Disorder......Page 278
4.2 Computer Processing–Oriented Analysis......Page 280
4.2.3 Modern Structured Analysis......Page 281
4.2.6 Are These Models Appropriate Only for Software?......Page 285
4.3 Data-Oriented Analysis......Page 287
4.3.2.2 Relational Database Development Using IDEF 1X......Page 288
4.3.4 DoD Architecture Framework......Page 289
4.4 Object-Oriented Analysis......Page 290
4.4.1.2 SADT and IDEF-0......Page 291
4.4.2.3 The Class and Object Model......Page 292
4.4.2.5 The Functional Model......Page 293
4.4.3 Function-Driven Early OOA......Page 294
4.4.4.1 Problem Space Entry and Continuation......Page 295
4.4.4.2.3 Activity Diagram......Page 296
4.4.4.3 Static Model Elements......Page 297
4.4.4.4 Unprecedented Application......Page 298
4.4.5 Moving to Specification......Page 299
4.5 System Modeling Using the DoD Architecture Framework......Page 300
4.5.2 Overview......Page 301
4.5.3.1.2 Integrated Dictionary (AV-2)......Page 302
4.5.3.2.2 Operational Node Connectivity Description (OV-2)......Page 303
4.5.3.2.6.2 Operational State Transition Description (OV-6b)......Page 304
4.5.3.2.7 Logical Data Model (OV-7)......Page 305
4.5.3.3.2 Systems Communications Description (SV-2)......Page 306
4.5.3.3.4 Systems Functionality Description (SV-4)......Page 307
4.5.3.3.9 Systems Technology Forecast (SV-9)......Page 308
4.5.5.1 Operational View Relationships......Page 309
4.5.6.4 Determine Views and Products to Be Built......Page 310
4.5.6.5 Build the Requisite Products......Page 311
4.5.6.6 Use the Architecture for Its Intended Purpose......Page 312
4.6 Structured Analysis Fusion and Reunification......Page 313
4.6.1 Functional Flow or Die!......Page 314
4.6.2.2 Functional Traceability......Page 315
4.6.3 Expanding Zigzag......Page 316
4.6.5 Model-Driven Development......Page 317
5 PART 5, SPECIFICATION CONTENT STANDARDS......Page 320
5.1 Specification Development Fundamentals......Page 322
5.1.2.1.1 Type A System/Segment Specification......Page 323
5.1.2.1.2.2 Type B2 Critical Item Development Specification......Page 324
5.1.2.1.3 Type C Product Specifications......Page 325
5.1.2.2 DoD Specification Forms under MIL-S-83490......Page 326
5.1.2.4 MIL-STD-490A Specification Baselines......Page 327
5.1.5 Other Requirements Document Types......Page 328
5.1.7 One- and Two-Part Specifications......Page 329
5.1.8 A Strange Specification Format......Page 330
5.2 General Specification Style Guide......Page 331
5.2.1.6 Symbols......Page 332
5.2.2.4 Figures, Tables, and Foldouts......Page 333
5.2.4.2 References to Other Documents......Page 334
5.2.4.5 Identification of Specifications......Page 335
5.2.4.6 Titling the Specification......Page 336
5.3 Specification Content Guidance......Page 337
5.3.1.2.1.2 Non-Government Documents......Page 338
5.3.1.3 Section 3: Requirements......Page 339
5.3.1.3.2.3.1 Materials......Page 340
5.3.1.3.2.9 Qualification (Paragraph 3.9)......Page 341
5.3.1.4.3 Special Tests and Examinations......Page 342
5.3.1.6.1 Intended Use......Page 343
5.3.2 MIL-STD-961D Content Standard......Page 344
5.3.4.2 Commercial Standards......Page 345
5.3.6 An Updated Content Standard......Page 346
5.4 Applicable Documents Analysis......Page 354
5.4.1.3 Document Tailoring......Page 355
5.4.2.2 Applicable Document Assessment Sources......Page 356
5.4.3.1 Create and Maintain Program-Applicable Document List, F3131......Page 358
5.4.3.6 Assemble Specifications Baseline Report, F3136......Page 360
5.4.3.16 Assemble and Review Assessment Recommendations, F313G......Page 361
5.4.5 System Engineering Standards Relating to Requirements Analysis......Page 362
5.5 Part II Specifications......Page 364
5.5.2 Specification Timing......Page 365
5.5.4.2 Content Development Techniques......Page 366
6 PART 6, REQUIREMENTS MANAGEMENT......Page 368
6.1 Process Overview from a Management Perspective......Page 370
6.1.1.2 Total Quality Management......Page 371
6.1.2.1 Resource Overview......Page 372
6.1.2.2 Specification Templates......Page 373
6.1.2.7 Applicable Document Action......Page 374
6.1.2.8 Teaming Planning......Page 375
6.1.2.9.2 PSL Variations......Page 376
6.1.3.1 Program Specifications Plan......Page 377
6.1.3.1.2 Responsibility Assignment......Page 378
6.1.3.2.1 Responsibility and Content......Page 379
6.1.3.4 Principal Engineer Selection, Assignment, and Training......Page 380
6.1.3.5 Program Specification Development Methods......Page 381
6.1.3.7 Regulating the Plunge......Page 382
6.1.3.8 Selective Requirements Development......Page 384
6.1.3.11 Tailoring the Development Intensity......Page 386
6.1.3.12 Development Data Package Concept......Page 388
6.1.4 Program Closeout......Page 390
6.2 Requirements Risk Management......Page 392
6.2.1 Validation and Risk......Page 393
6.2.2 The Validation Time Span......Page 394
6.2.3 Avoiding a Null Solution Space......Page 395
6.2.4.1 Overview......Page 396
6.2.4.2 Initial Screening of the Requirements for Validation......Page 397
6.2.4.3 Validation Intensity Selection......Page 399
6.2.4.4 Formal Requirements Validation Management......Page 400
6.2.4.6 Technical Performance Measurement......Page 401
6.2.4.7 Requirements Maturation Control......Page 402
6.2.6.1 Requirements Necessity and Completeness......Page 405
6.2.6.2 Requirements Value Credibility......Page 406
6.2.6.3 Synthesizability......Page 407
6.2.7.1 Development Evaluation Testing (DET)......Page 408
6.2.7.3 Technology Demonstration......Page 409
6.2.7.6 Validation by Review......Page 410
6.2.8.1 The Many Views of the Product......Page 411
6.2.8.2 Representation Identification......Page 412
6.2.8.4 Representations Documentation......Page 413
6.2.9 Whole Program Phases......Page 414
6.3 Requirements Value Management......Page 415
6.3.2 TBD/TBR Management......Page 416
6.3.3.3 Characteristics Margins......Page 417
6.3.4 Budgets......Page 418
6.4 Requirements Integration......Page 419
6.4.3.1.2 Completeness......Page 420
6.4.3.1.5 Balance......Page 421
6.4.5 Interface Requirements Analysis Integration......Page 422
6.4.7 Process Requirements Integration......Page 424
6.5 Interface Requirements Management......Page 425
6.5.3.4 Interface Control Document Control......Page 426
6.5.5 Interface Audit......Page 427
6.5.6 Some Nonstandard Interface Concepts......Page 428
6.6 Requirements Verification Management......Page 431
6.6.3 Verification Classes......Page 432
6.6.4.5.1 Similarity......Page 433
6.6.6 Acceptance Verification......Page 434
6.6.8 Management Matrices......Page 435
6.7 Specification Development, Review, and Approval......Page 437
6.7.1.2 Responsibility Assignment......Page 438
6.7.3 Specification Archiving, Distribution, and Access......Page 439
6.7.4.3 Proposed SCN......Page 443
6.7.5.1 A Profusion of Document Names......Page 445
6.7.5.2 Conditions of Use......Page 446
6.7.5.4 Interface Definition and Document Organization......Page 447
6.7.5.5 Interface Terminals and Media......Page 448
6.7.5.6 System Environmental Interfaces......Page 449
6.7.5.7 Transforming Lines into Requirements......Page 450
6.7.5.8.3 Mixed ICD......Page 451
6.7.6.3 The End of the Paper Specification......Page 452
7 PART 7, COMPUTER APPLICATIONS......Page 454
7.1 The Computer Tool Infrastructure......Page 456
7.1.2 Evolution of Methods......Page 457
7.1.4 Requirements and Specifications Electronic Environment......Page 458
7.1.5 Networking and Workgroup Computing......Page 459
7.1.6 A Basic Requirements Database......Page 460
7.1.8 Verification Tracking Tool......Page 461
7.1.9 Requirements Management Data Fields......Page 462
7.1.11 Traceability to Process......Page 463
7.1.12 Data Integrity......Page 465
7.2 Computer Tools for Requirements Analysis......Page 466
7.2.3 Available Tools and Their Features......Page 467
7.2.4.2 Tool Linkage......Page 468
7.2.5.2 Networking......Page 469
8 PART 8, CLOSING......Page 470
8.1 Where Have We Been?......Page 472
8.1.1.4 Demand-Driven Requirements Analysis......Page 473
8.1.2 Overcoming Impediments to SRA Success......Page 474
Acronyms......Page 476
index......Page 478