Acceptance: An activity to ensure whether the system meets all the requirements.
Acceptance test: A test that measure whether the system meets all the requirements.
Activity: A unit of work performed.
Activity diagram: A type of UML diagram that depicts the flow of actions in a system.
Actor: The people and systems in the context of a proposed system.
Adequacy: The extent to which the requirement satisfies the stakeholder needs.
Allocation: The process of assigning requirements to solution components.
Application domain: The context of a proposed system.
Artifact: The documents and reports generated in business analysis projects.
Association: A link between two elements in a diagram.
Assumption: Things that are believed to be true, but yet to be confirmed.
Attribute: A characteristic property of something.
Baseline: A stable set of requirements.
Behavior model: A model helps to explain the behavior of a proposed system.
Benchmarking: A process improvement methodology.
Black box tests: Tests carried out to demonstrate the correctness of inputs and outputs.
Brainstorming: A technique to generate creative ideas.
Bug: A defect in a software.
Business case: A document details the cost vs. benefit analysis of a proposed project.
Business constraint: The limits of a solution.
Business goal: A road map to the vision.
Business need: A higher order requirement that defines what the business wants.
Business process: Explains how value is generated in an organization.
Business requirements document: BRD is composed of the business and stakeholder requirements.
Business rule: Defines how certain decisions need to be made at micro level of organizations.
Capability: An ability to do certain things.
Cardinality: The minimum and maximum number of objects in a relationship.
Cause and effect diagram: Technique used to unravel the underlying root causes.
Change control board (CCB): A team that decides about the change requests.
Change request: A request to change a requirement after baselining.
Change-driven methodology: Iterative and incremental software development.
Checklist: A pre-printed list that ensures all the aspects that need to be reviewed.
Class: A common name for a group of objects.
Class diagram: A representation of class model.
Commercial-off-the-shelf software (COTS): A readily available software in the market.
Competitive analysis: A technique to understand the competitors.
Completeness: A quality attribute whether the requirement contains all the necessary information.
Component: An identifiable part of the system.
Configuration: A set of components that works together in a seamless manner.
Conformity: The extent to which the requirements meet the standards.
Consistency: Harmony between different requirements.
Context: The relevant part of the proposed system's environment.
Context diagram: A diagram that shows the system's environment.
Context boundary: The line that separate the relevant and irrelevant part of the environment.
Correctness: The extent to which the information in a requirement is demonstrable.
Cost benefit analysis: An analysis to compare the cost with the benefits of implementing something.
Data dictionary: A diagram depicting the data structure of a proposed system.
Data entity: People, place and things.
Data flow diagram (DFD): Shows how input data is processed and output is generated.
Data model: Depicts the logical model of the data.
Decision analysis: A technique that aids in decision making.
Decomposition: Breaking a complex problem into smaller units.
Defect: Things that are preventing the delivery of requirements.
Deliverable: A contractually agreed output.
Desired outcome: The accrued benefits of a system.
Document analysis: Generating the requirements by going through the existing documents in the organization.
Domain subject matter expert (SME): A person who is knowledgeable of the areas where we are performing business analysis.
Effectiveness: Doing things the best possible way.
Efficiency: Accomplishing something with minimal resources.
Elicitation: Pulling out the requirements from stakeholders, systems and documents.
Elicitation workshop: Gathering requirements from group of stakeholders.
End user: The person who will be using the system.
Enterprise: A organization.
Enterprise architecture: How process, systems and people are working together to perform certain operations in the organization.
Entity-relationship diagram: A graphical representation of the relationship between various entities of a system.
Event: Something that happens in or outside the system.
Evolutionary prototype: A prototype that ultimately becomes the final product.
Exploratory prototype: A prototype that is used to verify the requirements.
External interfaces: Interface with other systems.
Fault tolerance: The ability of a system to continue to deliver requirements in spite of issues.
Feasibility analysis: To assess the viability of a given solution.
Feature: A characteristic of a system that is wanted..
Focus group: A group is interviewed to define a product requirement.
Force field analysis: A technique that identifies the forces that oppose and support a proposed solution or implementation.
Functional requirement: The behavioral capabilities that are expected out of a system.
Functionality: The capabilities of a system.
Gap analysis: What is missing between your current state and future state.
Glossary: A definition of business terms, concepts and data.
Goal model: A decomposition of a complex goal into sub goals.
Homonym: An identical term which has different meanings based on the context.
Horizontal prototype: Gives a border idea about the system, but doesn't get into details.
Impact analysis: Carried out to understand the effort required to implement change requests.
Incremental delivery: A product gets better and better in each implementation.
Indicator: An attribute measured to know the progress or performance.
Inspection: A technique where the business analysis artifacts are peer reviewed to validate the documents.
Interface: A boundary between two systems through which they communicate with each other.
Interoperability: Capability of two systems to communicate with each other by exchanging data or services.
Interview: Business analyst meets the stakeholders in-person and collects the requirements through questioning.
Iteration: It is an implementation cycle, where business analysis, system design and project implementation is done for a prioritized features. This cycle is repeated multiple times until the stakeholders get the perfect system.
Knowledge area: A group of interrelated tasks make a knowledge area.
Lessons learned process: The successes and failures of the past projects are great sources of information to learn. These are documented and stored and referred when similar situation occurs.
Maintainability: The ease of changing a feature, requirement or correcting a defect in a software.
Metadata: It is data about data. Certain attributes of requirements are stored to give a better understanding to the reader.
Model: A text based or graphical representation of an existing or proposed system.
Modeling language: A symbol based language to make models.
Non-functional requirement: The expected quality attributes of the proposed system such as usability, performance, security etc.
Observation: Gathering requirements by watching the way a work is performed by the stakeholder.
Organization modeling: A graphical model that depicts the structure, reporting relationship, roles and responsibilities of an organization.
Organizational process asset: All documents that supports the performance of the process improvement, business analysis and projects in an organization.
Organizational readiness assessment: An assessment of the preparedness of the organization to accept the proposed change.
Peer review: A technique used to validate the quality aspects of a document.
Plan-driven methodology: Also known as waterfall methodology. The business analysis, system design and project implementation are sequentially carried out in one go.
Prioritization: Arranging or selecting the requirements on the basis of their importance or business value.
Problem statement: A document that explains the current state, identifies the problems, defines the future state and identifies the solution that could solve the problem and take the organization to the future state.
Process map: A graphical model of the activities performed in a business process.
Product: The result of implementing a solution during a project.
Product backlog: The list of stakeholder needs and requirements that are in a parking lot and waiting for consideration in future releases.
Product scope: The expected behavior of the proposed product.
Project: A one time initiative that aims at creating a product, process, system, application or software.
Project charter: A formal document that notifies the commencement of the project to all the stakeholders. This authorizes the sponsor and project manager with the necessary resources.
Prototype: A partially working model of the proposed system.
Quality assurance: The system instilled in place to ensure that the products or services developed meets the established quality standards.
Questionnaire: A set of pre-written questions that helps to elicit the requirements.
Redundancy: An unnecessary repeat of certain information or data in a document.
Regulator: An authorised body at international or national or local level entrusted to monitor the performance of an industry.
Repository: A physical or virtual place where documents or information is stored.
Release: A set of requirements with appropriate versions.
Reliability: The ability of a system to deliver performance at consistent level.
Request for information (RFI): A document requesting the vendors to explain how their solution will solve a given problem.
Request for proposal (RFP): A document requesting a formal proposal from a vendor for a given solution.
Request for quote (RFQ): A document requesting quote from vendors for a given product.
Requirement: A condition or capability needed by a user to solve a problem or achieve an objective.
Requirements management: Activities such as requirements storage/maintenance, assigning attributes, change management and traceability.
Requirements management tool: A software tool that automates and organizes the requirements management.
Requirements traceability: The upstream and downstream connection between the requirements and other artifacts.
Requirements validation: This is to ensure that the baselined requirements are in line with the goals and objectives of the organization.
Requirements verification: This is to ensure the quality characteristics of the requirements are satisfied.
Requirements analysis: A knowledge area where the requirements are prioritized, organized, modeled, verified and validated.
Requirements document: A document contains the requirements specifications.
Requirements source: Requirements are derived from stakeholders, existing systems, documents, standards and others. These are called requirements source.
Requirements specification: A set of requirements about a proposed system.
Return on investment: The degree of profitability of a venture.
Risk: An uncertain event or condition that, if it occurs, will affect the goals or objectives of a proposed change.
Safety: The ability of the system to protect itself and the people and system in the surroundings.
Scenario: One particular instance of a use case or a test case.
Security: The ability of the system to protects its resources from unauthorized use.
Sequence diagram: An UML diagram that depicts the interactions between objects and actors.
Solution: It is a prescription to a problem or need or opportunity.
Solution requirement: Functional and non-functional requirements that can deliver the business and stakeholder requirements.
Solution scope: The abilities that a solution should possess.
Sponsor: A stakeholder who has the highest interest / benefit from the project and who pays for the project.
Stakeholder: Set of people who are either impacted by the project or impacting the project.
State diagram: A model indicates the various states in which a system can exist.
Stated requirement: The requirements that were told by the stakeholders.
Structured walkthrough: A technique used to present the requirements and to get buy-in from the stakeholders.
Techniques: Techniques alter the way a business analysis task is performed or describe a specific form the output of a task may take.