2 Agenda Definitions of system and systems engineerThe role of a systems engineerSystems engineering vs. project managementSystems engineering functions and processesRequirements Development and ManagementOperations ConceptDecompositionTechnology PlanningSystem analysis and designSystem IntegrationResource ManagementQuality ControlVerification and Validation

3 Definitions What is a System?“A System is a set of interrelated components which interact with one another in an organized fashion toward a common purpose”NASA Systems Engineering Handbook SP6105

4 Definitions (Continued)What is Systems Engineering?“Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems.”INCOSE Handbook

6 Definitions (Continued)In simple terms, the systems engineering approach consists of:Identification and quantification of system goals,Creation of alternative system design concepts,Performance of design trades,Selection and implementation of the best design,Verification that the design is properly built and integrated, andPost implementation assessment of how well the system meets (or met) the goals

7 Definitions (Continued)“Engineering of Systems”Anyone involved in engineering a system should exercise good systems engineering practices.

8 Twelve Systems Engineering Roles1. Requirements Owner2. System Designer3. System Analyst4. Validation and Verification Engineer5. Logistics & Operations Engineer6. Owner of the “Glue” among subsystems7. Customer Interface8. Technical Manager9. Information Manager10. Process Engineer11. Coordinator of the Disciplines12. “Classified Ads” Systems EngineerTo solve a complex problem, we must deal with the problem in a way that fits with how we think.Engineering at any level involves some of this type of thinking—we always break the problem up into more manageable chunks.Systems engineering typically refers to problems which are so complex that different people must work on the different pieces of the problem.Specialists handle the details and systems engineers make sure the pieces work together to form something which is more than the sum of its parts.INCOSE--System designer decides how to break up system. Requirements owner manages requirements which define system and subsystems. System analyst confirms that the designed system will meet requirements. Val/Ver Engineer makes sure the system does meet requirements. Ops Engineer maintains system through operations and end-of-life. Glue role makes sure things don’t fall through the cracks. CI, TM, IM, PE are fairly obvious. Coordinator facilitates group actions. Last one refers to engineers involved with information technology—formerly maintainers of mainframe computer system.1. Requirements OwnerRequirements manager, allocator, and maintainerSpecifications writer or ownerDeveloper of functional architectureDeveloper of system and subsystem requirements from customer needsSystem DesignerOwner of "system" productChief engineerSystem architectDeveloper of design architectureSpecialty engineer (some, such as human-computer interface designers)“Keepers of the holy vision" [Boehm 94]3. System AnalystPerformance modelerKeeper of technical budgetsSystem modeler and simulatorRisk modelerSpecialty engineer (such as electromagnetic compatibility analysts)4. Validation and Verification EngineerTest engineerTest plannerOwner of the system test programSystem selloff engineer5. Logistics and Operations EngineerLogisticsOperationsMaintenance and disposal engineerDeveloper of users’ manuals and operator training materials6. Owner of the "Glue" among subsystemsSystem integratorOwner of internal interfacesSeeker of issues that fall "in the cracks"Risk identifier“Technical conscience of the program" [Fisher 92]7. Customer InterfaceCustomer advocateCustomer surrogateCustomer contact8. Technical ManagerPlanner, scheduler, and tracker of technical tasksOwner of risk management planProduct managerProduct engineer9. Information ManagerConfiguration managementData managementMetrics10. Process EngineerBusiness process reengineerBusiness analystOwner of the systems engineering process11. Coordinator of the disciplinesTiger team headHead of integrated product teams (IPTs)System issue resolver12. “Classified Ads” Systems EngineeringWhat ever special engineering is necessary to keep things from falling through the cracks.from Sarah A.Sheard (INCOSE proceedings of 1996)

10 Key Systems Engineering FunctionsVerification and ValidationProject Objectives and ConstraintsRequirements Development and ManagementArchitecture and DesignTools help engineers evaluate their systems more quickly and more efficiently, but they do not replace the “Art” and “Creativity” necessary to conceive themVerificationandValidationVerification and ValidationProject Objectives Met,Ready for OperationsOperations ConceptSystems Engineering Management Plan“The objective of systems engineering is to see to it that the system is designed, built, and operated so that it accomplishes its purpose in the most cost-effective way possible, considering performance, cost, schedule and risk.”NASA Systems Engineering Handbook SP6105

