Module

3 will cover enabling systems engineering technical processes.

The objec<ve of this module is to introduce and review the set of enabling systems engineering processes, where the rst set of processes are the technical processes. Think of these as part of the toolkit to allow the implementa<on of systems engineering principles.

These are the technical processes (as opposed to management and support processes) that we perform as systems engineering on a project. These are the processes and models shown in our Systems Engineering V model, as well as in NASAs Systems Engineering Engine, (both from previous modules), and in other SE standards, such as Mil Standard 499. In this module, we will step through these one at a <me.

First lets examine the rst process within the context of requirements development: the synthesis of stakeholder expecta<ons.

Requirements development is predicated on the assump<on that we have the correct mission objec<ve, market opportunity and/or need dened. As we go through each step of the roadmap and the system engineering thought process becomes clearer, you may nd that an original need statement does not adequately express the need. As a result, systems engineering teams quite oUen modify/iterate/ change a prospec<ve projects need statement several <mes as new informa<on from the customer is understood this is a normal part of the process!

Well discuss stakeholders in greater detail in the next module, and then well make the dis<nc<on between ac<ve and passive stakeholders. Basically, a stakeholder can be a person, organiza<on, en<ty or other system that can will either aect or be aected by the solu<on to the need/mission. For now, this stakeholder deni<on is all we need to con<nue our focus on the enabling Technical Processes.

It can indeed be very challenging to develop a complete and accurate set of Stakeholder Expecta<ons. Some<mes the stakeholders/customers cant clearly ar<culate their own needs and constraints. OUen, they have a mental image of what they want the system to accomplish, but theres diculty in geang that same image into the mind of the system developer. History is replete with examples where the developer delivered a system that didnt meet the customers need or intent. For instance, the Denver Interna<onal Airports original, highly-automated baggage- handling system was a costly embarrassment. It proved incapable of safely and reliably delivering baggage from an airplane to the luggage carousel.

We put how well in quotes because this phrase encompasses aspects of performance, quality, aesthe<cs, cost, and schedule. The capabili<es will evolve into our func<onal requirements, and the characteris<cs will evolve into our non- func<onal requirements.

 Note the way were depic<ng the process. The inputs (leU) are the problem/ opportunity/mission/need, obvious stakeholders, customers, users. Any constraints due to the legacy environment are also input. In the ac<vi<es (center), we must rst dene the complete problem, and ul<mately the complete solu<on. What is the context for solu<on, and what denes an acceptable solu<on? Controls (top) is where constraints, scope of the solu<on and any policies aec<ng the solu<on space come in. Enablers will be resources, <me, money, processes. Our output will be a complete problem deni<on, a complete understanding of the stakeholders and their rela<onship/use of the solu<on, and an agreement as to when the solu<on is done. This is the same construct as in an IDEF0 view in a func<onal architecture, with the physical architecture represented via the Enablers at the bojom. This will help you get into the mindset to understand func<ons. In this module, well use this construct for all the major enabling processes.

Now lets look at technical requirements synthesis, as part of requirements development.

10

