Tip: Make sure your team understands what you mean by "requirements"

 

Requirements Consultants

We throw around the word requirements during different stages of an IT project, assuming that the team is on the same page on what requirements are. But let’s pause for a moment and think: Have we ever walked IT and business stakeholders  through a quick definition of what this word means in the organization?

When stakeholders talk about requirements they are usually focusing on the “set” of requirements that is most relevant to them, and unwittingly, their conflicting priorities can lead to waste in misunderstandings, or even errors in tactical decision making.

For example, if you hear statements from your team such as we need an “agile business analyst” because there is not enough time to go through every single requirement, and we need to prioritize. Is the person talking referring to design requirements (specs) needed to build the solution? Or, are they talking about not having enough time to gather a requirements baseline that can be used to determine the gaps in the solution?

An Agile approach would definitely help the team on the former case, while the latter situation simply means the project is heading for trouble: if there is no gap analysis, there is no product backlog yet, so there is nothing to be Agile about.

In Leverforce we view requirements as 5 different sequential “sets” in a project. These sets are traceable to each predecessor, and they expand or contract as business analysis deliverables “check” through different project toll gates:

 requirements lifecycle

Leverforce ConcerniterationLeverforce User RequirementiterationLeverforce GapsiterationLeverforce Analysis

As project advances from charter to final product, we move from the blue spheres (problem domain) to the green ones (solution domain) and involvement and accountability of IT increases.

Thus, the statement set as an example earlier: “…there is not enough time to go through every single requirement, and we need to prioritize” would describe a very different situation for a project when the person talking is referring to set 2 in the problem domain, as opposed to sets 4 and 5 during software delivery.

Here is another way of looking at the same 5 sets of requirements:

 

requirements agile

 

I am adding a detailed description as a footnote to this article, but if you are comfortable and recognize these five sets of requirements in your own projects, let’s have a quick look at the implications to team dynamics and project success:

Business Process Model Analysts  Different stakes on requirements: When software delivery teams talk about requirements, they usually are referring to the set of requirements that supports the product backlog (set 4) while business stakeholders are thinking of the larger (set 2) of User Requirements and Business Rules included in their requirements baseline.

Business Analysis Consultants  Requirements for AGILE: An Agile Business Analyst would be an expert at defining requirements to support a product increment (set 5), based on the requirements that support the product backlog (set 4). Occasionally, AGILE business analysts would have to go back to Functional and Nonfunctional Gaps (set 3) as priorities are renegotiated, or to make sure product increments can be traced back to original value intended.

Gap Analysis Risks  An AGILE BA might not be enough to save the project: If requirements did not go through the toll gates in sequence (perhaps the statement of work was not negotiated based on a gap analysis, or the gap analysis was not structured around a validated requirements baseline) then the AGILE Business analyst will not be able to represent stakeholders or owners. Product or process owners will have to become available during the sprints (The original AGILE way)

This last scenario could be expensive for the business and a project blocker, especially if we are talking enterprise software and stakeholders are scattered geographically. 

   By Larry Velarde, CBAP®

Five sets of requirements in greater detail:

(1) The first set of requirements includes the very high level business requirements which have been established by project sponsors as value drivers for the project via a business case, a project charter, or a feasibility study.

2) The second set is the requirements baseline, the universe of requirements and business rules grounded on set (1) and needed to address risks and opportunities relevant to the processes (or products) in scope. These requirements are “locked” when stakeholders validate them, and they are usually compiled into a BRD (Business Requirements Documentation).

3) The third set of requirements is a sub set of (2): As the requirements baseline is analyzed with the solution as a backdrop, only requirements not met by the solution design will be included in set (3). Obviously, the reminder of the requirements is not relevant for the development team.

4) Perhaps the business has decided to postpone investment and address some of the gaps via changes to business processes instead. Thus set (3) is further reduced and remaining requirements are prioritized into a product backlog. Requirements that do not make it to the backlog are not relevant to the development team either.

5) Finally the development lead, scrum master, or project manager, decide on what to implement from the backlog, at that point the AGILE Business Analyst will define further requirements to support AGILE specifications.

 A note on fidelity or degree of definition on requirements: AGILE requires a low definition of solution requirements (low fidelity of design at beginning of delivery). This is of course the very best characteristic of AGILE. Unfortunately, the web is full of empty talk from practitioners who tend to confuse keeping low definition of design (on sets 3 and 4) with low definition in the requirements baseline! (Set 2).

For a brief overview on how we handle the different sets of requirements in our business analysis practice, click here

Copyright Leverforce

Leverforce  Copyright 2016 Leverforce Inc All Rights Reserved. CBAP® is a registered certification mark owned by International Institute of Business Analysis. This certification mark is used with the express permission of International Institute of Business Analysis. IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. These trademarks are used with the express permission of International Institute of Business Analysis. 

CLICK TO READ THE TERMS OF USE FOR THIS WEBSITE

SAAS Modules

  • Module: Concern +

    Use this module to manage a list of all business concerns associated to an analysis. A concern defines what the client, or the corporate sponsor, seeks to obtain for the business from the IT changes requested. Read More
  • Module: User Requirement +

    This module allows management of user requirements associated to one or many concerns. A user requirement describes a behavior or condition a user requires from an IT service in order to satisfy a concern. Read More
  • Module: Gap +

    Use this module to manage the traceability of all gaps related to one or many user requirements. A gap is the initial proposal from an IT provider. It explains what is going to be built or changed in an IT service to ensure that the behavior or condition requested is available to the user. Read More
  • 1
  • 2
  • Modelio UML Tool +

    With the Modelio extension Business Analysts can use the Modelio visual modelling tool to construct a model of all business processes that will support changes in the service and then sit back and see how the resulting XMI file automatically populates the Leverforce database Read More
  • JIRA Issues +

    Set up JIRA projects from Leverforce’s SLA or Product Increment Modules. Read More
  • 1