Conceptual Design and Requirements Development

Question 1

Stakeholders

Answer 1

Definition: Stakeholders are individuals or groups who have an interest in, or are affected by, the project or product’s outcome. They include anyone with a direct or indirect influence over the product’s development, usage, funding, or regulatory compliance.

Examples: This category encompasses customers, project sponsors, engineers, regulatory bodies, investors, senior management, suppliers, and even community members. Essentially, anyone impacted by the project’s success or failure.

Role: Stakeholders influence project goals, funding, resources, timelines, and compliance requirements. They may have competing interests, making it important for project teams to balance these interests through effective communication and negotiation.

Focus: Stakeholders are concerned with the project’s overall success, risk management, adherence to policies, and long-term implications.

Question 2

“Needs Analysis”

Answer 2

• First step in the design process
• Involves getting an inventory of the Operational Deficiencies, Customer Perspectives, and Technological Opportunities

Answering Three Big Questions:
1) “What problem are we solving?” (via Operational Deficiencies)
2) “What could we use to solve it?” (via Technological Opportunities)
3) “What does an acceptable solution actually look like?” (via customer perspectives)

Question 3

“Concept Development”

Answer 3

Second Step in the Design Process

Refers to the identification of the requirements, mission phases (ConOps, Operational Scenareos) and high-level behaviors (use cases, state machines) needed to actually solve the problem

This comes after the “Needs Analysis”, but before the Preliminary Design

Question 4

Importance of “Precedence” during Mission and Concept Definition

Answer 4

When looking at what technologies you can leverage for your solution, you need to keep in mind that any technology you develop is going to be a PRECEDENTED system… means it needs to be built up for existing/proven technological solutions

*This is particularly important when examining the question “What could we use to solve it?” via Technological Opportunities

Question 5

Customers

Answer 5

Scope: All customers are stakeholders, but not all stakeholders are customers. Stakeholders include a wider range of individuals or groups, while customers are specifically the users or buyers.

Interests: Customers prioritize usability, value, and satisfaction, while stakeholders may focus on broader aspects like financial performance, regulatory compliance, project sustainability, and risk.

Decision-making Influence: Customers influence requirements directly related to product functionality, whereas stakeholders may shape the project direction, resources, and timing to align with organizational or regulatory goals.

Question 6

Stakeholder v. Customers

Answer 6

Definition: Stakeholders are individuals or groups who have an interest in, or are affected by, the project or product’s outcome. They include anyone with a direct or indirect influence over the product’s development, usage, funding, or regulatory compliance.

Examples: This category encompasses customers, project sponsors, engineers, regulatory bodies, investors, senior management, suppliers, and even community members. Essentially, anyone impacted by the project’s success or failure.

Role: Stakeholders influence project goals, funding, resources, timelines, and compliance requirements. They may have competing interests, making it important for project teams to balance these interests through effective communication and negotiation.

Focus: Stakeholders are concerned with the project’s overall success, risk management, adherence to policies, and long-term implications.

Question 7

Types of Customers

Answer 7

1) Sponsors
2) Active Stakeholders
3) Passive Stakeholders

Question 8

Technological Opportunity

Question 9

Operational Need

Question 10

Operational Deficiency

Question 11

Operational Need v. Operational Deficiency

Question 12

Active Stakeholders

Answer 12

Definition: Active stakeholders are customers directly involved in the project’s ongoing activities, decisions, and execution. They frequently engage with the project team and have an immediate influence on project outcomes.
- Emphasizing the fast that they are CUSTOMERS

Examples: This category includes project managers, engineers, product designers, quality assurance teams, regulatory bodies, and sometimes customers who are providing active feedback. Essentially, anyone who participates regularly in project meetings, decision-making, or development processes.

Role: Active stakeholders help define requirements, set priorities, make critical decisions, and directly impact the project’s direction. They are often involved in day-to-day activities and provide regular feedback and support.

Focus: Active stakeholders focus on achieving project goals and milestones, managing risks, ensuring the project stays on schedule and within budget, and addressing issues as they arise.

Question 13

Passive Stakeholders

Answer 13

Definition: Passive stakeholders are customers who are affected by the project or have a vested interest in its outcome but are not actively involved in its day-to-day processes. Their influence is indirect, and they may only interact with the project team at key points or through feedback channels.
- Emphasizing the fast that they are CUSTOMERS

Examples: This group includes end-users (if not directly involved in development), external investors, community members, and some regulatory or compliance entities that review the project’s output rather than its process. They may also include departments that will handle the product post-launch, such as marketing or customer support.

Role: Passive stakeholders provide feedback on the project outcomes or support activities once the product is released. They may set high-level goals or offer retrospective insights but don’t influence the daily activities.

Focus: Passive stakeholders are generally interested in the final product’s performance, compliance with regulations, alignment with strategic goals, and long-term sustainability.

Question 14

Active Stakeholders v. Passive Stakeholders

Answer 14

Level of Involvement: Active stakeholders are engaged in the project daily, while passive stakeholders interact only periodically or once the project has reached major milestones.

Influence on Project Direction: Active stakeholders can shape project decisions dynamically, while passive stakeholders influence the project’s broader goals and outcomes.

Feedback Timing: Active stakeholders provide ongoing feedback, whereas passive stakeholders often give input at specific stages or after project completion.

Question 15

End Users

Question 16

Problem Statement

Question 17

Requirements

Answer 17

Any condition, characteristic, or capability that must be achieved and is
essential to the end item’s ability to perform its mission in the environment in which it must
operate.

Stakeholders provide user requirements, captured in the Voice of the Customer and with
context provided by the Concept of Operations.
– Customers
– Users
– etc.

• Given the use cases and the constraints of physics, system modeling and analysis generates
  requirements for the system and for the respective system elements.
  – Component specifications such that the system will perform as required
• Interfaces to other systems or system components will generate interface requirements

Question 18

Types of Requirements

Answer 18

1) Customer Requirements
2) Functional Requirements
3) Non-functional Requirements
4) Performance Requirements
5) Derived Requirements
6) Stakeholder Requirements
7) Specification Requirements

Question 19

Customer Requirements

Answer 19

Customer requirements focus specifically on the needs and preferences of the end-user or the client who will directly use or benefit from the system. Customer requirements are a subset of stakeholder requirements and are often more specific to usability, accessibility, and direct functional utility

Extremely dynamic… you can expect these to evolve throughout the design lifecycle
- But you cannot rely on the customer to be forthcoming about these changes
- Need to be proactive about following up, maintaining your understanding of the requirements, and tracking these changes
- MBSE is a great way of tracking this

These are the basis for ‘system validation’
- That’s why it’s so important to maintain your list of customer requirements
- Both your team and design also needs to be extremely flexible so that you can adapt to changing requirements.

Validated through user acceptance testing (UAT) and usability assessments, focusing on customer satisfaction and feature functionality. Customer requirements are often tested in the final stages to confirm they meet user expectations​

Generally remain stable once defined but can change in response to feedback on usability, functionality, or performance. Since they directly affect user satisfaction, customer requirements often take priority in iterative design phases to optimize the user experience.

Usually detail specific features or performance criteria. For instance, a customer might require that a system have a specific response time or intuitive interface but may not specify underlying technical or regulatory needs.

