System requirements analysis 2nd edition

System Requirements Analysis System Requirements Analysis Second Edition Jeffrey O Grady JOG System Engineering San Diego, CA, USA AMSTERDAM • BOSTON • HEIDELBERG • LONDON • NEW YORK • OXFORD PARIS • SAN DIEGO • SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO Elsevier 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 This book has been manufactured using Print On Demand technology Each copy is produced to order and is limited to black ink The online version of this book will show color figures where appropriate List of Illustrations Figure 1.1 Figure 1.2 Figure 1.3 Figure 1.4 Figure 1.5 Figure 1.6 Figure 1.7 Figure 1.8 Figure 1.9 Figure 1.10 Figure 1.11 Figure 1.12 Figure 1.13 Figure 1.14 Figure 1.15 Figure 1.16 Figure 1.17 Figure 1.18 Figure 1.19 Figure 1.20 Figure 1.21 Figure 1.22 Figure 1.23 Figure 1.24 Figure 1.25 Figure 1.26 Figure 2.1 Figure 2.2 Figure 2.3 Figure 2.4 Figure 2.5 Figure 2.6 Figure 2.7 Figure 2.8 Figure 2.9 Figure 2.10 Figure 2.11 Figure 2.12 The ultimate system abstraction (A) Traditional, (B) modern structured analysis, and (C) unified modeling language The fundamental system relation The enterprise and system life cycle Typical matrix organization System development transformations The analyst’s relationship to problem space Modeling set organization (A) first tier sets, (B) second tier sets, and (C) third tier sets Vision and need statement relationships Multiphase program structures Program phasing and generic process relationships Product and process system life cycle Grand systems definition Structured selection of the preferred concept Requirements quality assurance Synthesize system Preliminary design Detailed design DoD acquisition life-cycle model FAA acquisition life-cycle model NASA acquisition life-cycle model A successful prescription Development models Modeling history Systems definition Specification content linkage to modeling UADF work pattern Primitive requirement statement Typical CRL structure Parametric analysis example Three-dimensional traceability Single-tier traceability matrix Multiple document traceability matrix Requirements vertical traceability General interdocument traceability Program-wide requirements traceability Verification traceability string Manual RAS Lateral traceability using RAS complete 12 16 27 39 41 44 47 50 51 53 57 59 65 66 68 69 75 76 76 78 82 83 88 90 91 95 96 102 109 111 111 116 121 122 124 127 130 xvi Figure 2.13 Figure 2.14 Figure 2.15 Figure 3.1 Figure 3.2 Figure 3.3 Figure 3.4 Figure 3.5 Figure 3.6 Figure 3.7 Figure 3.8 Figure 3.9 Figure 3.10 Figure 3.11 Figure 3.12 Figure 3.13 Figure 3.14 Figure 3.15 Figure 3.16 Figure 3.17 Figure 3.18 Figure 3.19 Figure 3.20 Figure 3.21 Figure 3.22 Figure 3.23 Figure 3.24 Figure 3.25 Figure 3.26 Figure 3.27 Figure 3.28 Figure 3.29 Figure 3.30 Figure 3.31 Figure 3.32 Figure 3.33 Figure 3.34 Figure 3.35 Figure 3.36 Figure 3.37 Figure 3.38 Figure 3.39 Figure 3.40 Figure 3.41 Figure 3.42 List of Illustrations Requirements design margin accounts (A) Margins in an architecture context; (B) margin Venn diagram Freestyle is for experts and fools Three cloning methodologies Unprecedented system definition Requirements fusion and partition System context diagram General preferred concept selection Typical trade matrix Utility curve examples Precedented system definition System life-cycle model Grand system requirements analysis process function Three-faceted problem space Traditional entry facet and sequence The problem space entry perspective continuum SAR coordination with program processes and specification templates Traditional structured analysis Development planes Functional analysis Life-cycle master flow diagram FFD style sheet, blocks FFD style sheet, combinatorial symbols Alternative OR symbol usage example FFD levels Functional N-square diagram Recommended functional model specification structure Integration of user, acquisition agent, and contractor requirements work Generic master function flow diagram Diagramming comparison VPA and MRA process flow Maintenance analysis using process diagramming Functional and performance requirements analysis Team-oriented function allocation Typical RAS RAS—example RAS—example RAS—example RAS—example Specification template for performance requirements Functional analysis summary Product entity synthesis process Typical product entity diagram System hierarchy level names Centaur upper-stage product entity structure Warship packaging structure 137 144 145 155 156 162 163 165 166 169 173 174 177 178 180 181 186 189 190 196 197 199 199 200 203 206 208 211 213 219 223 225 226 229 234 235 236 237 238 239 241 243 248 249 251 List of Illustrations Figure 3.43 Figure 3.44 Figure 3.45 Figure 3.46 Figure 3.47 Figure 3.48 Figure 3.49 Figure 3.50 Figure 3.51 Figure 3.52 Figure 3.53 Figure 3.54 Figure 3.55 Figure 3.56 Figure 3.57 Figure 3.58 Figure 3.59 Figure 3.60 Figure 3.61 Figure 3.62 Figure 3.63 Figure 3.64 Figure 3.65 Figure 3.66 Figure 3.67 Figure 3.68 Figure 3.69 Figure 3.70 Figure 3.71 Figure 3.72 Figure 3.73 Figure 3.74 Figure 3.75 Figure 3.76 Figure 3.77 Figure 3.78 Figure 3.79 Figure 3.80 Figure 3.81 Figure 3.82 Figure 3.83 Figure 3.84 Figure 3.85 Figure 3.86 Figure 3.87 Existing product entity example Typical N-square diagram Extended RAS Compound N-square diagram example SBD symbols Universal ultimate SBD Typical system SBD Primitive SBD Finished SBD Triangular matrix SBD example Crossface SBD expansion Typical interface dictionary listing RAS capture of interface requirements Interface responsibility model Interface partitions Subsystem principal engineer views Cross-organizational interface through an SBD Functional hierarchy diagram Trigger construct Multiple exit construct Repetition constructs: (A) Iteration construct and (B) loop construct Kill branch construct Commodity flow in enhanced functional flow Behavioral diagramming Typical IDEF diagram FRAT sequencing State diagram Superconductor super collider state transition diagram Petri nets Example of a mathematically specified problem Scenario formed by icons System function depiction The QFD house of quality QFD augmented structured analysis Typical process flow diagram (A) Computer graphics process diagram and (B) project planning software process diagram Process-product entity matrix A multiplicity of processes TPA and MRA process flow LSA process flow Typical system process diagram Postflight maintenance process flow LSA example (A) First task analysis sheet, (B) second task analysis sheet, and (C) third task analysis sheet Operational sequence diagram System modification process Ultimate system diagram xvii 252 257 259 262 263 264 265 267 267 268 269 270 271 274 275 276 278 280 281 282 282 283 283 284 285 286 288 290 293 294 296 297 299 301 308 310 311 316 321 323 324 325 328 329 330 xviii Figure 3.88 Figure 3.89 Figure 3.90 Figure 3.91 Figure 3.92 Figure 3.93 Figure 3.94 Figure 3.95 Figure 3.96 Figure 3.97 Figure 3.98 Figure 3.99 Figure 3.100 Figure 3.101 Figure 3.102 Figure 3.103 Figure 3.104 Figure 4.1 Figure 4.2 Figure 4.3 Figure 4.4 Figure 4.5 Figure 4.6 Figure 4.7 Figure 4.8 Figure 4.9 Figure 4.10 Figure 4.11 Figure 4.12 Figure 4.13 Figure 4.14 Figure 4.15 Figure 4.16 Figure 4.17 Figure 4.18 Figure 4.19 Figure 4.20 Figure 4.21 Figure 4.22 Figure 4.23 Figure 4.24 Figure 4.25 Figure 4.26 Figure 4.27 Figure 4.28 Figure 4.29 List of Illustrations The system relationship Function sequence Function decomposition System life cycle Traditional RAS Function-product entity (architecture) matrix System product entity structure Traditional isolated N-square diagram Juxtaposition of RAS and N-square diagrams System environment System context diagram Environmental requirements RAS addition RAS-complete in graphical form RAS-complete in tabular form Verification extension Functional SAR structure Specification management matrix Flowchart example (A) Level n flowchart and (B) level n+1 flowchart Higher-tier flowchart Context diagram Dataflow diagram Data dictionary fragment Processing specification (P-spec) MIL-STD-498 SRS format DFD for discussion Entity relationship diagram IDEF-1X diagram IPO diagram SADT diagramming Class and object artifact according to Rumbaugh Class and object relationships (A) Generalization, (B) aggregation, and (C) association State diagram notation Functional model notation example Hierarchical static structure relationships Use case diagram Statechart diagram Activity diagram Communication diagram Sequence diagram Component and deployment diagrams Framework product partitioning Logical data model example High-level operational concept graphic example Organizational relationships chart Activity model example Operational state transition description example 330 331 332 333 334 335 336 338 338 339 340 341 344 345 345 354 356 365 366 367 368 369 369 370 373 375 377 380 381 384 384 385 386 388 389 390 391 392 392 393 399 403 404 404 405 406 List of Illustrations Figure 4.30 Figure 4.31 Figure 4.32 Figure 4.33 Figure 4.34 Figure 4.35 Figure 5.1 Figure 5.2 Figure 5.3 Figure 5.4 Figure 5.5 Figure 5.6 Figure 5.7 Figure 5.8 Figure 5.9 Figure 5.10 Figure 5.11 Figure 5.12 Figure 5.13 Figure 5.14 Figure 5.15 Figure 5.16 Figure 5.17 Figure 5.18 Figure 5.19 Figure 5.20 Figure 5.21 Figure 6.1 Figure 6.2 Figure 6.3 Figure 6.4 Figure 6.5 Figure 6.6 Figure 6.7 Figure 6.8 Figure 6.9 Figure 6.10 Figure 6.11 Figure 6.12 Figure 6.13 Figure 6.14 Figure 6.15 Figure 6.16 Figure 6.17 Figure 6.18 Operational event/trace description example System interface description diagram example System–systems matrix System functionality description Operational activity to systems traceability matrix Systems evolution description Specialty engineering scoping matrix Design constraints identification form Typical reliability model Operator sequence diagram Safety hazard diagram (A) Safety index and (B) program safety hazard index metric System relationship with its environment System environmental classes Time line diagram symbols and conventions Typical timeline diagram Time analysis sheet example System environmental requirements analysis Service use profile analysis AQM-91 firebolt operations and maintenance process diagram Three-dimensional end item environmental model Sample zoning diagram Environmental relationships Self-induced environmental stress EME class comparison A fragment of a RAS containing environmental requirements The system and its environment The ultimate system Federated database structures Program preparation process Modeling pathways Universal architecture Venn diagram Inter-model transfers in system definition Inter-model transfer possibilities Functional UADF inter-model transfers Software extended environmental categories PSARE analysis of the context bubble PSARE architecture template The UML–SysML modeling scheme UML/SysML inter-model transfer options Adjusted UPDM for specification modeling support Extended UPDM UADF modeling artifacts Function/MSA UADF inter-model transfer possibilities Model transfer matrix Example functional analysis data in the RAS Traceability evaluation (A) Common RAS fragment, (B) crossmodel traceability evaluation matrix, and (C) requirements traceability table fragment xix 407 412 413 413 414 415 423 425 435 449 450 454 457 461 461 465 469 471 472 473 476 480 481 483 486 488 489 497 500 501 502 503 506 517 520 522 524 528 529 534 537 542 543 544 546 xx Figure 6.19 Figure 6.20 Figure 6.21 Figure 6.22 Figure 6.23 Figure 6.24 Figure 7.1 Figure 7.2 Figure 7.3 Figure 7.4 Figure 7.5 Figure 7.6 Figure 7.7 Figure 7.8 Figure 7.9 Figure 8.1 Figure 8.2 Figure 8.3 Figure 8.4 Figure 8.5 Figure 8.6 Figure 8.7 Figure 8.8 Figure 8.9 Figure 8.10 Figure 8.11 Figure 8.12 Figure 8.13 Figure 8.14 Figure 8.15 Figure 8.16 Figure 8.17 Figure 8.18 Figure 8.19 Figure 8.20 Figure 8.21 Figure 8.22 Figure 8.23 Figure 8.24 Figure 8.25 Figure 8.26 Figure 8.27 Figure 8.28 Figure 8.29 Figure 8.30 Figure 8.31 Figure 8.32 List of Illustrations Requirements traceability across the gap Common product entity structure Functional relations to physical interfaces transform Equivalent schematic block diagram Universal specification structure Product entity structure crafted through observation Method of identifying two-part specifications Specification types of interest Work progression Modeling sequence Specification development timing Part 2 outline Typical summary status briefing viewgraph Applicable document assessment workflow ANSI/EIA 632 requirements work sequence Prepare program for structured analysis Coordinated specification responsibility and models Cost-sharing formula Typical specification tree Specification development environment Development schedule modularization The advancing wave Sample IPT meeting cycle DDP responsibility matrix Requirements validation is imbedded in the risk program Risk identification form Sample program risk list Risk index Program risk index profile Item requirements validation process Correlation of validation with the metrics and program risk universe Evaluate requirements activity Requirements validation intensity hierarchy Requirements Validation Tracking Matrix TPM parameter documentation: (A) technical performance measurement chart and (B) TPM action plan TBD/TBR closure matrix Database structure subset supporting TBD/TBR Parametric analysis of cost and reliability Validation traceability Synthesizability validation traceability record example Typical product entity block diagram Single-item view of the process Specialty engineering integration process Federated ICWT structure Interface integration categories The RAS-complete view of verification Verification matrices 546 548 550 551 553 554 580 583 611 612 614 615 626 627 636 642 644 651 656 658 660 661 665 670 672 674 675 675 676 680 682 683 685 687 689 692 693 697 699 700 707 718 723 728 729 736 741 List of Illustrations Figure 8.33 Figure 8.34 Figure 8.35 Figure 8.36 Figure 8.37 Figure 8.38 Figure 8.39 Figure 8.40 Figure 8.41 Figure 8.42 Figure 9.1 Figure 9.2 Figure 9.3 Figure 9.4 Figure 10.1 Figure 10.2 Figure 10.3 Typical graphical specification tree Specification development process Specification publishing Specification review and approval Specification change notice Interface definition ICD figure and text coordination Two-layer media-partitioned interface definition Hardware ICD outline Software ICD outline Evolution of system development Computer tool environment Verification tracking links Integrated specialty engineering tools Putting Humpty Dumpty back together again (A) The designer’s knowledge base in earlier years and (B) the designer’s knowledge base today The movement toward model-driven development Will teams accept a new member? xxi 743 745 746 747 754 760 761 762 765 766 770 773 779 781 792 797 799 788 System Requirements Analysis language (UML) These tools are generally not well-suited as a general program requirements management application 9.2.4  Features Not Generally Supported Commercially available tools continue to improve rapidly, but there are some features that the tool companies have been slow to implement Some of the tools covered above that are still available include a modeling environment where the problem can be modeled in a functional flow, IDEF-0, state transition, behavioral, or DFD that encourages identification of performance requirements Functionality is identified and allocated to architecture items, placing a demand for a performance requirement based on that allocated function against the item to which it was allocated Most of the tools listed not provide this capability but provide a sound database system into which requirements derived from various manually implemented models can be entered, linked through traceability, and generated into specifications 9.2.4.1  Design Constraints Identification Available tools generally not provide models adequate to encourage identification of appropriate design constraints: interface, specialty engineering, and environmental requirements Physical system schematic block diagramming or N-Square diagramming to which block diagram lines or marked N-Square intersections required interface requirements identification for the pair of items thus identified would be helpful Some of the ideas in the environmental requirements analysis section involving service use profile and end item zoning could be employed to support environmental requirements identification The specialty area is very extensive, and different disciplines need different kinds of support that lead to another area of commercial tool shortcomings addressed in the next paragraph One could appeal to the old USAF notion of a design constraints scoping matrix, covered in Section 2.5.2, but all that would by itself is to encourage the right disciplines to write requirements about specific items in the system architecture 9.2.4.2  Tool Linkage Many tools are structured such that a builder consultant can provide interfaces between their tool and others that the client wishes to use in combination This may be especially helpful between separate hardware and software requirements tools But, ideally, tools would provide links to the specialty engineering tools used for mass properties, reliability, maintainability, and life-cycle cost math models, to name a few These requirements are in the form of numbers in the source models, and these values should communicate into the requirements database without rekeystroking We should be able to easily update the specification model from selected specialty engineering databases Computer Applications 789 9.2.4.3  Primitive Capture and Numerical Content One of the things that stands in the way of specialty tool coupling noted above is that the requirements values in specification statements are generally retained mixed with text in an ASCII string While it might be possible to seek out these ASCII values for the numbers, it would be difficult to differentiate between numbers used in requirement quantification and for other purposes in the text An alternative approach would be to capture requirements in primitive form where we capture paragraph number, paragraph title, characteristic name, numerical value, and units plus a trailing text field It is possible, as shown in the prior section, to string these components together to automatically form a complete sentence Once you have the numerical value in a separate numerical field, it could be interacted with other numerical fields for margin and demonstrated design values, permitting the tool to search for management space when problems develop in satisfying particular requirements Margin accounts could be maintained well in context with the actual requirements values rather than in some double-booking scheme But the additional powerful capability availability would be to permit refreshing the requirements database numerical fields from corresponding specialty engineering models for baseline updates—an end specialty engineering requirements double booking 9.2.5  Implementation Suggestions 9.2.5.1  Overcoming Use Difficulties One of the most serious problems with the use of requirements tools is the difficulty of acquiring skill in their use and maintaining that skill with less than regular use Some companies have tried to move to a particular tool use on a grand scale but have failed to reach their goal for this reason Some companies have perfected a good compromise in the use of the very best tools, which tend to be difficult to master They train a relatively small population to use the tool in its full capability, and these people accomplish the requirements analysis work on programs, entering data into the tool or acting as data-entry persons The rest of the population is provided read-only access to the data through a Web page A click on a requirements icon brings up a list of all of the documents in the system A click on one document in a list brings it up on the screen in a word processor document format rather than a multiscreen database system This same approach can be implemented for any other application, of course The beauty of this solution is that the operators of the application can use the very best applications available, updating to take advantage of new capabilities, while users may gain access with a generic easy-to-use application Everyone does not have to learn and maintain skills on everyone else’s applications 9.2.5.2 Networking Your tool should be located on a server and operable from multiple workstations You should wire not only your workspaces but also your meeting rooms for network 790 System Requirements Analysis connection, so that a computer can be located in the meeting rooms, supporting computer projection of database content for use by cross-functional teams doing realtime concurrent engineering on the requirements as they are developed and subjected to changes This capability also enables projection review of specifications The computer application examples covered in this book are drawn from a singleuser application that will work on a single program where a single engineer does all of the requirements work This is a very uncommon situation, except possibly on the concept-development phase of a project On large programs in the engineering and manufacturing development phase, involving distributed requirements analysis responsibilities, we need a much grander solution Such a program needs a networked system capable of multiuser operation that encourages concurrent development of the requirements among the several specialists contributing Some engineering organizations have a central-system engineering group to all requirements analysis and specification development Others use a distributed approach, where each principal engineer or integrated development team is responsible for their own requirements analysis work, with a system engineer being named the principal for the system level and radiating downward to the level where the product entities break up neatly into design group or integrated development team responsibilities The author believes that the distributed approach is the wave of the future and that the networked computer will be the tool that assembles the gaggle of good specialized engineers back together into the equivalent of one great, all-knowing engineer The networked computer will permit the many specialists to concurrently and rapidly blend their specialized knowledge while evolving an appropriate set of requirements for an item Then this team will press on to concept development and a design for the item that is responsive to the requirements Computer-aided specialty engineering tools interlocked with computer-aided design tools will advise the design engineer immediately when he or she has broken a specialty design rule, such as locating an electronic component junction too close to a heat source on a circuit board layout It will not be necessary to await a human specialty engineer to discover the design fault during a drawing sign-off review The principal application of specialty engineering will be to support the design of the specialty tools, but these engineers will also have to interact with the designers on things that no one has been smart enough to introduce into the tools 10 Closing This chapter explores the path we have followed in this book and in our profession followed by an attempt to look into the future—seldom a successful undertaking The reader’s enterprise of interest can, of course, follow the encouragement offered in this book and improve its performance in systems development but the prescription offered may not apply for all time far into the future We will continue to improve our machinery and knowledge leading to advances in method So, it is insufficient to simply master the present Enterprises that wish to improve should observe the differences between university or professional sports franchises recognizing that many such organizations may be successful over a period of time and then fall into a pit while others preserve a winning pattern over the long haul A good coach (management and motivation) is essential, of course, but continuity of progress across changes in management is often hard to achieve 10.1  Where Have We Been? 10.1.1  What Is the Essence of Our Story? System engineering is an organized method for decomposing a large problem into a series of smaller, hierarchically arranged problems and the integration of the solutions to these smaller problems into a solution for the large problem The need for this seemingly complex approach has been spawned by the tremendous amount of knowledge available to humanity, the complexity of our problems, and the knowledge limitations of the normal human beings working to solve those problems within an environment of competition and customer cost and schedule constraints 10.1.1.1  Teamwork and Concurrency The need for specialization has exploded in step with the expanding scope of humanity’s knowledge, leading, in some companies, to serial work patterns to the detriment of our efficiency We need to find ways to glue the all-knowing design engineer back together Figure 10.1 illustrates this problem Many years ago a design engineer could master the complete field of design, at least within one domain In simpler times, the problems design engineers drew would often surrender to a single engineering discipline (mechanical, electrical, and so on) As specialties grew, as a result of knowledge growth, and each expanded its knowledge base, it became impossible for designers to master their own specialized trade and these others as well The result has been to create a tremendous communications problem for the design engineer System Requirements Analysis DOI: http://dx.doi.org/10.1016/B978-0-12-417107-7.00010-5 © 2014 2013 Elsevier Inc All rights reserved 792 System Requirements Analysis (A) (B) 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 We have suggested ways in this book to bring about a condition of teamwork and concurrent development of the product design, production, verification, and sustainment processes These methods have the effect of bonding the several specialists together into a team that is once again capable of an enlightened singleness of purpose that only a few older design engineers may still remember tales of We have emphasized that the development organization should seek to first understand the requirements, evolve alternative concepts supportive of those requirements, select the most effective concept, refine the requirements, and proceed to design The identification and definition process should, ideally, work in a downward direction within a moving band of architecture under the control of a Program Integration Team (PIT) leader or chief engineer by whatever name Once the requirements are known, the design process will generally work best in a bottom-up direction for hardware Software can be defined and implemented in about any direction 10.1.1.2  Developmental Directionality A development organization should consciously choose their preferred developmental directionality In this book, we have emphasized flexibility in that selection with a preference for the top-down direction This was based on the notion that we should work from the simple to the complex, from the general to the specific The alternatives of middle-out and bottom-up offer advantages in narrow circumstances, but our structured requirements analysis (SRA) approach was focused on the top-down approach It is not entirely clear to me how to organize an equivalent comprehensive SRA process for the bottom-up case when dealing with the hardware aspects of a system 10.1.1.3  Multiple Requirements Analysis Strategies We have discussed four requirements identification strategies and indicated the utility of each While a program may choose to enforce one of these strategies, they may also elect to permit local selection within some constraining rules My opinion has Closing 793 been clearly stated as favoring structured analysis in some form In particular, as this is being written, the author would encourage traditional structured analysis (TSA) for systems and hardware entities, as explained in Chapter 3, and Unified Modeling Language (UML) for software, as explained in Chapter  In the not-too-distant future, these two modeling approaches will merge into a truly universal modeling approach with tremendous HW–SW integration benefits for those organizations that can master it The work has been started by International Council on Systems Engineering (INCOSE) and Object Modeling Group with their release of Systems Modeling Language (SysML) version 1.0 10.1.1.4  Demand-Driven Requirements Analysis We have tried to find ways to encourage analysts to write requirements in response to a demand characterized by primitive attributes Each of these demands can be keyed to a specific structured modeling artifact and a specific person, team, or department, who must then respond with a value or qualitative phrasing to complete the requirement This helps to remove an impediment to getting started 10.1.1.5  Progressive Requirements Writing Many engineers are confused by the language they see in specifications In an attempt to strip away all of the trivia, we have emphasized a progressive writing scenario First, we use structured analysis techniques to identify attributes Then we apply domain-specific analysis, allocation, models, or good engineering judgment to determine a sound value for the attribute Finally, we complete the sentence in a format that is consistent with a customer’s expectations defined in a specification standard 10.1.1.6  The Computers Are Coming! No, they are here! Engineering organizations must find out how to employ them to rebuild the engineering team and glue the designer back together The computer offers us a communication tool to blend our minds together into a powerful engine of creativity in a concurrent development environment We have also tried to show how computers may be used to provide broad access to system requirements and a ready repository for the work of many analysts As industry moves toward model-driven development, our computers will become linked together through networks, forming a nervous system for program teams working on the parts of the system development effort that extends our human communications system, consisting of speech augmented by reading and writing 10.1.2  Overcoming Impediments to SRA Success The two greatest impediments to successfully implementing an effective system requirements analysis capability in an engineering organization are (i) a topmanagement-supported notion that design groups should have autonomy to protect their creativity and (ii) a narrow, religious interpretation of the system engineering 794 System Requirements Analysis process as a centralized activity by the members of a system engineering department These two attitudes are poles apart, and closure on a solution cannot be attained until these two buttresses are bridged or knocked down The first step must be taken by the system engineering community, and that is to apply self-discipline and educate its own members in a flexible, distributed approach to system engineering The next step is to gain understanding on the part of design groups and engineering management that SRA is a systematic method for doing what they probably call “a process of deriving requirements.” Ask some design managers, particularly those most hostile to the notion of a systems approach, to sketch out the process their engineers use to derive requirements You will get a lot of different ideas but seldom a systematic, closed-loop process description It will be orally presented by the manager because it is not written down anywhere Explain that the requirements derivation work that his or her engineers can be done in an organized way or an ad hoc way at about the same overall cost If you can then get the point across that the 3000 avoidable engineering changes subsequent to Critical Design Review (CDR) on a recent program were a symptom of lack of upfront requirements analysis within a systematic environment, you are on the road to recovery The final step is to help the design groups through a requirements analysis training phase tailored to their needs (do not force them to sit through hours of the stuff system engineering cultists adore) In Section 1.3, this book offered a simple eight-step prescription that could be useful in educating the staff SRA has been applied to some programs very well in the past, but it has also been applied in ways that consume forests, recycle money, and drive engineering managers to early retirement It should not be so Applied with skill and sensitivity, it can liberate the design engineers to soar to the creative heights they deserve within a protective framework that prevents failure The rigid application of an SRA process has been likened to placing the participants in an old-fashioned zoo with cages This book proposes the equivalent of the San Diego Wild Animal Park, where the animals roam free of cages, as an alternative You may say that this is a distinction of little substance because we are still talking about a zoo But perhaps we have already carried that analogy too far We have to understand that the development of complex systems is the most difficult technical undertaking humanity has conceived It may never surrender to the beautifully simple situation described in the management literature The chief executive officer (CEO) tells his or her staff to bring their department manuals to the next board meeting As they arrive for the meeting, the CEO’s assistant takes the manuals, throws them into a 55-gallon drum, and burns them to a crisp As the staff sits down at the table wringing their hands in anguish, the CEO passes out a two-page summary of the new company policy There are companies that can and actually operate this way The development program for putting humans on Mars will not be run like this System development organizations can choose to operate in an autonomous, internally competitive fashion until their customer base has escaped; or they can, as they see fit, convert to a fully concurrent approach emphasizing teamwork But it is Closing 795 unlikely, as the competitive economic squeeze becomes more binding, that the old style ad hoc organizations will be among the survivors When you cast an eye toward some countries where capitalism has been economically embraced without benefit of the rule of law and the protections contained in the U.S Constitution, you might wonder whether unrestrained competition might produce a human condition as bad as the forms of totalitarianism humanity defeated in the twentieth century The author believes that we will be sufficiently creative in the structuring of development methods and work that humans will not become slaves to system development but rather will come more to enjoy the experience because we will unload much of the tedious busywork into computers and expose the system engineer to the interesting and challenging problems humans are most efficient in dealing with, those that require human thought and creativity 10.2  The Future 10.2.1  Are You Ready for the Future? Engineers graduating from college and reporting for their first job often feel that every great idea has already been thought and every exciting experience has already been had This is, of course, never true but never has it been less true for the profession of system engineering than in 2012 Many of the prerequisites for departure from a paradigm that has served us well for 50 years have been satisfied for a move that will be breathtaking even for those individuals and enterprises ready for it Soon we will establish closure on a universal modeling capability that can feed requirements into a universal specification format while we decide how to implement a semiautomatic model-driven development process Fifty years ago system engineers learned the profession on the job, could refer to few books on their profession, had no professional society to give them a center, and could attend few universities to study their profession There are now many books available on system engineering and a growing number of universities offering educational opportunities in the field We also now have a mature international society serving our profession in the INCOSE The number of system engineers needed in industry is a function of the product and knowledge boundary conditions development programs must deal with We have solved most of the simple problems so we will continue to develop solutions for increasingly more complex problems with more product boundary conditions While man’s individual mental capacity for knowledge remains fairly fixed, the available knowledge continues to expand far beyond this capacity limit reached several thousand years ago encouraging individuals to increasingly more finely specialize With human knowledge capacity fixed and the amount of knowledge expanding we cannot help but have to deal with more knowledge boundary conditions The effect of these two phenomena predetermines an increasing need for system engineers in our future With everything looking up for the system engineering profession, perhaps it is time to blast off into the future leaving behind some of the features of a development 796 System Requirements Analysis paradigm that have served us well for many years but will act as an anchor in the future The present condition of a proliferation of system development models employed in various combinations by some and ignored in total by other developers is not an ideal industrial model This book offers the alternative that embraces one of several possible coordinated modeling sets that are comprehensive, linked to a universal specification template, and employed within an organizational structure where respect is complete for the rule that all requirements shall be derived from models The four Universal Architecture Description Framework (UADF) presented in Chapter 5 are intended to only crack open the door through which others can stride with energy and genius to build rigorously defined comprehensive descriptive models that are coordinated with executable modeling capabilities and effective computer applications There will be a significant improvement in the system definition process in the near term consolidating a common specification development process that networks the specialists contributing to the specifications stimulating a flow of information out of models and into the specifications Hopefully, the tools used by several domains that contribute to specification development will cease being islands connected by human communications and emerge as a network of information nodes What we have been describing in this book is a model-driven development environment where models are exploited to drive out essential characteristics that must be respected in designs and to evolve coordinated design solutions, the manufacturing instructions for which can be generated from the engineering definition of the design The third link can be forged in this same environment as covered in the author’s book “System Verification” to coordinate the system definition work with the proof process that what was designed satisfies the driving requirements 10.2.2  Our Past The contract for the Wright Flier issued to the Wright brothers in the 1920s by the Army Air Corp was a simple document of relatively few pages that included the requirements for the aircraft These requirements were derived from a simple understanding of the problem space by the customer They were captured in a document that was used as the basis for a contract This pattern was applied for many years During the development of intercontinental ballistic missiles the U.S Air Force required its contractors to capture the requirements in computer databases implemented on mainframe computers fed data through Hollerith card readers These databases were used as the source for printing simple paper documents preserving the same document-driven development model as suggested in Figure 10.2 As databases became more capable and human access to their content became easier, it occurred to some people that it would be possible to use the content of the databases directly leading to a potential for what could be called database-driven development With the success of computers and the applications that run on them, over time most engineering work today is accomplished so as to produce computer work products that can continue to mature in step with work accomplished It is possible to develop systems in a document-driven world without doing modeling work This is Closing 797 NOW Rise in the use of implementable models Model-driven development Database-driven development Document-driven development 1920 1970 1990 2010 2030 Figure 10.2  The movement toward model-driven development known because a lot of systems have been developed in this fashion that have been reasonably successful The number of these that have fallen short of complete success were, however, in greater number than we would like to admit it must be said The author believes that over the past 50–60 years there has been an increase in interest in using models as the basis for the development of specifications and the author projects that a history of successful use of modeling in a development organization will be a characteristic of those that succeed in making the next jump to model-driven development 10.2.3  Onward to Model-Driven Development Many development firms can claim to be employing manually implemented modeldriven development at present The many specialist required on a program developing a solution for a fairly complex problem apply their skill and knowledge to pieces of the overall problem contributing to the greater good System engineers integrate and optimize across these knowledge boundaries and product entity boundaries In so doing we sometimes come to realize that there are conflicts between the islands of information being contributed The conflicts are discussed in written and spoken form, meetings are held, action items handed out, and decisions finally reached about what to regarding the conflict Finally, one, both, or all of the source data is changed and the program moves on These kinds of problems often are occurring throughout a program structure of teams all manually responded to across sets of islands of data in different combinations The islands of data are today interconnected by human communications We might ask if there is a better way An alternative would be to introduce special development software between the islands that is capable of detecting conflicts This can be fairly easy where the relationship between the islands is mathematical or logical Where human judgment is required involving a more complex rule set, the intervening software will be more difficult to evolve 798 System Requirements Analysis There exist some inter-island relationships today that have been integrated by software and it is but a matter of time until many others pass over the line Computer-aided design (CAD) software is able to determine that a heat generating component has been placed on a circuit board physically too close to a sensitive semiconductor junction preventing a design engineer from completing such a design Twenty years ago this would have required that a reliability engineer and thermodynamics engineer study the completed printed circuit board design to reach this conclusion Certainly, the reader can see the tremendous improvement in productivity between these two situations CAD is participating in a real-time concurrent engineering process as effectively as if it were accepted as a team member We should recognize two possible modes in implementing these capabilities One possible mode is to accept the error message from the intervening software and, after a study of the situation, trigger through a human management decision a response based on it This is a semiautomatic mode of model-driven development depending on software to alert management to problems that they can choose to react to or not A third alternative is for the intervening software to not only detect conflicts but to act on them without human interference in a fully automatic model-driven development mode What we should see evolving over time is movement of some information island relationships from manual to semiautomatic and others move from semiautomatic to fully automatic There will likely be slow movement in this direction across the contractual boundary where large acquisition agencies are involved like Department of Defense (DoD), Federal Aviation Administration (FAA), and National Aeronautics and Space Administration (NASA) until a lot of contractual, legal, and cultural issues are disposed of But, within an enterprise, there appears to be little to slow movement toward accepting the networked computer, upon which rides the isolated islands of information, into becoming an accepted member of our integrated product and process team (IPPT) as suggested in Figure 10.3 10.2.4  Extension of UADF to Enterprise and Program Systems A system is said to be a collection of entities that interact in accordance with a process to achieve a common purpose In this book, we have applied this definition to the systems that enterprise programs create, but the reality is that enterprises and their programs are systems as well and can be architected just as the product systems they create The entities of the enterprise system are its functional departments that contribute resources from particular knowledge domains to programs based on a clear definition of the common enterprise process The relationships in the enterprise system are described in terms of the generic relationships between the work performed by the departments on a program This can be described by the work products that have to be created on programs and how they flow through the common process tasks and in the process are contributed to by people from these functional departments staffing the program-IPPTs The enterprise can be architected starting with the enterprise vision statement that forms the ultimate enterprise function The vision statement is decomposed using any of the UADF covered in Chapter 6 resulting in a clear definition of the enterprise functionality represented, for example, in a generic or common process diagram that Closing 799 Will there be room for human emotion in the development process? I hope so! Figure 10.3  Will teams accept a new member? is to be implemented on all programs tailored as appropriate for the phase, spiral, and program needs The functionality is allocated to functional departments each of which must at some level of indenture collect all of its work allocations into a department charter statement and manual describing the work it must perform on programs For each task in the enterprise common process diagram we must identified all of the work products that should result from having done the work associated with that process task and how these work products flow among the common process tasks in accomplishing the work on a program An audit of the enterprise architecture in accordance with the content of a recognized system engineering standard (such as Electronics Industry Association (EIA)731 or Capability Maturity Model Integration (CMMI)) provides a verification process for the enterprise system A program system can be architected starting with the customer need statement by whatever name that is decomposed using a UADF to reveal needed functionality that is allocated to product entities subordinate to the block named system We identify interfaces between these entities that are necessary in order for the entities to achieve their function Programs can be audited for verification purposes to discover the extent to which they have complied with their program planning and enterprise common process The author encourages the enterprise to create an enterprise architecture report (EAR) to contain the enterprise architecture data similar to the use of a system architecture report (SAR) on a program to capture the system architecture and configuration manage it These ideas are expanded upon in the author’s book “System Engineering Management” from Elsevier Academic Press 10.2.5  Your Preparation for an Exciting Future So, what can the reader to prepare himself/herself for this stimulating future work environment within our profession? Well, you can sit back and let it happen around 800 System Requirements Analysis you Or you can become a soldier in the march to more effective system development capability If you choose the latter then there are some things you can You can continue your studies of requirements work There are many good books today about this very important work If you are fortunate enough to live in San Diego, CA, besides being able to enjoy the tremendous weather you would also be able to enroll in University of California San Diego (UCSD) extension courses featuring TSA, UML, SysML, DoD Architecture Framework (DoDAF), and Process for System Architecture and Requirements Engineering (PSARE) You may find that universities serving your area have similar programs If they not, you might look into teaching some of these courses for one of these universities The author has taught a general course in requirements analysis over 120 times in the past 15 years and can tell you the sad truth that no one learns more about the subject of a course than the instructor If you are not already a self-proclaimed expert in UML and SysML, you should find a way to improve your understanding about them because they offer the most realistic chance of forming an effective comprehensive UADF Within your company and programs to which you are assigned develop your modeling skills using models of preference in your enterprise Think about how the modeling work on programs could be better coordinated across the hardware–software gap that would lead to more effective integration Join INCOSE and sign up for working groups that deal with the issues covered in this book and offer your ideas Interact with fellow members expanding your professional horizon 10.2.6  Enterprise Actions If you are in a decision-making role within an enterprise system engineering department there are some things you can to encourage future success in system definition Insist on requirements being derived from models Reach a decision that UADF will be successful in your environment and select a set of models for your UADF Find the support for training your people to apply those models to problem and solution space Perfect inter-model traceability and integration skills in the staff as well as coordination of modeling and concept development work You should develop and apply a universal specification format coordinated with the components of our UADF Establish a way to capture and configuration manage the work products that result from modeling work Evaluate the computer tools currently being used against a need to realize better cross-tool coordination and traceability Talk to tool companies, those you are already dealing with and those that would like your business, about how that can be made available 10.2.7  Can It Be Fun and Rewarding As Well? Above all, you should find the profession of system engineering fulfilling and enjoyable As suggested in Figure 10.3 the press of the difficulty of our job should not become a burden There is much to enjoy in our work and much to feel about with Closing 801 real passion But might this not lead to forceful debate and interpersonal conflict? It could at that, but the author is not a supporter of the human resources approach to cross-functional team membership requiring everyone to treat everyone else with sensitivity Some of the most enjoyable times he can recall in system engineering work were accomplished while all parties were yelling at 100 db but short of physical violence, of course There is a lot to be said for the tremendous lift one feels after achieving a great individual accomplishment as in the Olympics, for example, or in having a book published for that matter But, there is also a great feeling of achievement one feels from being a member of a team that has achieved something that none of the members could have done alone This is certainly true of the surviving members of a well-led and prepared military unit in action and can be for the members of a cross-functional team in industry successfully dealing with a series of very difficult choices involving conflicting options requiring intense interaction among specialists toward a common and well understood but difficult goal Try it; you may come to enjoy it It is called being a system engineer Bibliography Booch, (2005) The unified modeling language user guide (2nd ed.) Addison-Wesley [Paragraph 4.5] Demarco, T (1979) Structured analysis and system specification Yourdon Press [Paragraph 9.2.1] Department of Defense MIL-STD-961E, specifications [Paragraphs 1.15.3, 1.4.1.5.2] Department of Defense MIL-STD-490A, specifications [Paragraphs 1.1.15.3, 7.7.5] Department of Defense MIL-STD-498, software [Paragraph 1.4.1.5.1] Department of Defense (1969) MIL-STD-499, engineering management [Paragraph 1.1.14] Department of Defense MIL-STD-499A, engineering management [Paragraph 1.1.14] Department of Defense FIPS PUB 183, IDEF-0 [Paragraph 3.7.2.4] Department of Defense FIPS PUB 184, IDEF 1X [Paragraph 4.3.2.1] Department of Defense CMAN80008A, system specification DID [Paragraph 3.7.3.1] Department of Defense (2009) DODAF, version [Paragraph 4.6.1] DSMC (1983) System engineering management guide [Paragraph 1.1.14] Electronic Industry Association EIA-J-016 [Paragraph 1.4.1.5.1] Electronic Industry Association EIA 632, systems engineering [Paragraph 1.1.8] Grady, J O (1994) System engineering planning and enterprise identity CRC Press [Paragraph 1.3.5] Grady, J O (1999) System engineering deployment CRC Press [Paragraph 1.3.5] Grady, J O (2010) System management, planning, enterprise identity, and deployment CRC Press [Paragraph 1.3.5] IEEE IEEE-1220 [Paragraph 7.7.5] Introduction to automata theory, languages, and computation (1979) Addison-Wesley [Paragraph 3.7.3.2] Jacobson, (2005) The unified software development process (2nd ed.) Addison-Wesley [Paragraph 4.5] Jovanovich (1981) Quantitative methods for business decisions Harcourt Brace [Paragraph 2.1.2.2] Rubinstein, M (1975) Patterns in problem solving Prentice-Hall [Paragraph 2.1.2.2] Rumbaugh, (2005) The unified modeling language reference manual (2nd ed.) AddisonWesley [Paragraph 4.5] SAMSO (1968) SAMSO Exhibit 68–62 [Paragraph 1.1.14] SAMSO (1977) SAMSO STD 77-6 [Paragraph 1.1.14] L.Sullivan (1918) Kindergarten chats and other writings (collected by a relative of Sullivan) [Paragraph 1.5.1] System requirements analysis (2006) Elsevier Academic Press [Paragraph 1.1.15.1] System requirements analysis (1993) McGraw-Hill [Paragraph 1.1.15.1] USAF Ballistic Missile Office (1986) BMO-STD-77-6A [Paragraph 1.1.14] USAF Systems Command (1985) AFSCM 375-5, system engineering management procedures [Paragraphs 1.1.14, 7.7.5] US Army (1979) FM 770-78, system engineering [Paragraphs 1.1.14, 7.7.5] Wymore, W (1993) Model-based systems engineering CRC Press [Paragraph 3.7.3.2] Yourdon, (1989) Modern structured analysis Yourdon Press [Paragraph 4.1.2] ... 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. .. reserved 2 System Requirements Analysis There exist natural systems in our universe, such as the ultimate system, the universe itself, the climatic system on Earth, and the human circulatory system. .. and specifications 8 System Requirements Analysis 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