System Requirements
Analysis
Second Edition
Jeffrey O. Grady
JOG System Engineering
San Diego, CA, USA
32 Jamestown Road, London NW1 7BY 225 Wyman Street, Waltham, MA 02451, USA
Copyright © 2014, 2006 Elsevier Inc. All rights reserved
No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangement with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions
This book and the individual contributions contained in it are protected under copyrightby the Publisher (other than as may be noted herein).
Notices
Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary.
Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein.
In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility.
To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein.
British Library Cataloguing-in-Publication Data
A catalogue record for this book is available from the British Library
Library of Congress Cataloging-in-Publication Data
A catalog record for this book is available from the Library of Congress
ISBN: 978-0-12-417107-7
For information on all Elsevier publications visitour website at store.elsevier.com
List of Illustrations
Figure 1.1 The ultimate system abstraction. (A) Traditional, (B) modern structured analysis, and (C) unified modeling language.
3
Figure 1.2 The fundamental system relation. 12
Figure 1.3 The enterprise and system life cycle. 16
Figure 1.4 Typical matrix organization. 27
Figure 1.5 System development transformations. 39
Figure 1.6 The analyst’s relationship to problem space. 41 Figure 1.7 Modeling set organization (A) first tier sets, (B) second tier sets,
and (C) third tier sets.
44 Figure 1.8 Vision and need statement relationships. 47
Figure 1.9 Multiphase program structures. 50
Figure 1.10 Program phasing and generic process relationships. 51
Figure 1.11 Product and process system life cycle. 53
Figure 1.12 Grand systems definition. 57
Figure 1.13 Structured selection of the preferred concept. 59
Figure 1.14 Requirements quality assurance. 65
Figure 1.15 Synthesize system. 66
Figure 1.16 Preliminary design. 68
Figure 1.17 Detailed design. 69
Figure 1.18 DoD acquisition life-cycle model. 75
Figure 1.19 FAA acquisition life-cycle model. 76
Figure 1.20 NASA acquisition life-cycle model. 76
Figure 1.21 A successful prescription. 78
Figure 1.22 Development models. 82
Figure 1.23 Modeling history. 83
Figure 1.24 Systems definition. 88
Figure 1.25 Specification content linkage to modeling. 90
Figure 1.26 UADF work pattern. 91
Figure 2.1 Primitive requirement statement. 95
Figure 2.2 Typical CRL structure. 96
Figure 2.3 Parametric analysis example. 102
Figure 2.4 Three-dimensional traceability. 109
Figure 2.5 Single-tier traceability matrix. 111
Figure 2.6 Multiple document traceability matrix. 111
Figure 2.7 Requirements vertical traceability. 116
Figure 2.8 General interdocument traceability. 121
Figure 2.9 Program-wide requirements traceability. 122
Figure 2.10 Verification traceability string. 124
Figure 2.11 Manual RAS. 127
Figure 2.13 Requirements design margin accounts. (A) Margins in an architecture context; (B) margin Venn diagram.
137
Figure 2.14 Freestyle is for experts and fools. 144
Figure 2.15 Three cloning methodologies. 145
Figure 3.1 Unprecedented system definition. 155
Figure 3.2 Requirements fusion and partition. 156
Figure 3.3 System context diagram. 162
Figure 3.4 General preferred concept selection. 163
Figure 3.5 Typical trade matrix. 165
Figure 3.6 Utility curve examples. 166
Figure 3.7 Precedented system definition. 169
Figure 3.8 System life-cycle model. 173
Figure 3.9 Grand system requirements analysis process function. 174
Figure 3.10 Three-faceted problem space. 177
Figure 3.11 Traditional entry facet and sequence. 178
Figure 3.12 The problem space entry perspective continuum. 180 Figure 3.13 SAR coordination with program processes and specification
templates.
181
Figure 3.14 Traditional structured analysis. 186
Figure 3.15 Development planes. 189
Figure 3.16 Functional analysis. 190
Figure 3.17 Life-cycle master flow diagram. 196
Figure 3.18 FFD style sheet, blocks. 197
Figure 3.19 FFD style sheet, combinatorial symbols. 199
Figure 3.20 Alternative OR symbol usage example. 199
Figure 3.21 FFD levels. 200
Figure 3.22 Functional N-square diagram. 203
Figure 3.23 Recommended functional model specification structure. 206 Figure 3.24 Integration of user, acquisition agent, and contractor requirements
work.
208
Figure 3.25 Generic master function flow diagram. 211
Figure 3.26 Diagramming comparison. 213
Figure 3.27 VPA and MRA process flow. 219
Figure 3.28 Maintenance analysis using process diagramming. 223 Figure 3.29 Functional and performance requirements analysis. 225
Figure 3.30 Team-oriented function allocation. 226
Figure 3.31 Typical RAS. 229
Figure 3.32 RAS—example 1. 234
Figure 3.33 RAS—example 2. 235
Figure 3.34 RAS—example 3. 236
Figure 3.35 RAS—example 4. 237
Figure 3.36 Specification template for performance requirements. 238
Figure 3.37 Functional analysis summary. 239
Figure 3.38 Product entity synthesis process. 241
Figure 3.39 Typical product entity diagram. 243
Figure 3.40 System hierarchy level names. 248
Figure 3.41 Centaur upper-stage product entity structure. 249
List of Illustrations xvii
Figure 3.43 Existing product entity example. 252
Figure 3.44 Typical N-square diagram. 257
Figure 3.45 Extended RAS. 259
Figure 3.46 Compound N-square diagram example. 262
Figure 3.47 SBD symbols. 263
Figure 3.48 Universal ultimate SBD. 264
Figure 3.49 Typical system SBD. 265
Figure 3.50 Primitive SBD. 267
Figure 3.51 Finished SBD. 267
Figure 3.52 Triangular matrix SBD example. 268
Figure 3.53 Crossface SBD expansion. 269
Figure 3.54 Typical interface dictionary listing. 270
Figure 3.55 RAS capture of interface requirements. 271
Figure 3.56 Interface responsibility model. 274
Figure 3.57 Interface partitions. 275
Figure 3.58 Subsystem principal engineer views. 276
Figure 3.59 Cross-organizational interface through an SBD. 278
Figure 3.60 Functional hierarchy diagram. 280
Figure 3.61 Trigger construct. 281
Figure 3.62 Multiple exit construct. 282
Figure 3.63 Repetition constructs: (A) Iteration construct and (B) loop construct.
282
Figure 3.64 Kill branch construct. 283
Figure 3.65 Commodity flow in enhanced functional flow. 283
Figure 3.66 Behavioral diagramming. 284
Figure 3.67 Typical IDEF diagram. 285
Figure 3.68 FRAT sequencing. 286
Figure 3.69 State diagram. 288
Figure 3.70 Superconductor super collider state transition diagram. 290
Figure 3.71 Petri nets. 293
Figure 3.72 Example of a mathematically specified problem. 294
Figure 3.73 Scenario formed by icons. 296
Figure 3.74 System function depiction. 297
Figure 3.75 The QFD house of quality. 299
Figure 3.76 QFD augmented structured analysis. 301
Figure 3.77 Typical process flow diagram. (A) Computer graphics process diagram and (B) project planning software process diagram.
308
Figure 3.78 Process-product entity matrix. 310
Figure 3.79 A multiplicity of processes. 311
Figure 3.80 TPA and MRA process flow. 316
Figure 3.81 LSA process flow. 321
Figure 3.82 Typical system process diagram. 323
Figure 3.83 Postflight maintenance process flow. 324
Figure 3.84 LSA example. (A) First task analysis sheet, (B) second task analysis sheet, and (C) third task analysis sheet.
325
Figure 3.85 Operational sequence diagram. 328
Figure 3.86 System modification process. 329
Figure 3.88 The system relationship. 330
Figure 3.89 Function sequence. 331
Figure 3.90 Function decomposition. 332
Figure 3.91 System life cycle. 333
Figure 3.92 Traditional RAS. 334
Figure 3.93 Function-product entity (architecture) matrix. 335
Figure 3.94 System product entity structure. 336
Figure 3.95 Traditional isolated N-square diagram. 338 Figure 3.96 Juxtaposition of RAS and N-square diagrams. 338
Figure 3.97 System environment. 339
Figure 3.98 System context diagram. 340
Figure 3.99 Environmental requirements RAS addition. 341
Figure 3.100 RAS-complete in graphical form. 344
Figure 3.101 RAS-complete in tabular form. 345
Figure 3.102 Verification extension. 345
Figure 3.103 Functional SAR structure. 354
Figure 3.104 Specification management matrix. 356
Figure 4.1 Flowchart example. (A) Level n flowchart and (B) level n+1 flowchart.
365
Figure 4.2 Higher-tier flowchart. 366
Figure 4.3 Context diagram. 367
Figure 4.4 Dataflow diagram. 368
Figure 4.5 Data dictionary fragment. 369
Figure 4.6 Processing specification (P-spec). 369
Figure 4.7 MIL-STD-498 SRS format. 370
Figure 4.8 DFD for discussion. 373
Figure 4.9 Entity relationship diagram. 375
Figure 4.10 IDEF-1X diagram. 377
Figure 4.11 IPO diagram. 380
Figure 4.12 SADT diagramming. 381
Figure 4.13 Class and object artifact according to Rumbaugh. 384 Figure 4.14 Class and object relationships. (A) Generalization, (B) aggregation,
and (C) association.
384
Figure 4.15 State diagram notation. 385
Figure 4.16 Functional model notation example. 386
Figure 4.17 Hierarchical static structure relationships. 388
Figure 4.18 Use case diagram. 389
Figure 4.19 Statechart diagram. 390
Figure 4.20 Activity diagram. 391
Figure 4.21 Communication diagram. 392
Figure 4.22 Sequence diagram. 392
Figure 4.23 Component and deployment diagrams. 393
Figure 4.24 Framework product partitioning. 399
Figure 4.25 Logical data model example. 403
Figure 4.26 High-level operational concept graphic example. 404
Figure 4.27 Organizational relationships chart. 404
Figure 4.28 Activity model example. 405
List of Illustrations xix
Figure 4.30 Operational event/trace description example. 407 Figure 4.31 System interface description diagram example. 412
Figure 4.32 System–systems matrix. 413
Figure 4.33 System functionality description. 413
Figure 4.34 Operational activity to systems traceability matrix. 414
Figure 4.35 Systems evolution description. 415
Figure 5.1 Specialty engineering scoping matrix. 423
Figure 5.2 Design constraints identification form. 425
Figure 5.3 Typical reliability model. 435
Figure 5.4 Operator sequence diagram. 449
Figure 5.5 Safety hazard diagram. (A) Safety index and (B) program safety hazard index metric.
450 Figure 5.6 System relationship with its environment. 454
Figure 5.7 System environmental classes. 457
Figure 5.8 Time line diagram symbols and conventions. 461
Figure 5.9 Typical timeline diagram. 461
Figure 5.10 Time analysis sheet example. 465
Figure 5.11 System environmental requirements analysis. 469
Figure 5.12 Service use profile analysis. 471
Figure 5.13 AQM-91 firebolt operations and maintenance process diagram. 472 Figure 5.14 Three-dimensional end item environmental model. 473
Figure 5.15 Sample zoning diagram. 476
Figure 5.16 Environmental relationships. 480
Figure 5.17 Self-induced environmental stress. 481
Figure 5.18 EME class comparison. 483
Figure 5.19 A fragment of a RAS containing environmental requirements. 486
Figure 5.20 The system and its environment. 488
Figure 5.21 The ultimate system. 489
Figure 6.1 Federated database structures. 497
Figure 6.2 Program preparation process. 500
Figure 6.3 Modeling pathways. 501
Figure 6.4 Universal architecture Venn diagram. 502
Figure 6.5 Inter-model transfers in system definition. 503
Figure 6.6 Inter-model transfer possibilities. 506
Figure 6.7 Functional UADF inter-model transfers. 517
Figure 6.8 Software extended environmental categories. 520
Figure 6.9 PSARE analysis of the context bubble. 522
Figure 6.10 PSARE architecture template. 524
Figure 6.11 The UML–SysML modeling scheme. 528
Figure 6.12 UML/SysML inter-model transfer options. 529 Figure 6.13 Adjusted UPDM for specification modeling support. 534
Figure 6.14 Extended UPDM UADF modeling artifacts. 537
Figure 6.15 Function/MSA UADF inter-model transfer possibilities. 542
Figure 6.16 Model transfer matrix. 543
Figure 6.17 Example functional analysis data in the RAS. 544 Figure 6.18 Traceability evaluation. (A) Common RAS fragment, (B)
cross-model traceability evaluation matrix, and (C) requirements traceability table fragment.
Figure 6.19 Requirements traceability across the gap. 546
Figure 6.20 Common product entity structure. 548
Figure 6.21 Functional relations to physical interfaces transform. 550
Figure 6.22 Equivalent schematic block diagram. 551
Figure 6.23 Universal specification structure. 553
Figure 6.24 Product entity structure crafted through observation. 554 Figure 7.1 Method of identifying two-part specifications. 580
Figure 7.2 Specification types of interest. 583
Figure 7.3 Work progression. 611
Figure 7.4 Modeling sequence. 612
Figure 7.5 Specification development timing. 614
Figure 7.6 Part 2 outline. 615
Figure 7.7 Typical summary status briefing viewgraph. 626
Figure 7.8 Applicable document assessment workflow. 627
Figure 7.9 ANSI/EIA 632 requirements work sequence. 636
Figure 8.1 Prepare program for structured analysis. 642
Figure 8.2 Coordinated specification responsibility and models. 644
Figure 8.3 Cost-sharing formula. 651
Figure 8.4 Typical specification tree. 656
Figure 8.5 Specification development environment. 658
Figure 8.6 Development schedule modularization. 660
Figure 8.7 The advancing wave. 661
Figure 8.8 Sample IPT meeting cycle. 665
Figure 8.9 DDP responsibility matrix. 670
Figure 8.10 Requirements validation is imbedded in the risk program. 672
Figure 8.11 Risk identification form. 674
Figure 8.12 Sample program risk list. 675
Figure 8.13 Risk index. 675
Figure 8.14 Program risk index profile. 676
Figure 8.15 Item requirements validation process. 680
Figure 8.16 Correlation of validation with the metrics and program risk universe. 682
Figure 8.17 Evaluate requirements activity. 683
Figure 8.18 Requirements validation intensity hierarchy. 685 Figure 8.19 Requirements Validation Tracking Matrix. 687 Figure 8.20 TPM parameter documentation: (A) technical performance
measurement chart and (B) TPM action plan.
689
Figure 8.21 TBD/TBR closure matrix. 692
Figure 8.22 Database structure subset supporting TBD/TBR. 693 Figure 8.23 Parametric analysis of cost and reliability. 697
Figure 8.24 Validation traceability. 699
Figure 8.25 Synthesizability validation traceability record example. 700
Figure 8.26 Typical product entity block diagram. 707
Figure 8.27 Single-item view of the process. 718
Figure 8.28 Specialty engineering integration process. 723
Figure 8.29 Federated ICWT structure. 728
Figure 8.30 Interface integration categories. 729
Figure 8.31 The RAS-complete view of verification. 736
xxi List of Illustrations
Figure 8.33 Typical graphical specification tree. 743
Figure 8.34 Specification development process. 745
Figure 8.35 Specification publishing. 746
Figure 8.36 Specification review and approval. 747
Figure 8.37 Specification change notice. 754
Figure 8.38 Interface definition. 760
Figure 8.39 ICD figure and text coordination. 761
Figure 8.40 Two-layer media-partitioned interface definition. 762
Figure 8.41 Hardware ICD outline. 765
Figure 8.42 Software ICD outline. 766
Figure 9.1 Evolution of system development. 770
Figure 9.2 Computer tool environment. 773
Figure 9.3 Verification tracking links. 779
Figure 9.4 Integrated specialty engineering tools. 781
Figure 10.1 Putting Humpty Dumpty back together again. (A) The designer’s knowledge base in earlier years and (B) the designer’s knowledge base today.
792
Figure 10.2 The movement toward model-driven development. 797
Table 1.1 Comparison of Models 87
Table 2.1 Rationale Traceability 115
Table 2.2 Specification Sections and Functions 119
Table 2.3 Specification Traceability to Responsibility and Method 129 Table 2.4 Sample Requirements in a Comprehensive RAS 131
Table 3.1 Four Three-Faceted Modeling Approaches 177
Table 3.2 Model Coverage References 184
Table 3.3 Principal Organization Responsibility Map 212
Table 3.4 Intermediate Allocation Character Codes 230
Table 3.5 Intermediate Allocation Class Codes 230
Table 3.6 State Dictionary 288
Table 3.7 State Transition Dictionary 289
Table 3.8 JOGSE Universal MID List 347
Table 5.1 Interface Requirements Specification Template 420 Table 5.2 RAS Specialty Engineering Entries Example 427
Table 5.3 System Reliability Data Table 436
Table 5.4 Reliability References 439
Table 5.5 Maintainability Parameters 442
Table 5.6 Corrective Maintenance Requirements List 443
Table 5.7 Maintainability References 446
Table 5.8 Specialty Engineering Specification Template 453 Table 5.9 Some Natural Environmental Parameter References 458
Table 5.10 Typical Serial Time Allocation Example 464
Table 5.11 Sample Environmental Subset Definition Table 473
Table 5.12 E3 Class Relationships 482
Table 5.13 System and Hardware Item Performance Specification Template for Environmental Requirements
487
Table 6.1 Universal Model Coupling 509
Table 6.2 JOGSE Universal MID List for Functional Analysis 514
Table 6.3 MSA-PSARE Modeling Artifact List 525
Table 6.4 System Specification Template Employing MSA-PSARE UADF
527
Table 6.5 JOGSE MID List for UML–SysML UADF 532
Table 6.6 Modeling Artifact Correlation 535
Table 6.7 Functional Relations To Physical Interfaces Transfer Map 549
Table 6.8 RAS Fragment Showing Interfaces 551
Table 7.1 Specification Types 560
Table 7.2 Specification References 567
xxiv List of Tables
Table 7.4 System Specification Template Employing Functional UADF
585
Table 7.5 System Specification Template Employing MSA-PSARE UADF
589
Table 7.6 System Specification Template Employing UML-SysML UADF
590
Table 7.7 Definitions 624
Table 7.8 Compliance Classes 626
Table 7.9 Principal Organizational Responsibilities 629
Table 8.1 SAR Structure for MSA-PSARE 646
Table 8.2 SAR Structure for UML-SysML 646
Table 8.3 Principal Engineer Levels 653
Table 8.4 Development Control Table 662
Table 8.5 DDP Data Destinations 669
Table 8.6 Sample Representations Identification Matrix 690
Table 8.7 Margin Accounts 715
Table 8.8 LCT Identification 729
Table 8.9 Typical Tabular Specification Tree 744
Table 8.10 Program Team Responsibilities 744
Table 9.1 Sample Database Structure and Data 776
Table 9.2 Field Types 777
Table 9.3 Type Codes 777
Table 9.4 Sample Traceability Data 778
List of Acronyms
ABD Architecture block diagram
ASCII American standard code for information interchange ASIC Application specific integrated circuit
BIT Built-in test
CAD Computer-aided design CAIV Cost as an independent variable CAM Computer-aided manufacturing CASE Computer-aided software engineering CCB Configuration control board
CDR Critical design review CDRL Contract data requirements list CDROM Compact disk read-only memory CEP Circular error of probability CFD Control flow diagram
CI Configuration item
CM Configuration management CMM Capability maturity model CONOPS Concept of operations COTS Commercial off the shelf CPC Corrosion prevention and control CPM Critical path method
CRL Concept requirements list
CSCI Computer software configuration item CSCSC Cost schedule control system criteria
C4ISR Command, control, communications, computers, intelligence, surveillance, and reconnaissance
DBS Drawing breakdown structure DCA Design constraints analysis
DCIF Design constraints identification form DCSM Design constraints scoping matrix DDP Development data package
DFD Data flow diagram
DID Data item description DMA Database modeling analysis DoD Department of Defense
DoDAF Department of Defense Architecture Framework DPA Deployment planning analysis
xxvi List of Acronyms
DTE Development test and evaluation EADL Enterprise applicable document list ECP Engineering change proposal EDD Enterprise definition document
EFFBD Enhanced functional flow block diagram EIA Electronics Industry Association EID End item description
EIT Enterprise integration team EMC Electromagnetic compatibility
EMD Engineering and manufacturing development EME Electromagnetic environment
EMI Electromagnetic interference EMP Electromagnetic pulse ERB Engineering Review Board ERD Entity relationship diagram ESD Electrostatic discharge EW Electromagnetic warfare
E3 Electromagnetic environmental effects FA Functional analysis
FAA Federal Aviation Administration FCA Functional configuration audit FDA Food and Drug Administration FFBD Functional flow block diagram FFD Functional flow diagram
FMECA Failure modes effects and criticality analysis
FRACAS Failure reporting, analysis, and corrective action system FRAT Functions requirements architecture test
FRB Failure Review Board
GFE Government furnished equipment GFP Government furnished property GPS Geographic positioning system
GIDEP Government Industry Data Exchange Program GUI Graphical user interface
HAHST High-altitude high-speed target
HERF Hazards of electromagnetic radiation to fuel HERO Hazards of electromagnetic radiation to ordinance HERP Hazards of electromagnetic radiation to personnel HOL Higher order language
HP Hatley Pirbhai
HPM High-power microwave
HW Hardware
ICAM Integrated computer-aided manufacturing ICBM Intercontinental ballistic missile
ICD Interface control document ICWG Interface control working group ICWT Interface control working team IDEF Integrated definition
IMS Integrated master schedule
INCOSE International Council on Systems Engineering IO Input–Output
IOC Initial operating capability IPO Input process output
IPPT Integrated product and process team IRD Interface requirements document IRFNA Inhibited red fuming nitric acid
ITER International thermonuclear experimental reactor JOGSE JOG System Engineering
LCC Life-cycle cost
LCT Lowest common team
LOX Liquid oxygen
LSA Logistics support analysis
MBS Manufacturing breakdown structure
MID Modeling ID
MoD Ministry of Defense
MoDAF Ministry of Defense Architecture Framework MOE Measure of effectiveness
MRA Manufacturing requirements analysis MSA Modern structured analysis
MTBF Mean time between failures MTBM Mean time between maintenance MTTR Mean time to repair
NASA National Aeronautics and Space Administration NATO North Atlantic Treaty Organization
NCOSE National Council on Systems Engineering OMG Object modeling group
OOA Object-oriented analysis
ORD Operational requirements document OTE Operational test and evaluation PCA Physical configuration audit PCB Parts control board PDR Preliminary design review
PERT Program evaluation and review technique PIT Program integration team
PMP Parts materials and processes
PMP Parts materials and processes selection list PPEM Process product entity matrix
PSARE Process for system architecture and requirements engineering PSL Program specifications library
QFD Quality function deployment RAS Requirements analysis sheet
RID Requirement ID
RS Raw score (in a trade study) SAC Strategic air command
xxviii List of Acronyms
SCA Sneak circuit analysis SCD Specification change notice SDR System design review
SEMP Systems engineering management plan SEP System engineering plan
SESM Specialty engineering scoping matrix
SOW Statement of work
SRA System requirements analysis SRD System requirements document SRR System requirements review SRS Software requirements specification SW Software
SysML System modeling language TAAF Test analyze and fix
TBD To be determined
TBR To be resolved
TLCSC Top-level computer software component TPM Technical performance measurement TQM Total quality management
TRA Teledyne Ryan Aeronautical TSA Traditional structured analysis TV Trade value (in a trade study)
UADF Universal architecture description framework UML Unified modeling language
UPDM Unified process for DoDAF MoDAF USAF United States Air Force
USA United States of America
USSR Union of Soviet Socialist Republics UV Utility value (in a trade study) VCRM Verification cross reference matrix
VDC Volts DC
The serious study of the practice of how to determine the appropriate content of a specification is a seldom-appreciated pastime. Those who have the responsibility to design a product would prefer a greater degree of freedom than permitted by the con-tent of a specification. Many of those who would manage those who would design a product would prefer to allocate all of the project funding and schedule to what they consider more productive labor. These are the attitudes, of course, that doom a project to defeat but they are hard to counter no matter how many times repeated by design engineers and managers. A system engineer who has survived a few of these experiences over a long career may retire and forget the past but we have an endur-ing obligation to work toward changendur-ing these attitudes while tryendur-ing to offer younger system engineers a pathway toward a more sure success in requirements analysis and specification publishing.
This is the third attempt I have made to capture the essence of an effective process for accomplishing requirements analysis to expose the proper content of a specifica-tion. The first attempt was a book published by McGraw-Hill in 1993 with the title “System Requirements Analysis.” It was based on work done at General Dynamics Space Systems Division as the Systems Development Department Manager. The method was dominated by functional analysis. Since that time I have been the owner of JOG System Engineering, a system engineering consulting and training enterprise for which I have taught the subject of this book over 120 times at universities, in pri-vate and public courses for short course companies, and at companies through direct sale by my company. As a result I have been exposed to many theories about how to teach others how to do this work and have tried to capture the good ideas and to ignore the bad ones as the book has progressed to another publisher, and two more recent editions of the book.
xxx Preface
The result is captured in this edition integrated with the complete story. That story includes three Universal Architecture Description Framework (UADF) that are immediately identifiable: functional, MSA-PSARE, and UML-SysML. Plus a fourth possible candidate in the form of an extended unified process for DoDAF MoDAF (UPDM). The book includes an encouragement that an enterprise select one of these UADF, select a tool set compatible with it, educate personnel in the application of the model and tool set, and over time continue to improve through repetition of a common process on all programs.
This book also improves upon an earlier proposition that all requirements derived through modeling be traceable to the modeling artifacts from which they were derived requiring a unique means of identifying every artifact from which requirements could be derived no matter the UADF selected. The suggestion is also advanced that a development program should capture the modeling artifacts in a fashion that they can be retained in a configuration-managed baseline in a set of paper documents or computer files.
Each of the UADF offered is formed by a set of problem-space models and solution-space models. The former deals with the problem one is trying to solve expressed in functional or behavioral descriptions, while the latter deals with the physical perspective after the product entities and interfaces have been identified through application of the problem-space models. The solution-space models cover interface, specialty engineering, and environmental requirements while problem-space models are employed in identifying product entities, interfaces, and perfor-mance requirements related to them.
System Requirements Analysis. DOI:
© 20132014 Elsevier Inc. All rights reserved.
http://dx.doi.org/10.1016/B978-0-12-417107-7.00001-4
Introduction
1
The book and its first chapter begin with an introduction to the work this volume focuses on. Many of the subject matter words the reader will find throughout the book are defined and explained. One of the key ideas that support the use of the word “affordability” is that the book encourages the use of models and shows ways that all requirements appearing in all specifications can be derived from models and in the second chapter we will introduce the idea of modeling. Requirements work is what a program begins with so it is appropriate to discuss the management infra-structure within which it and later program phases will occur. Some variations on a central theme are also discussed. Closing out this chapter will be an insight into a proposed prescription for achieving an effective system development process that is affordable to apply while producing good program results.
The overall objective of the book is to show system engineers how to accomplish the early program work related to developing the program-peculiar specifications needed to define the problem that must be solved through design, procurement, and manufacture. A companion volume titled “System Verification” completes the story by covering how a program may determine to what extent the manufactured product complies with the content of the specifications.
1.1 Introduction to Systems Requirements
1.1.1 What Is a System?
System Requirements Analysis 2
There exist natural systems in our universe, such as the ultimate system, the uni-verse itself, the climatic system on Earth, and the human circulatory system. These systems evolved through natural processes not requiring any human engineering activity, and a good thing because there were no humans when many of these sys-tems evolved. Some readers may prefer to recognize that natural syssys-tems were actu-ally put in place by God. The author neither poses a counterargument to that premise nor recognizes that there would be any significant difference in the content of this book if that were the case. Natural systems can be characterized using techniques described in this book, but we must recognize one fundamental difference between natural and man-made systems. Natural systems are not designed by people, they simply must be understood and described by people and this is perhaps more of a job for scientists than engineers.
This situation is changing, however. We are manipulating natural systems to an increasingly powerful extent, bordering on redesign on a small scale. As a result, there will likely be an increasing application in the future for organized system engineering methods in natural system fields like biotechnology, agronomy, weather, and aquifers. The requirements impact analysis approach discussed in this book in association with engineering change proposals and environmental requirements analysis may apply to these situations more than we would care to think about. A TRW (Thompson, Ramo, Woolridge who were the three gentlemen forming this company) systems engineer working on the Yucca Mountain nuclear waste storage site once told the author that the developer first had to identify the degree of isolation provided between the stored material and the local aquifer offered by government furnished property (GFP) before determining what man-made features were required. The author asked how GFP was involved and the engineer replied—“No, God-furnished property.”
A man-made system is developed to achieve a preplanned function, goal, or purpose. These systems require engineering development work to convert the pre-planned function, goal, or purpose into a practical solution composed of physical hardware elements that can be manufactured and assembled from available materi-als. Most often, these systems will also include computer software and, commonly, human operators who interact with the hardware and software to guide the system toward its function, goal, or purpose. Finally, these systems will include relationships implemented through interfaces between the product entities composing the system. Figure 1.1 shows three ways systems are illustrated at the very top level and related to their environment using models that we will discuss in this book.
is where the decomposition process starts, with the ultimate requirement. The two fundamental blocks shown in Figure 1.1 are interrelated by three different kinds of interfaces identified as I1, I2, and I3 that will be explained in a later section.
Using a functional modeling process we can progressively decompose or parti-tion the funcparti-tionality represented by the need into lower-tier funcparti-tionality as a means of gaining insight into what the system and its parts must accomplish and how well it and its many elements must perform. The decomposition process stops when we have identified all of the system resources that will yield to detailed design by a single design agent or team in the producing enterprise or can be procured from a single supplier. In the late 1990s, the author, trying to impress a manager on the International Thermonuclear Experimental Reactor (ITER) program, then based in La Jolla, California, and thus encourage him to purchase a system engineering training program, showed the manager his schematic block diagram (SBD) of the universe. The author, thinking that the universe included everything there was, illus-trated only one block on the diagram containing everything rather than the two-block arrangement shown in Figure 1.1A. The diagram in question will appear in the section dealing with environmental requirements analysis. The manager looked at the diagram briefly and said, “You may have forgotten a few wormholes.” A con-tract was not forthcoming so that may not have been a good marketing technique. Chapter 3 of this book covers the functional analysis (FA) approach depicted in Figure 1.1A in considerable detail. Performance requirements are derived from func-tions and allocated to product entities thereby identifying lower-tier system entities.
Figure 1.1B offers the ultimate system view from the perspective of an adher-ent of modern structured analysis (MSA) used for many years, and to this day, by some to develop computer software. The system, whatever it may become during the development process, is shown interacting with several (three in this case) external entities called terminators. This is a very useful diagram no matter what modeling approach one might employ. A context diagram can also be used to identify all of the parties interested in the development effort, often called stakeholders. In the case of MSA these terminators relate to sources and destinations of information. When
Einvironment
E A
System (A)
(B) (C)
Terminator 3 Terminator 1
Terminator 2
System Use case
Actor
13 12 11
System Requirements Analysis 4
we extend MSA to the process for system architecture and requirements engineering (PSARE), initially called Hatley–Pirbhai modeling, in Chapter 4 we will find that the terminators can be information, energy, or material because PSARE was developed so as not be limited to software development as MSA was intended.
Figure 1.1C illustrates a system from the perspective of an adherent of system modeling language (SysML) or unified modeling language (UML). Actors interact with the system through what are called use cases achieving specific benefits in so doing. Modeling artifacts are then employed to describe these benefits from which requirements are derived. Chapter 4 also covers the model depicted in Figure 1.1C.
This book covers three comprehensive modeling approaches coordinated with the three top-end views in Figure 1.1. A forth modeling approach, also addressed in the book involves over 50 modeling artifacts and the author cannot think of a simple view of the overall process that could be included in Figure 1.1. The U.S. Department of Defense (DoD) has shown great interest in a development model named DoDAF for DoD Architecture Framework. This interest has been extended through cooperation with the UK Ministry of Defence (MOD) under the acronym MODAF. It was initially developed to model large-scale information systems but was initially not appropriate as a comprehensive general system modeling approach like the other three brought together in Chapter 6. Chapter 4 provides an overview of this process in the interest of completeness and recognizes the continuing work being done since 2004 by the Unified Process for DoDAF MoDAF (UPDM) RFC Group composed of several companies in cooperation with the U.S. DoD and UK MOD to advance the use of the modeling artifacts of UML-SysML rather than whatever modeling artifacts the customer, team, or program prefers. In Section 6.5, we also extend the model so that it may be used as a single model that can be used to define the system architecture and support derivation of all requirements that will populate specifications no matter how the system is to be implemented in terms of hardware, software, and people doing things.
The author maintains that all requirements appearing in specifications should be derived through modeling. The author’s set of comprehensive modeling approaches started with three useful models for doing this work covered in Chapters 3 through 5 with the beginnings for them noted in Figure 1.1. With the emergence of UPDM the author has grudgingly added it to form a forth comprehensive modeling approach from which an enterprise may select a single model and encourage its employees to become proficient in using that one model on all programs.
The modeling capability of the problem space components of these four UADF are effective in: (1) identifying needed functionality or behavior, (2) deriving appro-priate performance requirements from that functionality, (3) identifying the product entities that the system should consist of, and (4) identifying the interface relation-ships that will have to exist between the product entities and between the system and its environment. We will have to add to each of the first three UADF an additional trio of solution space models to complete the work begun under the problem space components of these three UADF. The three problem space models are covered in Chapters 3 and 4. In addition to these modeling capabilities they must be combined with the solution space models covered in Chapter 5 for interface, specialty engi-neering, and environmental requirements though MSA-PSARE, UML-SysML (and therefore UPDM) do include adequate interface modeling capability. All or parts of these three models can be coordinated with any of the three UADF to form four complete models each one of which is comprehensive meaning that it may be used to derive all requirements for all entities in a system no matter how we decide to imple-ment the system in terms of hardware, software, and people doing things. These four UADF are then brought together in Chapter 6.
1.1.2 Types of Systems
The central premise of this book is that new systems are most advantageously devel-oped using modeling but this is a conditional premise. There are different kinds of systems and the same development approach will not necessarily work equally well for all kinds. In the search for a truly comprehensive and universal development approach it has been concluded from a study of many systems that all development programs and the systems they create may be partitioned into three sets: (1) unprec-edented, (2) precunprec-edented, and (3) mixed.
1.1.2.1 Development of Unprecedented Systems
System Requirements Analysis 6
a program experimenting with the alternatives, reduces later program development and life cycle use cost substantially. In this book we will set these champions aside because they are the exception and can only be successful where they have adequate financial resources to weather early failures. Most customers would prefer an organ-ized development plan be applied following a tried and proven approach. Such an approach calls for the development of a set of specifications coordinated with a con-current effort to identify design concepts that validate the content of those specifica-tions leading them to a determined effort to design products that comply with the content of the specifications.
There are many ways to prepare and publish specifications all of which, the good and the bad, will be discussed in this book. But, if we wish to be able to do so afford-ably and successfully we must use modeling. The author believes the more unprece-dented the problem space the more emphatically imperative it is that modeling be done well, despite the counterclaims by some people suggested in the previous section.
The problem and solution space modeling approaches, covered in many books that have been practiced on many programs can be effective in piecewise modeling subsets of a total problem space that will be the basis for a particular unprecedented system on a development program. This book will point out that none of these mod-eling approaches are comprehensive permitting just one of them to be used for the derivation of every requirement for every part of every system in which you might become involved in developing. Section 1.5 offers an affordable prescription involv-ing the application of one of four comprehensive modelinvolv-ing approaches within the context of an overall effective systems development infrastructure. Chapters 3–5 of this book offer detailed descriptions of the parts of these four model sets and Chapter 6 provides chapters that focus on each of the four.
1.1.2.2 Development of Precedented Systems
If we are faced with a precedented problem space where a development action taking place at some time in the past produced a system that can be observed functioning somewhere in the world but either the program did not capture the modeling basis or the work products that were created have been lost, we may choose to precede the selective design process with an overall problem space modeling development pro-cess using one of the four UADF suggested in this book.
system development process calling for the application of an effective systems requirements effort as the beginning.
Today, the money is commonly not available to undertake substantial unprec-edented development efforts and we find organizations like the U.S. DoD embracing spiral development rather than the traditional waterfall approach that permits evolu-tion of new capabilities using a cyclical or evoluevolu-tionary approach to satisfying the ultimate need and uniting families of previously independent systems characterized by weak linkages into Earth circling systems that are able to apply tremendous lever-age to hostile forces. Much of this work revolves around the development or knitting together of precedented systems.
The reality today is that many military, space, and commercial systems that are developed are heavily precedented based on a prior history of development of similar systems that exist in the real world and can be observed functioning if one simply travels to a particular place on Earth. The development of the 2014 Chevrolet will likely be such a development unless General Motors has a breakthrough in a new form of propulsion between now and then. It is also likely that the B52 will pass through at least one more development effort before all models finally take up final residence in the Tucson, AZ bone yard.
In the case where the problem space modeling and specifications exist for the old system, we can dispense with trying to re-create it. We should first make sure we clearly understand the need associated with the new system being developed. We can then compare the functionality of the new system with the old system functionality and then apply the functional differential to the existing product entity structure.
The process of applying the functional differential to the old product entity struc-ture is accomplished in this and the prior case by determining for each entity in the old product entity structure which of the following apply.
1. Okay as is.
2. Suitable for use with modification.
3. Unsuitable for use in the new system and may require replacement or reconfiguration of the system to accomplish the related functionality elsewhere.
4. There exists nothing in the existing system that can accomplish new functionality calling for the addition of a new item to the system.
System Requirements Analysis 8
1.1.2.3 Development of Systems with a Mixed Legacy
Systems are commonly composed of systems and some parts of large systems may fall into the unprecedented case while other parts are properly precedented in nature. That is of no mind because any system view will fall into only one class at the level it is being considered. Subordinate elements of that system may partition between the two classes but at the level of interest it will be one or the other. In a large devel-opment, or the integration across previously developed systems being accepted into a grander view of a system, one will commonly find a mix of classes but each can be dealt with in accordance with a set of rules that apply to precedented and unprec-edented systems within its own scope. This is a very common case in many systems today where we find needs being satisfied by linking together several previously independently developed systems. At one time the U.S. Navy did not view a com-plete ship as a system but now a ship is but a node in a grand system with its parts linked together into networks.
1.1.2.4 Emergent Behavior
In the first section of this book it was said that a system was an organized collection of entities that interact synergistically via the interfaces connecting them to achieve preplanned goals in accordance with a predetermined plan or process. Enterprises involved in the development of some systems today and in particular military systems that are said to be systems of systems often find that unexpected features, functions, characteristics, or opportunities emerge over the development period or even in early testing and operation. It may seem that this occurrence contradicts the earlier claim. The reality is that we do the best we can with what we can know early in the development of a new system or collection of systems but it is very hard to know everything of interest about a system under development by multiple organiza-tions at the time when it would be most helpful for the smooth evolution of the over-all program.
The author maintains that one of the modeling approaches covered in this book offers the best opportunity for the timely selection or discovery of characteristics of systems no matter how complex the problem space and program organizational structure. But, it is critically important that the system engineers doing the mode-ling work early in the development effort really understand what they are doing in their modeling work relative to their customer’s mission intent. A slavish devotion to modeling and computer implementations of those models is not a healthy atti-tude. We model in an effort to understand a problem space. Persons doing this work should have a broad enough perspective to deal with both the realities of that prob-lem space and the modeling of it without becoming lost in the model of the space.
more than the development force can do to consciously identify and exclude all such behavior. We might be better off to model and develop a system to the best of our ability to satisfy the customer need while maintaining an interest in identifying any capabilities not intended and either excluding those found to be disadvantageous and encouraging those that are advantageous.
1.1.3 The Word Affordable
The word affordable and the term system development are not thought to properly fit into the same sentence by many people some of whom have had to pay the price for development of a system. The fact is that systems, whatever they are, can be devel-oped well or badly, affordably or outrageously expensively. That customers deserve well and affordable but do not always get that combination is true. This book makes the claim that it is possible, however, to achieve both characteristics in a delivered system. It is a fact that money spent well in early development work can reduce the slope of the cost curve later in development and significantly reduce life-cycle cost. Granted, one may have to spend more money in the beginning to achieve this out-come but the total program cost will be less.
1.1.4 Onward to a Model
This ultimate view of a system and its environment shown in Figure 1.1 is impor-tant because in developing new (unprecedented) systems we commonly do not have knowledge of the details. What we have is a very high-level view of our need and most often from an operational perspective dealing with solving a particular prob-lem. This top-level beginning point happens to fit together well with the ideas of Louis Sullivan, an architect in the late nineteenth and early twentieth centuries, who thought that “… form should ever follow function.” That is, in developing a solution to a complicated problem we should first try to understand the needed functionality and base the form of the solution on that functionality. Thus in our modeling efforts we will first attempt to understand the customer’s need as the ultimate expression of system function or behavior. We will then apply decomposition of that functionality and a means by which we can associate functionality with product entities at the sys-tem and subordinate levels.
So far the book has used the word modeling several times and the word will appear many more times because the book is based on the reality that when we develop systems that have few precedents we have no current model in our existing reality because we have never developed a similar system. The top-level models illustrated in Figure 1.1 express three different modeling approaches that have evolved over the past 50 years and to those we will add one more. Each of these four modeling approaches offers interesting insights into an effective system development process but the time is long past when we should find a single universal way to model systems. It is a goal of this book to do so even if we have to accept four as a temporary plateau.
System Requirements Analysis 10
environmental influences on the product as well as what is called environmen-tal impact, which covers the negative influences on the natural environment by our system. The environment is actually much grander than the natural environment. In addition to the natural environment, we need to consider hostile systems effects, cooperative systems interfaces, and noncooperative systems influences. Also, certain aspects of some systems interact with the natural environment to feed back poten-tially damaging effects called self-induced environmental effects.
We must deal with one other kind of system while developing systems, the sys-tem that gives birth to the product syssys-tem, that we humans are members of. There was a time when engineers believed that it was sufficient to optimize the product at the system level. We should recognize that we need to optimize at the aggregate system level, including the product and the process. In this book, we consider two components of this creator system: the processes, such as manufacturing, quality assurance, materials, logistics, and the programmatic aspect, including the organiza-tional arrangement, funding, scheduling, and management of the process.
1.1.5 The Fundamental System Relation
Many attempts have been made to identify the essence of a system. The model offered here is no better than any other, only the one that the author of the book has used as a frame of reference to sort out what is important in a requirements analysis process description. The model uses elementary set theory but is not intended as a serious mathematical system through which systems are defined and designed. It has exerted some influences the author is probably not aware of in shaping this require-ments analysis process description. Ideally, this influence has been in a positive direction. But, if, in the reader’s opinion, this is not the case, this brief explanation of the author’s mental model of system development may be helpful in understanding why the author went astray from the reader’s expectations.
While a field engineer operating on the opposite side of the world from his com-pany, often alone, the author found it necessary to carry a lot of system information in his head. It was not convenient to carry several volumes while flying operational missions as a technical advisor on unmanned reconnaissance aircraft launch mis-sions staged from a DC-130 during the Vietnam War. While it was not possible to remember all the details of the operations and maintenance processes for any given model, it was possible to remember a framework into which things fit, so that, when questions were posed by the customer about particular operations and maintenance practices, answers came to mind as an extension of his economical system context. Some of this information was also classified and could not be easily carried about in paper form. The model exposed here grew out of that experience as a means to quickly identify important information about new systems and organize this infor-mation, minimizing its volume in a model to conform to the author’s normal limited memory capacity.
other characteristic of a system can be linked. Systems consist of entities and rela-tions among those entities, and our definition of a system must absolutely establish whether or not any given object is in the system. If it is not, it is in the system’s envi-ronment. If it is in the system environment, it will either exert an influence on the system or not. If it does not, it can be disregarded. The entities that compose a sys-tem can be organized into a hierarchical tree structure. The complete set of entities that form a system when organized in this manner are collectively referred to as the
product entity structure. This always begins with the block illustrated in Figure 1.1A called the system. The system comprises two or more subordinate elements. Each of these may be composed of two or more elements and so on down through the system structure to detailed parts and materials. We will see shortly why it is necessary to organize a system in this hierarchical fashion.
Each of the elemental system descriptors is assigned a modeling ID (MID), such that traceability can be identified and retained for the modeling source from which all requirements were derived. So, product entity is one of these fundamental system descriptors and its MID is a sting of characters beginning with the letter “A.” At one time the author referred to the product entity structure as a depiction of the system architecture but has come to agree with many other people who more appropriately apply the word architecture in a much broader context to include not only what the system is physically composed of but all of the descriptive modeling elements.
The entities, parts, or objects of the system must interact in useful ways for the aggregate of entities to qualify as a system. The medium for this interaction is called an interface. Each interface element is characterized by two terminals and a media connecting them. An interface is completed either via an element of the system (a wire harness or fluid plumbing run, for example) or via some characteristic of the system environment (a radio signal from a ground station through the atmos-phere and outer space to a satellite, for example). These interfaces are a second fundamental descriptor. The MID applied to interfaces are strings beginning with the letter “I.” Each interface element maps to a pair of terminals, at least one of which is an element in the system product entity structure. Each interface element is com-pleted between these terminals via some kind of media that is part of the system or its environment.
The product entities interact via interfaces with each other and with the system environment, which may include other competing (hostile), independent (noncoop-erating), or cooperating systems, to achieve the system goals. The environment is a third descriptor using the letter “Q” as its lead character. The environment includes space, time, some subset of the natural environment, a possible hostile environ-mental element as well as cooperative and noncooperative environenviron-mental elements. Environmental influences could be treated as interfaces (in fact, cooperative ones are treated that way) but they are generally singled out as a separate category.
System Requirements Analysis 12
A system is intended to satisfy predefined functions, identified in each case by a MID with the beginning letter “F.” The highest-level function is the customer need (F), and this need is also the ultimate system requirement. All other performance requirements for the system and its parts, in theory, are or should be derived from it through a functional modeling structure. Any performance requirement not traceable to the need may be a source of unnecessary cost.
Finally, a man-made system should have a prescribed physical process for opera-tion of the system, and this process is the sixth system descriptor. In the author’s model process steps are identified using an MID string with leading character being a letter “P.” The system process includes all the planned steps involved in operation and maintenance of the system. For an existing system that is actually in operation in its normal environment, we can see the architecture elements interacting with themselves and the system environment via interfaces in accordance with a prede-fined process to achieve the system function (satisfy the system need). For new sys-tems we wish to create, we need a model of this vision to make it perfectly clear to everyone working to develop the new system. Figure 1.2 illustrates a simplistic set-theoretic approach to understanding the relationship between these entities. If we imagine the product entities (A), interfaces (I), and environmental elements (Q) as sets in a mathematical sense, each consisting of many elements, then we can cre-ate a mathematical construct for the cross product (x) of the power sets of these entities (A*x I*x Q*). Since a power set (such as A*) contains every possible subset for a set of elements, including the null as well as all the elements, we can be cer-tain that at least some of these subsets concer-tain useful combinations of system ele-ments and every useful combination is in the power set. The cross product of these power sets includes every possible combination of system product entities, inter-face, and environmental elements that could be useful in completing every system process. This set also contains a lot of useless collections. As system engineers building a model of the system to be developed, we have to determine the useful sets of elements.
Function plane (F) Process axis (P)
Architecture plane (A*) Environment plane (E*) Interface plane (I*)
S = P:(A*xI*xE*) F
The physical system processes call up the system elements, so let us use the sys-tem processes as a relation that maps the cross product of the power sets of product entity, interface, and environment sets to the system functions. As the system process axis flows through the intersection of the three planes illustrated, it can be thought of as sequentially aligning the three power set planes to pick up the trio of subsets required to achieve a particular system function. Therefore, a system (S) can be said to be defined by the map of the cross product of the power sets of A, Q, and I to the set F.
For a new system not yet defined, an unprecedented system, we do not have this full picture, as we do for an existing system, put into the context of Figure 1.2. In the most extreme case, we may know only the top-level system function, the need. Our problem in system development is to somehow convert this system need into the full picture of a set of resources that interact among themselves and the environ-ment via specific interfaces in accordance with prescribed processes to achieve the system function. Many systems operate in the cyclical fashion illustrated here but not all. The reason for the cyclical nature of many systems is reusability of some major element in the system in the interest of economy. In any case, we can say that the system has satisfied its function if, in N cycles of the process axis, the function set is covered (every element of the function set has been satisfied). Thus, we can say that a system is defined as the sequenced process set that maps the cross product of prod-uct entity, interface, and environmental power sets to a function set.
With this diagram for reference, it appears that we develop systems in a kind of inverted way. We begin with the ultimate function and work back toward the details of how that function may be satisfied in terms of a set of product entities (resources) interacting in a described environment via interfaces in accordance with a planned process. The system development process guides us along this backward road, work-ing from the general toward the specific, dividwork-ing up large problems into small ones, solving those small problems, and integrating those small problem solutions to opti-mize at the system level.
If we make the correct choices during this problem decomposition process, the solutions to these little problems come together in a synergistic way to cover the sys-tem’s function set and fully satisfy the customer need. If we make bad choices, the result almost certainly is some combination of a customer need unfulfilled, unneces-sary cost, and late delivery.
System Requirements Analysis 14
A system that has been developed and delivered has a physical existence but prior to its development its existence is conceptual at best. A system of the kind with which we are interested in this book comes into being through a human reali-zation that some desired or necessary activity or function cannot at the time be accomplished and this realization is phrased in what this book refers to as a need that is a simple statement expressed in a sentence or section from a user’s perspec-tive describing the problem and expressing some idea of its solution, perhaps in the form of a scenario or set of scenarios, and the results of its application to a specific problem space. Commonly, those who have needs they can understandably express do not also possess the resources or ability to develop them into a system to satisfy those needs.
Systems are commonly created by enterprises that specialize in the development of systems for persons and organizations that have recognized a need and contracted with the enterprise for the purpose of obtaining a system to satisfy that need. The development enterprise accomplishes the development action gaining income for its services and the materials of which the delivered system is composed and some part of the proceeds is profit. Thus, in a capitalistic economic framework within a free society, a system development enterprise transforms the knowledge base of its employees and their physical work into profits. The management of such an enter-prise commonly wishes to maximize the profit from each contract while delivering systems that customers find cost-effective in responding to the needs they have that drove the development effort. The question therefore is, “How can the system devel-opment process be configured to best encourage this result?”
One of the fundamental problems that many development organizations have dif-ficulty with is in developing the clear definition of the problem space as a prerequi-site to solving the problem. Some development enterprises make little effort to define the problem they are trying to solve, rather they move too quickly into the design solution work. The author once heard a software manager tell a systems engineering manager at an enterprise, “Who the heck are you to tell my people that they have to model? We don’t have time to model. We have to write code.” Many hardware design engineers share this dislike for the time they see as being wasted in modeling and requirements work. Many program managers also are not big supporters of money spent on front-end modeling. For those, however, who wish to develop affordable unprecedented systems with the least possible risk and remain in business a long time, modeling offers a good prescription.