Primarily address the features, functionality, and user-friendliness needed to satisfy end-users. They focus on how the system will perform tasks, solve problems, or fulfill needs directly for the customer, often emphasizing functional requirements over non-functional concerns

Derived primarily from the end-user or purchasing organization. These are gathered through direct interactions such as surveys, focus groups, user feedback, and market research to ensure alignment with customer expectations

Focus specifically on the needs, preferences, and expectations of the customer or end-user. These requirements often prioritize user experience, ease of use, and specific features that directly impact the user, offering a more narrow perspective centered around functionality and usability

Question 20

Functional Requirements

Answer 20

Define what functions
need to be performed to accomplish the objectives.
– Identified via functional analysis techniques such as
FFBDs or SysML Activity Modeling and system design

Typically reside in higher level (e.g.
system or system element)
requirements and are defined earlier
in the life cycle than performance or
non-functional requirements

Example: The Thrust Vector Controller (TVC) shall provide vehicle control about the pitch and yaw axes.
* This statement describes a high-level function that the TVC must perform. The technical team needs to transform this statement into a set of design-to functional and performance requirements

Question 21

Perspective Getting

Question 22

Nonfunctional Requirements

Answer 22

Specify physical constraints such as attributes and characteristics

Deal with operational conditions such as safety, system security, reliability, human system integration, environmental, etc.) and life cycle constraints such as maintenance & disposal.
– Identified via standards, guidelines, regulations, etc

Typically result from applicable
standards, guidelines, regulations,
etc.

Example: The TVC shall be serviceable by ground crew personal without requiring hazardous materials
precautions.

Question 23

Derived Requirements

Answer 23

Highly Design Dependent

[more]

Use Cases and Operational Scenarios provide an
operational capability based foundation for requirements derivation

Question 24

Stakeholder Requirements

Answer 24

Stakeholder requirements encompass the expectations and needs of ALL individuals or groups impacted by the system, including regulatory bodies, internal team members, and external users (whether they can be considered customers or not). These requirements capture a broader perspective, covering functional needs, environmental conditions, constraints, and performance expectations across the entire system lifecycle.

These encompass the needs and constraints of all parties affected by or involved in the system, including customers, regulatory agencies, investors, technical teams, and organizational leadership. They reflect a holistic view, balancing competing interests from a broad spectrum of stakeholders across the system’s entire lifecycle.

Gathered from multiple channels, including interviews with various departments, regulatory standards, industry best practices, and organizational goals. This includes contributions from groups that may not directly use the system but have an influence or stake in its operation and outcome.

Aim to ensure the system aligns with organizational objectives, legal compliance, operational constraints, and the needs of technical and support staff. Stakeholder requirements also cover non-functional aspects like reliability, maintainability, and regulatory adherence, which may not be of direct interest to customers but are vital for system longevity and performance.

Include both high-level and technical requirements. For example, a stakeholder requirement might stipulate that the system must operate under specific environmental conditions or integrate seamlessly with other systems, as specified by regulatory or internal guidelines.

Tend to evolve as new stakeholders are identified or as the project scope broadens, which can introduce additional constraints or requirements. They are managed continuously to balance diverse interests and evolving regulatory demands.

Verified through compliance testing, risk assessments, and systems validation to ensure all stakeholder needs are met. The system is validated as a whole against these requirements, including reliability and safety.

Question 25

Stakeholder Requirements v. Customer Requirements

Answer 25

While all customer requirements are stakeholder requirements, not all stakeholder requirements align strictly with customer desires—they may also consider factors critical to other parties, such as maintainability for the technical team or compliance for regulatory bodies.

The distinction helps systems engineers ensure that designs not only meet customer needs but also address the expectations and constraints set by the broader stakeholder ecosystem, balancing functional and non-functional requirements effectively to create a comprehensive solution​.

Question 26

Stakeholder Requirements v. Derived Requirements

Answer 26

Question 27

Kano Model

Answer 27

Question 28

Performance Requirements

Answer 28

Define how well the system needs to perform the functions.
– Identified by systems design, modeling and analysis
– Sound like TPMs/KPPs

Typically result from refinement of functional or higher level performance requirements

Question 29

Specification Requirement

Answer 29

Detailed, formalized statement describing a system or component’s specific attributes, performance criteria, and operational constraints needed to meet the stakeholder and customer needs. Specification requirements serve as a bridge between broad stakeholder needs and technical implementation, capturing the precise details necessary to ensure the system performs as intended in its environment

Question 30

Operational Requirements

Answer 30

A type of specification Requirement

Operational Requirements specify high-level requirements to achieve system mission
objectives and behavioral interactions

Question 31

Categories of Specification Requirements

Answer 31

1) Operational Requirements
2) Capability Requirements
3) Non-functional Requirements
4) Interface Requirements
5) Design and Constructions Constraint Requirements
6) Verification Requirements
7) Validation Requirements

Question 32

House of Quality

Answer 32

Question 33

Parts of a Requirement

Question 34

Key Performance Parameters (KPPs)

Answer 34

Extremely Solution Dependent: subset of the performance parameters representing the most critical capabilities and characteristics

Used to communicate to ENGINEERS how EFFECTIVE the system is (Characterize the System in the “voice of the engineer”)

Can be calculated or measured (the inputs in those equations are “Technical Performance Measures”, TPMs)

Question 35

Measures of Effectiveness (MOEs)

Answer 35

Top-Level measures of success that are closely related to the achievement of mission or objectives; they provide insight into the accomplishment of the mission needs independent of the system design

Used to communicate to CUSTOMERS how EFFECTIVE the system is (Characterize the System in the “voice of the customer”)

Can be calculated or measured (the inputs in those equations are “Measures of Performance”, MOPs)

Question 36

Measures of Performance (MOPs)

Answer 36

Measurable quantities that can be used to predict/calculate the value of MOEs (for the customers)

All MOPs are TPMs, but not all TPMs are MOPs

Question 37

Technical Performance Measures (TPMs)

Answer 37

• Refers to any USEFUL measurement that can be made during modeling/simulation/testing
• Sometimes just called “engineering data”

TPMs can be used to calculate EITHER:
1) Key Performance Parameters (KPPs)
2) Measures of Effectiveness (MOEs)

MOPs are a subset of TPMs

Question 38

Characteristics of Good TPMs

Answer 38

• Should be important and relevant
• Should be relatively easy to measure
• Performance should be expected to improve with time
• If the measure crosses its threshold, corrective action should be known
• The measured parameter should be controllable
• Management should be able to tradeoff cost, schedule and performance
• Should be documented
• Should be tailored for the project

Question 39

Technical Margins (Margins for TPMs)

Answer 39

Can be established based on three criteria:
1) Historical Data/Statistics
2) Modeling Simulation
3) Expert Opinion

Question 41

Voice of the Customer (VoC)

Answer 41

VoC represents the needs, preferences, expectations, and desires of the end-users or customers. It’s the qualitative and quantitative input gathered through interviews, surveys, focus groups, feedback, and observation to inform the design process. VoC helps in defining product features, usability, and overall customer satisfaction. Its goal is to ensure that the end product provides the value customers seek and addresses real-world needs effectively.

Examples of VoC inputs: Desired features, ease of use, safety, aesthetics, and specific use-case requirements.
Key role: Drives the requirements and specifications that directly impact user satisfaction and market success.

Question 42

