a



Introduction to Requirements Management

by Janette Toral


(visit the photo gallery for a bigger size)


In my experience and encounter with IT managers and professionals, requirements management is often, if not the most, underestimated task in software development. If the project scope is not accurately predicted in terms of schedule and budget, all subsequent tasks will be greatly affected and can result to project loss or failure.

 

For non-IT project proponents and participants, getting trained is very important. Understanding how the software development lifecycle takes place will make you sensitive on the realities of this process. Untrained project proponents oftentimes have unrealistic expectations and are primary causes of their project failures.

 

Getting software process improvement knowledge beforehand will make you confident as well in dealing with vendors and be able to discern which entity can deliver the expectations in your software project based on their competency and process maturity.

 

Obtain an understanding of requirements

In principle, every software or application development project must be clearly defined before development begins. It must address a problem that the organization currently has. The requirements management and gathering process is a necessary step in order to come up with a solution appropriate for the organization.

 

The work mostly done in this phase is performed by a person or team referred to as a requirements analyst. The document, Vision and Scope, gets prepared to document understanding of the system and subject for approval by the users.

 

Developer’s dilemma

The common concern of developers is that they usually don’t have any control on the software requirement being presented to them. As a result, they are forced to bend all rules, sacrificing quality time and self, just to finish a software project.

 

Developers can be helped by allowing them to form a collaborative relationship with those who supply the requirements. This includes conducting reviews on the requirements document before it gets finalized in order to ensure that there’s enough information for the developer to implement it.

 

Another way to manage requirements properly is to limit the use of ambiguous or vague terms that can be subjected to a lot of personal and biased interpretations. For example, user-friendly is a word commonly found in a requirements document. However, all of us have different definition on what makes a software interface or program user-friendly. Other commonly used vague terms are support, such as, and/or, including, several, efficient, fast, among others. Making these terms explicitly defined can make the implementation phase specific and measurable.

 

To further increase accuracy, validation from the requirements analysts, customer or end user who got consulted on the requirements, developers, and testers will help significantly. Test cases, prototypes, dataflow diagrams, and the like can also be useful.

 

In reality, there are no perfect requirements. If there are specific areas where requirements aren’t fully clear or uncertain, modularized or phase it so that the whole development won’t be paralyzed waiting for the entire requirements document to be finished and approved.

 

The requirements afterwards get consulted with the project leader who draws the project description and identifies resources that will be needed. This collaboration will result to a vision & scope or project charter document that will be used to win approval from top management or client.

 

Obtain commitment to requirements

Once the Vision & Scope or Project Charter document is prepared, this gets submitted to the client for approval. Any confusion or misunderstanding gets corrected at this level as this shall serve as the basis of all work.

 

Stakeholders from the client side are properly oriented as well for their responsibility to project timeline and given accountability for success or failure of the project.

 

Once commitment from senior management and stakeholders are obtained, a formal project plan shall be developed. 

 

Manage requirements changes

In the context of CMMI, the requirements management process area purpose is to manage the requirements of the project’s product and product components, identify inconsistencies between those requirements and the project’s plan and work products.

 

It controls changes in the requirements baseline and the impact to project implementation. With this in place, all changes require a formal procedure, especially once initial requirements have been approve, and proper version control.

 

Customers also tend to approach developers directly when it comes to change requests. Make sure that all requests have been approved by those who defined the requirements and managing the project. Having a change request process makes it easy for developers to handle these personal requests.

 

Bi-directional requirements traceability

Requirements and features were not created or given to us by clients for just the heck of it. They should arise from a need or problem given by stakeholders that may came from an output of a user interview or workshop. All of these requirements and changes should be traceable and managed accordingly.

 

A traceability matrix needs to be created for this purpose. This will form the skeletal structure of the project from requirements and to its various work product components.

 

  1. The business needs and product features stated in your Vision & Scope document serves as a basis on all developments in the system.
  2. All needs and product features should be traceable to your use case scenario and technical requirements.
  3. All use case scenario and technical requirements are traceable to your test plan.

In addition, remember to note the following in your matrix.

  • Each requirement has a source and its purpose. Each feature can be traced back to a business need.
  • Is this requirement related or connected to another requirement?
  • Will this requirement impact the content of systems design, user manual, deployment, and among others?

Identify Inconsistencies between project work and requirements

With a traceability matrix and requirements scope on hand, you’ll be able to analyze inconsistencies between project work and requirements.

 

As a vendor or IT group, this early validation will help you in coming up accurate budget, tools, resource, and schedule estimates.

 

Requirements Management and Requirements Development

Note that this process area is done in parallel with requirements development and support each other in the process as new requirements and changes come into play.

 

Requirements Management Tools

There are several requirements management tool out in the market today that you can consider in using such as: