Business requirements Modeling example
Definition of a Requirement
A more precise definition is provided by the IEEE Glossary of Software Engineering Terminology and the Business Analysis Body of Knowledge® (BABOK®). Both define a requirement as a
- condition or capability needed by a user to solve a problem or achieve an objective.
- condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
- documented representation of a condition or capability in (1) or (2).
Not all requirements are at the same level. Some might be high level requirements expressed by the business sponsor (e.g., reduce the cost of invoicing customers), others might be very specific requirements that describe a function needed by a particular user (e.g., allow me to click on a customer name and then display that customer's account history).
The BABOK® defines the following requirements types: business, user (stakeholder), functional (solution), non-functional (quality of service), constraint, and implementation (transition).
Note that these terms are overloaded and often have different definitions within some organizations. For example, a user requirement is referred to as a business requirement in some organizations and a business requirement is sometimes called a business goal or project objective. Functional requirements are also often called technical requirements, detailed requirements, or system requirements. So, it is important to understand the semantics of the terms being used. If in doubt, ask, but don't assume. In fact, publish a glossary of terms to clarify the meaning of terms that are used by the project team.
Examples of Different Types of Requirements
To clarify the different kinds of requirements types, let's take a look at some examples for each type.
Table 1. Requirements Examples
The scope of a project refers to the agreed upon set of features that the final product will contain. Scope creep is a common occurrence and it describes the propensity of scope to expand as stakeholders add requirements during the project without regard to its impact on budget, schedule, and deliverables. The project manager must work with the stakeholders to get agreement on the scope.
The stakeholders are the main source of requirements. They have specific needs that the analyst must identify. This is easier said than done: often stakeholders are not quite sure what they need and they often don't know how to express what they need. It is the analyst's job to help uncover the requirements of the stakeholders.