Voice of the Engineer (VoE)

Answer 42

VoE embodies the technical insights, constraints, capabilities, and innovation potential of the engineering team. Engineers focus on the feasibility of implementing customer requirements within practical constraints like technology limitations, cost, manufacturability, and safety standards. VoE ensures that while customer needs are addressed, they are met within a technically viable and sustainable framework.

Examples of VoE inputs: System limitations, performance optimization, technical standards, reliability, and manufacturability.
Key role: Ensures the product is practical, functional, and compliant with technical and safety standards.

Question 43

“Voice of the Customer” v. “Voice of the Engineer”

Answer 43

VoC centers on customer needs and usability, while VoE focuses on technical feasibility and engineering constraints.
Successful projects balance both voices, translating customer needs into technically sound requirements that engineers can implement effectively.
Potential conflicts can arise when customer desires exceed technical or budgetary limits, which necessitates negotiation and prioritization to create a viable, customer-satisfactory product.
Balancing VoC and VoE is key in systems engineering, ensuring a product that meets customer needs while staying feasible and reliable.

Question 44

Visually Tying Customer Requirements to KPPs

Answer 44

Done using a matrix

• Must be completed with the whole team so you get all viewpoints
• Start with the highest priority requirements
• Do not allow the matrix to become too big
• Two primary principles for evaluation:
  1) Does it make sense in principle
  2) Do we have evidence/observations to support that

Question 45

Operational Concept v. Concept of Operations v. ConOps

Answer 45

Concept of Operations is the ‘Organization Level’ definition of the system

Question 46

Operational Concept

Answer 46

Describes the system and its context with both text graphics, but IN THE USER’S TERMINOLOGY

Prepared to support the development of a new or modified/upgraded system. They may be prepared by the customer as part of the request for proposal.
- In this case, they are often called the concept of operations.
- Maintained throughout the product lifecycle

Captured in an “Operational Concept Document” (OCD)

Question 47

Concept of Operations

Answer 47

Describes how a system, product, or service is envisioned to be deployed, operated, and
maintained.
– Typically produced by the system developer, and so usually does not address system sustainment &
retirement/disposal.
– Produced in collaboration with users & stakeholders to provide a shared vision for the deployment,
operation, and maintenance of the system

Question 48

ConOps

Answer 48

Communicates to all stakeholders in the users language… the desired characteristics of a system to be developed.
- Provides a mechanism to trigger questions and raise issues regarding operator-related and use-related needs and associated design trades.

A ConOps should provide, in prose and graphics (unlike a specification), a narrative which describes how system is envisioned to fit and function within the operational environment.
* The language and forms of communication, such as graphics, functional flow diagrams, timelines, simulations, and operational mockups should be chosen predominantly to be those that the system users will understand

Question 49

Benefits of ConOps Development

Answer 49

Primary Benefit: Tells a story for the customer. Create a narrative that describes the system’s intended use.

• act as a catalyst to stimulate the development of
  complete, consistent, testable requirements and
  designs with emphasis upon those attributes that shape the user-related elements of the system;
  – provide guidance and clarification for the development of the subsequent system definition
  documentation (e.g., operational
  system specifications and interface control drawings);
  – form the basis for long range operational planning activities (i.e., staffing, facilities, training, security,
  safety, and logistics);
  – describe the system behavior(s) that are needed (give best and worst case); and
  – reduce cost overrun and schedule slips by defining more accurately the system earlier in the
  development stage; and decrease the chances that stakeholder dissatisfaction will terminate the
  project

Question 50

Elements of ConOps

Answer 50

1) Whats: These are the known principal components or elements and top level capabilities
required of the system to perform the necessary functions. The components are described
from an operational point of view. Necessary mission phases or modes may also be described
here.
– The Whats also include descriptions of the external systems with which the system of interest
interfaces, and the external interfaces. Principal internal interfaces are also described.

2) Wheres: These are the environments, such as geographical and physical locations of
customer’s facilities and interfacing systems, within which the capabilities are required to be
performed and supported. A description of the nature of the interfaces with other systems,
organizations, and the environment is also needed.

3) Whens: These describe activities, tasks, flows, precedence, concurrencies, and other
time/sequence-related elements necessary to achieve the mission objectives in each of the
various mission modes and conditions. Whens may also include information as to system
development and operational availability dates, such as program milestones

4) Whos: These describe the interactions among the various human elements within the system
including their interfaces with people external to the system. The OCD and related scenarios
should also identify decision points to include the organizational entity with authority to make
those decisions. Other systems with which this system interoperates are also identified.

5) Whys: These provide the rationale behind any established partitioning of the mission tasks
between the system components and the operators, and the reasoning for specific sequences
of activities or tasks. For example, an important function of an OCD is to provide the rationale
behind the definition of the level of technical expertise required of the system operators. This
will provide a basis for the definition of a set of system requirements and designs with a
consistent level of complexity and sophistication.

6) Hows: These tie together the other elements (the what, where, when, who, and why) to
describe how the system is expected to be used, operated, maintained and, ultimately, retired
in the given environment, under all significant conditions. The emphasis should be on
concepts and should avoid any system design or implementation inferences

Question 51

Operational Scenarios

Answer 51

An Operational Scenario defines a sequence of events over a period of time representing
some generally complete system functions or transactions that, once initialized, tend to run to
some end.

Operational scenarios are the key to developing a successful Operations Concept Document

Describe the dynamic views of the system’s operation, primarily from the users’ points of view.
* Articulate how the system will operate through various modes and mode transitions, including its expected interactions with the external environment, outlining all important anticipated user, operator, tester, and maintainer interactions that provide the basis and framework for the system analysis and evaluation

Question 52

“Form”

Answer 52

Definition: Form refers to the physical appearance, shape, and aesthetic characteristics of a product or component. It includes dimensions, color, texture, and overall visual style.

Importance: Form is crucial for customer appeal, user experience, ergonomics, and brand identity. In some cases, form also impacts how components are assembled or fit together within a system.

Example: In consumer electronics, form includes the sleek, minimalistic appearance of smartphones, with specific color schemes and finishes to appeal to users.

Question 53

“Fit”

Answer 53

Definition: Fit pertains to how well a component or part aligns and interfaces with other parts in the assembly or system. It includes tolerances, alignment, and compatibility with other components.

Importance: Ensuring the correct fit prevents misalignment, wear, and failure in mechanical systems and promotes ease of assembly. Fit is also essential for achieving structural integrity and optimal performance in complex systems.

Example: In automotive manufacturing, ensuring that each part precisely fits within the chassis or engine block is essential to prevent issues like vibrations, misalignment, or assembly difficulties.

Question 54

“Function”

Answer 54

Definition: Function is the specific purpose, capability, or role of a component or system. It describes what the product is designed to do and how it operates to fulfill its intended use.

Importance: Function is the core reason for a product’s existence and directly impacts its performance, reliability, and utility. Design changes to form or fit should never compromise function.

Example: In a power drill, function includes the ability to rotate a drill bit at varying speeds and torque levels to drill into different materials effectively.

Question 55

Four factors that determine Form, Fit, and Function

Answer 55

– Stakeholders
– Mission applications
– Performance based objectives
– Operating environmen

Question 56

Use Cases

Answer 56

Describes the desired services & capabilities of a system from the perspective of the users (actors) who participate in or invoke a system behavior.

