1. ISA 201 Lesson 6 Systems & Software Engineering - Review of Fundamentals -
Lesson Point of Contact:
Name: John Rice
Phone:
Slide 1
As an ISA 201 student, this review of fundamentals for systems and software engineering will benefit you in understanding the related terms and processes. For starters, commonalities and overlap exist between systems and software engineering in determining user needs, baselining requirements, breaking those requirements into design details and products, then testing and deploying the products. The specifics of these processes will be described in this mini-lesson.

2. Systems Engineering Terms
Definition of a system.
The systems engineer’s role.
Boundaries between systems.
Considerations regarding a system’s environment.
Slide 2
A system is commonly defined to be a collection of hardware, software, people, facilities, and procedures organized to accomplish some common objectives.
“In the simplest terms, a system is a collection of interconnected components that work together to fulfill a common objective.”
Systems Engineers (SEs) play an important role in designing and managing complex systems. Specifically:
SEs are concerned with the whole system and take a top-down, interdisciplinary approach to design and management.
SEs are problem definers, not just problem solvers.
SEs are involved with a system throughout its lifecycle.
The system boundary is often arbitrarily drawn depending upon the particular system of interest.
The boundary is “the line forming a closed circle around selected variables, where there is less interchange across the line of the circle than within the line of the circle.”
The boundary we define will be based in part on what problem we are attempting to solve.
No guidelines exist for sizing/scoping systems.
Environment is that which is external to the system, or not comprised of the system itself.
Environment contains that which is outside the system’s control and also impacts system performance.
Systems & SW Engineering

3. DoD Systems Engineering Process
Slide 3
The SE Vee is essentially decomposition (design) and realization (build and test). Verification and validation link each side of the Vee as requirements are determined to be “built right” and “the right thing built”, resp. In addition, the technical management processes are a means of controlling the technical processes of the Vee. Maintaining databases for requirements, configurations, risks, data, et.al. is key to effective technical management. Automated tools are available for these activities.
Systems & SW Engineering

4. Technical Processes Slide 4
Stakeholder Requirements Definitions
Involves the translation of requirements from relevant stakeholders into a set of top-level technical requirements. The process helps ensure each individual stakeholder’s requirements, expectations and perceived constraints are understood from the acquisition perspective.
Requirements Analysis
Involves the decomposition of top-level requirements captured by the Stakeholder Requirements Definition process into a clear, achievable, verifiable and complete set of system requirements.
Architecture Design
Involves two primary efforts; design and realization. Outputs included the detailed design down to the lowest system elements in the system architecture, and the fabrication/production procedures.
Implementation
Involves two primary efforts; detailed design and realization. Outputs included the detailed design down to the lowest system elements in the system architecture, and the fabrication/production procedures.
Integration
Incorporates the lower level system elements into a higher level system element in the physical architecture.
Verification
Provides evidence that the system or system element performs its intended functions and meets all performance requirements listed in the system performance specification and functional and allocated baselines. Verification answers the question, “Did you build the system correctly?”
Validation
Provides objective evidence that the capability provided by the system complies with stakeholder performance requirements, achieving its use in its intended operational environment. Validation answers the question, “Is it the right solution to the problem?”
Transition
Moves any system element to the next level in the physical architecture. For the end-item system, it is the process to install and field the system to the user in the operational environment.
Slide 4
Technical processes are essentially decomposition (design) and realization (build and test). This is typically represented as the SE Vee. DoD includes the Transition step as opposed to academic/industry models which typically stop with the Validation phase. Transition is the transfer of the system to the next lifecycle phase, to the testing community, to fielded units, etc.
Systems & SW Engineering

