This type of diagram can be used to illustrate use cases and business use cases.

Business Analyst Business Analysts are responsible for identifying the business needs of their clients and stakeholders, to determine solutions to business problems.

The Business Analyst is responsible for requirements development and requirements management. Specifically, the Business Analyst elicits, analyzes, validates and documents business, organizational and/or operational requirements. Solutions are not predetermined by the Business Analyst, but are driven solely by the requirements of the business. Solutions often include a systems development component, but may also consist of process improvement or organizational change.

The Business Analyst is a key facilitator within an organization, acting as a bridge between the client, stakeholders and the solution team. Business analysis is distinct from financial analysis, project management, quality assurance, organizational development, testing, training and documentation development. However, depending on an organization, an individual Business Analyst may perform some or all of these related functions.

Class Model A type of diagram defined by UML that describes one or more Objects with a uniform set of attributes and services, including a description of how to create new objects in the Class.

Constraint A constraint describes any limitations imposed on the solution. Business constraints are things like budget limitations, restrictions on the people who can do the work, the skill sets available, etc. Technical constraints include any architecture decisions that are made.

Deliverable On the highest level a deliverable is the solution due to the customer at the end of a project. But, during a project there are a number of project artifacts and solution components due by project team members to other project team members. Any tangible and verifiable components of a project, resulting from tasks or activities that must be produced to complete a project. Project Management Deliverable(s) are objects (usually a document) which relate to the Project Management requirement in the lifecycle.

Enterprise Analysis This Knowledge Area covers pre-project activities and approaches for capturing the necessary view of the business to provide context to requirements and functional design work for a given initiative and/or for long-term planning. In some organizations this work is treated as an investigative, feasibility or business architecture project and may be managed as a project.

Feature A feature is a service the system/solution provides to fulfill one or more stakeholder needs. Features are typically fairly high-level abstractions of solution and will turn into functional or non-functional requirements. They allow for early priority and scope management and for getting a high-level sense of the stakeholders view of the solution.

Functional Design Observable behaviours of the solution; as opposed to technical design.

Functional Requirements Functional requirements describe both the systems behaviour in detail and the information the system will manage.

Modeling Representations of a business or solution that often include a graphic component along with supporting text and relationships to other components.

Needs A type of high level requirement that is a statement of a business objective, or an impact the solution should have on it’s environment.

Non-functional Requirements Required system capabilities that do not describe functionality. Examples of non functionalrequirements include: the number of end users, response times, fail-over requirements, useability and performance. Also known as supplementary requirements.

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 behaviour and attributes from other components; and whose components communicate via messages with one another. In some organizations, the same OO approach is used for business engineering to describe and package the logical components of the business.

Product A solution or component of a solution that is the result of a project.

Project A temporary endeavor undertaken to create a unique product, service or result.

Requirements A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective.

Requirements Analysis & Documentation Requirements analysis and documentation is the knowledge area of business analysis that describes how business, functional, and nonfunctional requirements can be assessed, documented and presented. Requirements analysis defines the methods, tools and techniques used to structure the raw data collected during Requirements Elicitation, identify gaps in the information, and define the capabilities of the solution, which must be documented. The documentation approaches used must clearly communicate the requirements to the stakeholders and to the project team. Business Analysts must understand the documentation options and select the appropriate format(s) for their project.

Requirements Attribute Characteristic of a requirement that captures additional information about the requirements, such as the priority of the requirement or level of risk associated with it.

Requirements Communication This knowledge area is a collection of activities and considerations for presenting and communicating requirements to stakeholders and getting approval.

Requirements Discovery Session A forum (like a JAD) where stakeholders, Subject Matter Experts (SME) get together to provide information about the target system. This forum needs to be led by a Business Analyst who is a skilled Facilitator, and assisted by a Scribe whose role is to document the business requirements discovered.

Synonym: Requirements Elicitation, Requirements Discovery Session (RDS), Joint Requirements, Planning Session (JRPS)

Requirements Document The document or artifact that captures gathered requirements and serves to communicate them.

Requirements Elicitation This is a Knowledge Area within the BA BOK. This Knowledge Area describes the collection of activities and approaches for capturing the requirements of a target system, from the stakeholders.

