Business Analysis
February 23, 2023 2023-03-26 7:29- Home
- Glossary: Business Analysis
Activity Diagram
A model that illustrates the flow of processes and/or complex use cases by
showing each activity along with information flows and concurrent activities.
Steps can be superimposed onto horizontal swimlanes for the roles that perform
the steps.
Actor(s)
The human and nonhuman roles that interact with the system.
Analyst
A generic name for a role with the responsibilities of developing and managing
requirements. Other names include business analyst, business
integrator,requirements analyst, requirements engineer, and systems analyst.
Assumption
Assumptions are influencing factors that are believed
to be true but have not been confirmed to be accurate.
Baseline
A point-in-time view of requirements that have been reviewed and agreed upon
to serve as a basis for further development.
Black Box Tests
Tests written without regard to how the software is implemented. These tests
show only what the expected
input and outputs will be.
Business Analysis
Business analysis is the set of tasks and techniques used to work as a liaison
among stakeholders in order
to understand the structure, policies and operations
of an organization, and recommend solutions that enable the organization to
achieve its goals.
Business Analysis Communication Plan
A description of the types of communication the business analyst will perform
during business analysis, the recipients of those communications, and the form
in which communication should occur.
Business Analyst
A practitioner of business analysis.
Business Case
An assessment of the costs and benefits associated with a proposed initiative.
Business Domain
See domain.
Business Event
A system trigger that is initiated by humans.
Business Need(s)
A type of high-level business requirement that is a statement of a business
objective, or an impact the solution should have on its environment.
Business Process
A set of defined ad-hoc or sequenced collaborative activities performed in a
repeatable fashion by an organization. Processes are triggered by events and
may have multiple possible outcomes. A successful outcome of a process will
deliver value to one or more stakeholders.
Business Requirements Document
A Business Requirements Document is a requirements
package that describes business requirements
and stakeholder requirements (it documents requirements of interest to the
business, rather than documenting business requirements).
Capability
A function of an organization that enables it to achieve a business goal or objective.
Cause and Effect Diagram
See fishbone diagram.
Change-driven Methodology
A methodology that focuses on rapid delivery of solution
capabilities in an incremental fashion and direct involvement of stakeholders to
gather feedback
on the solution’s performance.
Class
A descriptor for a set of system objects that share the same attributes,
operations, relationships, and behavior. A class represents a concept in the
system under design. When used as an analysis model, a class will generally also
correspond to a real-world entity.
Code
A system of programming statements, symbols, and rules used to represent
instructions to a computer.
Competitive Analysis
A structured process which captures the key characteristics
of an industry to predict the long-term profitability prospects and to determine
the practices
of the most significant competitors.
Context Diagram
An analysis model that illustrates product scope by showing the system in its
environment with the external entities (people and systems) that give to and
receive from the system.
Customer
A stakeholder who uses products or services delivered
by an organization.
Data Entity
A group of related information to be stored by the system. Entities can be
people, roles, places, things, organizations, occurrences in time, concepts, or
documents.
Data Model
An analysis model that depicts the logical structure
of data, independent of the data design or data storage mechanisms.
Decision Tables
An analysis model that specifies complex business rules or logic concisely in an
easy-to-read tabular format, specifying all of the possible conditions and actions
that need to be accounted for in business
rules.
Decomposition
A technique that subdivides a problem into its component parts in order to
facilitate analysis and understanding of those components.
Deliverable
Any unique and verifiable work product or service that a party has agreed to
deliver.
Desired Outcome
The business benefits that will result from meeting
the business need and the end state desired by stakeholders.
Dialog Hierarchy
An analysis model that shows user interface dialogs
Discovery Session
See requirements workshop.
Domain
The problem area undergoing analysis.
Elicitation
An activity within requirements development that identifies sources for
requirements and then uses elicitation techniques (e.g., interviews, prototypes,
facilitated workshops, documentation studies) to gather requirements from those
sources.
End User
A person or system that directly interacts with the solution. End users can be
humans who interface with the system, or systems that send or receive data
files to or from the system.
Enterprise Architecture
Enterprise architecture is a description of an organization’s
business processes, IT software and hardware, people, operations and projects,
and the relationships between them.
Evaluation
The systematic and objective assessment of a solution
to determine its status and efficacy in meeting
objectives over time, and to identify ways to improve the solution to better meet
objectives. See also metric, indicator and monitoring.
Event Response Table
An analysis model in table format that defines the events (i.e., the input stimuli
Exploratory Prototype
A prototype developed to explore or verify requirements.
Feasibility Analysis
See feasibility study.
Feature
A cohesive bundle of externally visible functionality
that should align with business goals and objectives.
Each feature is a logically related grouping of functional requirements or non-
functional requirements
described in broad strokes.
Focus Group
A focus group is a means to elicit ideas and attitudes
about a specific product, service or opportunity
in an interactive group environment. The participants
share their impressions, preferences and needs, guided by a moderator.
Functional Requirement(s)
The product capabilities, or things the product must do for its users.
Glossary
A list and definition of the business terms and concepts relevant to the solution
being built or enhanced.
Horizontal Prototype
A prototype that shows a shallow, and possibly wide, view of the system’s
functionality, but which does not generally support any actual use or interaction.
Implementation Subject Matter Expert (SME)
A stakeholder who will be responsible for designing,
developing, and implementing the change described
in the requirements and have specialized knowledge regarding the construction
of one or more solution components.
Incremental Delivery
Creating working software in multiple releases so the entire product is delivered
in portions over time.
Initiative
Any effort undertaken with a defined goal or objective.
Interface
A shared boundary between any two persons and/or systems through which
information is communicated.
Interview
A systematic approach to elicit information from a person or group of people in
an informal or formal
setting by asking relevant questions and documenting
the responses.
Knowledge Area
A group of related tasks that support a key function
of business analysis.
Metadata
Metadata is information that is used to understand the context and validity of
information recorded in a system.
Metric
A metric is a quantifiable level of an indicator that an organization wants to
accomplish at a specific point in time.
Monitoring
Monitoring is a continuous process of collecting data to determine how well a
solution is implemented
compared to expected results. See also metric and indicator.
Non-functional Requirement(s)
The quality attributes, design and implementation constraints, and external
interfaces that the product
must have.
Object Oriented Modeling
An approach to software engineering where software
is comprised of components that are encapsulated
groups of data and functions which can inherit behavior and attributes from
other components;
and whose components communicate via messages with one another. In some
organizations,
the same approach is used for business engineering
to describe and package the logical components
of the business.
Operational Support
A stakeholder who helps to keep the solution functioning,
either by providing support to end users (trainers, help desk) or by keeping the
solution operational
on a day-to-day basis (network and other tech support).
Opportunity Analysis
The process of examining new business opportunities
to improve organizational performance.
Organization
An autonomous unit within an enterprise under the management of a single
individual or board, with a clearly defined boundary that works towards
common goals and objectives. Organizations
operate on a continuous basis, as opposed to an organizational unit or project
team, which may be disbanded once its objectives are achieved.
Organizational Process Asset
All materials used by groups within an organization
to define, tailor, implement, and maintain their processes.
Organizational Unit
Any recognized association of people in the context
of an organization or enterprise.
Plan-driven Methodology
Any methodology that emphasizes planning and formal documentation of the
processes used to accomplish
a project and of the results of the project. Plan-driven methodologies emphasize
the reduction
of risk and control over outcomes over the rapid delivery of a solution.
Problem Statement
A brief statement or paragraph that describes the problems in the current state
and clarifies what a successful solution will look like.
Process Map
A business model that shows a business process in terms of the steps and input
and output flows across multiple functions, organizations, or job roles.
Product
A solution or component of a solution that is the result of a project.
Product Scope
The features and functions that characterize a product, service or result.
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.
Project Scope
The work that must be performed to deliver a product,
service, or result with the specified features and functions. See also scope.
Quality
The degree to which a set of inherent characteristics
fulfills requirements.
Quality Attributes
The subset of nonfunctional requirements that describes
properties of the software’s operation, development,
and deployment (e.g., performance, security,
usability, portability, and testability).
Regulator
A stakeholder with legal or governance authority over the solution or the process used to develop it.
Relationship Map
A business model that shows the organizational context in terms of the
relationships that exist among the organization, external customers, and
providers.
Request For Information (RFI)
A requirements document issued to solicit vendor input on a proposed process or
product. An RFI is used when the issuing organization seeks to compare different
alternatives or is uncertain regarding the available options
Request For Quote (RFQ)
An informal solicitation of proposals from vendors.
Requirement(s) Attribute
Metadata related to a requirement used to assist with requirements development
and management.
Requirements Allocation
The process of apportioning requirements to subsystems
and components (i.e., people, hardware, and software).
Requirements Document
See requirements package.
Requirements Management
The activities that control requirements development,
including requirements change control, requirements attributes definition, and
requirements traceability.
Requirements Management Tool
A software tool that stores requirements information
in a database, captures requirements attributes
and associations, and facilitates requirements
reporting.
Requirements Package
A requirements package is a set of requirements grouped together in a
document or presentation for communication to stakeholders.
Requirements Risk Mitigation Strategy
An analysis of requirements-related risks that ranks risks and identifies actions
to avoid or minimize
those risks.
Requirements Trace Matrix
A matrix used to track requirements’ relationships. Each column in the matrix
provides requirements information and associated project or software
development
components.
Requirements Validation
The work done to ensure that the stated requirements
support and are aligned with the goals and objectives of the business.
Requirements Workshop
A requirements workshop is a structured meeting in which a carefully selected
group of stakeholders collaborate to define and or refine requirements under the
guidance of a skilled neutral facilitator.
Return on Investment
A measure of the profitability of a project or investment.
Risk Mitigation Strategy
See requirements risk mitigation strategy.
Scenario
An analysis model that describes a series of actions or tasks that respond to an
event. Each scenario is an instance of a use case.
Scope Model
A model that defines the boundaries of a business domain or solution.
Sequence Diagram
A type of diagram that shows objects participating
in interactions and the messages exchanged between them.
Software Engineer
Solution
A solution meets a business need by resolving a problem or allowing an
organization to take advantage
of an opportunity.
Solution Scope
The set of capabilities a solution must deliver in order
to meet the business need. See also scope.
Sponsor
A stakeholder who authorizes or legitimizes the product development effort by
contracting for or paying for the project.
Stakeholder Analysis
The work to identify the stakeholders who may be impacted by a proposed
initiative and assess their interests and likely participation.
Stakeholder Requirement
Stakeholder requirements are statements of the needs of a particular
stakeholder or class of stakeholders.
They describe the needs that a given stakeholder
has and how that stakeholder will interact with a solution. Stakeholder
requirements serve as a bridge between business requirements and the various
State Machine Diagram
See state diagram.
Stated Requirements
A requirement articulated by a stakeholder that has not been analyzed, verified,
or validated. Stated
requirements frequently reflect the desires of a stakeholder rather than the
actual need.
Storyboard
See dialog hierarchy and dialog map.
Subject Matter Expert (SME)
A stakeholder with specific expertise in an aspect of the problem domain or
potential solution alternatives
or components.
Survey
A survey administers a set of written questions to stakeholders in order to collect
responses from a large group in a relatively short period of time.
SWOT Analysis
SWOT is an acronym for Strengths, Weaknesses, Opportunities and Threats. It is
a model used to understand influencing factors and how they may affect an
initiative.
Technical Constraint(s)
Technical constraints are limitations on the design
of a solution that derive from the technology used in its implementation. See
also business constraint.
Temporal Event
A system trigger that is initiated by time.
Throw-away Prototype
A prototype used to quickly uncover and clarify interface requirements using
simple tools, sometimes
just paper and pencil. Usually discarded when the final system has been
developed.
Traceability
See requirements traceability.
Unified Modeling Language (UML)
A non-proprietary modeling and specification language
used to specify, visualize, and document deliverables for object-oriented
software-intensive systems.
Use Case Diagram
A type of diagram defined by UML that captures all actors and use cases involved
with a system or product.
User Acceptance Test
Test cases that users employ to judge whether the delivered system is
acceptable. Each acceptance test describes a set of system inputs and expected
results.
User Requirements Document
A requirements document written for a user audience,
describing user requirements and the impact of the anticipated changes on the
users.
Validated Requirements
Requirements that have been demonstrated to deliver
business value and to support the business goals and objectives.
Variance Analysis
Analysis of discrepancies between planned and actual performance, to determine
the magnitude of those discrepancies and recommend corrective and
preventative action as required.
Verified Requirements
Requirements that have been shown to demonstrate
the characteristics of requirements quality
and as such are cohesive, complete, consistent, correct, feasible, modifiable,
unambiguous, and testable.
Vision Statement (product vision statement)
A brief statement or paragraph that describes the why, what, and who of the
desired software product
from a business point of view.
Work Breakdown Structure (WBS)
A deliverable-oriented hierarchical decomposition of the work to be executed by
the project team to accomplish the project objectives and create the required
deliverables. It organizes and defines the total scope of the project.
Activity
A unit of work performed as part of an initiative or process.
Allocation
See requirements allocation.
Association
A link between two elements or objects in a diagram.
Attribute
A data element with a specified data type that describes
information associated with a concept or entity.
Benchmarking
A comparison of a process or system’s cost, time, quality, or other metrics to
those of leading peer organizations
to identify opportunities for improvement.
Brainstorming
Brainstorming is a team activity that seeks to produce
a broad or diverse set of options through the rapid and uncritical generation of
ideas.
Business Analysis Approach
The set of processes, templates, and activities that will be used to perform
business analysis in a specific context.
Business Analysis Plan
A description of the planned activities that the business analyst will execute in
order to perform the business analysis work involved in a specific initiative.
Business Architecture
A subset of the enterprise architecture that defines an organization’s current and
future state, including its strategy, its goals and objectives, the internal
environment through a process or functional view, the external environment in
which the business operates, and the stakeholders affected by the organization’s
activities.
Business Constraint(s)
Business constraints are limitations placed on the solution design by the
organization that needs the solution. Business constraints describe limitations on
available solutions, or an aspect of the current state that cannot be changed by
the deployment of the new solution. See also technical constraint.
Business Domain Model
A conceptual view of all or part of an enterprise focusing on products,
deliverables and events that are important to the mission of the organization.
The domain model is useful to validate the solution scope with the business and
technical stakeholders.
See also model.
Business Goal
A state or condition the business must satisfy to reach its vision.
Business Policy
A business policy is a non-actionable directive that supports a business goal.
Business Requirement
A higher level business rationale that, when addressed,
will permit the organization to increase revenue, avoid costs, improve service, or
meet regulatory
requirements.
Business Rule(s)
A business rule is a specific, actionable, testable directive that is under the
control of the business and supports a business policy.
Cardinality
The number of occurrences of one entity in a data model that are linked to a
second entity. Cardinality
is shown on a data model with a special notation,
number (e.g., 1), or letter (e.g., M for many).
Change Control Board (CCB)
A small group of stakeholders who will make decisions
regarding the disposition and treatment of changing requirements.
Checklist
A quality control technique. They may include a standard set of quality elements
that reviewers use for requirements verification and requirements validation or
be specifically developed to capture issues of concern to the project.
Class Model
A type of data model that depicts information groups as classes.
Commercial-off-the- Shelf Software (COTS)
Software developed and sold for a particular market.
Constraint
A constraint describes any limitations imposed on the solution that do not
support the business or stakeholder needs.
Cost Benefit Analysis
Analysis done to compare and quantify the financial
and non-financial costs of making a change or implementing a solution compared
to the benefits gained.
Data Dictionary
An analysis model describing the data structures and attributes needed by the
system.
Data Flow Diagram (DFD)
An analysis model that illustrates processes that occur, along with the flows of
data to and from those processes.
Decision Analysis
An approach to decision-making that examines and models the possible
consequences of different decisions. Decision analysis assists in making an
optimal decision under conditions of uncertainty.
Decision Tree
An analysis model that provides a graphical alternative
to decision tables by illustrating conditions and actions in sequence.
Defect
A deficiency in a product or service that reduces its quality or varies from a
desired attribute, state, or functionality. See also requirements defect.
Design Constraints
Software requirements that limit the options available
Developer
Developers are responsible for the construction of software applications. Areas of
expertise include development languages, development practices and application
components.
Dialog Map
An analysis model that illustrates the architecture of the system’s user interface.
Document Analysis
Document analysis is a means to elicit requirements
of an existing system by studying available documentation and identifying
relevant information.
Domain Subject Matter Expert (SME)
A person with specific expertise in an area or domain
under investigation.
Elicitation Workshop
See requirements workshop.
Enterprise
An organizational unit, organization, or collection of organizations that share a
set of common goals and collaborate to provide specific products or services to
customers.
Entity-Relationship Diagram
An entity-relationship diagram is a graphical representation
of the entities relevant to a chosen problem domain, the relationships between
them, and their attributes.
Event
An event is something that occurs to which an organizational
unit, system, or process must respond.
Evolutionary Prototype
A prototype that is continuously modified and updated
in response to feedback from users.
External Interfaces
Interfaces with other systems (hardware, software, and human) that a proposed
system will interact with.
Feasibility Study
An evaluation of proposed alternatives to determine
if they are technically possible within the constraints of the organization and
whether they will deliver the desired benefits to the organization.
Fishbone Diagram
A diagramming technique used in root cause analysis
to identify underlying causes of an observed problem, and the relationships that
exist between those causes.
Force Field Analysis
A graphical method for depicting the forces that support and oppose a change.
Involves identifying
the forces, depicting them on opposite sides of a line (supporting and opposing
forces) and then estimating the strength of each set of forces.
Gap Analysis
A comparison of the current state and desired future
state of an organization in order to identify differences that need to be
addressed.
Goal
See business goal.
Impact Analysis
An impact analysis assesses the effects that a proposed
change will have on a stakeholder or stakeholder
group, project, or system.
Included Use Cases
A use case composed of a common set of steps used by multiple use cases.
Indicator
An indicator identifies a specific numerical measurement
that indicates progress toward achieving
an impact, output, activity or input. See also metric.
Inspection
A formal type of peer review that utilizes a predefined
and documented process, specific participant
roles, and the capture of defect and process metrics. See also structured
walkthrough.
Interoperability
Ability of systems to communicate by exchanging data or services.
Iteration
A process in which a deliverable (or the solution overall) is progressively
elaborated upon. Each iteration
is a self-contained “mini-project” in which a set of activities are undertaken,
resulting in the development of a subset of project deliverables. For each
iteration, the team plans its work, does the work, and checks it for quality and
completeness.
(Iterations can occur within other iterations as well. For example, an iteration of
requirements development would include elicitation, analysis, specification, and
validation activities.)
Lessons Learned Process
A process improvement technique used to learn about and improve on a process
or project. A lessons
learned session involves a special meeting in which the team explores what
worked, what didn’t work, what could be learned from the just-completed
iteration, and how to adapt processes and techniques before continuing or
starting anew.
Methodology
A set of processes, rules, templates, and working methods that prescribe how
business analysis, solution development and implementation is performed
in a particular context.
Model(s)
A representation and simplification of reality developed
to convey information to a specific audience
to support analysis, communication and understanding.
Need(s)
See business need.
Objective
A target or metric that a person or organization seeks to meet in order to
progress towards a goal.
Observation
Observation is a means to elicit requirements by conducting an assessment of
the stakeholder’s work environment.
Operative Rule(s)
The business rules an organization chooses to enforce
as a matter of policy. They are intended to guide the actions of people working
within the business. They may oblige people to take certain actions, prevent
people from taking actions, or prescribe the conditions under which an action
may be taken.
Optionality
Defining whether or not a relationship between entities
in a data model is mandatory. Optionality is shown on a data model with a
special notation.
Organization Modeling
The analysis technique used to describe roles, responsibilities
and reporting structures that exist within an organization.
Organizational Readiness Assessment
An assessment that describes whether stakeholders
are prepared to accept the change associated with a solution and are able to use
it effectively.
Peer Review
A validation technique in which a small group of stakeholders evaluates a portion
of a work product to find errors to improve its quality.
Prioritization
The process of determining the relative importance of a set of items in order to
determine the order in which they will be addressed.
Process
See business process.
Process Model
A visual model or representation of the sequential flow and control logic of a set
of related activities or actions.
Product Backlog
A set of user stories, requirements or features that have been identified as
candidates for potential implementation, prioritized, and estimated.
Project
A temporary endeavor undertaken to create a unique product, service or result.
Project Manager
The stakeholder assigned by the performing organization
to manage the work required to achieve the project objectives.
Prototype
A partial or preliminary version of the system.
Quality Assurance
Activities performed to ensure that a process will deliver products that meet an
appropriate level of quality.
Questionnaire
See survey.
Relationship
A defined association between concepts, classes or entities. Relationships are
usually named and include
the cardinality of the association.
Repository
A real or virtual facility where all information on a specific topic is stored and available for retrieval.
Request For Proposal (RFP)
A requirements document issued when an organization
is seeking a formal proposal from vendors. An RFP typically requires that the
proposals be submitted following a specific process and using sealed bids which
will be evaluated against a formal evaluation methodology.
Requirement
1. stakeholder
to solve a problem or achieve an objective.
A condition or 2. capability that must be met of possessed by a solution or
solution component to satisfy a contract, standard, specification or other formally
imposed documents. A documented representation of a condition or 3. capability as in 1) or 2).
Requirement(s) Defect
An error in requirements caused by incorrect, incomplete,
missing, or conflicting requirements.
Requirements Discovery Session
See requirements workshop.
Requirements Iteration
An iteration that defines requirements for a subset of the solution scope. For
example, an iteration of requirements would include identifying a part of the
overall product scope to focus upon, identifying requirements sources for that
portion of the product, analyzing stakeholders and planning how to elicit
requirements from them, conducting elicitation
techniques, documenting the requirements, and validating the requirements.
Requirements Management Plan
A description of the requirements management process.
Requirements Model
A representation of requirements using text and diagrams. Requirements models
can also be called user requirements models or analysis models and can
supplement textual requirements specifications.
Requirements Quality
See requirements validation and requirements verification.
Requirements Signoff
Formal approval of a set of requirements by a sponsor
or other decision maker.
Requirements Traceability
The ability to identify and document the lineage of each requirement, including
its derivation (backward traceability), its allocation (forward traceability), and its
relationship to other requirements.
Requirements Verification
The work done to evaluate requirements to ensure they are defined correctly
and are at an acceptable level of quality. It ensures the requirements are
sufficiently
defined and structured so that the solution
development team can use them in the design, development and
implementation of the solution.
Retrospective
See lessons learned process.
Risk
An uncertain event or condition that, if it occurs, will affect the goals or
objectives of a proposed change.
Root Cause Analysis
Root cause analysis is a structured examination of an identified problem to
understand the underlying
causes.
Scope
The area covered by a particular activity or topic of interest. See also project
scope and solution scope.
Secondary Actor
An actor who participates in but does not initiate a use case.
Service
Work carried out or on behalf of others.
Software/Systems Requirements Specification
A requirements document written primarily for Implementation SMEs describing
functional and nonfunctional requirements.
Solution Requirement
A characteristic of a solution that meets the business
and stakeholder requirements. May be subdivided
into functional and non-functional requirements.
Span of Control
Span of control is the number of employees a manger
is directly (or indirectly) responsible for.
Stakeholder
A group or person who has interests that may be affected by an initiative or
influence over it.
Stakeholder List, Roles, and Responsibility Designation
A listing of the stakeholders affected by a business need or proposed solution
and a description of their participation in a project or other initiative.
State Diagram
An analysis model showing the life cycle of a data entity or class.
State Transition Diagram
See state diagram.
Structural Rule
Structural rules determine when something is or is not true or when things fall
into a certain category. They describe categorizations that may change over
time.
Structured Walkthrough
A structured walkthrough is an organized peer review of a deliverable with the
objective of finding
errors and omissions. It is considered a form of quality assurance.
Supplier
A stakeholder who provides products or services to an organization.
Swimlane
The horizontal or vertical section of a process model
that show which activities are performed by a particular actor or role.
System
A collection of interrelated elements that interact to achieve an objective.
System elements can include
hardware, software, and people. One system can be a sub-element (or
subsystem) of another system.
Technique
Techniques alter the way a business analysis task is performed or describe a
specific form the output of a task may take.
Tester
A stakeholder responsible for assessing the quality of, and identifying defects in,
a software application.
Timebox
A fixed period of time to accomplish a desired outcome.
Transition Requirement(s)
A classification of requirements that describe capabilities
that the solution must have in order to facilitate transition from the current state
of the enterprise to the desired future state, but that will not be needed once
that transition is complete.
Use Case
An analysis model that describes the tasks that the system will perform for
actors and the goals that the system achieves for those actors along the way.
User
A stakeholder, person, device, or system that directly
or indirectly accesses a system.
User Requirement
See stakeholder requirement(s).
User Story
A high-level, informal, short description of a solution
capability that provides value to a stakeholder. A user story is typically one or
two sentences long and provides the minimum information necessary to allow a
developer to estimate the work required to implement it.
Validation
The process of checking a product to ensure that it satisfies its intended use and
conforms to its requirements.
Validation ensures that you built the correct solution. Also see requirements
validation.
Verification
The process of checking that a deliverable produced
at a given stage of development satisfies the conditions or specifications of the
previous stage. Verification ensures that you built the solution correctly. Also see
requirements verification.
Vertical Prototype
A prototype that dives into the details of the interface,
functionality, or both.
Walkthrough
A type of peer review in which participants present,
discuss, and step through a work product to find errors. Walkthroughs of
requirements documentation
are used to verify the correctness of requirements.
See also structured walkthrough.
Work Product
A document or collection of notes or diagrams used by the business analyst
during the requirements
development process.