*Use Cases provide a good starting point for operations analysis. They feed the ConOps
through support of Operations Scenario development and identification of System Modes

• Created early in system life cycle
  – Used during development phase for concept of operations (ConOps)
  – Useful view for stakeholders to see mission objectives

A Use Case is a service or behavior the system will perform for an external actor or external system
– The name is always a verb phrase.
– The perspective of the use case is that of the Actors (i.e., users or stakeholders), not the designers
* Services the system must provide, missions the system must be able to accomplish, or capabilities of the system
– not how the system will provide the services, accomplish the mission, or meet the capabilities
– Use cases are invoked by actors
* Primary Actor invokes the use case
– Each use case should accomplish this actor’s need
– The system should respond in a manner that protects all stakeholders’ interests
* Secondary Actors participate in use case
– Primary actors may also be secondary actors
–
Not all behaviors of system are use cases – only system services &/or capabilities invoked or
participated in by external actors
* Identify Use Cases by finishing the statement, “I need to…”

*The Use Case can provide much of the information needed for the scenarios to be
developed for the ConOps

Question 57

Actor

Answer 57

An actor in a use case may be a human, an organization, or any external system that interacts directly with the system or indirectly through other actors.

Refers to ‘primary stakeholders’ (people, organizations, and even policies)

Two types of actors:
1) Primary Actors
2) Secondary Actors
*These are overlapping sets: Primary actors can also be secondary actors

Question 58

Form v. Fit v. Function

Answer 58

Comparison
- Form is primarily concerned with aesthetics and physical dimensions.
- Fit focuses on compatibility and alignment with other components.
- Function addresses the practical utility and performance of the component or system.

Relationship and Trade-offs
Design decisions often involve trade-offs between form, fit, and function. For example:
- In some cases, form may be modified to accommodate better fit and function without compromising product appeal.
- In safety-critical systems, function and fit are prioritized over form to ensure reliability and performance.

Question 59

Primary Actor

Answer 59

Actors that invokes the use case
– Each use case should accomplish this actor’s need
– The system should respond in a manner that protects all stakeholders’ interests

Question 60

Secondary Actor

Answer 60

Secondary Actors participate in use case
– Primary actors may also be secondary actors

Question 61

Use Case Specification

Answer 61

A use case should contain a story in textual form called a use case specification. The use case
specification should be developed in concert with the stakeholder(s)/end user(s).
* A use case specification should include:
– Use case name – a verb phrase
– Scope – the entity that provides the use case service
– Actor(s) – the actor(s) who is/are responsible for invoking &/or are involved in the service
– Stakeholder(s) – entity with vested interest in the system services/capabilities
– Pre-conditions – what must be true for this use case to begin
– Post-conditions – what must be true at the conclusion of the use case
– Trigger – what initiates the use case
– Main Success Scenario – sometimes called “the happy path”
* The nominal case.
– Extensions – alternate steps that deviate from the happy path
– Related information – anything else needed for information

Question 62

Operational Philosophy

Answer 62

An operational philosophy outlines the fundamental principles, strategies, and high-level objectives that guide how a system will operate and be used throughout its lifecycle. This philosophy provides a cohesive vision that aligns system capabilities with the intended mission, user requirements, and organizational goals. It acts as a blueprint, ensuring that every subsystem, component, and operational process aligns with a clear, overarching purpose

[confirm?]

Question 63

System Constraints and Limitations

Answer 63

System Constraints and Limitations refer to the specific boundaries, restrictions, and trade-offs that define what a system can and cannot do within its operating environment and objectives. These constraints shape the design, capabilities, performance, and scope of a system, influencing how effectively it can achieve its intended purpose

Question 64

Operational Scenarios v. Use Cases

Answer 64

Overall, operational scenarios support high-level strategic planning by exploring system behaviors in real-world contexts, while use cases break down those interactions into functional requirements that guide design specifications and development efforts for individual system functions.

Question 65

Use Case Diagrams

Question 66

Extends Relationship in Use Case Diagrams

Question 67

Key Aspects of an Operational Philosophy

Answer 67

1) Purpose and Mission: Defines the main objective or mission of the system and how it serves end-users or stakeholders. This includes considerations for system performance, reliability, and efficiency in achieving its goals.

2) Operational Environment: Outlines the context in which the system will operate, including external conditions (such as physical environments, user expertise levels, and support infrastructure). This helps ensure that design choices support intended use cases and real-world operating conditions.

3) User Interaction: Specifies how users will interact with the system, including ease of use, training requirements, and anticipated user expertise. It guides human factors considerations like accessibility, ergonomics, and intuitive operation.

4) Reliability and Safety: Establishes standards for safety, reliability, and resilience, especially for mission-critical or safety-critical systems. It includes policies for system redundancy, fault tolerance, and failure management.

5) Maintainability and Support: Describes expectations for system maintenance, support, and upgrades, including how frequently the system should be serviced, expected lifespan, and adaptability to future needs.

6) Resource Utilization: Defines efficiency targets, such as energy consumption, resource allocation, and operational costs. It ensures that the system is designed to operate within acceptable resource constraints.

7) Adaptability and Scalability: Plans for how the system can evolve over time, scaling to meet increasing demands or adapting to new technologies. This promotes longevity and relevance in a changing operational environment.

Question 68

Relationship between use cases and system modes

Answer 68

The «extend» relationship is used to indicate use cases that could be included in a higher-level use case, but only when the system is in a particular mode

Each extend relationship indicates at least one transition between two states

Question 69

Use Case Pitafalls

Answer 69

It’s easy to make use cases too broad.
– Too many decision points in the use case
– Too many happy paths

More than one ‘happy path’
– May contain multiple scenarios but only one is success
– Additional scenarios represent exceptions or errors

Use case at too high a level
– A use case that is associated with all actors may be at too high a level
– One remedy may be to refine the use case with include, extend, &/or specialize relationships and then associate the actors to the more particular use cases as appropriate

• Actor at too high a level
  – An actor associated with all use cases
  – One remedy may be to re-define the single actor into multiple actors and then associate with the
  appropriate use case(s)
• Repeated actors
  – Multiple actors all having the same use case associations
  – Verify that all actors are indeed representing distinct stakeholder roles; if not, duplicate actors should be removed from the diagram

Something missing
– Use cases having no actor associations and vice versa
– Causes include:
* Use case or actor not needed
* Actor or use case missing
* Missing association between a use case & an actor
* Missing relationship between use cases
– Remedy can be straightforward depending on the caus

Question 70

Key components of System Constraints and Limitations

Answer 70

1) Technical Constraints
These involve hardware and software limitations, such as processing power, memory, bandwidth, and compatibility with other systems. Technical constraints also include performance-related factors like maximum speed, load capacity, and real-time processing capabilities. Technical constraints must be managed to ensure the system operates reliably within feasible bounds​
JACOW

2) Environmental Constraints
Environmental limitations consider the conditions in which the system must operate, such as temperature, humidity, altitude, radiation, and exposure to physical elements. Systems designed for extreme environments (e.g., aerospace or underwater) often require special materials and protections that add complexity and cost​
AR5IV

3) Operational Constraints
These constraints address how the system is intended to function within its lifecycle, including maintenance schedules, reliability requirements, and usability standards. Operational constraints are often shaped by end-user capabilities and available resources for system upkeep.