12 Systems Engineering Process “V” (Continued)Developed by Kevin Forsberg and Harold Mooz*Starts with user needs on the upper left and ends with a user-validated system on the upper rightAdds concurrent risk managementUser involvementUser approval and in-process validationAdds verification problem resolutionPromotes a risk-responsive, phased system development process*Kevin Forsberg and Harold Mooz, "The Relationship of System Engineering to the Project Cycle," Proceedings of the First Annual Symposium of National Council on System Engineering (NCOSE), Chattanooga, Tennessee, Oct. 1991, pp

13 Requirements DevelopmentCollect top-level requirements from customers and stakeholdersDevelop an operations conceptDerive lower-level requirements to support top-level requirements and the operations conceptWriting requirements without a fully understood, agreed upon and documented operations concept will result in poor and misunderstood requirements, cost overruns and schedule slips.

14 Requirements Development (Continued)Writing Good Requirements“Functional Requirements” - What needs to be doneFunctional Requirements are generally not Verified because Performance Requirements specify how good the function needs to beFunctional Requirements define a logical breakdown“Performance Requirements” - How well it needs to be donePerformance Requirements are VerifiableRequirements Decomposition and Parent-Child RelationshipRequirements flow from higher to lower levelsRequirements at lower levels (“children”) must trace from a higher level requirement (“parent”)Eliminate any “orphan requirements” (requirements without parents)Add rationale or comments to the requirements to help trace “why” that requirement was created

15 Requirements Development (Continued)Decompose the requirements in a hierarchical, parent-child relationshipRequirements flow from higher to lower levelsRequirements at lower levels (“children”) must trace from a higher level requirement (“parent”)Eliminate any “orphan requirements” (requirements without parents)Add rationale or comments to the requirements to help trace why that requirement was created

16 Requirements Development (Continued)Writing the right requirementsWhat is necessary to Achieve Full Mission Success Criteria?Levels of requirements (Level 1, Level 2, etc.)Level 1 Generally Highest Level Agreement with Ultimate CustomerLower Levels up to each Project to chooseTraceability (Parent, child, orphan, widow, etc.)PrioritiesOrganizing the requirements(templates and guidelines)Reviewing RequirementsGate keepersFormal reviews (SRR, PDR, CDR)Verification Plan must addresseshow each requirement will be verified

17 Requirements Development (Continued)Use the word “shall” when defining requirements and only for requirements:“The attitude control system shall point the instrument boresight to within 6 arc seconds of the commanded attitude.”Make it clear to the reader exactly what must be done.Requirements should be:MeasurableAvoid vague statements like “shall point as accurately as possible”VerifiableIf no one can demonstrate that a system does or does not meet a requirement, then there is no requirement: shall not exceed 55 kg, but we aren’t going to weigh itDocument rationale!Capture the “why” while it is fresh.Enable future changes—people are afraid to change things they don’t understand.

18 Requirements Development (Continued)What the Proposal PromisedPreliminary DesignDesign DrawingsThe Customer’s SwingThe customer requested a new kind of swing that allowed the customer more than one way of swinging.As Built by ManufacturingFollowing Inspection and ReworkWhat the Customer WantedDesign Change SpecificationAfter ReworkWhat Happened toThe Engineering TeamCommunication and Understanding is Key!

19 Requirements ManagementCollect top-level requirements from customers and stakeholdersDevelop operations conceptDerive lower-level requirements to support top-level requirements and the operations conceptChoose an appropriate tool to store and manage the requirementsThis can range from an Excel spreadsheet for simple projects to sophisticated tools such as DOORS, Team Center, CORE, etc. for more complex projectsBaseline the requirements at a System Requirements Review (SRR)“Baseline” means requirements are signed off and put under configuration controlControl any future changes to requirements through a configuration management process

21 Operations ConceptAn Operations Concept is a vision (in general terms) for what the system is, and a description of how the system will be used.An Operations Concept consists of a set of scenarios describing how the system will be used during all of its operational phases.The scenarios are often accompanied by illustrations of the system operations.An Operations Concept:Serves as a validation reference for the design throughout the life cycleDescribes how the design can accomplish the mission described by the objectivesKey to defining all the requirementsEvolves into the flight operations plan later in the life cycle