5. Technical Management Technical Planning Requirements Management
Ensures that the SE processes are applied properly throughout a system’s life cycle, includes defining the scope of the technical effort required to develop, field, and sustain the system, as well as providing critical quantitative inputs to program planning and life-cycle cost estimates.
Requirements Management
Ensures bi-directional traceability from the high-level requirements down to the system elements through the lowest level of the design (top down); and from any derived lower-level requirement up to the applicable source from which it originates (bottom-up).
Configuration Management
Establishes and maintains the consistency of a system’s functional, performance, and physical attributes with its requirements, design, and operational documentation throughout the system’s life cycle.
Interface Management
Ensure interface definition and compliance among the system elements, as well as with other systems. Documents all internal and external interface requirements and requirements changes in accordance with the program’s Configuration Management Plan.
Technical Data Management
Identifies, acquires, manages, maintains, and ensures access to the technical data and computer software required to manage and support a system throughout the acquisition life cycle.
Decision Analysis
Transforms a broadly stated decision opportunity into a traceable, defendable, and actionable plan. Employ procedures, methods, and tools, such as trade studies, for identifying, representing, and formally assessing the important aspects of alternative decisions to select an optimum decision.
Technical Assessment
Compares achieved results with defined criteria to provide a fact-based understanding of the current level of product knowledge, technical maturity, program status, and technical risk. Includes methods such as technical reviews and use of technical performance measures (TPMs).
Risk Management
Involves the mitigation of program uncertainties that are critical to achieving cost, schedule, and performance goals at every stage of the life cycle. Encompasses identification, analysis, mitigation planning, mitigation plan implementation, and tracking of program risks.
Slide 5
Technical management processes are a means of controlling the technical processes of the Vee. Maintaining databases for requirements, configurations, risks, data, et.al. is key to effective technical management. Automated tools are available for these activities.
A key distinction is data mgmt vs. config mgmt. The former is mgmt of technical data, computer software documentation, financial information, management information any other information required by a contract to be delivered to the Government. The latter is mgmt of version baselines to include software, specifications, drawings.
Systems & SW Engineering

6. Software Development Process
Slide 6
IEEE/EIA 12207, Software Life Cycle Processes, describes the U.S. implementation of the ISO standard on software processes. This standard describes the development of software specifications as one aspect of the software development process. The process described in IEEE/EIA for allocating requirements in a top-down fashion and documenting the requirements at all levels parallels the systems engineering process. The standard requires first that system-level requirements be allocated to software items (or configuration items) and that the software requirements then be documented in terms of functionality, performance, and interfaces, and that qualification requirements be specified. Software item requirements must be traceable to system level, and be consistent and verifiable.
IEEE/EIA 12207, Software Life Cycle Processes
Systems Engineering

7. Functional to Physical Matrix
Slide 7
This matrix is an example of relating a simple physical architecture to the functional architecture. During design synthesis, re-evaluation of the functional analysis may be caused by the discovery of design issues that require re-examination of the initial decomposition, performance allocation, or even the higher-level requirements. These issues might include identification of a promising physical solution or open-system opportunities that have different functional characteristics than those foreseen by the initial functional architecture requirements.
Systems & SW Engineering

8. Work Breakdown Structure
Slide 8
At the system level, top-level aggregate system requirements and performance goals are established.
Generally, the Govt program management office is responsible for the top 3 level. They take the prime product elements to the third level. Mil-STD 881C provides guidance for WBS development. The contractor is responsible for further decomposition.
Level One—Overall System
Level 1 is the entire defense materiel item; for example, an electronic system. An "electronic system“ might be a command and control system, a radar system, a communications system, an information system, a sensor system, a navigation or guidance system, or an electronic warfare system. Level 1 is usually directly identified as a program or a sub-element of a program.
Level Two—Major Element (Segment)
Level 2 elements are the major elements of the defense materiel item; for example, a fire control system or an automatic flight control system. These prime mission products include all hardware and software elements (if they reside on specific equipment), aggregations of system level services (like system test and evaluation, or systems engineering and program management), and data.
Level Three—Subordinate Components (Prime Items)
Level 3 elements are elements subordinate to level 2 major elements. For example, a radar data processor, a signal processor, an antenna, a type of service (like development test and evaluation, contractor technical support, or training services), or a type of data (like technical publications) would be typical level 3 elements for an electronic system. Lower levels follow the same process.
Systems & SW Engineering
EMW – JUL 2013

9. Defense Acquisition Guidebook Chapter 4: Systems Engineering
Slide 9
We have covered commonalities and overlap between systems and software engineering in determining user needs, baselining requirements, breaking those requirements into design details and products, then testing and deploying the products.
For further information on this topic, the Defense Acquisition Guidebook is a valuable resource. Chapters 4 and 7 describe Systems Engineering and Acquiring Information Technology, respectively. It is available at DAU’s website,
Systems & SW Engineering