4) Regulatory and Compliance Constraints
Many systems must adhere to standards and regulations imposed by governmental or industry bodies. These include safety, security, privacy, and environmental standards that influence system design, data handling, and operational processes​
JACOW

5) Resource and Budget Constraints
Every system is limited by resources like time, budget, manpower, and materials. Financial constraints affect everything from the quality of materials used to the scope of features and durability, shaping the overall feasibility and longevity of the system.

6) Design and Scope Limitations
These involve the predetermined goals, objectives, and functional requirements that define the system’s purpose and boundaries. Scope limitations help prevent scope creep by setting a clear boundary for what the system is and is not expected to achieve.

Question 71

Mode of Operation

Answer 71

An abstract label applied to a User selectable option that enables a set
of Use Case – based capabilities to be employed in conjunction with Enterprise processes and
procedures to Monitor, Command, & Control (MC2) an Enterprise or Engineered system,
product, or service to achieve a specific mission outcome, objectives, and levels of
performance

Question 72

State

Answer 72

A significant condition in the life of a “block”
– Example: Light – ON or OFF

An observable and measurable physical attribute used to characterize the current
configuration, status, or performance-based
condition of a System or Entity. Based on
principals of physics, states represent conditions that are observable, measurable, and verifiable

Question 73

Block

Answer 73

Abstraction of an element internal (or external) to the SOI that supports the mission

Any “thing” that supports the system can be represented with a block

If the block has many states/modes, then it can be represented using a State Machine Diagram (and/or a Use Case diagram if those states/modes affect user-level functionality)
- not all blocks have multiple states

Question 74

States v. Modes

Answer 74

Modes and States serve as an analytical decision aid framework for conceptualizing how a
User (operator, maintainer, trainer, etc.) can monitor, command, and control a system,
product, or service during operations

*Modes contain states

*Modes also contain multiple use cases

Question 75

Mission Phases

Answer 75

Phases broadly relate the operational uses of the system or subsystem and should typically
relate to the system in the context of user developed operational scenarios.

Phases relate to user defined operational levels for systems or subsystems. Modes relate to
functional and performance requirements such as ‘the landing gear shall have an engaged
mode’ and ‘the landing gear shall have a cruising mode’. States relate to the actual
implementation of the design

Mission life cycle phases of operation are characterized by performance-based outcomes and objectives. (Can be refined into lower-level outcomes/objectives)

*Phases CONTAIN modes

Question 76

Mission Phases v. Design Phases v. Product Lifecycle Phases

Answer 76

Each one has a different focus.

1) Mission Phases: Focus on performance-based outcomes/objectives. Closely related to the ConOps

2) Design Phases: Refers to the stage-gate model of design, where technical review are required before moving on to the next phase of the design/production

3) Product Lifecycle Phases: Broadest of all phase types. Focus on highest-level phases from conceptualization to retirement

Question 77

Mission Phases v. Modes v. Use Cases

Answer 77

Mission Phases contain Modes
Modes contain Use Cases

Question 78

Affinity Analysis

Answer 78

*sometimes used to abstract sets of Use Cases that share common objectives into higher-level system modes.

Question 79

State Machine

Answer 79

Significant part of the Operations Domain Solution

State Machines describe how a block transitions from one state to another
– Not all blocks have states: if a block always acts in the same manner, it has only one state; hence, definition of states is N/A
* e.g. consider the chassis as part of an automobile

*Often used to REFINE a use case diagram, specifically the refines relationship in Use Case Diagrams

Question 80

State Machine Diagram

Answer 80

Used to model how a block changes state
* Helps to define what happens when entering or exiting a state
* Graphical depiction of states, transitions, and event

Question 81

Trade Studies

Answer 81

Definition: Trade studies (also known as trade-off analyses) are systematic evaluations of multiple alternatives or design options to identify the best choice based on specified criteria and constraints. This process involves assessing each option’s advantages, disadvantages, risks, and performance relative to key attributes, such as cost, reliability, and feasibility.

Purpose: The primary purpose is to make informed decisions by comparing different designs, materials, technologies, or approaches to optimize overall system performance. Trade studies help prioritize factors based on stakeholder needs and project goals, enabling teams to justify decisions with clear, comparative data.

Example: In a CubeSat project, a trade study might compare different communication modules, weighing factors like power consumption, signal range, data rate, and compatibility to determine the best choice for mission requirement

Question 82

Feasibility Studies

Answer 82

Definition: A feasibility study assesses whether a proposed solution or system is viable and practical within the project’s technical, operational, economic, and legal constraints. It examines the likelihood of achieving the desired outcome and evaluates risks, resource requirements, and critical dependencies.

Purpose: The goal of a feasibility study is to determine whether a project, design, or approach is worth pursuing before committing substantial resources. It’s often conducted in the early stages of project planning to ensure that the project scope, timeline, and budget are realistic and achievable.

Example: In the initial phase of designing a CubeSat, a feasibility study might analyze whether a low-cost communication module can sustain reliable communication throughout the suborbital mission, given power limitations and anticipated environmental challenges

Question 83

“Trade Studies” v. “Feasibility Studies”

Answer 83

Scope: Trade studies are typically more specific, focusing on comparing and selecting between defined options. Feasibility studies are broader, evaluating whether the overall project or system is possible within the given constraints.

Timing: Feasibility studies usually precede trade studies, as they establish whether the project or concept is viable, while trade studies refine specific design or component choices.

Focus: Trade studies emphasize optimization and selection between alternatives, while feasibility studies focus on viability and risk assessment of the project as a whole.

Question 84

Request for Proposals

Question 85

Gap Analysis

Question 86

Risk Analysis

Answer 86

Purpose: RFPs invite vendors to propose their approach to fulfill a mission requirement, with more flexibility for the vendor to outline solutions and innovation.
Role in Mission Development: Used when NASA requires unique or high-complexity systems, such as a new spacecraft component or research services. RFPs are often part of the concept development stage for complex projects where the specific details might still be under refinement.
Example Usage: NASA might issue an RFP for a custom scientific instrument, asking vendors to propose novel solutions based on broad specifications.

Question 87

Sources Sought Notices (SSNs)

Answer 87

Purpose: SSNs are preliminary requests for information to gauge market interest or assess existing solutions before a formal solicitation like an RFQ or RFP.
Role in Mission Development: NASA might use SSNs in the concept development phase to identify potential vendors or assess industry capabilities when there is uncertainty about how best to meet mission requirements.
Example Usage: NASA could issue an SSN to identify companies capable of manufacturing radiation-resistant materials for a new satellite design.

Question 88

Small Business Innovation Research (SBIR)

Answer 88

The primary goal is to fund research and development (R&D) projects led by small businesses to foster innovation and develop products with strong commercial potential. The focus is on empowering small businesses to independently advance technology, often with potential commercial applications outside of the sponsoring agency.

Collaboration with research institutions is optional but not required. Small businesses may complete the work in-house or choose to subcontract a portion of the work to other entities, including universities.

Nearly all federal agencies with extramural R&D budgets exceeding $100 million are required to allocate a portion of their funds to the SBIR program, including agencies like NASA, the Department of Defense (DoD), and the National Institutes of Health (NIH).

Small businesses retain full ownership of intellectual property developed under the program. This setup incentivizes companies to focus on commercialization, as they hold exclusive rights to the technology they develop.