22 Operations Concept (Continued)Stakeholders participate in the development of the Operations ConceptTrade studies and analyses are used to demonstrate that the operations concept will meet the mission requirements within cost and schedule constraints

23 Operations Concept (Continued)Considerations for developing an Operations Concept for a Space Mission:Allocation of functions between ground segment and flight segmentMission operational modes and configurationsTime ordered sequence of mission activitiesIdentification of facilities, equipment and procedures needed to ensure the safe development and operation of the systemOperations team size, staffing and extent of automationGround segment functionsContingency conceptsGround test configurations necessary to accomplish verification including GSE, BTE, simulators and non-flight articles such as ETU’sDescription of functions that cut across various subsystemsObservation strategyDate collection, storage and downlinkGround station utilizationMission orbit maintenance and maneuversPower and battery management

25 Many types of decompositionRequirements DecompositionFunctional DecompositionFunctional ArchitecturePhysical DecompositionPhysical ArchitectureOperational ArchitectureAllocates functions to physical subsystemsProvides complete description of the system designIntegrates the requirements decomposition with the functional and physical architectures

27 Technology PlanningProjects are sometimes initiated with known technology shortfallsTechnology “Pull”Often there are areas for which new technology will result in substantial product improvementTechnology “Push”Technology development can be done in parallel with the project evolution and inserted as late as the PDRRisk mitigation requires a parallel approach that is not dependent on the development of new technologyThe technology development activity should be managed as a critical activity

29 Systems Analysis and DesignModelingModels are the language of the designer.Models are representations of the system-to-be- built or as-built.Models are a vehicle for communications with various stakeholders.Models allow reasoning about characteristics of the real system.Models can be used for verification by analysis.All models must themselves be verified.

30 Systems Analysis and Design (Continued)There are two basic approaches that are commonly used for system design and integrationStructured AnalysisObject-oriented Analysis and DesignIt can be shown that either approach can be translated into the other.

31 Structured Analysis Structured AnalysisProcess Modeling, also known as Data Flow Modeling or Functional DecompositionIDEF0*SADT (Structured Analysis & Design Technique)Data ModelingIDEF1xEntity-Relationship DiagramsBehavior ModelingRulesState Transition Diagrams*The IDEF process was developed by the Air Force in the early 1970’s as part of the ICAM program (Integrated Computer Aided Modeling). IDEF originally stood for “ICAM Definition” but NIST later changed it to “Integration Definition”.

36 Object-Oriented Analysis and DesignThe concept of “object” or “object class” is the result of a long history of software engineering design.From a programming viewpoint, an object is a collection of specialized data packaged with the functions (operations and methods) which are needed specifically by that specialized data.From a systems design viewpoint, an object is a system or component which maintains its own information and is able to perform some specific functions.Developed more recently for software engineering, object- oriented design is now migrating to systems engineering.Object-oriented design defines the relationships between object classes and the behavior of the classes.

37 Unified Modeling Language (UML)UML is a language for visualizing, specifying, constructing and documenting the artifacts of software-intensive systems, as well as for business modeling and other non-software systems.UML supports the entire development lifecycle.UML is supported by many tools (e.g., IBM Rational ROSE, Visio, etc.).SysML is the extension of UML to systems engineering.

39 Unified Modeling Language (UML)(3)Domainof InterestBox means Class or Meta Class (top is name) or type2nd box means attributes3rd box means Methods or member functionsDiamond means aggregation/decompositionLine means relationship (words on line describe relationship)(XX) Means look at Concept semantic dictionaryDiamond with a C in the middle means a Complete decompositionLoop line with Diamond means hierarchal decomposition of items of the same typeArrow/triangle means specialization/generalization Depending on directionA number on each end of a line means multiplicity(1)C(4)(22.10)11From MDSD Workshop 5 Feb 2003

44 System IntegrationIntegration is the process of assembling the system from components.Integration begins with the elementary pieces or configuration items (CI’s) of the system.After each CI is tested, components comprising multiple CI’s are tested.This process continues until the entire system is assembled and tested.Interface Specifications and Interface Control are critical to a successful system integration.

