Introduction to Requirements Management

by Janette Toral

 

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 requirements are gathered by a person referred to as a requirements analyst. Their work includes:

 

1. Talk to users and project proponents. Data gathering can come in many ways such as use cases, workshop, video conferencing, prototyping, survey, meetings, document review, natural observation, and user interviews. Preparation is important. If there are several options being considered and information is available, a comparative evaluation will also be performed.

 

After every meeting, minutes are prepared for concurrence with the client. Until sufficient information is gathered, drafting of documents, such as the Vision and Scope document (sometimes referred to as Project Charter), that shall serve as a preliminary agreement with the client, can’t proceed.

 

2. Document the requirements. The requirements analyst should be able to document the requirements in the following areas:

• Business requirements stated by project sponsor. This shall serve as the ground work for the vision and scope of the project.
  
• User requirements given by user representatives. This details the tasks that users must be able to perform with the new application. Quality attributes, like maintainability and usability, are noted here as well. The user requirements should be properly aligned with business requirements and rank priorities accordingly.
  
•  Expectations and constraints by various stakeholders that needs to be fulfilled in order for the project to take off.
  
• Functional and non-functional requirements to be discussed with development and testing personnel.
  
• Size and complexity information concerns by the project manager.

One of the failures in software projects today is the lack of documentation. Make sure that all requirements stated in your software project must be documented. Apart from the project plan and vision & scope, customer and product requirements must be prepared and approved. These documents shall serve as the basis for project planning, testing, and customer acceptance.

 

Avoid including fancy features that were not defined to be needed in the project. Each unnecessary function added, even on goodwill, has a cost allocated to it.

 

Poor documentation of Vision & Scope or Project Charter can impact all succeeding project documentation.

 

3. Identify your success criteria. Each feature or component in your requirements was included for a specific reason. Whatever that is, it must be cited along with its goals or success criteria. This is the only way you can measure whether you have met your objectives. A success criteria can be a business statement like “decrease the number of days for order processing from 5 to 3 days” to technical statement like “complete monthly sales report generation in 30 minutes”.

 

4. Identify users and stakeholders. Most projects fail due to lack or poorly defined participation of stakeholders. All identified actors in the project must be clear, given appropriate responsibility, time, and resource. They should be made accountable for non-cooperation in the software development project.

 

One factor overlooked that may result to poor cooperation is the lack of knowledge about the software development lifecycle. That is why it is important to have a workshop during the start of the project to level the knowledge among project participants and other relevant stakeholders.

 

5. Project priorities. Customers should know the cost and implications of adding new features or even changing it once implementation starts. This is where your project priorities must be clear and parameters for trade-off defined earlier on. Find out which is fix and flexible: features, cost, and schedule. An example can be, “Given fix cost, we will choose the features and adjust the schedule as necessary.

 

The importance of knowing your project priorities is to make request for changes as realistic and reasonable as possible, with fairness to both parties.

 

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.

 

The project charter or vision and scope document can contain the following, at the minimum:

 

• Business requirements
• Background
• Opportunity
• Business objectives
• Success criteria
• Customer or market needs
• Business risks
• Vision of the solution
• Vision statement
• Features
• Assumptions
• Dependencies
• Scope and limitations
• Initial release
• Subsequent release
• Business context
• Project stakeholders
• Project priorities
• Operating environment
• If available, Initial assumed cost that covers personnel, quality assurance or audit, equipment, and software to be utilized in the project.
• Anticipated returns, whether in terms of profit or savings for the organization.

Note that in the deliberation process of this document, your approved minutes of the meeting must be on hand to back-up your assumptions for the project.

 

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:

• IBM Rational RequisitePro (http://www.rational.com)
• DOORS (http://www.qssinc.com)
• RTM Workshop (http://www.chipware.com)
• Enterprise Architect (http://sparxsystems.com/)
• Borland (http://www.borland.com)