System Analysis, Design, and Development : Concepts ...

1 System analysis , design , and DevelopmentConcepts, Principles, and PracticesCharles S. WassonA John Wiley & Sons, Inc., PublicationSystem analysis , design , and DevelopmentSystem analysis , design , and DevelopmentConcepts, Principles, and PracticesCharles S. WassonA John Wiley & Sons, Inc., PublicationCopyright 2006 by John Wiley & Sons, Inc. All rights by John Wiley & Sons, Inc., Hoboken, New simultaneously in part of this publication may be reproduced, stored in a retrieval System , or transmitted in any form or byany means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted underSections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission ofthe Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright ClearanceCenter, Inc., 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400, fax 978-646-8600, or on the web Department, John Wiley & Sons, Inc.

2 , 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, e-mail: of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts inpreparing this book, they make no representations or warranties with respect to the accuracy or completenessof the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for aparticular purpose. No warranty may be created or extended by sales representatives or written sales advice and strategies contained herein may not be suitable for your situation. You should consult with aprofessional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or anyother commercial damages, including but not limited to special, incidental, consequential, or other general information on our other products and services please contact our Customer Care Departmentwithin the at 877-762-2974, outside the at 317-572-3993 or fax also publishes its books in a variety of electronic formats.

3 Some content that appears in print, however,may not be available in electronic of Congress Cataloging-in-Publication Data:Wasson, Charles S., 1948 System analysis , design , and Development : Concepts , principles, and practices / by Charles S. cm. A Wiley-Interscience publication. Includes bibliographical references and 978-0-471-39333-7 ISBN-10 0-471-39333-9 (cloth : alk. paper)1. System design . 2. System analysis . I. 1 dc222004061247 Printed in the United States of America10987654321 If an error or omission is discovered, please notify the publisher with corrections in writing. at Requests to the Publisher for permission should be addressed to the PermissionsTable of ContentsPrefaceixAcknowledgementsxii1 Introduction12 Book Organization and Conventions3 Part I System analysis ConceptsSystem Entity Concepts Series3 What Is a System ?174 System Attributes, Properties, and Characteristics275 System Roles and Stakeholders396 System Acceptability467 The System /Product life Cycle59 System Architecture Concepts Series8 The Architecture of Systems679 System Levels of Abstraction and Semantics7610 The System of Interest Architecture8611 The Operating Environment Architecture9712 System Interfaces110 System Mission Concepts Series13 Organizational Roles, Missions, and System Applications12214 Understanding the Problem, Opportunity, and Solution Spaces13515 System Interactions with its Operating Environment14616 System Mission Analysis15917 System Use Cases and Scenarios167 System Operations Concepts Series18 System Operations Model17819 System Phases, Modes.

4 And States of Operation18920 Modeling System and SupportOperations206 System Capability Concepts Series21 System Operational Capability Derivation and Allocation21722 The Anatomy of a System Capability229 System concept Synthesis23 System analysis Synthesis241vPart II System design andDevelopment PracticesSystem Development Strategies Series24 The System Development Workflow Strategy25125 System design , Integration, and Verification Strategy26526 The SE Process Model27527 System Development Models290 System Specification Series28 System Specification Practices30229 Understanding Specification Requirements31530 Specification Analysis32731 Specification Development34032 Requirements Derivation, Allocation, Flow Down, and Traceability35833 Requirements Statement Development370 System Development Series34 Operational Utility, Suitability, and Effectiveness39035 System design To/For Objectives40036 System Architecture Development41037 Developing an Entity s Requirements Domain Solution43038 Developing an Entity s Operations Domain Solution439viTable of Contents39 Developing an Entity s Behavioral Domain Solution45140 Developing an Entity s Physical Domain Solution46541 Component Selection and Development48042 System Configuration Identification48943 System Interface analysis , design , and Control50744 Human System Integration52445 Engineering Standards, Frames of Reference, and Conventions54446 System design and Development Documentation562 Decision Support Series47 Analytical Decision Support57448 Statistical Influences on System Design58649 System Performance analysis , Budgets, and Safety Margins59750 System Reliability, Availability, and Maintainability (RAM)

