Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

MBSE > Wasson's Principles > Flashcards

Wasson's Principles Flashcards

1
Q

SE Alpha-Omaga Principle

A

SE begins and ends with the Users of a system, product, or service

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Content-Grammar Principle

A

Substantive content must always precede grammar to achieve successful results. Avoid negotiating content for the sake of achieving grammatical elegance and eloquence unless it precluded misinterpretation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Intellectual Control Principle

A

One of the key roles of an SE is to maintain “intellectual control of the problem solution”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

User’s Problem Space Principle

A

Thoroughly understand the problem or issue the User needs to solve, not just the underlying root cause and its contribution

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Decision Artifacts Principle

A

If a key decision or event and its contributory inputs, constraints, and their sources are not documented, the decision or event never occurred

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

System Interactions Principle

A

Systems, products, and services must be capable of encountering, engaging, and responding to external systems and dynamic conditions in the operating environment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Types of Interaction Principle

A

External system encounters and interactions are characterized as cooperative, supportive, and defensive, or combinations of these

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

System Reactive and Adaptive Behavior Principle

A

Systems/products/services must be capable of responding with reactive and adaptive behavior (non-responses, aggressive actions, protection mechanisms, or defensive countermeasures) to stimuli or cues originating from external systems in their operating environment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

System Responses Principle

A

Systems produce products, by-products, services, behaviors, or combinations of these to accomplish mission outcome-based performance objectives and survive in their operating environment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Law of Unintended Consequences

A

Systems, products, by-products, or services responses may result in self-inflicted adverse or catastrophic conditions or effect with negative consequences that impact its performance, mission or survival

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Higher Order Systems Principle

A

Every system serves as the pleasure of or is subject to higher order human systems and natural environment systems that exercise authoritative control over the system, its operation, and the conduct of its missions

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

System Existence Principle

A

Every System exists for its stakeholders based on their perceived operational needs

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

System Equilibrium Principle

A

Every system, depending on its condition exists in a state of equilibrium with its operating environment to ensure survival

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

System Stabilization Principle

A

Every System exhibits a level of stability that requires the user and system to monitor, command & control, its performance, to successfully accomplish mission objectives

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

System Life Cycle Principle

A

Every natural and human system exhibits a system life cycle that characterizes its stage evolution from conception to disposal

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

User Benefits Principle

A

Every system, product, or service must provide six benefits to stakeholders to be considered worth of their consideration for missions:
1. Operation Utility
2. Operational Suitability
3. Operational Availability
4. Operational Usability
5. Operational Effectiveness
6. Operational Efficiency

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Operational Utility Principle

A

Every system/product/service must be operationally useful to enable its User to C2 the system and perform situational assessments with the least number of human errors

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Operational Suitability Principle

A

Every system/product/service must be operationally suitable for the user’s mission application (the right tool for the right job)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Operational Usability Principle

A

Every system/product/service must be operationally usable (easy to understand and operate) according to the user’s mental models, knowledge and skill levels with inducing human errors that affect mission or system performance

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Operational Availability Principle

A

Every system/product/service must be operationally available on demand to perform missions when required by its user.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Operational Effectiveness Principle

A

Every system/product/service must be operationally effective in producing the required mission outcomes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Operationally Efficient Prionciple

A

Every system/product/service must be operationally efficient for the user’s mission application

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Customer Needs Principle

A

Success in providing systems, products, r services solutions to a highly competitive global marketplace requires two levels of knowledge:
1. Understanding the operational needs of your users/customers
2. Understanding what the User’s customer expects of them

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

System Existence Principle

A

Every system/product/service has a purpose and exists for the benefit of performing missons for its users and end users.
Failure of either or both represents system obsolescence leading to system retirement and disposable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

The customer and “customer’s customer” principle

A

To fully understant and support your customer as a system user, you must understand what their customers (the system’s end users) expect form them and the enabling role your system/product/service contributed to the accomplishment of those results

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Dual Producter-Supplier Role Principle

A

Every system product or service preforms two contextual roles:
1. A mission system (producer) role
2. An enabling system (supplier) role

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

System I/O Fitness-for-use principle

A

Every system input/output must comply with pre-defined fitness-for-use performance standards and acceptance criteria established by its stakeholders (users and end users)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Enabling System (supplier role) principle

A

As an enabling system (supplier role), every system delivers products, by-rpoducts, or services to meet the needs and fitness for use standards of its stakeholders (users and end users) performing their mission system roles

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Mission system (producer role) principle

A