Question 89

Small Business Technology Transfer (STTR)

Answer 89

Similar to SBIR in terms of supporting small businesses in technology development, but it specifically emphasizes collaboration between small businesses and research institutions. STTR is designed to bridge the gap between scientific research and practical applications by requiring partnerships with nonprofit research organizations, such as universities.

Collaboration with a nonprofit research institution is mandatory. A minimum of 30% of the work must be conducted by the research institution, while at least 40% must be performed by the small business. This partnership model aims to leverage the research institution’s expertise and facilities to advance the small business’s technology development.

Only agencies with extramural R&D budgets exceeding $1 billion participate in the STTR program, so fewer agencies are involved. Key STTR agencies include NASA, DoD, and NIH, but they provide fewer STTR awards compared to SBIR.

The IP ownership and sharing agreements are established in the partnership agreement between the small business and the research institution. This arrangement allows the small business and research institution to benefit from IP, but terms must be clarified before proceeding to ensure fair commercialization opportunities.

Question 90

Phases in SBIT and STTR Programs

Answer 90

Phase I: Focuses on feasibility and proof of concept. Both programs provide similar funding levels for this initial phase, typically around $50,000 to $250,000.
Phase II: Supports further R&D to develop the technology based on Phase I results. Funding levels in Phase II are generally higher, often ranging from $750,000 to $1.5 million or more.
Phase III (Commercialization): Unlike Phases I and II, Phase III does not provide federal funding. Instead, companies are expected to seek private or non-SBIR/STTR government funding to bring their products to market.

*Both programs are open to U.S.-based small businesses (fewer than 500 employees) that are majority-owned by U.S. citizens or permanent residents.
STTR eligibility requires a formalized partnership with a U.S.-based nonprofit research institution.

Question 91

SBIR v. STTR

Answer 91

Question 92

Other Transactional Authorities (OTAs)

Answer 92

OTAs are designed to bypass traditional federal acquisition regulations (FAR), allowing agencies to partner with private sector firms, universities, and other entities to develop prototypes, research, and production solutions. They prioritize speed, flexibility, and partnership with non-traditional contractors to accelerate technology development and address urgent needs.

Open to a wide range of participants, including large businesses, small businesses, academic institutions, and consortia. The main goal is to attract “non-traditional” vendors—companies that do not typically work with the government and may lack the experience to navigate the FAR requirements.

OTAs are not subject to the FAR, allowing agencies to negotiate custom terms, faster timelines, and simplified reporting requirements. This makes OTAs particularly attractive for developing and testing prototypes or entering partnerships with innovative companies that might otherwise avoid government contracts.

OTA agreements are often milestone-based rather than phased, meaning payments or funding are provided as specific milestones are achieved. This setup allows for flexibility and a rapid transition from prototyping to production if milestones are met satisfactorily.

OTAs offer more flexible IP and data rights negotiations. This approach makes OTAs attractive to commercial companies that want to retain ownership of their innovations or limit the government’s use of proprietary information. OTAs often include negotiated IP terms that allow companies to protect their commercial interests while still fulfilling government requirements.

OTAs are specifically designed to expedite the acquisition process. They enable agencies to go from identifying a need to a solution faster than traditional contracts and even faster than SBIR/STTR by reducing or eliminating many administrative steps and restrictions.

Question 93

OTAs v. SBIR/STTR

Answer 93

These programs fund small businesses (SBIR) and partnerships with research institutions (STTR) to create innovative technologies that meet emerging SPS and CDD needs. SBIR/STTR advances early-stage R&D through a structured, phased approach, focusing on feasibility (Phase I) and prototype development (Phase II). This approach incrementally aligns new technology with specific capability or performance criteria.

OTAs enable rapid prototyping and testing, which is especially useful for refining technologies against SPS and CDD requirements. OTAs allow flexible, milestone-based contracting, supporting iterative testing and adjustment to evolving requirements. They bridge the gap from prototype to initial production, ensuring that technologies meet performance and capability benchmarks quickly and efficiently.

Question 94

System Performance Specification (SPS)

Answer 94

The SPS, on the other hand, is a detailed specification document created after the CDD. It defines the exact technical requirements and performance standards the system must meet to satisfy the CDD’s objectives. The SPS includes specific metrics, design constraints, and precise system characteristics to ensure that the developed system can fulfill the operational needs outlined in the CDD.

The SPS translates the CDD’s high-level requirements into actionable, quantifiable technical specifications. It details every aspect of the system’s performance, from system architecture to environmental resilience, reliability, maintainability, and safety. This level of detail serves as a blueprint for the engineering and manufacturing teams, ensuring alignment with the capability goals.

The SPS is developed after the CDD, during the system design and development phases. It serves as a contract-like document that provides measurable benchmarks for design, testing, and validation efforts. The SPS helps ensure that the final system not only meets high-level capability goals but also adheres to stringent technical and operational standards.

The audience for the SPS is more technical, including engineers, designers, quality assurance teams, and contractors responsible for developing, testing, and certifying the system. It provides these stakeholders with clear requirements and metrics for system performance and quality assurance.

The SPS can be updated as the design matures, especially during prototyping and testing phases, to address unforeseen technical challenges or incorporate improvements. Changes to the SPS are typically more controlled, as they affect detailed design and production.

Question 95

Capability Development Document (CDD)

Answer 95

The CDD is developed early in the acquisition process to define the required capabilities for a system. It focuses on high-level operational needs, describing what the system must achieve to meet mission requirements. The CDD outlines capability gaps, key performance parameters (KPPs), and performance objectives without going into specific technical or design details.

The CDD operates at a conceptual level, providing broad operational requirements and capabilities. It outlines essential features and functionalities but avoids detailed technical requirements. The document focuses on what the system must do rather than how it must be built.

Developed during the early concept development and requirements definition phases, the CDD guides initial research, feasibility studies, and early design efforts. It shapes the overall direction of the project, enabling stakeholders to assess whether current technology can meet mission objectives or if further R&D is necessary.

The primary audience includes project managers, systems engineers, and executive decision-makers who use the CDD to determine strategic direction and allocate resources. It also involves high-level stakeholders who assess whether the project aligns with organizational and mission priorities.

The CDD may undergo revisions as new information, emerging threats, or technology changes impact mission requirements. However, once approved, the CDD provides a stable foundation that should remain relatively consistent to prevent shifts in mission focus or scope creep.

Question 96

SPS v. CDD

Answer 96

The CDD provides the “what”—defining capabilities that the system must achieve for mission success. The SPS then provides the “how”—detailing exactly how those capabilities will be implemented and measured within the system. This structure ensures that high-level mission objectives flow smoothly into actionable technical requirements, aligning all phases of development from concept to production.

SBIR and STTR programs focus on developing innovative technologies that address the high-level capabilities outlined in the CDD. These programs help small businesses and research institutions create and validate new solutions that can meet CDD needs, laying the groundwork for later development.

OTAs are frequently used to refine and test prototypes against the specific performance metrics outlined in the SPS. Since OTAs allow for rapid adjustments, they are ideal for finalizing system components to ensure they meet SPS standards, bridging the gap between initial concept development and full system deployment.

