s
| Term | Description |
|---|---|
| scope | The boundaries of control, change, a solution, or a need. |
| scope model | A model that defines the boundaries of a business domain or solution. |
| secondary actor | An actor external to the system under design that supports the execution of a use case. |
| sequence diagram | A type of diagram that shows objects participating in interactions and the messages exchanged between them. |
| service (business analysis) | The performance of any duties or work for a stakeholder, from the perspective of the stakeholder. |
| SIPOC | See suppliers, inputs, process, outputs and customers |
| SME | See subject matter expert. |
| software engineer | See developer. |
| solution | A specific way of satisfying one or more needs in a context. |
| solution component | A sub-part of a solution that can be people, infrastructure, hardware, software, equipment, facilities, and process assets or any combination of these sub-parts. |
| solution option | One possible way to satisfy one or more needs in a context. |
| solution requirement | A capability or quality of a solution that meets the stakeholder requirements. Solution requirements can be divided into two sub-categories: functional requirements and non-functional requirements or quality of service requirements. |
| solution life cycle | The stages through which a solution progresses from inception to retirement. |
| solution scope | The set of capabilities a solution must deliver in order to meet the business need. |
| SOW | See statement of work. |
| sponsor | A stakeholder who is responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize the work to be performed and control the budget and scope for the initiative. |
| stakeholder | A group or individual with a relationship to the change, the need, or the solution. |
| stakeholder analysis | Identifying and analyzing the stakeholders who may be impacted by the change and assess their impact, participation, and needs throughout the business analysis activities. |
| stakeholder list | A catalogue of the stakeholders affected by a change, business need, or proposed solution, and a description of their attributes and characteristics related to their involvement in the initiative. |
| stakeholder proxy (business analyst) | The role a business analyst takes when representing the needs of a stakeholder or stakeholder group. |
| stakeholder requirement | A description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements. |
| state diagram | An analysis model showing the life cycle of a data entity or class. |
| stated requirement | 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. |
| statement of work (SOW) | A written description of the services or tasks that are required to be performed. |
| strategy | A description of the chosen approach to apply the capabilities of an enterprise in order to reach a desired set of goals or objectives. |
| strengths, weaknesses, opportunities, and threats analysis (SWOT) | An analysis model used to understand influencing factors and how they may affect an initiative. Also known as SWOT analysis. |
| structural rule | See definitional business rule. |
| subject matter expert (SME) | See domain subject matter expert; implementation subject matter expert. |
| supplier | A stakeholder outside the boundary of a given organization or organizational unit who provides products or services to the organization and may have contractual or moral rights and obligations that must be considered. |
| suppliers, inputs, process, outputs, and customers (SIPOC) | A tool used to describe relevant high-level elements of a process. May be used in conjunction with process mapping and ‘in/out of scope’ tools, to provide additional detail. |
| survey | Collecting and measuring the opinions or experiences of a group of people through a series of questions. |
| swimlane | A horizontal or vertical section of a process diagram that shows which activities are performed by a particular actor or role. |
| SWOT analysis | See strengths, weaknesses, opportunities and threats analysis. |
| system | A set of interdependent components that interact in various ways to produce a set of desired outcomes. |
t
| Term | Description |
|---|---|
| task (business analysis) | A discrete piece of work that may be performed formally or informally as part of business analysis. |
| technique | A manner, method, or style for conducting a business analysis task or for shaping its output. |
| temporal event | An event based on time that can trigger the initiation of a process, evaluation of business rules, or some other response. |
| tester | An individual responsible for determining how to verify that the solution meets the requirements defined by the business analyst, and conducting the verification process. |
| throw-away prototype | A prototype used to quickly uncover and clarify requirements or designs using simple tools, sometimes just paper and pencil. It is intended to be discarded when the final system has been developed. |
| time-box | An agreed-upon period of time in which an activity is conducted or a defined deliverable is intended to be produced. |
| traceability | See requirements traceability |
| transition requirement | A requirement that describes the capabilities the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. |
u
| Term | Description |
|---|---|
| UAT | See user acceptance test. |
| UML® | See unified modelling language. unified modelling language™ A notation specified by the Object Management Group for describing software application structure, behavior, and architecture. It can also be used for describing business processes and data structures. The most common UML® diagrams used by business analysts are use case diagrams, activity diagrams, state machine diagrams (also known as state diagrams), and class diagrams. |
| use case | A description of the observable interaction between an actor (or actors) and a solution that occurs when the actor uses the system to accomplish a specific goal. |
| use case diagram | A type of diagram defined by UML® that captures all actors and use cases involved with a system or product. |
| user | See end user. |
| user acceptance test (UAT) | Assessing whether the delivered solution meets the needs of the stakeholder group that will be using the solution. The assessment is validated against identified acceptance criteria. |
| user requirement | See stakeholder requirement. |
| user story | A small, concise statement of functionality or quality needed to deliver value to a specific stakeholder. |
v
| Term | Description |
|---|---|
| validation (business analysis) | The process of checking that a deliverable is suitable for its intended use. See also requirements validation. |
| validated requirement | A requirement that has been reviewed and is determined to support the delivery of the expected benefits, and is within the solution scope. |
| value (business analysis) | The worth, importance, or usefulness of something to a stakeholder in a context. |
| value stream mapping | A complete, fact-based, time-series representation of the stream of activities required to deliver a product or service. |
| verification (business analysis) | The process of determining that a deliverable or artifact meets an acceptable standard of quality. See also requirements verification. |
| verified requirement | A requirement that has been reviewed and is determined to be defined correctly, adheres to standards or guidelines, and is at an acceptable level of detail. |
| vertical prototype | A prototype that is used to drill down into a proposed solution to uncover requirement and design considerations through multiple layers of a solution that are not easily understood or that are not discernible on the surface. It may include interaction between several solution components. |
| viewpoint | A set of conventions that define how requirements will be represented, how these representations will be organized, and how they will be related. |
| VSM | See value stream mapping. |
w
| Term | Description |
|---|---|
| walkthrough | A review in which participants step through an artifact or set of artifacts with the intention of validating the requirements or designs, and to identify requirements or design errors, inconsistencies, omissions, inaccuracies, or conflicts. |
| WBS | See work breakdown structure. |
| work breakdown structure (WBS) | A deliverable-oriented hierarchical decomposition of the work to be executed to accomplish objectives and create the required deliverables. It organizes and defines the total scope of the project. |
| work product (business analysis) | A document or collection of notes or diagrams used by the business analyst during the requirements development process. |
| Workshop | A facilitated and focused event attended by key stakeholders for the purpose of achieving a defined goal. |