In performing its mission system (producer role), every system performs missions or tasks to produce performance-based outcomes to benefit its users and end users

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Enabling system (supplier role principle)

A

As an enabling system (supplier role), every system delivers products, by-products, or services to meet that needs and fitness for use standards of its stakeholders (users and end users) performing their mission system roles

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Mission Outcomes Principle

A

Mission outcomes identify what has to be accomplished to eliminate, minimize, or control an emerging problem space or exploit an opportunity space.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Stakeholder moments of truth principle

A

Every time a system stakeholder (user and end user) encounters and interacts with your organization and its systems/products/services is a “moment of truth” that result in positive or negative experiences, outcomes, and consequences that impact business with you in the future.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Problem, Opportunity, and Solution Spaces Principle

A

Understand the user’s problem/opportunity and solution spaces. A worst-case scenario is writing perfectly stated specification requirements for the wrong problem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Problem/Opportunity Space Principle

A

One enterprise’s or system’s problem space is an opportunity space for a competitor or adversarial system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Operational Needs Principle

A

System analysis requires recognition and validation of three types of stakeholder (user and end user) operational needs:
1. Real
2. Perceived
3. Projected

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Problem-Symptom Solving Principle

A

There are two types of solution development activities: problem-solving and symptom solving. Recognize the difference.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Eliminate or Control the Problem Space Principle

A

If you cannot eliminate the problem space, try to control it until you can resolve or eliminate it.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Problem Statement Principle

A

Every problem or opportunity space should be clearly and concisely bounded by a well- articulated problem statement the does not identify causes, assign blame, or propose solutions

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Contributory Cause Determination Principle

A

Investigative teams determine probable causes and recommend solution based on analysis of the problem statement.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Problme Complexity Reduction Principle

A

Partition-decompose Problem or issue spaces into one or more manageable solution spaces as a means of reducing complexity and managing risk

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Problem space decomposition principle

A

Partitiion or decompose each problem space into one or more solution spaces

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

On-site visits principle

A

Always send a qualifie SE to accompany business development personnel during on-site visits to understand analyze, and document the opportunity/problem and solution spaces.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Counter Reactions Principle

A

When bounding a solution space, anticipate short-term and long-term competitor or adversarial reactionary responses and countermeasures to the solution space

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Mission Success Principle

A

Mission success requires five key elements:
1. A Purpose
2. Timely, sustainable resources
3. A reasonably achievable outcome-based performance objectives
4. A MET
5. A willingness to perform

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

Mission Statement Principle

A

A Mission statement should specify one and only one outcome to be achieved and supported by one or more performance based objectives.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

Mission Objectives Principle

A

Each mission should be bounded and specified by one or more performance-based objectives

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Mission Operating Constraints Principle

A

Each mission should be bounded by operating constraints that limit its acceptable usage: safety, operating range, affordability, and environmental conditions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Mission Reliability Principle

A

Each mission should be bounded in terms of the mission reliability to be achieved.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

User mission profile principle

A

Every system/product/service should include a characterization of its user mission profiles

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

Mission phases of operation principle

A

Human systems (enterprise and engineered) have at least three primary phases of operation:
1. Pre-phase
2. Mission
3. Post-Mission

*An interim phase, such as Storage may be required for some systems between missions

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

Mission Efficiency and Effectiveness Principle

A

Every system/product/service mission should be defined in terms of its efficiency and effectiveness.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Mission event timeline (MET) Principle

A

Every system/product/service should include an MET that identifies time-dependent events that represent the start and completion of mission operations and interim waypoints required to be accomplished to achieve mission success

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Measures of Effectiveness Principle

A

Mission and system success requires establishment of one or more MOEs that quantify mission objectives in terms of performance-based outcomes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

Measures of Success Principle

A

Mission and system success require establishment of one or more MOSs that quantify how well a system is required to perform its mission

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

USe Case Title Principle

A

Every Used case consists of a title that expresses an outcome to be accomplished from the perspective of the User (Actor)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

Use Case Identifier Principle

A

Every Use Case must be unique and consist of an identifier that:
1. Differentiates it from other Use Cases
2. Facilitates referencing

57
Q

Use Case Description Principle

A

Every Use Case should consist of a breif synopsis that describes how the US will accomplish the required outcome.

58
Q

Use case Actros Principle

A

Each use case represents a system/product/service capability required by one or more users in performing their assigned mission or task

59
Q

Use Case Outcome Principle

A

Every Use case expresses what outcome the users requires the system/product/service to produce, not what the system does to perform the action.

60
Q

Use Case Event Timeline Principle

A