As projects advance, the high-level capability requirements in the CDD are refined into specific performance metrics in the SPS. Feedback from SBIR/STTR and OTA-funded technology development provides insight into how feasible these capabilities are, potentially leading to SPS adjustments or CDD updates.

If a prototype developed under an OTA does not meet an SPS metric, the testing feedback may prompt adjustments in design or performance requirements. This iterative process ensures that the final system aligns closely with both the capability-driven CDD and the detailed performance metrics in the SPS.

Question 97

Historical Data Analysis and Trend Projection

Answer 97

Method: This involves analyzing historical data from similar projects to determine typical margin requirements for mass, power, and memory. Historical data provide an empirical basis for setting initial margin values based on previous performance trends and growth patterns in similar systems.

Application: This method is useful when there is a robust database of past project data, allowing engineers to derive average growth rates or risks for TPMs based on the project type, complexity, and environment​

Question 98

Monte Carlo Simulation for TPM Margin Calculation

Answer 98

Method: Monte Carlo simulations use statistical modeling to assess a range of possible outcomes for each TPM, factoring in uncertainties and variations in component specifications. The simulation runs thousands of scenarios with random variables to determine a distribution of potential TPM values, helping define robust margin levels.

Application: This method is particularly effective in high-risk environments or with new technologies where uncertainties are high. Monte Carlo outcomes provide probability-based insights into worst-case scenarios for mass, power, and memory requirements

Question 99

Probabilistic Risk Assessment (PRA) for TPM Margin Calculation

Answer 99

Method: PRA evaluates the likelihood of exceeding margins based on identified risks and uncertainties. This method applies probability distributions to estimate the likelihood of TPM overruns, enabling project teams to adjust margins based on the assessed risk level.

[actual approach]

Application: PRA is effective in risk-prone areas where critical TPMs (e.g., memory in data-intensive systems) are highly sensitive to design changes or operational conditions. PRA results allow designers to apply higher margins where risks are greatest

Question 100

Regression Analysis for TPM Margin Calculation

Answer 100

Method: Regression analysis models the relationship between key parameters and TPMs, allowing engineers to predict changes in TPMs as a function of other design variables (such as temperature, altitude, or mission duration). Linear or nonlinear regression models can forecast margin adjustments based on anticipated shifts in these parameters.

Application: Regression analysis is effective in systems with established correlations, such as memory usage increasing with computational complexity or power demands rising with component count. This method helps predict and set TPM margins more precisely based on real-time data inputs.

Question 101

Machine Learning Models for TPM Margin Calculation

Answer 101

Method: Machine learning algorithms, such as decision trees and neural networks, can be trained on historical TPM data to predict margin requirements based on various design configurations. These models can adjust margin predictions as new data become available, providing adaptive margin management.

Application: Machine learning is particularly useful in complex systems with many interdependent factors affecting TPMs. Adaptive models are beneficial in rapidly evolving fields like aerospace, where mass, power, and memory requirements may shift as design iterations progress

Question 102

Uncertainty Quantification (UQ) for TPM Margin Calculation

Answer 102

Method: UQ assesses and quantifies uncertainties in TPM predictions, often using methods like interval analysis and polynomial chaos expansion. By analyzing the uncertainty bounds around TPM estimates, engineers can set conservative margins that account for potential deviations from nominal values.

Application: UQ is valuable in early design phases where there is significant uncertainty in component performance, helping teams set TPM margins that account for unverified assumptions in mass, power, or memory

Question 103

Delphi Method

Answer 103

Delphi Method is a structured communication technique commonly used to gather expert opinions and reach consensus on complex topics or decisions. Originally developed by the RAND Corporation in the 1950s, it’s widely applied in fields like forecasting, systems engineering, and policy-making, where quantitative data may be sparse or unreliable.

Key Steps in the Delphi Method:

1) Selection of Experts: The process begins by identifying a panel of experts with relevant knowledge and experience. These experts can come from diverse fields or areas related to the topic of inquiry.

2) Initial Round of Questioning: Experts respond to a set of structured questions related to the topic. These questions may involve estimates, forecasts, or subjective assessments.

3) Anonymous Feedback and Iterative Rounds: After the first round, the responses are aggregated and shared anonymously with the group. Experts then review the group feedback, often re-evaluating their initial answers in light of others’ perspectives. This process is repeated in multiple rounds to refine the group’s overall responses, with each round moving the group closer to a consensus.

4) Final Consensus: The iterative process continues until a predetermined level of consensus is achieved or until diminishing returns make further rounds unnecessary.

5) Documentation and Analysis: The final results are documented, often highlighting consensus areas, unresolved disagreements, and any patterns that emerged during the rounds.

Question 104

Role of Delphi Method in calculating TPM Margins

Answer 104

In systems engineering, the Delphi Method is used for tasks like setting TPM margins, identifying potential risks, estimating cost and schedule, and forecasting technology trends. It’s particularly valuable in early project phases where there are uncertainties and few reliable data points. For example, in mass growth analysis or TPM margin determination, engineers might use Delphi to estimate growth trends and assign contingencies based on expert knowledge and historical insights

Question 105

Risks of applying the Delphi Method

Answer 105

The Delphi Method can be time-consuming, as reaching consensus may require multiple rounds. Additionally, it relies heavily on the expertise and engagement of the participants, making expert selection critical to the process’s success.

Question 106

Design Maturity

Question 107

Growth Allowance Tables

Answer 107

Provide recommendations for the growth of planned budgets (mass, power, computer memory) based on statistical based projects

Organized in a table

Question 108

Interface Requirements

Answer 108

Specification Requirement Categories

Interface Requirements specify the direct and indirect connectivity or interactions with
external systems

Question 109

Capability requirements

Answer 109

Type of “Specification Requirement”

Capability requirements specify the action and associated level of performance

Question 110

Design and Construction Constraint Requirements

Answer 110

Type of “Specification Requirement”

Design and Construction Constraint Requirements specify constraints for the systems’s design and construction such as manufacturing techniques, factors of safety, human factors,
etc

Question 111

Verification Requirements

Answer 111

Type of “Specification Requirement”

Verification Requirements specify methods of assuring the system complies with all
requirements

Question 112

Validation Requirements

Answer 112

Type of “Specification Requirement”

Validation Requirements specify methods of assuring the system meets the user’s
operational need(s).

Question 113

Specification Tree (Spec Tree)

Answer 113

Purpose/Role: requirements derivation, management, and control.
– Mirrors (but does not replace) the system architecture
- Sometimes you have to account for interim configurations, particularly if you intend to use the system while it is still under construction

Focus on requirements and standards for each system element. A Spec Tree organizes the specifications and requirements from high-level system needs down to individual components. This structure ensures each part meets specified standards, regulatory requirements, and performance metrics, supporting compliance and quality control

Organize specifications hierarchically, starting with overarching system requirements, followed by subsystem and component-level specifications. This tree structure clarifies which specifications apply to each subsystem or component, ensuring that all requirements are met in design and testing phases

Employed in design, compliance, and validation stages, especially in industries where strict regulatory adherence is required (e.g., aerospace and defense). It provides a roadmap for engineers to trace each specification from top-level requirements to individual component needs, aiding in validation and verification processes

Strongly compliance-focused, providing traceability from system-level requirements to individual component specifications. This traceability supports verification and validation by ensuring each component complies with necessary standards​

Question 114

Parts Tree v. Spec Tree

Answer 114

