Registration of Business Requirements using the Business Requirements application

General Add comments

The Business Requirements application is an addition to Service-Now’s SaaS and was created by 2e2 Consulting. The main purpose is to register changes made to the default Out-Of-The-Box functionality as delivered by Not only Business Requirements are registered, also the Functional Specifications and the Technical Specifications are captured.

Besides registration it also offers a testing plan and deliver tool.
If using the Business Requirements application as it is supposed, all changes to are specified, tested and approved.

The end result is an extensive overview of all changes made, including the reason for that change.
This is a great guide for supporting the customer and gives a good insight in changes made for future consultancy assignments.

Breakdown of the tool

The Business Requirements application breaks down in several sections:

  • Deployment Release
    • A Deployment Release consists of one or more Builds
  • Build
    • Build is a collection of Functional Specifications
      • A Build can be exported in a XML file to be transferred to another Service-Now Instance
  • Business Requirement
    • Describe the exact reason for this change
  • Functional Specification
    • Describe the functional specification of the change
    • Describe the technical solution for this change
    • Each created / adjusted element is connected here:
      • Access Controls, Applications, Business Rules, Client Scripts, Data Sources, Dictionary Entries, Email Notifications, Event Registry, Macros, Modules, Roles, Script Actions, Table Transform Maps, UI Actions, UI Policies and Audit Records

For all the above elements, the reason and documentation can/must be entered.

Usage of the tool

Good practice in using the Business Requirements application is first start with a top-down approach to specify the Business Requirements. Every aspect in the customer’s organization that can have an influence on the working with their Service-Now instance must be inventoried and described on a top level.

After the top-down, the bottom-up approach can be started. In the bottom-up approach, everything that is changed in Service-Now must be registered in the Business Requirements application. Each change to Business Rules, Client Scripts etc. can be connected to a Functional Specification related to a Business Requirement.

Illustration 1: The Business Rule form

As you can see in Illustration 1, a related list is added to the Business Rule form. This related list holds the relation to the Functional Specification of the adjustment made in this Business Rule. This is just a sample; the related list is added to all Service-Now elements that are covered by the Business Requirements application.

Results of the BRT

If used well, the Business Requirements application holds all information to give anyone confronted with a customers’ Service-Now instance a good insight in all changes made to that instance.

If you have question on (the use of) the Business Requirements application you can contact me on .

Leave a Reply