Follow us...

The Requirements of Connected Requirements, Estimates, and Work Plans

John A. Bellwin, JD, Accenture Senior Manager

Previously I wrote about the connection between Requirements, Estimates and Work Plans. A second article addressed the tools and process of this connection. This article addresses what the requirements need to look like to make this strong connection.

The core of the connection is in the functional requirements. Functional requirements need to identify for each requirement the relevant:
  • Data
  • The role that is using the data
  • The steps that the role is taking while using the data.
The common example that I use to explain this idea is software for a grocery shopping list (GSL).

Functional area: Product Selection

Data: product
type (e.g. cereal)
brand (e.g. Kellogg's)
name (e.g. Frosted Flakes)
aisle (e.g. 1)
Source of record: GSL application

Role: adult user
Attributes: can add any item to the grocery list.
Attributes for a role can also be described as security permissions.

Steps: product selection
     1. Select product
     2. Add product to shopping list

Requirement: An adult user shall select products that the GSL software will include on the grocery shopping list.

Requirement attributes: Identify "product" as the data, "adult user" as the role, and "product selection" as the steps.

Documentation: Data and roles are kept in a requirements management tool (e.g. RequisitePro). The documentation of steps I keep in my use case modeling tool (RAVEN).

So if you were going to implement this, how would you do it?

Step 1: Communicate
Tell both the business and the business analysts about documenting the data, roles and steps of application functionality. One appeal of this approach is that the documenting of data, roles and steps has value to the organization—even if everything else does not work, you still obtain valuable documentation.

Step 2: Enable Business Analysts
Some of your organization's data and roles are already documented. Ensure that business analysts know where that documentation is. Next, start building a common repository for those data and role definitions. This documentation can be done by a person that is new to the organization.

Step 3: Identify the Inconsistencies.
This one can be painful. I have seen organizations that do not have consistent definitions of data across applications. When I have seen this problem, it was not fixed. You have to evaluate whether you accept this because it is too much of an effort to fix. If you do accept this, one strategy is to ensure that all future applications have consistent definitions.

The way to find out if applications have inconsistent definitions is to talk to the developers (usually the database developers). After talking to developers, talk to the business users and ensure that the definition you have matches with the business person's understanding.

Step 4: Structure Requirements Meetings around Data, Roles and Steps
The deliverable from requirements meetings is a definition of data, roles and steps. If the business and the business analysts walk into functional requirements meetings knowing this, they tend to come better prepared. This is not to say that data, roles, and steps are the only topics of conversation in a requirements meeting. Asking about data, roles, and steps often uncovers issues that are otherwise not found until later stages.

Finally, Productivity

And finally, increased productivity comes from two things:

1. The obvious, the documented data and roles are re-usable, leaving more time for analytical thought that delivers a higher quality product.
2. Methodology - once the approach is captured in a methodology, that methodology can be used to develop a common understanding with people who are new to the process.

John Bellwin is a Senior Manager at Accenture, a global management consulting, technology services and outsourcing company, with approximately 236,000 people serving clients in more than 120 countries. John is a member of Accenture's Program, Project, and Service Management group. As a Program Management Office lead, John's work typically involves work planning, resource management, estimating, and requirements development/management.