Business Requirements Example


Here we will see business requirements example and definition. We will start with business rules examples and explanation. The page also contains examples of stakeholder requirements, solution requirements, transition requirements, assumptions, constraints, and use cases.

Business Requirements Example and Definition. Business Rules.

Business rules examples and definition

Business rules – A business rule is a specific, actionable, testable directive that is under the control of an organization and that supports a business policy. Particularly complex rules, or rules with a number of interrelated dependencies.

The business rules example – “Only accountants will be allowed to issue invoices”.

Business requirements example and definition. Other requirements.

Requirements – According to BABOK and IIBA, a requirement is:

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as in (1) or (2).

Requirements are divided into the following types:

  • Business requirements – high-level declarations of the goals, objectives, or needs of the organization.

Business requirements example – “The productivity will grow with 5% in 2013”

  • Stakeholder requirements – are declarations of the needs of a particular stakeholder or class of stakeholders.

Stakeholder requirement example – “The accountant sector needs new software which should provide following functionalities:…..”

  • Solution requirementsfunctional – describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses.

Functional requirement example – “The system shall provide following functionalities in the case of crediting an issued invoice: ..……”

  • Solution requirements – non-functional – defines conditions that do not directly connected to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have.

Non-functional requirement example – “The system response time shall be maximum 2 seconds.”

  • Transition requirements – capabilities that the solution must have in order to facilitate a transition from the current state of the enterprise to desired future state, but that will not be needed once that transition is complete.

Transition requirement example – “The data migration shall require……”

Assumptions and constraints – Constraints are factors that may limit the project management team’s options, whereas assumptions are factors that for planning purposes may be considered to be true, real, or certain.

  • Constrain example – “The integration service may receive no more than 100 requests per second.”
  • Assumption example – “The problem with XXX functionality shall be solved up to the end of 2013.”

Use cases – a use case is a list of steps, typically defining interactions between a role (known in UML as an “actor”) and a system, to achieve a goal. The actor can be a human or an external system.

Use case example of basic course of event, (system 1,2,3 are used only in the example, you may use your own system names), alternative flows and exceptions:

  1. The system 1 verifies that the actor is logged in.
  2. The system 1 visualizes the web complaint form with fulfilled information from the user’s web registration.
  3. The actor writes his/her complaint and clicks the Send button.
  4. The system 1 verifies the actor is fulfilled all mandatory fields including MSISDN.
  5. The system 1 verifies the MSISDN is an active MSISDN.
  6. The system verifies that the actor is not sent more than 20 complaints per day.
  7. The system 1 sends the complaint to the system 2.
  8. The system 2 sends the complaint to the system 3.
  9. The system 3 creates CRM case according complaint, the types and subtypes of the question and the phone/mail option – Appendix A and send a confirmation to system 2 and system 1.
  10. The system 1 sends a notification (Appendix B) to the actor that his/her complaint is accepted with status New.

You can see more about business requirements examples and other requirements on the IIBA website.

See also what is business analysis and business analyst.

In order to manage your requirements properly, you may need project management tools and business process management software.

Related Articles:

Leave A Reply