Question 115

Functional Flow Block Diagrams

Question 116

Requirements Domain Solution

Answer 116

Indended to bound and specify the user’s problem and solution space

Captures the voice of the customer

This is the top-most level of the solution domain hierarchy (everything in the lower levels should be traceable back to elements in the requirements domain solution

Question 117

Solution Domain Hierarchy

Answer 117

Breaks down the elements and considerations into four domains:
1) Requirements Domain Solution
2) Operations Domain Solution
3) Behavioral Domain Solution
4) Physical Domain Solution

As you get to lower and lower levels, the need for documentation increases

Question 118

Domain-Solution v. Mission Phase Matrix

Answer 118

Column are broken into phases (at a minimum: Pre-mission, Mission, and Post-Mission)

Question 119

Operations Domain Solution

Answer 119

Understand how the user intends to deploy; operate, maintain, and sustain (OM&S), and retire/dispose of the system

Includes:
1) Operational Tasks/Outcomes
2) States/Modes (traced back to an Operational Task)

Question 120

Operational Tasks

Answer 120

Significant part of the Operations Domain Solution

[more]

Question 121

Behavioral Domain Solution

Answer 121

Models system logical/behavioral interactions with its Operating Environment

Primarily modeling with Use Case Capability Threads

Question 122

Use Case Capability Threads

Answer 122

Significant part of the Behavioral Domain Solution

[more]

Question 123

Physical Domain Solution

Answer 123

Describes a cost-effective, acceptable risk, physical implementation

Primarily dealing with Physical Architecture Configurations
- Logical Capability Configuration

Question 124

Logical Capability Configuration

Answer 124

Significant part of the Physical Domain Solution

[more]

Question 125

Simplest way to break down the product phases

Answer 125

1) Pre-Mission Phase
2) Mission Phase
3) Post-mission Phase

Question 126

Parts of a Functional Requirement

Answer 126

1) Actor or SOI
2) “shall”
3) outcome to be accomplished

[Actor or SOI] shall [outcome to be accomplished]

Question 127

Parts of a Performance Requirement

Answer 127

1) Requirement ID
2) Actor or SOI
3) “shall”
4) outcome to be accomplished
5) relational Operator
6) Level of Performance
7) Condition

[Actor or SOI] shall [outcome to be accomplished] [relational operator] [Level of performance] [condition (optional)]

EXAMPLE: “SPS 3.1.3: The Radar System shall respond within 100 +/- 10 milliseconds to any operator command”
1) Requirement ID → “SPS 3.1.3”
2) Actor or SOI → “The Radar System”
2) “shall”
3) outcome to be accomplished → “respond”
4) relational Operator → “within”
5) Level of Performance → 100 +/- 10 milliseconds
6) Condition → “to any operator command”

Question 128

Tabular Approach to writing requirements

Answer 128

Question 129

SMART-VT criteria for evaluating requirements

Answer 129

SMART-VT model ensures that each requirement aligns with both project goals and practical constraints, enhancing project transparency and easing the verification and validation (V&V) processes. It’s particularly beneficial in complex projects, like aerospace or defense, where reliability and accuracy are paramount, and requirements must be meticulously managed to ensure project success

– Specific: Must be clear, precise, and unambiguous, specifying exactly what is needed. This minimizes misunderstandings.

– Measurable: Stakeholders can quantitatively assess whether the system meets the requirement.

– Achievable: Within the constraints of the organization (budget, man-years)

– Realistic: Within the constraints of physics and economics (supply chains, technological precedent)

– Testable: Each requirement must be structured so that its fulfillment can be verified during development AND after deployment, ensuring it meets the intended function and quality standards.

– Verifiable: Can prove whether the system complies with specified requirements. This is essential for regulatory compliance and quality assurance, confirming each requirement is met to stakeholder standards.

– Traceable: Traceable requirements link back to stakeholder needs, higher-level goals, or system specifications. This traceability supports accountability and ensures each requirement aligns with broader project objectives.

Question 130

Ways to verify requirements

Answer 130

1) Analysis
2) Inspection
3) Test
4) Demonstration

Question 131

Requirements Verification by Analysis

Answer 131

Method: Analytical verification uses modeling, simulations, or mathematical analysis to confirm that requirements are achievable and consistent. This method is commonly used when physical testing is impractical or expensive, such as for systems designed to operate in extreme environments.

Application: Suitable for requirements related to system performance, load capacities, and durability. For instance, modeling can verify that a structure will bear anticipated loads or that software will handle expected data throughput.

Benefit: Enables validation of requirements in theoretical scenarios, reducing risks in practical applications

Question 132

Requirements Verification by Demonstration

Answer 132

Method: Demonstration involves observing the system performing specific functions to show that it meets requirements. It’s typically conducted in real or simulated operational environments and relies on observable, measurable behaviors rather than formal testing.

Application: Often used for user-facing features or safety-critical functions to confirm that key requirements, such as ease of use, responsiveness, or emergency behaviors, are met.

Benefit: Provides a practical verification approach when formal testing or analysis is too resource-intensive. It also offers stakeholders an intuitive confirmation that requirements are fulfilled

Question 133

Requirements Verification by Test

Answer 133

Method: Testing is used to verify that a system meets specified requirements under controlled conditions. Testing includes unit testing, integration testing, system testing, and acceptance testing. Each level of testing verifies that specific aspects of the requirement are met within real-world scenarios.

Application: Particularly effective for requirements related to system functionality, performance, and reliability. Test cases are designed to match each requirement, demonstrating that it works as intended.

Benefit: Provides measurable evidence of compliance, helping teams identify design or implementation issues​

Question 134

Requirements Verification by Inspection

Answer 134

Method: Requirements are reviewed by stakeholders, engineers, and subject matter experts. This inspection process involves examining each requirement for clarity, completeness, feasibility, and consistency with project goals.

Application: Often used early in the project lifecycle, inspection helps identify ambiguous or contradictory requirements, enabling revisions before the design and development phases.

Benefit: Detects issues early and ensures requirements align with stakeholder expectations and project constraints

Question 135

Realities to accept when it comes to requirements development

Answer 135

1) Requirements are dynamic. They will be constantly changing and your team will have to keep up with these changes and adapt
2) Requirements come from multiple sources (standards, customers, regulations)

Question 136

“Requirements Analysis”

Answer 136

[more]

Must be completed

Question 137

Pros and Cons of a hierarchical decomposition of requirements

Answer 137

Pros:

Cons: Dilutes systems thinking (can cause individual systems engineers to lose perspective)

Question 138

System Specification

Question 139

Hardware Requirements Specification

Question 140

Software Requirements Specification

Question 141

Risks of Rushing into Requirements Development

Question 142

Detailed Requirement Summary

Answer 142

An optional extension of the requirement text. It provides additional context, background, and clarifying information to help improve the understanding of less-experienced systems engineers that may be trying to interpret those requirements in the future (just like you had to do for LTAMDS and Sentinel)

Question 143

Safety Factors in Requirements

Question 144

Requirements Flowdown

Question 145

Requirements Allocation

Question 146

Three Levels of Requirements

Answer 146

Level 1) Mission Requirements
Level 2) Segment Requirements
Level 3) Subsystem Requirements

Question 147

Mission Requirements

Question 148

Segment Requirements

Question 149

Subsystem Requirements