Glossary 2 Flashcards
(179 cards)
1
Q
Evaluation
A
See solution evaluation
2
Q
Expert Judgment
A
Judgment provided based upon expertise in an application area, Knowledge Area, discipline, industry, etc. , as appropriate for the activity being performed . Such expertise may be provided by any group or person with specialized education, knowledge, skill, experience, or training.
3
Q
Exploratory Testing
A
An unscripted, free-form validation or evaluation activity conducted by someone with in-depth business or testing knowledge to validate the product and discover product errors.
4
Q
Facilitated Workshops
A
An elicitation technique using focused sessions that bring key cross-functional stakeholders together to define product requirements. In business analysis, facilitated workshops use a structured meeting that is led by a skilled, neutral facilitator, in which a carefully selected group of stakeholders collaborate to explore and evaluate product requirements.
5
Q
Feasibility Analysis
A
A study that produces a potential recommendation to address business needs. It examines feasibility using one or more of the following variables: operational, technology/system, cost-effectiveness, and timeliness of the potential solution.
6
Q
Feature
A
A set of related requirements typically described as a short phrase
7
Q
Feature Model
A
A business analysis model that shows the first, second, and third level of features involved in a project
8
Q
Fishbone Diagram
A
A version of a cause-and-effect diagram that depicts a problem and its root causes in a visual manner. It uses a fish image, listing the problem at the head, with causes and subcauses of the problem represented as bones of the fish. See also cause-and-effect diagram.
9
Q
Five Whys
A
A technique for conducting root cause analysis suggesting anyone trying to understand a problem needs to ask why it is occurring up to five times to thoroughly understand its causes
10
Q
Focus Groups
A
An elicitation technique that brings together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result
11
Q
Functional Requirements
A
Requirements that describe the behaviors of a product
12
Q
Gap Analysis
A
A technique for understanding the gap between current capabilities and needed capabilities. Filling the gap is what comprises a solution recommendation
13
Q
Grooming the Backlog
A
A process used on agile projects where the product team works with the product owner to gain more depth about the user stories in the backlog list. A groomed backlog is an input for sprint planning meetings, which are used to determine which user stories to cover in the next iteration.
14
Q
Happy Path
A
See normal flow
15
Q
High-Fidelity Prototyping
A
A method of prototyping that creates a functioning representation of the final finished product to the user. High-fidelity prototyping is performed using a programming language or a pseudo language of the product to be demonstrated.
16
Q
Impact Analysis
A
A technique for evaluating a change in relation to how it will affect other requirements, the product, the program, and the project
17
Q
Iterative Life Cycle
A
A project life cycle where iterations develop the product through a series of repeated cycles, while increments successively add to the functionality of the product
18
Q
Interrelationship Diagram
A
A special type of cause-and-effect diagram that depicts related causes and effects for a given situation. Interrelationship diagrams help to uncover the most significant causes and effects involved in a situation. See also cause-and-effect diagram.
19
Q
Internal Rate of Return (IRR)
A
The projected annual yield of a project investment, incorporating both initial and ongoing costs into an estimated percentage growth rate a given project is expected to have
20
Q
Interviews
A
A formal or informal approach to elicit information from a group of stakeholders by asking questions and documenting the responses provided by the interviewees
21
Q
Ishikawa Diagrams
A
See fishbone diagram and cause-and-effect diagram
22
Q
Issue
A
A point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements
23
Q
Iterative Life Cycle
A
A project life cycle where the project scope is generally determined early in the project life cycle, but time and cost estimates are routinely modified as the project team’s understanding of the product increases. Iterations develop the product through a series of repeated cycles, while increments successively add to the functionality of the product.
24
Q
Job Analysis
A
A technique used to identify job requirements and the competencies needed to perform effectively in a specific job
25
Kanban
An adaptive life cycle in which project work items are pulled from a backlog and started when other project work items are completed. Kanban also establishes work-in-progress limits to constrain the number of work items that can be in-progress at any point in time.
26
Kanban Board
A tool used within the continuous improvement method of Kanban to visually depict workflow and capacity and assist team members in seeing the work that is planned, in process or completed. The Kanban board is a variation of the original Kanban cards.
27
Key Performance Indicator (KPI)
Metrics usually defined by an organization's executives that are used to evaluate an organization's progress toward meeting its objectives or goals
28
Key Stakeholders
A stakeholder who is identified as having a significant stake in the project or program and who holds key responsibilities such as approving requirements or approving changes to product scope.
29
Lessons Learned
The knowledge gained during a project, which shows how project events were addressed or should be addressed in the future for the purpose of improving future performance.
30
Low-Fidelity Prototype
A method of prototyping that provides fixed sketches, diagrams, and notes to provide a visual representation of what a screen will look like. Static prototypes do not demonstrate the operation of the system to the user.
31
Measure
The quantity of some element at a point in time or during a specific time duration, such as the number of work months spent on a project during a specific time period, the number of defects uncovered, or the number of customers responding to a survey stating that they were extremely satisfied.
32
Metric
A set of quantifiable measures used to evaluate a solution or business.
33
Model
A visual representation of information, both abstract and specific, which operates under a set of guidelines in order to arrange and convey a lot of information in an efficient manner.
34
Modeling Language
A set of models and their syntax. Examples include Requirements Modeling Language (RML), Unified Modeling Language (UML), Business Process Modeling Notation (BPMN), and System Modeling Language (SysML). It is important is to use consistent syntax each time a similar model is used so as not confuse stakeholders.
35
Monitoring
The process of collecting project performance data, producing performance measures, and reporting and disseminating performance information
36
MoSCoW
A technique used for establishing requirement priorities In this technique, the participants divide the requirements into four categories of must haves, should haves, could haves, and won't haves.
37
Multivoting Process
A technique used to facilitate decision making among a group of stakeholders. Participants are provided with a limited number of votes and are asked to apply those votes to a list of possible options. The option with the most votes is determined to be the most favorable option. Multivoting processes can be used to prioritize requirements, determine the most favorable solution, or to identify the most favorable response to a problem.
38
Narrative
A story. In business analysis, narratives are written when developing personas.
39
Needs Assessment
The domain of business analysis concerned with understanding business goals and objectives, issues, and opportunities, and recommending proposals to address them
40
Negotiation
The process and activities used to resolve disputes through consultations between involved parties
41
Net Present Value (NPV)
The future value of expected project benefits expressed in the value those benefits have at the time of investment. NPV takes into account current and future costs and benefits, inflation, and the yield that could be obtained through investing in financial instruments as opposed to a project or program.
42
Nonfunctional Requirements
Requirements that express properties that the product is required to have, including interface, environment, and quality attribute properties
43
Normal Flow
Within the context of use case analysis, the normal flow is the set of steps that are followed through the use case scenario when everything goes as planned or expected
44
Objective
Something toward which work is to be directed, a strategic position to be attained, a purpose to be achieved, a result to be obtained, a product to be produced, or a service to be performed. In business analysis, objectives are quantifiable outcomes that are desired from a product, result, or service.
45
Observation
An elicitation technique that provides a direct way of obtaining information about how a process is performed or a product is used by viewing individuals in their own environment performing their jobs or tasks and carrying out processes
46
Open-Ended Question
A question that allows the responder to answer in any way desired
47
Operational Feasibility
The extent to which a proposed solution meets operational needs and requirements related to a specific situation. It also includes factors such as sustainability, maintainability, supportability, and reliability.
48
Opportunity
A risk that would have a positive effect on one or more project objectives
49
Opportunity Analysis
A study of the major facets of a potential opportunity to determine the viability of successfully launching a new product or service
50
Opportunity Cost
The loss of value that could be realized in other actions or alternatives, if the current action is pursued
51
Organizational Modeling
A type of modeling that visually depicts the organizational structure and elements of an organization
52
Organizational Chart
A model that depicts the reporting structure within an organization or within a part of an organization. In business analysis, organizational charts can be used to help identify stakeholders who are involved in a project and to understand the reporting structures that exist among those identified
53
Organizational Goals
Broad-based translations of corporate goals into expressions that are actionable and measurable. Goals are typically longer in scope than objectives.
54
Organizational Objectives
Accomplishments that an organization wants to achieve to help enable goals. These are specific and tend to be of shorter duration than goals, often one year or less.
55
Pair-Matching
A step performed when constructing a weighted ranking matrix. It involves taking each option under analysis and comparing it one by one to all the other options listed.
56
Participant
One who participates in a group activity, such as focus groups or facilitated workshops
57
Payback Period (PBP)
The time needed to recover a project investment, usually in months or years
58
Persona
An archetype user representing a set of similar end users described with their goals, motivations, and representative personal characteristics
59
Policy
A structured pattern of actions adopted by an organization such that the organization's policy can be explained as a set of basic principles that govern the organization's conduct
60
Phase
See project phase
61
Predictive Life Cycle
A form of project life cycle in which the project scope, and the time and cost required to deliver that scope, are determined as early in the life cycle as possible
62
Problem
An internal or external environment of an organization that is causing detriment to the organization, for example, lost revenue, dissatisfied customers, delays in launching new products, or noncompliance with government regulations
63
Problem Domain
The area or context surrounding the problem that is currently under analysis
64
Procedure
An established method of accomplishing a consistent performance or result. A procedure typically can be described as the sequence of steps that will be used to execute a process.
65
Process
A systematic series of activities directed towards causing an end result such that one or more inputs will be acted upon to create one or more outputs
66
Process Flow
A business analysis model that visually shows the steps taken in a process by a human user as it interacts with an implementation. A set of steps taken by a system can be shown in a similar model, a system flow.
67
Process Worker
The stakeholder who physically works with or within the business process that is under analysis or the user who works specifically with a system that is part of the business process. Not all process workers are users.
68
Product
An artifact that is produced, is quantifiable, and can be either an end item in itself or a component item. Products are also referred to as materials or goods. See also deliverable
69
Product Backlog
See backlog
70
Product Scope
The features and functions that characterize a product, service, or result
71
Product Stakeholder
A business stakeholder affected by a problem or opportunity, or impacted by or interested in the solution
72
Program
A group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually
73
Project
A temporary endeavor undertaken to create a unique product, service, or result
74
Project Charter
A document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities
75
Project Life Cycle
The series of phases that a project passes through from its initiation to its closure
76
Project Management Plan
The document that describes how the project will be executed, monitored, and controlled
77
Project Manager
The person assigned by the performing organization to lead the team that is responsible for achieving the project objectives
78
Project Phase
A collection of logically related project activities that culminates in the completion of one or more deliverables
79
Project Schedule
An output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources
80
Project Scope
The work performed to deliver a product, service, or result with the specified features and functions
81
Project Stakeholder Management
Includes the processes required to identify all people or organizations impacted by a project, analyzing stakeholder expectations and impact on the project, and developing appropriate management strategies for effectively engaging stakeholders in project decisions and execution
82
Project Team
A set of individuals who support the project manager in performing the work of the project to achieve its objectives
83
Prototypes
A method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it
84
Questionnaire and Survey
A written set of questions designed to quickly accumulate information from a large number of respondents
85
RACI Model
A common type of responsibility assignment matrix that uses responsible, accountable, consult, and inform statuses to define the involvement of stakeholders in project activities
86
Regulation
A requirement imposed by a governmental body. These requirements can establish product, process, or service characteristics, including applicable administrative provisions that have government-mandated compliance.
87
Report Table
A business analysis model that documents in a tabular format all of the requirements necessary to develop a single report
88
Requirement
A condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification
89
Requirements Attribute
A property of a requirement used to store descriptive information about the requirement, such as last change date, author, source, etc
90
Requirements Change Process
The process that defines how changes to requirements will be handled across the project
91
Requirements Documentation
A description of how individual requirements meet the business need for the project
92
Requirements Analysis
The process of examining, breaking down, and synthesizing information to further understand it, complete it, and improve it
93
Requirements Elicitation
The activity of drawing out information from stakeholders and other sources for the purpose of further understanding the needs of the business, to address a problem or opportunity and the stakeholder's preferences and conditions for the solution that will address those needs
94
Requirements Elicitation and Analysis
The domain of business analysis concerned with the iterative work to plan, prepare, and conduct the elicitation of information from stakeholders and to analyze, model, and document the results of that work with the objective of defining a set of requirements in sufficient detail to enable the purchase or build of the preferred solution or refinement of processes to achieve the business objective
95
Requirements Life Cycle
The flow or life of a requirement throughout a project or program. The requirements life cycle is managed by assigning an attribute or qualifier onto the requirement to depict the requirement state at a specified point in time.
96
Requirements Management Plan
A component of the project or program management plan that describes how requirements will be analyzed, documented, and managed. See also business analysis plan.
97
Requirement State
An attribute of a requirement that identifies where the requirement falls within the requirements life cycle, for example, in-process, approved, deferred, or rejected
98
Requirements Traceability Matrix
A grid that links product requirements from their origin to the deliverables that satisfy them
99
Requirements Validation
The process of ensuring that the product satisfies its intended use and anticipated value, ensuring the correct product is delivered
100
Requirements Verification
The process of reviewing requirements and models to ensure they meet quality standards. Verification is performed to ensure that requirements are constructed properly and that models conform to the proper use of modeling notation.
101
Responder
Any participant or person from whom information is gathered by means of elicitation
102
Retrospective
A type of meeting in which participants explore their work and outcomes in order to improve both process and product. Retrospectives can occur on a regular basis (e.g., end of iteration or release), at the completion of a milestone, or after a special event (e.g., organizational change, accident)
103
Return on Investment (ROI)
The percent return on an initial project or program investment, calculated by taking the projected average of all net benefits and dividing them by the initial cost
104
Risk
An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives
105
Risk Analysis
The process of examining a program, project, or process for risk
106
Risk Tolerance
The degree, amount, or volume of risk that an organization or individual will withstand
107
Role
A defined function to be performed by a project team member, such as testing, filing, inspecting, or coding
108
Rolling Wave Planning
An iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level
109
Root Cause Analysis
An analytical technique used to determine the basic underlying reason that causes a variance or a defect or a risk. A root cause may underlie more than one variance or defect or risk.
110
Scenario
A case of usage of a solution often manifested as a concrete example of a use case or user story or several functional requirements specified in the sequence in which they occur. Any single pass through a system to achieve a goal for the primary actor.
111
Schedule
See project schedule
112
Scope
The sum of the products, services, and results to be provided as a project. In business analysis, scope is defined as the boundary for the products, services, or results. See also project scope and product scope.
113
Scope Baseline
The approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedures and is used as a basis for comparison
114
Scope Creep
The uncontrolled expansion to a product or project scope without adjustments to time, cost, and resources
115
Scope Model
A type of model that identifies the boundaries of the project, program, product, and/or system under analysis. A context diagram is one example of a scope model. Other scope models:
■ Goal and business objectives model
■ Ecosystem map
■ Context diagram
■ Feature model
■ Organizational chart (described in Business Analysis Planning)
■ Use case diagram
■ Decomposition model (described in Business Analysis Planning)
■ Fishbone diagram (described in Needs Assessment)
■ Interrelationship diagram (described in Needs Assessment)
■ SWOT diagram (described in Needs Assessment)
116
Scrum
A type of adaptive life cycle where a product is built in small incremental portions and each cycle of development builds upon the last version of the product
117
Situation
A condition which may be an internal problem or external opportunity that forms the basis of a business need and might result in a project or program to address the condition
118
Situation Statement
An objective statement of a problem or opportunity that includes the statement itself, the situation's effect on the organization, and the ultimate impact
119
SMART Goals
Goals that are well-written to meet the quality criteria of being specific, measurable, achievable, relevant, and time-bounded
120
Software Requirements Specification
A type of requirements documentation that includes the functional and nonfunctional requirements of a software system
121
Solution Evaluation
The domain of business analysis concerned with the activities to validate a solution that is about to be or that has already been implemented
122
Solution Requirement
A requirement that describes the features, functions, and characteristics of a product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements.
123
Sponsor
A person or group who provides resources and support for the project, program, or portfolio and is accountable for enabling success
124
Stakeholder
An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio
125
Stakeholder Analysis
A technique of systematically gathering and analyzing quantitative and qualitative information to determine whose interests should be taken into account throughout the project
126
Stakeholder Characteristics
The qualities and attributes of a stakeholder, which together determine aspects of how the stakeholder behaves
127
Stakeholder Identification
The process of determining the stakeholders impacted by a business problem or opportunity
128
Stakeholder Groups
A collection of stakeholders who have similar likes, interests, and stakeholder characteristics. Stakeholder groups are used by project managers and business analysts to manage large groups of stakeholders.
129
Stakeholder Map
A technique used to visually analyze stakeholders and their relationship to each other and to the problem or opportunity under analysis
130
Stakeholder Register
A project document including the identification, assessment, and classification of project stakeholders
131
Stakeholder Requirement
A requirement that describes the need of a stakeholder or stakeholder group
132
State Diagram
A business analysis model that visually shows how an object moves between different states. This model helps to show the life cycle of an object in a solution
133
State Table
A business analysis model that shows all of the possible states of an object and all of the valid transitions. This model helps to enumerate all possible states and possible transitions.
134
Subject Matter Expert (SME)
A person who is considered an expert in a particular subject area. In business analysis, SMEs are often involved in providing the requirements for their area of expertise.
135
Surveys
See questionnaires and surveys
136
SWOT Analysis
Analysis of strengths, weaknesses, opportunities, and threats of an organization, project, or option
137
Synchronous Interview
An interview conducted where the interviewer and interviewee are involved in the interview at the same time. Synchronous meetings can occur face to face, over the phone, or through web conferencing, etc. ; the two parties are not required to be in person with one another, but both need to be active in the interview at the same time
138
System Feasibility
See technology feasibility
139
System Interface Table
A business analysis model that documents the requirements for the connections between each interfacing system involved in a project, including how they are connected and what information flows between them
140
Technique
A defined systematic procedure employed by a human resource to perform an activity that produces a product or result or delivers a service, and that may employ one or more tools
141
Technology Feasibility
An analysis to determine the extent to which a technology exists in an organization to support a potential solution and if not present, how feasible it would be to acquire and operate the needed technology
142
Templates
A partially completed document in a predefined format that provides a defined structure for collecting, organizing, and presenting information and data
143
Threat
A risk that would have a negative effect on one or more project objectives
144
Time Feasibility
An analysis to determine how well a proposed solution can be delivered to meet the organization's needed time frame
145
To-Be Process
A proposed revision to an existing process that can provide an improvement for an organization over how activities are currently performed, or a revision to a new process when adding products or services
146
Traceability
Traceability provides the ability to track product requirements from their origin to the deliverables that satisfy them
147
Traceability and Monitoring
The domain of business analysis concerned with building and maintaining the traceability matrix to manage requirements and product scope, baselining the product requirements, assessing impacts of proposed requirement changes, and managing the required updates to the requirements and other business analysis deliverables once proposed changes are approved
148
Traceability Matrix
See requirements traceability matrix
149
Transition Requirements
Requirements that are the temporary capabilities, such as data conversion and training requirements, needed to transition from the current as-is state to the future state
150
Use Case
An analysis model that describes a flow of actor-system interactions and boundaries for those interactions, including trigger, initiating and participating actors, and preconditions and post conditions
151
Use Case Diagram
A business analysis model that shows all of the in-scope use cases for a project and which actors have a part in those use cases
152
User Class
A group of stakeholders who are users of a software system, product, or service and are grouped together due to the similarity in their requirements and use of the product
153
User Experience Analyst
Also referred to as user interface analysts; individuals who are responsible for studying user behavior, preferences, and constraints in order to identify user interface and usability requirements for software applications and other products
154
User Interface Flow
A business analysis model that shows the specific pages or screens of an application and how a user can navigate between them
155
User Story
A one or two sentence description, written from the viewpoint of the actor, describing what function is needed. A user story usually takes the form of
"As an (Actor), I want to be able to (Function), so that I can (Business Need).
156
Validation
The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification.
157
Verification
The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation.
158
Velocity
A measure of a team's productivity rate at which the deliverables are produced, validated, and accepted within a predefined interval. Velocity is a capacity planning approach frequently used to forecast future project work.
159
Version Control
The process of maintaining a history of changes on software or documentation
160
Version Control System (VCS)
A system that is used to track the history of revisions, often but not always related to software
161
Weighted Criteria
A technique used to help support objective decision making. It uses a weighted ranking matrix to compare alternatives and their weighted scores in order to evaluate decision options. See also weighted ranking matrix.
162
Weighted Ranking Matrix
A table used in decision making that combines pair matching of all alternatives with weighted criteria to add objectivity when formulating a decision or recommendation. Each alternative is compared with every other alternative on the basis of weighted criteria, and the resulting scores are added together to determine the preferred choice.
163
Work Breakdown Structure (WBS)
A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.
164
Work Product
An output produced as a result of some completion of work that is required for a short-term purpose and not required to be monitored and maintained on an ongoing basis
165
Likert Technique
Used mainly in training course evaluations and market surveys, Likert scales usually have five potential choices (strongly agree, agree, neutral, disagree, strongly disagree) but sometimes go up to ten or more. The final average score represents overall level of accomplishment or attitude toward the subject matter. Named after its inventor, the US organizational-behavior psychologist Dr. Rensis Likert (1903-81).
A psychometric response scale primarily used in questionnaires to obtain participant’s preferences or degree of agreement with a statement or set of statements. Likert scales are a non‐comparative scaling technique and are unidimensional (only measure a single trait) in nature. Respondents are asked to indicate their level of agreement with a given statement by way of an ordinal scale.
166
Types of observation
- passive
- active
- participatory
- simulation
167
Process models
Models that describe business processes and ways in which stakeholders interact with those processes. Examples:
■ Process flow
■ Use case
■ User story
168
Rule models
Models of concepts and behaviors that define or constrain aspects of a business in order to enforce established business policies
■ Business rules catalog
■ Decision tree
■ Decision table
169
Data models
```
Models that document the data used in a process or system and its life cycle. Examples:
■ Entity relationship diagram
■ Data flow diagram
■ Data dictionary
■ State table
■ State diagram
```
170
Interface models
```
Models that assist in understanding specific systems and their relationships within a solution
■ Report table
■ System interface table
■ User interface flow
■ Wireframes
■ Display-action-response
```
171
INVEST
Elements of the INVEST acronym can be applied to all requirements, regardless of the format, to ensure quality of the user stories:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
172
Principles of human-machine interface
- Compatibility
- Consistency
- Memory
- Structure
- Feedback
- Workload
- Individualization
173
Well-formatted Requirement
A well-formatted requirement consists of the following elements:
• Condition,
• Imperative,
• Active verb,
• Object,
• Business rule (optional), and
• Outcome (optional).
Example:
When the new account button is pressed (Condition), the system (Subject) will (Imperative) display (Active verb) the new account entry
screen (Object) allowing the creation of a new account (Outcome).
174
Characteristics of quality requirements
- Unambiguous
- Precise
- Consistent
- Correct
- Complete
- Measurable
- Feasible
- Traceable
- Testable
175
Correctness of the requirements
Is a purview of the business community. Correctness is established
through frequent review and confirmation sessions with the sources of information.
176
Kano Analysis
A technique for understanding which product features will help drive customer satisfaction.
The Kano Model of Customer satisfaction divides product attributes into three categories: threshold, performance, and excitement.
Kano model is best used for prioritizing stakeholder requirements.
177
Lineage
Backward traceability is also referred to as derivation or lineage.
178
Modeling concepts
Modeling concepts such as data, events, processes, rules and parties help BA to figure out how to better organize requirements.
179
Value engineering
Finding a less costly way to work.