When applicable, every Use Case should be bounded by and synchronized to an even timeline.

61
Q

Use Case Preconditions Principle

A

Establish the pre-conditions context for each UC

62
Q

Use Case Trigger Principle

A

Every use case requires a triggering condition or event to initiate its performance

63
Q

Use Case Completion Principle

A

Every Use case requires definition of actions to be accomplished by the user or system to finalize the use case.

64
Q

Use case Happy Path Principle

A

Every use case has a main success scenario that when everything works flawlessly the normal sequence of actions produces the required outcome

65
Q

Use Case Scenarios Principle

A

Every use case should include considerations for the most likely or probably scenarios when things go wrong that required alternate flows from the main success scenario (happy path) to enable recover and avoid system or product failure

66
Q

Ssytem Operations Model Principle

A

Human Systems (enterprise and engineered are characterized by a generalized system operations model developed in collaboration with users concerning how a system/product/service will be deployed, operatied , maintainted, sustained, retired, and disposed

67
Q

Operational Capability Principle

A

Every system operations represents a required operational capability that must produce a specified performance-based outcome while coping with one or more probably or most likely Operating Environment scenarios.

68
Q

System Operations Dictionary

A

Every project should consist of a system operations directory that clearly defined each system operation, its scope, and activities

69
Q

Value-added Operations Principle

A

Each system operations model operation or task and its performance by the system elements either add value and contribute to achieving a mission-based performance objective or not; if not, eliminate it!

70
Q

Synchronized Operations Principle

A

Every system operations model activity should be synchronized with the system/product/service’s mission event timeline

71
Q

ConOps Principle

A

Every project should include a system conops document that describes how the system/product/service being developed is envisioned to be deployed, operated, maintained, sustained, and disposed, via its OCDs

72
Q

Sub-phases of operation Principle

A

when enterprise or engineerd system/product/service’s Mission Life cycle phase of operation become too abstract, partition them into lower level sub-phases of operation, outcomes, and objectives

73
Q

System States Principle

A

Every Eneterprice and Engineered system, produce, or service is characterized by system states that represent its current logistical employment as an asset

74
Q

Operational States Principle

A

Every enterprise or engineered system/product/service is characterized by examinational states that represent its current condition, status, readiness, or availability to perform or continue a mission or task

75
Q

Moder of Operation Principle

A

Every enterprise or engineered system product or service is characterized by user-selectable modes of operation that enable the user to comand and control unique sets of UC-based architectural capabilities to accomplish a specific mission outcome and its objectives

76
Q

Triggering event criteria Principle

A

Every enterprise or engineered system mode of operation requires a pre-defined set of condition-based triggering event criteria to initiate a transition from one mode of operation to another mode

77
Q

Abstract US Modes Principle

A

Each enterprise and engineered system mode of operation represents a user selectable option to perform one or more USs that share similar outcomes and objectives

78
Q

Configuration Status Principle

A

Each enterprise or engineered system/product/service mode of operation commands and controls the configuration state of its architectural configurations

79
Q

Enivronmental States Principle

A

Every enterprise or engineered system/product/service must be capable of operating in and interacting with various types of time and location-dependent environmental states that exist in its operating environments

80
Q

Dynamic States Principle

A

Every enterprise or engineered system, product, or service must be capapble of withstanding and surviving dynamic or transitory conditions created by interactions created by interactions with its operating environment

81
Q

Allowable and prohibited actions principle

A

Every enterprize or engineered system/priduct/service mode of operations is constrainted by allowable and prohibited actions that serve as safeguards to ensure the safety of its users and prevent damage to equipment, the public, and external systems in its operating environment

82
Q

Levels of Abstraction Principle

A

Every SOI, its mission system enabling systems, and equipment (hardware and software) consists of one or more levels of abstraction with standardized titles

83
Q

Performing Entities Concept

A

System levels of abstraction (system, product

84
Q

Operational Environment Domains Principle

A

A system’s operational environment consists of two classes of domains:
1. A higher-order system domain
2. A physical environment domain.

85
Q

High-Order systems principle

A

Every human systme exists and performs mission under the C2 of higher-order systems domains

86
Q

Higher-Order system elements principle

A

Higher-order systems are composed of four analytical system elements:
1. An organization element
2. Roles and mission elements
3. Operating constraints element
4. a resources element

87
Q

Physical Environment Domain composition principle

A

A system’s phsyical environment domain is composed of three classes of analytical elements:
1. Natural system environment
2. Human system environment
3. Induced system environment

88
Q

Logistical-Physical Interfaces Principle

A

Logistical interfaces establish associative relationships with perfromance-based outcomes (e.g. what is to be achieved). Physical interfaces stablish how a logical interface will be implemented

89
Q

Interface Complexity Reduction Principle

A

Where practical, minimize the number of interfaces and to reduce complexity, technical risk, increase reliability, and reduce maintainability cost by standardizing on widely accepted and proven protocols and standards

90
Q

Interface Failure Mitigation Principle

A

Every interface should be specified and designed to :
1) detect failures
2) contain them to their sources
3) mitigate their effects on mission performance

91
Q

System Responsiveness Principle

A

Every system responds to stimuli, excitations, and cues in its operating environment with behavior actions, products, by-products, services, or combinations thereof

92
Q

System Encounters and Interactions Principle

A

System encounters and interactions with external systems in its operating environment during an engagement may be:
a. cooperative
b. friendly
c. benign
d. competitive
e. adversarial
f. a combination of these

93
Q

Compatibility and Interoperability Principle

A

Interfaces must be compatability in terms of form and fit. Where applicatible, they must be interoperable to be able to intelligently encode/decode, interpret, process, and exchange data

94
Q

System Capability Operations Principle

A

every operational capability, as an integrated system consists of a minimum of three phases of operations:
1. Pre-capability operations
2. Capability operations
3. post-capability operations

95
Q

Exception Handling and Recovers Operations Principle

A

Every capability requires a safety or contingency mechanism to detect exception, mitigate, and attempt recovery to return to and restore normal operations without doing any harm

96
Q

Capability Initiation Principle

A

Every operational capability requires an external trigger such as a stimulus, excitation, or visual cue to initiate its performance-based outcome processing

97
Q

Outcome results Reporting Principle

A

On completion of its required performance, every capability should report successful completion of the task.

98
Q

Four domain Solutions Principle

A

A system or entity’s design regardless od level of abstraction is composed of four domain solutions sequenced in a logical workflow:
1. Requirements
2. Operations
3. Behavioral
4. Physical

*based on decision dependencies to minimize redesign and rework

99
Q

Task-Based Outcome and Rewards Principle

A

If you reward engineers for activities, you get… activities. If you equip Engineers with the right processes, tools, and methods to accomplish performance-based outcomes, you get performance-based outcomes

100
Q

System Design Principle

A

system design is a highly interative, collaborative and multi-level process with each level of abstraction dependent on the maturations, stability, and integrity of higher-level specification requirements and design decisions

101
Q

Developemental Test & Evaluation Principle

A

DT&E is performed by the system developer to:
1. Mitigate development configuration technology, design, and ‘other’ risks
2. Provide insights and assurance that the evolving system design solution will comply with its SPS requirements

102
Q

System Design Solution Completion Principle

A

Contractually, a system design solution is not considered complete until it has been formally verified as compliant with its System performance specification (SPS) by the systems acquirer or used acceptance.

103
Q

Engineering Truth Principle

A

If engineering fails to perform its job well, system users (along with personnel, the equipment, the general public, and the environment may be placed at risk)

104
Q

Latent Defects Cost Principle

A

Identify and correct letent defects immediately. Depending on when a latent defect enters the system development phase, the cost-to-correct may increase as much as 100 times by the time system integration, test & Evaluation (SITE) is performed

105
Q

Verification Principle

A

Verification answers the stakeholder and developer’s question: Are we developing a system, entity, or task in compliance with its specified requirements?

106
Q

Validation Principle

A

Validation answers the user’s question: did we acquire the right system/entity/work product to satisfy our operational needs?

107
Q

Lifecycle V&V principle

A

Verification and validation (V&V) are performed continuously and relentlessly throughout every System/product life cycle phase, contract/subcontract, project charter, or task.

108
Q

V&V Applicability Principle

A

Verification and Validation to every stage of system development beginning with the proposal phase and continuing after contract award until system delivery and acceptance completion

109
Q

Defect Elimination Principle

A

The number of latent defects in the fielded system, product, or service is dependent on:
1. a willingness and commitment or provide resources to avoid and eliminate them
2. personnel competency (experience knowledge, training)
3. employment of the right tools, processes, and methods
4. time available to perform the job

110
Q

System Development V&V Strategy Principle

A

A system development V&V strategy requires three elements:
1. A roadmap consisting of incremental V&V activities to progress from contract award to system, product, or service delivery and acceptance
2. A task-based plan of action for implementing the strategy synchronized to milestone-driven event, accomplishments, and criteria.
3. Documented objective evidence of task completion that is, QRs (that demonstrates that you accomplished the planned results)

