Conceptual Design and Requirements Development Flashcards

Question

Stakeholder Requirements v. Customer Requirements

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

A type of specification Requirement Operational Requirements specify high-level requirements to achieve system mission objectives and behavioral interactions

Answer 5

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

Answer 6

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)

Answer 7

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)

Answer 8

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

Answer 9

- 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

Answer 10

* 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

Answer 11

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

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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

Answer 16

Concept of Operations is the 'Organization Level' definition of the system

Answer 17

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)

Answer 18

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

Answer 19

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

Answer 20

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

Answer 21

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

Answer 22

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

Answer 23

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.

Answer 24

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.

Answer 25

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.

Answer 26

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

Answer 27

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

Answer 28

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

Answer 29

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.

Answer 30

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

Answer 31

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

Answer 32

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

Answer 33

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?]

Answer 34

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

Answer 35

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.

Answer 36

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.

Answer 37

The <> 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

Answer 38

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

Answer 39

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.

Answer 40

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

Answer 41

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

Answer 42

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

Answer 43

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

Answer 44

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

Answer 45

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

Answer 46

Mission Phases contain Modes Modes contain Use Cases

Answer 47

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

Answer 48

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

Answer 49

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

Answer 50

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

Answer 51

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

Answer 52

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.

Answer 53

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.

Answer 54

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.

Answer 55

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.

Answer 56

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.

Answer 57

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.

Answer 58

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.

Answer 59

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.

Answer 60

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.

Answer 61

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.

Answer 62

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.

Answer 63

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

Answer 64

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

Answer 65

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

Answer 66

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.

Answer 67

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

Answer 68

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

Answer 69

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.

Answer 70

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

Answer 71

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.

Answer 72

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

Answer 73

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

Answer 74

Type of "Specification Requirement" Capability requirements specify the action and associated level of performance

Answer 75

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

Answer 76

Type of "Specification Requirement" Verification Requirements specify methods of assuring the system complies with all requirements

Answer 77

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

Answer 78

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

Answer 79

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

Answer 80

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

Answer 81

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

Answer 82

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)

Answer 83

Significant part of the Operations Domain Solution [more]

Answer 84

Models system logical/behavioral interactions with its Operating Environment Primarily modeling with Use Case Capability Threads

Answer 85

Significant part of the Behavioral Domain Solution [more]

Answer 86

Describes a cost-effective, acceptable risk, physical implementation Primarily dealing with Physical Architecture Configurations - Logical Capability Configuration

Answer 87

Significant part of the Physical Domain Solution [more]

Answer 88

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

Answer 89

1) Actor or SOI 2) "shall" 3) outcome to be accomplished [Actor or SOI] shall [outcome to be accomplished]

Answer 90

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"

Answer 91

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.

Answer 92

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

Answer 93

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

Answer 94

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

Answer 95

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

Answer 96

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

Answer 97

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)

Answer 98

[more] Must be completed

Answer 99

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

Answer 100

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)

Answer 101

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