This chart provides several deni<ons of technical requirements, as considered in texts, standards, and via the CMMI (Capability Maturity Model Integra<on from the SEI SoUware Engineering Ins<tute at Carnegie Mellon hjp://www.sei.cmu.edu/ cmmi/ )

11

Technical requirements are a precise statement of what, how well, and under what condi<ons something must be done. The technical requirements are derived from stakeholder expecta<ons, and are a func<on of the concept of opera<ons, the preferred technical concepts and business models. As noted previously capabili<es are translated into func<onal requirements, and characteris<cs, including constraints, get translated into non-func<onal requirements. I am saying that this is almost true, since the transla<on of capabili<es into func<onal requirements is not completely separate from performance (that are dened in non-func<onal requirements). But this slide conveys the concept of two kinds of requirements

12

So what is the role of the systems engineer in synthesizing the requirements? It is cri<cal that systems engineers close the seman<c gap for synthesizing and formalizing requirements. They must represent stakeholder expecta<ons, ul<mately performing this role within the development team. At the beginning of this process, however, they are in ask and listen only mode. In solici<ng the stakeholders view, they must also ensure that all stakeholders ac<vely par<cipate. At the conceptual level, the SEs are the system integrator. How will all the parts work together? A major role is to develop complete and consistent requirements that ideally all stakeholders buy into. The systems engineer also challenges requirements and their specicity (or lack) when appropriate.

13

Note the subtle but fundamental dierences between this slide and slide #11. The ac<vi<es shown here rely on having successfully performed the Stakeholder expecta<ons synthesis. These ac<vi<es take us to the next level, in which we select a general design concept and then translate and codify the stakeholder expecta<ons into a set of system requirements that the design engineers can use to design the elements of the system, with good condence that the nal product will meet the Stakeholder expecta<ons.

14

Next we will look at logical, that is func<onal analysis and decomposi<on.

15

16

17

 So briey, what is a func<onal architecture? The IDEF0 Diagram shown in the bojom of the slide is an example of a rst-level func<onal decomposi<on for a small rocket motor, such as might be used for aatude-control on a spacecraU. It is used here merely to give you a sense of how such diagrams look. If you can read this diagram, note that N2H4 is Hydrazine. In this example of a monopropellant rocket motor, the liquid hydrazine is stored in a tank. When the command is given to open the throjle, the liquid is metered to the thrust chamber (delivered in the correct amount to give the desired thrust level). In the thrust chamber, the hydrazine is owed over a metallic catalyst material, which causes the hydrazine to heat up and become hydrazine steam, which is expelled through the rockets nozzle, providing the thrust. A major advantage of this type of motor is its simplicity and reliability, combined with good thrust performance.

18

19

 What is the Design Solu<on Deni<on? It is the process where we develop alterna<ve physical implementa<ons that address the requirements and func<onal architecture, including the context (such as process and people) outside the system, interfaces, traceability. The emphasis here is on interoperability between components and subsystems. The output of this step in the process is the Physical Architecture.

20

What is a physical architecture? Briey, it provides the system resources or components to perform its func<ons. Press pause to read this slide on your own.

21

22

Here we see here how the systems overall func<on maps to the physical system. The system is built from components, and those system sub func<ons map to the individual components. In a well-done architecture, this mapping is clear, which helps ensure we dont omit any func<onality desired by the stakeholders. The term Allocated to is importantit is the terminology used in SYS 650, System Architecture and Design. And its the term used in the CORE architec<ng soUware package used in that class.

23

 Now we overlay the Requirements onto the Func<onal and Physical representa<ons of our system. In a well-done architecture, every func<on traces back to a requirement--or mul<ple requirements. (And very requirement traces forward to one or more func<ons.). This gure also shows succinctly how we can trace the requirements ul<mately to the components. I.e., every component is there for a reason (requirement). Some<mes we say that the traceability is up and down the architecture. Note also the CORE terminology Basis of and Allocated to. These terms are used in SYS 650, System Architecture and Design.

24

 The process of developing the func<onal and physical architectures happens at all levels of the system designthe overall system, the subsystems, and the components. The process is itera&ve within each level. I.e. at any one level, such as the subsystem level, we itera<vely develop requirements, which are used to generate the subsystem func<onal architecture, which feeds into the subsystem physical architecturewith each of these steps feeding back into the others, un<l were sa<sed. The process is also recursive between levels. That is, as we architect at the subsystem level, we learn things that feed back into the system level architecture, resul<ng in changes there, and perhaps new itera<ons there.

25

This slide shows a physical block diagram of a cars drive system. Its one way of conveying the physical layout of the system, showing func<onal elements that have been translated into physical elements, and the ow of inputs and outputs between them. Think of the func<ons that each of these physical blocks represents. Car enthusiasts will recognize the Ferrari Testarossa.

26

27

Briey, implementa<on performs the detailed design, and/or the construc<on/ procurement of the lowest level elements in the physical system hierarchy. The implementa<on prepares the these components, COTS or subsystems for integra<on, verica<on, and valida<on the next steps.

28

29

 Integra<on is the process of incorpora<ng the lower level system elements of the physical architecture into higher level systems physical elements. Integra<on also prepares for the nal incorpora<on of the system into its opera<onal environment. Systems Integra<on is the subject of another follow-on course SYS605. Integra<on strategy and planning begins up front once the ini<al concept is known. This integra<on strategy can impose constraints on the design, and would also be considera<ons included in the system requirements and architecture. Shown here undergoing integra<on is a Virginia-Class submarine, the newest class of American nuclear-powered ajack submarines. All of the subassemblies required are integrated into the USS Virginia. They are built by General Dynamics Electric Boat, and as of April 2012, nine submarines of this class have been delivered. According to Navy.mil: All Virginia-class submarines currently under construc<on are scheduled to deliver earlier than their original contract delivery dates.

30

31

Verica<on generates evidence of compliance with build to specica<ons. At its comple<on, there are ar<facts that document that the system was built according to the requirements, or in other words: Did you build the system right?

32

33

Valida<on is all about examining the system in its opera<onal environment, and ensuring that the Right System was built per the customer. Again integra<on, verica<on and now valida<on are all started in the upfront systems engineering framework to reduce risk and ensure that there are no surprises with the stakeholders upon deployment. So valida<on really begins with stakeholder expecta<ons.

34

 In this example of the valida<on process, the Navy, a key stakeholder, created a special unit (the Pre-Commissioning Unit Mississippi SSN782) to work on the valida<on team of the USS Mississippi, a Virginia-class submarine. The USS Mississippis sea trials validated her performance and suitability for her design missions. (The missions are: an<-submarine; an<-surface ship; strike; special opera<on forces; intelligence, surveillance, and reconnaissance; irregular warfare; and mine warfare.) The following are excerpts from an ar<cle on Navy.mil, <tled Future USS Mississippi Successfully Passes Sea Trials, On Track for Summer Commissioning. (Posted April 18, 2012) Alpha sea trials included diving to test depth, conduc<ng an emergency surfacing, and tes<ng the submarine's propulsion plant and were designed to evaluate the ship's seaworthiness and opera<onal performance. Bravo trials consisted of tes<ng Virginia's acous<c performance and combat systems. The ninth ship of the Virginia-class, Mississippi is on track to deliver up to one year early of its contract delivery date.

35

36

 The nal step in our technical process, is the transi<on. Here the transi<on process installs a veried system into the opera<onal environment, along with relevant enabling systems, e.g. operator training systems. Transi<on can include: congura<on management, relevant support documenta<on, elements required for support and logis<cs opera<ons, and may also involve a series of technical reviews or peer reviews.

37

Here is the outline of the Systems Engineering process. The arrows depict movement from one major set of ac<vi<es/processes to the next. We begin with mission/ stakeholder focus (#1) to the Concept of Opera<ons and Opera<onal Architecture focus (#2), to the Technical System Requirements, Constraints and Assump<ons focus (#3) to the System Architecture, Func<onal and Physical Par<<oning (#4) and then iterate, as necessary back through these. The bullets outside the boxes are key ar<facts generated and input to the next box.

38

This slide illustrates the feedback between the parts of the Systems Engineering process. Specically, the blue arrows, and bulleted items show the feedback loop and key ar<facts that can aect change/itera<on in the earlier processes. In this way, the ar<facts and system are iterated to improvement.

39

Technical processes must con<nue to enable development from the ini<al stakeholder requirements and concept genera<on through transi<on and disposal. Look for ways to iterate technical ac<vi<es and involve the stakeholders in the decision making and review processes. Collect the necessary evidence throughout the ac<vi<es to ensure good feedback and status determina<on. Systems engineering is rarely a once through process, and should be a suppor<ng discipline throughout the lifecycle.

40

This slide shows a detailed roadmap of the technical processes that we will follow for this class. We will be following the arrows, ending with the func<onal/physical views of a prospec<ve system. The follow on SYS650 Systems Architecture course will pick up with the func<onal architecture and go into more detail on the func<onal and physical views of the system. We will be coming back to this slide throughout the course.

41