111
Q

System Verification Principle

A

System verification assesses the compliance of a work product’s attributes, characteristics and performance-based outcomes to one or more contract, project charter, spec, or task requirements.

112
Q

Verification Methods Principle

A

Verification methods consist of inspection, examination, analysis, demonstration, and test or combinations of these

113
Q

Verification Method selection principle

A

Select the least number of verification methods required to prove compliance to a single requirment

114
Q

Compliance Testing Principle

A

Leverage each test to collect as much data that will enable you to verify compliance to the largest number of requirements

115
Q

System Validation Principle

A

System validation assesses a stakeholder’s satisfaction with a work products performance-based outcomes to their documented operational needs and expectations

116
Q

Operational Test and Evaluation Principle

A

OT&E enables users to assess how well a system/product/service satisfies their operational needs based on independent field trials with trained user personnel operating the system in a realistic operating environment

117
Q

Validation Independence Principle

A

To ensure independnece and avoid a conflict of interest, OT&E is typically performed by an ITA with User Personnal the have been trained to operate and maintain the system under actual field operating environment conditions based on scripted scenarios

118
Q

Verified System Modifications Principle

A

Any uncoordinated, unapproved, and inverified modifications to a verified developmental configuration of a physical system without prior authorization during OT&E effectively invalidate the developmental configuration SVR results

119
Q

Problem-solving-solution development Principle

A

A quantum leap from requirements to a point design solution does not reflect problem solving or solution development

120
Q

Decision-Making Stability Principle

A

Mature and stabilize decision-making at higher levels as soon as practical to enable decision-making at each successive lower levels to mature and stabilize

121
Q

Suboptimization Principle

A

Avoid degrading or suboptimizing overall system or entitiy technical cost or risk performance just to optimize a lower level specific aspect.

122
Q

Agile Incremental Product Releases Principle

A

Incrementally develop and deliver just-in-time product releases using short iterative development cycles called ‘Sprints’ based on the value and priority of each to the User

123
Q

User Story Authoring Principle

A

Every User Story should be written by the user in their own words from the perspective of a specific role-based use of a system/product/service

124
Q

USer Story priority Principle

A

Express each user story in terms of the originator’s:
1. Role
2. Need
3. Value
4. Priority to their enterprise or mission

125
Q

User Story composition Principle

A

Each user story consisits of two parts:
1. Statement of Need
2. Conditions of Satisfaction

126
Q

User Story syntax principle

A

Format each user story using an “As a <type>, I want <some> so the <some>" syntax</some></some></type>

127
Q

User Stories Repository

A

Create a product backlog managed by a product owner to serve as the single repository for story and managing all user stories

128
Q

USer Story Scope Princple

A

Scope the selected set of user stories for completion within the time-boxed constrains of a sprint

129
Q

Agile Product Increment Principle

A

Create optional Product increments based on a grouping of user stories that form a planned software “build”

130
Q

Product backlog completion principle

A

Track planned versus actual performance of product backlog user stories in terms of those completed, those in-process, and those remaining to be completed

131
Q

Sprint backlog completion Principle

A

Track planned versus actual performance of sprint backlog user stories to terms of those completed, those in-process, and those remaining to be implemented

132
Q

Daily Scrums Princple

A

conduct brief daily scrums to assess individual or team accountability for three questions:
1. What did you accomplish yesterday
2. What issues need to be addressed today?
3. What do you plan to accomplish today?

133
Q

Incomplete User Stories Principle

A

Return user stories that are incomplete at the end of a tim-boxed sprint to the product increment backlog (optional) or product backlog for reprioritization and reassignment to a subsequent sprint

134
Q

Development process model principle

A

Select a development process model based on requirements, technology, team skills, and schedule risk constraints unique to the product, not the project itself

135
Q

Risk-success expectations principle

A

Adjust project expectations of success based on the level of risk

136
Q

Non-prescriptive methods principle

A

As a process, Agile development does not prescribe a specific development method or model to be used to create a system/product/service

137
Q

Minimal-essential SE documentation Principle

A

Produce only minimal, essential documentation that is necessary and sufficient for the:
1. Developers to specifcy, design, build, integrate, test, train, and maintain the product
2. User’s to operate, maintain, and sustain (where applicable) the system, product, or service to perform missions

138
Q

Project Development Models Principle

A

Select system development process models to uniquely satisfy:
1. system, product, subsystem, assembly, development requirements,
2. technology, risk, team skills, and development constraints

[what is he talking about??]

139
Q
A

MBSE (20 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions