Best Practices to Organize Requirements | Requirements Architecture

Why Organize Requirements?

#

A business analyst deals with many different requirements every day. The requirements may be related to the same change initiative or different changes.

A software system is being evolved/changed continuously hence change management becomes a key task for any business analyst and the project team.

If the requirements are not organized properly, it can lead to various problems such as:

• Difficult to relate requirements
• Duplication of requirements
• Difficult to locate or retrieve a requirement and it’s implementation information
• Possibility of deviating from Industry or Organization standards while implementing requirement
• Incomplete and outdated information about a change
• Difficulty in explaining change history to the stakeholders

These problems lead to poor requirement management and it would adversely impact on the future changes to the system(s).

Basically, it will create a chaos if the requirements are not organized using a well defined requirements structure.

Hence, it’s very important to organize requirements to avoid these problems.

Standard Guidelines on Organizing Requirements aka Requirements Architecture

#

According to BABOK v3, the task of organizing requirements is called “Define Requirements Architecture”.

The main purpose of having a good requirement architecture is to organize related requirements, it’s models and specifications together so that it clearly depicts the relationships between the requirements and this helps to manage new changes efficiently.

Following are the standard guidelines on organizing requirements:

• Follow organizational or industry standards or conventions that describe how the requirements should be represented and related with each other. For example, which type of models to use, which attributes to use consistently across models, model notations and analytical approaches used to identify and maintain relationships among models. This can act as a Standard Template for a particular type of requirement.
• Use simple consistent definitions and business terminology used in the organization while stating the requirements
• Document dependencies and interrelationships among the requirements
• Produce a consistent set of models and templates to document requirements

Best Practices to Organize Requirements

#

• Identify the main categories of business requirements (e.g. Functional Changes, Regulatory Changes) and sub categories within a main category (e.g. different modules within functional changes).
• Identify appropriate models to be prepared and select a standard notation to follow while preparing models such as UML, BPMN etc. There can be main model and sub models as well depending on the scope.
  • Refer these models to analyze a new change and update the models for consistency and completeness.
• Prepare standard templates to describe business requirements and requirement specifications (Software Requirement Specification doc or user stories). Follow these standard templates while documenting the requirements.
  • A typical Software Requirement Specification (SRS) document has the following sections:
    • Table of Contents (or Index)
    • Requirement Overview with a reference to the Business Requirement
    • Logical sections to specify implementation requirements for each section along with references to models and/or UI designs.
  • A typical User Story has the following sections:
    • Title
    • Value Statement
    • Conversation
    • Acceptance Criteria
• Follow standard naming convention to name the models, business requirements and requirement specification artifacts for easy identification and referencing purpose.
• Refer or link to the corresponding models and business requirements while specifying requirements for development in the form of Software Requirement Specification document or User Stories.
• Group and Store the related artifacts (Models & Specifications) of a Category together in a Repository or Project Management Tool for easy referencing and retrieval.

Example of Organizing Requirements

#

Let’s take an example to understand how to organize requirements or how to define requirements architecture.

Consider a software application that manages onboarding and KYC of corporate banking customers and this is an internal application used by the branch staff globally to onboard and manage relationship with banking customers. Also, this application is interconnected to a few reporting apps, core banking platform and a few client facing apps.

• Categories and Sub Categories of Business Requirements are identified as follows:

  • Functional
    • Module 1
    • Module 2
  • Regulatory
  • Security
  • External Interfaces
  • Performance

• Models and Sub models are identified as follows:

  • Context Diagram (UML)
  • Functional Decomposition diagram (UML)
  • Data Flow Diagram (UML)
  • Main Business Process Diagrams (BPMN)
    • Sub business process diagrams (BPMN)
  • Entity Relationship Diagram (UML)
  • Business Rules (Decision Tree / Decision Table)

• Consider that there are Wireframes (low-fi designs) to develop User Interface. These can be broken down into different modules of the application within the wireframing tool such as Figma or Balsamiq.

• The project follows Agile Scrum methodology to develop software hence there are following artifacts come into play:

  • Product Backlog
  • Epics
  • User Stories

• Consider that this project uses JIRA as a project management tool and a Cloud repository (Google Drive / MS One Drive) to store the artifacts.

• The requirements can be organized/structured for this project as follows:

  • Create the following folder structure under the main project’s folder in the cloud repository to store models and business requirement documents together for a specific category.
    • Common Models - Store all the common model diagrams here
    • Requirements
      • Functional
        • Module 1
        • Module 2
      • Regulatory
      • Security
      • External Interfaces
  • JIRA
    • Create Labels for each main and sub category of requirements
    • Create “Epic” for each business requirement, assign appropriate label to it and link it to corresponding Model(s) and Business Requirement Document
    • Create “User Story” for each Epic and provide references to models and wireframes where necessary
      • An Epic can have multiple related user stories
    • Create a Product Backlog to prioritize user stories

This is just an example to demonstrate how to organize requirements. Each organization has different environment (standards, policies, tools etc.) hence a business analyst should work with stakeholders in the planning phase to define requirement architecture that suits best to the organization and project.

Conclusion

#

Organizing requirements helps a business analyst and stakeholders to holistically understand everything related to a change, efficiently manage upcoming changes and manage the project artifacts efficiently.

Whenever a new change request comes, a business analyst and stakeholders can refer to the requirement structure to easily find out the related artifacts, evaluate the change to see what’s already there and what needs to be done and carry out the new change efficiently.

Project management tools such as JIRA and Cloud repositories help a lot in defining and maintaining requirements architecture hence leverage these tools to their best for efficient management of requirements.

Lastly, Requirement architecture helps to maintain Requirement traceability as well. Traceability is often used to link each requirement back to it’s objective and shows how an objective was met, while Requirement architecture is used to show how different elements work in harmony with each other to support business requirements and to structure them for better change management.