Technical Processes Flashcards
Is “Initial RVTM” an output of 4.1 ?
No, only a Preliminary validation criteria.
Page 146
Which process does “project constraints” come from in the IPO diagram of 4.1?
5.1 Project Planning Process
Page 146
“We have to establish a comprehensive set of alternative solution classes in the activity of ‘defining the problem or opportunity space’ during the business or mission analysis process (4.1) .” True or false.
False. We have to do it in the activity of “characterizing the solution space”.
Page 148
What are the definitions of needs and requirements for a system?
For a system, needs are often capabilities or things that are lacking but wanted or desired by one or more stakeholders, and requirements are formal structured statements that can be verified and validated.
Page 140
What are the 14 technical processes?
- Business or mission analysis process
- Stakeholder needs and requirements definition process
- System requirements definition process
- Architecture definition process
- Design definition process
- System analysis process
- Implementation process
- Integration process
- Verification process
- Transition process
- Validation process
- Operation process
- Maintenance process
- Disposal process
Page 142-144
What concepts are included within the preliminary life cycle concepts?
Acquisition concept, deployment concept, operational concept (OpsCon), support concept, and retirement concept.
Page 142
What are the 3 purposes stated in ISO/IEC/IEEE 15288 for 4.1 ?
- To define the business or mission problem or opportunity
- To characterize the solution space
- To determine potential solution class(es) that could address a problem or take advantage of an opportunity.
Page 146
Do we have to nominate major stakeholders to be involved in the retirement of the solution during 4.1?
Yes, business owners nominate the major stakeholders who are to be involved in the acquisition, operation, support, and retirement of the solution.
Page 148
What’s the main distinction between ConOps (concept of operations) and OpsCon (operational concept) ？
ANSI/AIAA G-043A-2012 notes that an important distinction exists in that each has a separate purpose and is used to meet different ends. The ConOps is developed by/for the leadership at the enterprise level of the organization using the SOI, addressing the leadership’s intended way of operating the organization. The OpsCon is prepared at the business level, a user-oriented document that describes system characteristics of the to-be-delivered system from the user’s viewpoint.
Page 150-152
Is it true that the purpose of 4.2 is to define the stakeholder requirements for a system in whatever environment?
No, it shall be a defined environment.
Page 154
What are the 4 “preliminary” inputs of 4.2?
Preliminary life cycle concepts, preliminary validation criteria, preliminary MOE needs and preliminary MOE data.
Page 158
What are included in stakeholder validation criteria?
It includes measures of effectiveness (MOEs) and measures of suitability (MOSs).
Page 160
What is the reason for eliciting and analyzing requirements?
To understand the needs of the stakeholders well enough to support the architecture definition and design definition processes.
Page 162
Do engineers need to consider stakeholders of enabling systems when identifying stakeholders?
Yes, same as stakeholders of interoperating systems, these will also impose constraints that need to identified and considered.
Page 162
Where can the outputs of the stakeholder needs and requirements definition process be captured?
These outputs can be captured in life cycle concept documents (particularly the OpsCon) and the StRS.
Page 164
Please think of some techniques for requirements elicitation.
Interviews, focus groups, the Delphi method, and soft systems methodology etc.
Page 166
If you have to cope with the uncertainty, what are the essential tools you can use?
Scenarios and what-if thinking.
Page 166
What is the primary goal of a concept document?
To capture, early in the system life cycle, an implementation-free understanding of stakeholder needs by defining what is needed, without addressing how to satisfy the need.
Page 168
Do we need to define a complete OpsCon or to allocate functions to hardware or software elements at the stage of developing life cycle concepts?
No, this comes later during architectural design.
Page 170
Is it true that the purpose of the 4.3 is to transform the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the customer?
No, is to meets the operational needs of the user.
Page 172
Is “stakeholder requirements traceability” necessary in 4.3?
Yes, the output of the process must be compared for traceability to and consistency with the stakeholder requirements, without introducing implementation biases, before being used to drive the architecture definition process.
Page 174
What are included in system verification criteria?
It includes measures of performance (MOPs) and technical performance measures (TPMs).
Page 178
What can be employed during requirements definition and analysis?
This complex process employs performance analysis, trade studies, constraint evaluation, and cost-benefit analysis.
Page 180
Is requirements definition and analysis a “top-down” or a “bottom-up” process?
Both. Once the top-level set of system requirements has been established, it is necessary to allocate and flow them down to successively lower levels. As the allocation and flow-down process is repeated, it is essential that traceability be maintained to ensure that all system level requirements are satisfied in the resulting design.
Page 180
What are the necessary constraints that need to be reflected during requirements definition and analysis?
Standards, utilization environments, essential design considerations and design constraints.
Page 180-182
What are the characteristics should be considered for every requirement?
It should be necessary, implementation independent, unambiguous, complete, singular, achievable, verifiable and conforming.
Page 182-186
What are the characteristics should be considered for a set of requirements as a whole?
The set of requirements should be complete, consistent, feasible/affordable and bounded.
Page 186
Individual requirement statements may have a number of attributes attached to them, what are they?
Trace to parent, trace to source, trace to interface definition, trace to peer requirements, trace to verification method, trace to verification requirement(s), trace to verification results, requirements verification status, requirements validation status, priority, criticality, risk, key driving requirement (KDR), owner, rationale, applicability and type.
Page 188-192
What is the primary focus through System Requirement Review (SRR)?
Defining, deriving, and refining functional and performance requirements apply to the total system over its life cycle.
Page 192
What is the purpose of the Architecture Definition process?
To generate system architecture alternatives, to select one or more alternative(s) that frame stakeholder concerns and meet system requirements, and to express this in a set of consistent views.
Page 196
What are the differences between system architecture and design?
System architecture is more abstract, conceptualization oriented, global, focused to achieve the mission and OpsCon of the system, and focused on high-level structure in systems and system elements. It addresses the architectural principle, concepts, properties, and characteristics of the SOI. While system design is more technology oriented through physical, structural, environmental, and operational properties forcing decisions for implementation by focusing on compatibility with technologies and other design elements and feasibility of construction and integration.
Page 196
“Interface definition update identification” is an input of 4.4, which process does this come from?
From 4.8 Integration.
Page 198
What is the goal of coupling matrix used during architecture definition?
To keep the interfaces as simple as possible.
Page 210
Nonfunctional requirements and/or architectural characteristics are sued as criteria to analyze, assess and select candidate system elements and logical partitions. Could you please name a few examples of assessment criteria?
Similar transformations within the same technology, similar level of efficiency, exchange of same type of input/output flows (information, energy, materials), centralized or distributed controls, execution with close frequency level, dependability conditions, environmental resistance level, and other enterprise constraints.
Page 212
What is the proposition for a preferred architecture to match the complete set of stakeholder and system requirements?
It depends on stakeholder and system requirements being feasible and validated, and that feasibility and validation are demonstrated or proven.
Page 214
What is the purpose of Design Definition process?
To provide sufficient detailed data and information about the system and its elements to enable the implementation consistent with architectural entities as defined in models and views of the system architecture.
Page 216
What is a design descriptor?
It is the set of generic design characteristics and of their possible values.
Page 224
What does design definition starts and ends with?
It starts with the system as a whole consisting of system elements and ends with a definition (i.e., design) for each of these system elements (not just one of them) and how they are designed to work together as a complete system.
Page 224
What is the purpose of the System Analysis process?
To provide a rigorous basis of data and information for technical understanding to aid decision-making across the life cycle.
Page 226
What analyses does 4.6 use to perform quantitative assessments and estimations?
Cost analysis, affordability analysis, technical risk analysis, feasibility analysis, effectiveness analysis, and other critical quality characteristics.
Page 228
“Analysis situations” is an input of 4.6, where does it come from?
Anywhere from the life cycle.
Page 230
What costs might be included within the full life cycle costs?
It may include labor and non-labor cost items; development, manufacturing, service realization, sales, customer utilization, supply chain, maintenance, and disposal costs.
Page 234
Is it true that “technical risks are project risks”?
No, technical risks should not be confused with project risks even if the method to manage them is the same. Technical risks address the system itself, not the project for its development. But it may interact with project risks.
Page 234
What is effectiveness analysis?
It is a term for a broad category of analyses that evaluate the degree or extent to which a system meets one or more criteria —- the effectiveness of the system in meeting the criteria in its intended operational environment.
Page 236
What is the purpose of the Implementation process?
To realize a specified system element.
Page 236
Which process will the output “implementation record” go to in 4.7?
Implementation record goes to 7.6, the knowledge management process.
Page 238
Which four forms of system elements does 4.7 typically focuses on?
Hardware/physical, software, operational resources and services.
Page 242
What is the purpose of the Integration process?
To synthesize a set of system elements into a realized system (product or service) that satisfies system requirements, architecture, and design.
Page 244
What we can do to establish the integration strategy that minimizes integration time, costs, and risks?
- Define an optimized sequence order of assembly aggregates, composed of system elements, based on the system architecture definition, and on appropriate integration approaches and techniques.
- Define the configurations of the aggregate to be built and verified (depending on sets of parameters).
- Define the assembly procedures and related enablers.
Page 246
What is “aggregate”?
An aggregate is made up of several implemented system elements and their physical interfaces (system elements and connectors).
Page 250
Give some examples of integration techniques.
Global integration, integration “with the stream”, incremental integration, subset integration, top-down integration, bottom-up integration, criterion-driven integration, reorganization of coupling matrices.
Page 252-254
What is the purpose of the Verification process?
To provide objective evidence that a system or system element fulfils its specified requirements and characteristics.
Page 256
Which process does the input “verification criteria” come from?
4.3 System requirements definition process.
Page 256
What detailed descriptions for the selected verification actions will be included in the verification plan?
Item to be verified; expected results and success criteria; selected verification method or techniques; the data needed; the corresponding enabling systems, products, or services.
Page 260
Give some examples of verification actions.
Verification of a stakeholder requirement or a system requirement; verification of the architecture of a system; verification of the design of a system element; verification of a system (product, service, or enterprise) or system element.
Page 266
What are the basic verification techniques?
Inspection, analysis, demonstration, test, analogy or similarity, simulation, sampling.
Page 266-268
Is it true that verification occurs after integration and before validation?
No, in most of the cases, it is more appropriate to begin verification activities during development and to continue them into deployment and use.
Page 268
What is the purpose of the Transition process?
To establish a capability for a system to provide services specified by stakeholder requirements in the operational environment.
Page 270
What typically marks the beginning of the utilization stage of the SOI?
The successful conclusion of the transition process.
Page 270
Which process does the input “verification report” of 4.10 come from?
4.9 Verification and 5.2 project assessment and control.
Page 272
What is the purpose of the Validation process?
To provide objective evidence that the system, when in use, fulfills its business or mission objectives and stakeholder requirements, achieving its intended use in its intended operation environment.
Page 276
Give some examples of validation actions.
Validation of a requirement, validation of an engineering artifact (architecture, design etc.), and validation of a system (product, service, or enterprise).
Page 286
Is it true that “validation concerns system elements instead of system itself”?
No, validation concerns the global system seen as a whole and is based on the totality of requirements (system requirements, stakeholder requirements).
Page 288
Acceptance is an activity conducted before or after transition?
It is an activity conducted prior to transition such that the acquirer can decide that the system is ready to change ownership from supplier to acquirer.
Page 288
What are the three basis for certification?
The development reviews, verification results, and validation results.
Page 290
When we have to make the readiness for use assessment?
This may occur many times in the life cycle, including the first article delivery, completion of production (if more than a single system is produced), and following maintenance actions.
Page 290
What is the purpose of the Operation process?
To use the system to deliver its services.
Page 292
Give examples of operation enabling systems.
Operational environment, training systems, technical data, facilities and infrastructure, sustaining engineering, maintenance planning and management.
Page 298
What is the purpose of the Maintenance process?
To sustain the capability of the system to provide a service.
Page 298
What activities are included in maintenance?
It includes the activities to provide operations support, logistics, and material management.
Page 300
There are various types of maintenance actions, what are they?
Corrective maintenance, adaptive maintenance, perfective maintenance, and scheduled preventive maintenance.
Page 302
What details shall be considered in the maintenance concept?
- Types of maintenance: corrective maintenance, preventive maintenance, system modifications
- Levels of maintenance/repair: user/operator maintenance, in situ maintenance and repair, factory
Page 308
What are the maintenance enabling systems?
Operational environment, supply support/PHS&T, training systems, technical data, facilities and infrastructure, tools and support equipment, design interface/sustaining engineering, maintenance planning and management.
Page 310-312
Give some examples of maintenance techniques.
Condition-based maintenance (CBM), reliability-centered maintenance (RCM), and performance-based life cycle product support
Page 314
What is the purpose of the Disposal process?
To end the existence of a system element or system for a specified intended use, appropriately handle replaced or retired elements, and to properly attend to identified critical disposal needs.
Page 314