Solution Assessment and Validation This Knowledge Area includes the tasks necessary to ensure that the solution meets the stakeholder objectives, is thoroughly tested, and is implemented smoothly.

Reverse engineering requirements Identifying requirements by interviewing developers, reading code, testing applications.

Requirements Planning and Management The Knowledge Area includes the activities involved with determining and planning the requirements activities a BA will perform on a particular project, what deliverables they will produce, and how they will control and manage changes to the deliverables.

Requirements Workshop Also known as a Requirements Discovery Session. Sequence Diagram A type of diagram defined by UML that shows object interactions in time sequence. In particular, it shows objects participating in interactions and the messages exchanged. This type of diagram can be used to depict Use Cases, by capturing the actors involved in the use case and the system under development as objects.

Traceability An association that exists between requirements when more detailed requirements are associated with the higher level requirements (needs and features) those detailed requirements support. Traceability associations can also exist between detailed requirements and both design models and test cases. Traceability between requirements and other project artifacts allows a BA to manage scope creep and ensure all requirements have been met.

Use case Diagram A type of diagram defined by UML that captures all actors and use cases involved with a system or product.

End product Project’s material outcome; maybe a service, event or any material object (e.g., a machine, computer system, new drug, building, etc.). The end product includes all necessary aspects of the deliverable (e.g., training, documentation, etc.).

End-user Individuals or groups who will use the software system and/or application.

Functional Owner Person responsible for activities performed within a specific department or function (ex. claims, enrollment, legal, grievance & appeals, member service, provider relations, marketing, sales).

IT Lead Authorized to coordinate the day-to-day IT activities and deliverables for the project across all IT functions. These responsibilities include providing the appropriate products and estimates (time and/or cost) for IT efforts, provide the Project Manager with status updates on IT progress as well as tracking and escalating issues. This person is, in essence, the IT Project Manager for the IT component of the project and in some cases may assume the role of the overall Project Manager.

Lead Business Analyst Responsible for developing, documenting and managing all business requirements. Lead Business Analysts may oversee the work efforts of one or more Business Analysts when working on large complex projects, which may cross functional areas.

Project A temporary endeavor, with definite objectives, undertaken to create a unique and measurable product, service or result and must be delivered within specific parameters (Time, Scope and Cost). Characteristics of a Project:

• Unique and defined scope
• Specific and measurable objective(s)
• Has a definite start and an end date
• Progressively Defined

Project Manager Authorized individual responsible for managing all aspects of a project including:

• Issue tracking
• Managing: deliverables, quality, risks, status, and budget
• Coordinating the day-to-day activities/resources.

Has the responsibility to conclude the project on schedule and within budget. Identified during the Identification Phase.

Project Owner Member of the requesting organization who is assigned by the Project Sponsor to provide decision support and guidance to the Project Manager and project team and is responsible for directing the delivery of a project. In most cases, the Project Owner develops the Project Charter, assists in gathering requirements, manages the scope of the project through various decisions, and verifies that the “right” solution was developed.

Project Sponsor Typically a member of the senior management team (usually from the division requesting the work); facilitates commitment to all major project decisions, has final authority to approve project completion, accountable for the project’s financial performance, compliance to project management standards, and for making sure the project meets the original intended objectives.  Assigns a Project Owner and authorizes a Project Manager. May be responsible for budgeting funds to undertake the project.

Project team Individuals or groups who are assigned to and working on the project. The team may be further defined as core team and extended team, where core team refers to members that are engaged on a more frequent basis.

Quality Control (QC) Process of monitoring specific project results to determine if they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance. Quality Control is typically associated with testing. May also refer to the organizational unit that is assigned responsibility for quality control.

SME Subject Matter Expert; individual or organization that provides specialized support and consultation to the project team.

Stakeholder(s) Diverse community of individuals and organizations who are either:

• Directly involved in the project, or
• Whose interests may be positively or negatively impacted by the result of the project, or
• Have a clear sense of why the project is being undertaken and the ultimate value it will provide, both to the organization and its customers (members & providers).

Key stakeholders includes: Project Sponsor, Project Owner, Project Manager, end-users, PMO, Subject Matter Experts. Additional stakeholders will be identified during the Identification & Design Phase.