5 61551 System Modeling and Simulation65152 Trade Study analysis of Alternatives672 Verification and Validation Series53 System Verification and Validation69154 Technical Reviews71055 System Integration, Test, and Evaluation733 System Deployment, Operations, and Support Series56 System Deployment758 Table of Contentsvii57 System Operations and Support (O&S)773 Epilogue788 Index789 PrefaceAs a user, acquirer, or developer of a System , product, or service, have you ever been confrontedwith one of the situations listed below? Wondered if the people who designed a product bothered to ask potential users to simply tryit before selling it to the public. Found that during a major program review prior to component Development that someonethought a requirement was so obvious it didn t have to be written down. Participated in a new System Development effort and discovered at Contract Award that teammembers were already designing circuits, coding software, and developing mechanical draw-ings BEFORE anyone understood WHAT System users expected the System to provide orperform?

6 Procured one of those publicized designed for assembly products and discovered that itwas not designed for maintainability? Interacted with a business that employed basic business tools such as desktop computers,phones, and fax machines that satisfied needs. Then, someone decided to install one of thosenew, interactive Web sites only to have customers and users challenged by a new andimproved System that was too cumbersome to use, and whose performance proved to beinferior to that of the previous System ?Welcome to the domain of System analysis , design , and Development or, in the case of the scenar-ios above, the potential effects of the lack of System Engineering (SE).Everyday people acquire and use an array of systems, products, and services on the pretenseof improving the quality of their lives; of allowing them to become more productive, effective, effi-cient, and profitable; or of depending on them as tools for survival.

7 The consumer marketplacedepends on organizations, and organizations depend on employees to ensure that the products theyproduce planned missions efficientlyandeffectivelywhen called user skills and capabilities to accomplish tasks ranging from simple to using commonly available their intended environment with minimalrisk and intru-sion to the general public, property, and the the user to complete missions and return maintained and stored until the next use for low any environmental, safety, and health risks to the user, the public, or the a book entitled Moments of Truth, Jan Carlzon, president of an international airline, observedthat every interactionbetween a customer and a business through product usage or service supportis a moment of truth. Each customer product/service interaction, though sometimes brief, producesand influences perceptions in the User s mind about the System , products, and services of eachixorganization.

8 Moment of truth interactions yield , the expe-riences posed by the questions above are moments of truthfor the organizations, analysts, and engineers who develop graduate from college every year, enter the workforce, and learn System Analysis, design , and Development methods from the bottom up over a period of 10 to 30 years. Many spendentire careers with only limited exposure to the Users of their designs or products. As engineersare assigned increasing organizational and contract responsibilities, interactions with organizationalcustomers also increase. Additionally, they find themselves confronted with learning how to inte-grate the efforts of other engineering disciplines beyond their field. In effect, they informally learnthe rudiments of System Engineering, beginning with buzzwords, from the bottom up throughobservation and story is told about an engineering manager with over 30 years of experience.

9 The manageropenly bragged about being able to bring in new college graduates, throw them into the work envi-ronment, and watch them sink or swim on their own without any assistance. Here was an individ-ual with a wealth of knowledge and experience who was determined to let others also spend 30years getting to comparable skill levels. Granted, some of this approach is fundamental to thelearning experience and has to evolve naturally through personal trialsand errors. However, doessociety and the engineering profession benefit from this type of enter the workplace from college at the lowest echelons of organizations mainly toapply their knowledge and skills in solving unique boundary conditionproblems. For many, thecollege dream of designing electronic circuits, software, or impressive mechanical structures isgiven a reality check by their new employers. Much to their chagrin, they discover that physicaldesign is not the first step in engineering.

10 They may be even startled to learn that their task is notto design but to find low-cost, acceptable risk solutions. These solutions come from research of themarketplace for existing products that can be easily and cost-effectively adapted to fulfill these same engineers adapt to their work environment, they implicitlygain experience inthe processes and methods required to transform a user s operational needs into a physical System ,product, or service to fulfill contract or marketplace needs. Note the emphasis on implicitly. Formany, the skills required to understand these new tasks and roles with increasing complexity andresponsibility require tempering over years of experience. Ifthey are fortunate, they may beemployed by an organization that takes System engineering seriously and provides formal 10 years or so of experience, the demands of organizational and contract performancerequire engineers to assimilate and synthesize a wealth of knowledge and experience to formulateideas about how systems operate.