45 Work and Resource ManagementA Work Breakdown Structure (WBS) is a hierarchical breakdown of the work necessary to complete a project.The WBS should be a product-based, hierarchical division of deliverable items and associated services.The WBS should contain the Product Breakdown Structure (PBS).At the lowest level are products such as hardware items, software items, and information items (documents, databases, etc.) for which there is a cognizant engineer or manager.A project WBS should be carried down to the cost account level appropriate to the risks to be managed.

48 Technical Resource ManagementCritical mission resources shall be identified, allocated and managedAcceptable resource margins shall be establishedA margin management philosophy shall be set up based on design maturity and timeRequired margins are reduced as the project maturesMargins are assessed based on the fidelity of the estimateCare must be taken that margins are not added to marginsStacked margins that do occur simultaneously in real lifeLead systems engineer holds the overall system marginsSubsystem engineers must be allowed to hold some margin in order to meet their design requirementsThis hierarchy of margins must be taken into account so that the overall system margins do not drive the design and the costMargin costs money, so there is always pressure to reduce margin.Use good judgment and the experience of others to judge how much margin is appropriate.

50 Specialty EngineeringSpecialty engineers support the systems engineering process by applying specific knowledge and analytic methods from a variety of engineering specialty disciplines to ensure that the resulting system is actually able to perform its mission in its operational environment.For space systems these specialty areas often include:Quality AssuranceReliabilityMaintainabilityProducibilityLogisticsSafetyEnvironment (e.g., radiation, atomic oxygen, atmospheric density, etc.)ContaminationParts Engineering

51 Reliability * PerformanceQuality AssurancePerformanceProviding confidence that the systemactually produced and delivered is inaccordance with its functional,performance, and design requirements.QualityCostTimeEngineeringEfficiency=Reliability * PerformanceCost * Time

53 MaintainabilityMaintainability is that system design characteristic associated with the ease and rapidity with which the system can be retained in operational status, or safely and economically restored to operational status following a failure.

54 Verification Verification: “Did I build the System Right?”Each requirement must be verifiedVerification Methods: Test, Analysis, Inspection and DemonstrationRule #1: “Test wherever possible”Perform Analysis and Inspection, where Test is not possiblePay careful attention to validity of simulators and modelsRule #2: “Test the way you fly, fly the way you test”Identify what is not tested in flight configurationCareful review to assure items are properly verified by a combination of Analysis, Inspection or Test.Review of the assumptions and interfaces of element verified in piecesAttention to validity of simulators and simulationsCareful review to assure these items are properly verified by a combination of Analysis, Inspection or Test.

55 Verification (Continued)Rule #3: “Test the system end-to-end”Carefully review the assumptions and interfaces of any elements verified in piecesRule #4: “Verify Off-Nominal Conditions”Verify Redundancy and Graceful Degradation Modes along with On Board Fault Protection and Ground Contingency ProceduresStress Testing and Negative Testing to find Latent Flaws

56 Validation Validation: “Did I design or build the Right System?”Validation shows that the Design when used according to the Operations Concept meets the Requirements and the Customers Goals and Objectives and can be produced within the Cost, Schedule and Risk constraintsValidation Methods: Analysis, Predictions, Trade Studies, TestThe requirements flow is also validated to show that “Parent” requirements have valid “Child” requirements and that “Orphan” requirements are not driving the system design or implementation.Initial Validation during Phase A and B is critical to proceeding into Phase C where detail design occursOtherwise the detail design proceeds on the “Wrong” systemValidation also occurs in parallel with verification where End to End Tests, Mission Simulations show that the “Right System” has been built

57 Summary Systems Engineering addresses the total program lifecycleLargely a communications activityConsistent Requirements, Design, and Operations ConceptTime Phased “Crawl Before You Walk, Walk Before You Run”No Cookbooks or Magic RecipesMultilayered Review, Inspection and Test ProcessIt is the Project Team, the People, that makes projects successfulSystems Engineering Techniques Balance Performance, Cost, and Schedule

59 Homework AssignmentIn a brief paragraph describe a system of your choosingIn another paragraph describe its operation (operations concept)Draw a high-level product breakdown structure (PBS) for that system