Term
|
Definition
| A type of diagram defined by UML that can be used to show activities and decision points, and the roles with responsibilities to those activities and decision points. This type of diagram can be used to illustrate use cases and business use cases. |
|
|
Term
|
Definition
| A constraint describes any limitations imposed on the solution. Business constraints are things like budget limiations, restrictions on people who can do the work, the skill sets available, etc. Technical constraints include any architecture decisions made. |
|
|
Term
|
Definition
| 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. |
|
|
Term
|
Definition
| On the highest level this is a solution due to the customer at the end of the project. But, during the project there are a number of project artificats and solution components due by project team members to other project team members. |
|
|
Term
|
Definition
| 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. |
|
|
Term
|
Definition
BAs are responsible for identifying the business needs of their clients and stakeholders, to determin solutions to business problems. The BA is responsible for requirements development and requirements management. The BA elicits, analyzes, validates and documents business, organizational and/or operational requirements. The BA is a key facilitator within an organization, acting as a bridge between client, stakeholders and solution team.
|
|
|
Term
| Business Requirements Document |
|
Definition
|
|
Term
|
Definition
|
|
Term
|
Definition
See Requirements Discovery Session A forum (like JAD) where stakeholders, Subject Matter Experts (SME) get together to provide information about a target system. This forum needs to be lead by a BA 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)
|
|
|
Term
|
Definition
This is a knowledge area within the BA BOK. This knowledge area covers pre-project actitivies 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 investigative, feasibility or business architecture project and may be managed as a project.
|
|
|
Term
|
Definition
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 turne into functional and non-functional requirements. They allow for early priority and scop management and for getting a high-level sense of the stakeholders views of the solution.
|
|
|
Term
|
Definition
| Observable behaviours of the solution; as opposed to technical design. |
|
|
Term
|
Definition
|
|
Term
|
Definition
|
|
Term
| Non-functional Requirements |
|
Definition
Required system capabilities that do not describe functionality. Examples of non functional requirements include: the number of end users, response times, fail-over requirements, useability and performance. Also known as supplementary requirements.
|
|
|
Term
|
Definition
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 whos components communicate via message with one another. In some organizations, the same OO aproach is used for business engineering to describe and package the logical components of the business.
|
|
|
Term
|
Definition
|
|
Term
|
Definition
| A temporary endeavor undertaken to create a unique product, service or result. |
|
|
Term
|
Definition
|
|
Term
| Requirements Analysis and Documentation |
|
Definition
This is a knowledge area with the BA BOK. Requirements analysis and documentation is the knowledge area of business analysis that describes how busines, functional, and non functional 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.
|
|
|
Term
|
Definition
|
|
Term
| Requirements Communication |
|
Definition
| This is knowledge area with the BA BOK. This knowledge area is a collection of activities and considerations for presenting and communicating the requirements to stakeholders and getting approval. |
|
|
Term
| Requirements Discovery Session |
|
Definition
A forum (like JAD) where stakeholders, Subject Matter Experts (SME) get together to provide information about a target system. This forum needs to be lead by a BA 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) |
|
|
Term
|
Definition
|
|
Term
|
Definition
|
|
Term
| Solution Assessment and Validation |
|
Definition
This is knowledge area with the BA BOK. This knowledge area includes the tasks necessary to ensure that the solution meets the stakeholders objectives, is thoroughly tested, and is implemented smoothly.
|
|
|
Term
| Reverse engineering requirements |
|
Definition
|
|
Term
| Requirements Planning and Management |
|
Definition
This is knowledge area within the BA BOK. 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.
|
|
|
Term
|
Definition
|
|
Term
|
Definition
A type of diagram defined by UML that shows object interactions in time sequence. In particular, it shows objects participating in intereactions 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.
|
|
|
Term
|
Definition
An association that exists between requirements when more detailed requirements are associated with a 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 artificats allows a BA to manage scope creep and ensure all requirements have been met.
|
|
|
Term
|
Definition
|
|
