Better Requirements Definition Management in Software Development Projects

Genefa Murphy, HP Software and Solutions

Why focus on requirements definition management in the application lifecycle?

Increasingly, smart businesses are looking much closer at requirements definition (RD) and requirements management (RM) (sometimes grouped together under the Gartner-coined phrase, requirements definition management (RDM)) to streamline the entire application lifecycle. Why? Because systematic and effective RDM captures software defects earlier in the lifecycle, and it reduces the overall likelihood that defects will be introduced. That's important. How important? According to one study, the cost to fix a defect after delivery is more than 100 times the cost to fix it in the requirements and design phase. [1] No business wants to be hit with that bill. Now to add to this the growing interest in agile development techniques as a way to deliver higher quality applications and we have an interesting recipe for success.

What exactly is Requirements Definition Management?

Before we can apply solid RDM practices, we need to understand what RD and RM are. Requirements definition and requirements management are the terms used to describe the process of eliciting, documenting, analyzing, prioritizing, and agreeing on requirements, and then controlling, managing, and overseeing changes and risk. In its most effective use, RDM is a continuous process that occurs throughout the application lifecycle. Now, how does this change when it comes to agile? Well in my opinion the basics shouldn't change - the only difference is that in agile this process is a lot more iterative, probably has more stakeholders involved and the currency we will probably be speaking in is user stories and tasks and not requirements per se.

So keeping this in mind what is the difference between a requirement and a user story? In my mind its all about structuring of the requirement as essentially both a requirement and a user story do the same thing - they describe a specific condition or capability needed by a user to solve a problem or achieve an objective. The difference between traditional requirements and user stories is that in traditional waterfall environments, requirements are normally broken down first into two blocks functional and non-functional and then into a deeper layer of granularity, layering business requirement with design specs etc normally in a hierarchical manner. Conversely in agile these specifications are usually first wrote as "user stories" and then the non-functional elements of the user story are captured as "fit criterion". At the heart of the user story approach are the usages of short and concise sentences which use the everyday language of the business user to describe the functionality that should be implemented. If the further detail is required the user can either tie several user stories together to form an epic or super story.

Given this what information should go where?

In the functional requirements or the body of the user story the aim should be to articulate the system-wide elements such as the main product features particular to the business (say order processing for a shipping business). Coupled with this in the non-functional requirements or "fit criterion" the user should aim to describe what elements should be included in order to enhance the user experience with the software. Common non-functional requirements include:

Usability: This includes looking at capturing and stating requirements based around user interface issues-things such as accessibility, interface aesthetics, and consistency within the user interface.

Reliability: This defines requirements such as availability levels, computation accuracy, and recoverability of the system from shutdown or failure.

Performance: This involves things such as throughput of information or computation through the system or application, response time (which also relates to usability), recovery time, and startup time.

Supportability: This specifies a number of requirements such as testability, adaptability, maintainability, compatibility, configurability, installability, scalability, localizability, and the like.

Both functional and non-functional requirements vary tremendously with the type of application or product being developed. As we have already discussed they can take the form of traditional requirements specifications or more agile like user stories. Similarly, they can be defined and captured in simple text format or visualized more elaborately with pictures, business process flows and even simulations. It all depends on your organization's development method.

To visualize or not to visualize

Whether a requirement is textual or needs to be visualized is a product of the requirement itself. How do you know? Here are some questions to ask:

• Will visualization facilitate more agile and rapid requirements definition or will it add time to the development process unnecessarily?
• Will requirements complexity (multiple sub-requirements, for example) result spider-web in diagramming that over-complicates definition?
• Will requirements be visualized by type? For instance, visualizing the user story and textualizing functional requirements associated with the user story.
• Will requirements be visualized by priority or risk? High-priority or high-risk requirements may be visualized while low-level requirements are not.

Visualization is a useful tool to help business communicate better with IT. Answering these questions can give you an indication of the level of visualization requirements your project demands. Nevertheless, you may also find that visualization is not required.

Once you have requirements, what do you do with them?

It is not enough to get your requirements and or user stories on paper or in a tool, distributed to your team, and then hope that they are met. Once requirements are defined and captured, it is essential that they are managed actively and correctly. This is even more important in agile as each iteration is a pressure cooker where user stories and requirements need to be defined, estimated, re-estimated, developed and tested in a short period of time. Here are some basics tenants to follow for successful RM:

Prioritize requirements and user stories so resources are assigned to address the highest-priority, highest-risk requirements. This helps prevent a lesser requirement (with perhaps a more vocal stakeholder) taking precedent over other more important requirements.

Baseline requirements to set measurable success standards/thresholds for all requirements so that all stakeholders are on the same page. Achieve sign-off agreement between business analysts and between business and IT.

Track changes to compare current baseline requirements against pre-defined thresholds. Business analysts can flag requirements exceeding change thresholds, assign risk, and take appropriate action - for example doing this may show that a user story is too large as is and needs to become an epic with multiple user stories under it.

Defining, capturing, and managing requirements properly in this way can add tremendous value to business, IT, and to the ultimate success of the software application or service developed. Improper RDM, or merely choosing to place less importance on it, can result in a cascade of negative effects that not only affect software in the development and testing stages, but the business as a whole. For example, according to Gartner, 40 percent of unplanned downtime is caused by application failures, costing an average of $100k per hour for mission-critical applications. [2] A large portion of those failures are due to poor requirements introduced during the development phase.

The problems of poor RDM

The unfortunate results of poorly defined and managed requirements have been known and even quantified for some time. Defects are most often introduced early and found later in the application lifecycle. This is, in part, because business analysts have historically worked in an ad hoc way using word processing and spreadsheet software. Those were the only options available until recent RDM-specific software tools helped them work more systematically.

Working ad hoc with tools not designed specifically for the job naturally leads to problems. The National Institute of Standards and Technology (NIST) estimates that 70 percent of software defects are introduced in the requirements phase [3]. The later defects are found in the application lifecycle, the more expensive they are to fix. This issue is compounded in agile because if each iteration is bogged down with defects from the start how are the teams meant to move forward and isn't one of the aims of agile to produce higher quality software?

So what is the real cost of weak RDM to business?

According to voke Inc.'s recent Business Analyst Survey, a software development project can cost anywhere between $1 million and $20 million. [4] An average project typically has the following profile:

• People per project: 75
• Project duration: 17.2 months
• Cost per project: USD$3.2 million

So, based on an average project spend of USD$3 million and factoring in the estimated effect of poor RDM, an average project could end up costing as much as USD$5.87 million-nearly double its original cost. Furthermore, if we estimate that this happens in 5 out of 10 major projects per year, that is an estimated total yearly cost of almost USD$30 million. That kind of money does not merely affect IT and software development. That level of unneeded expenditure affects every part of the business and the overall bottom line.

Superior RDM, superior project results.

The pillars of good RDM: Business analysts and software quality managers

As we've stated, poor RDM introduces a wide range of negative effects to business and IT. While defining and managing quality requirements and user stories early in the software development lifecycle helps verify that the final software or application product delivers what the business needs and customers want-effectively and efficiently, it also mitigates release date extensions and costly fixes later that may negatively impact resources and business-critical functions.

Applying effective management of requirements used to be the realm of the business analyst. However, experience has shown that requirements are more accurately defined when a joint effort between business analysts and software quality managers exists. With agile this even more true as in agile all stakeholders should be involved in the development of the user story so that it is properly estimated and defined so it can be auctioned by DEV and QA. Here is a quick look at the general responsibilities of the different stakeholders involved in the life of a requirement / user story:

Business analysts must properly:

• Write a succinct user story in the business language
• Define unambiguous requirements
• Establish the business value of each requirement
• Quantify the risk associated with each requirement
• Understand the dependencies of each requirement

Software quality managers have critical questions to answer in relation to the requirements business analysts define:

• Are the requirements verifiable when implemented?
• Are the requirements realistic, and how can they be implemented and tested?
• Where do I assign testing resources for increased

Developers should:

• Be involved in the definition and estimation of the requirement to ensure realistic times are allocated to the user story for development purposes
• Make sure they have enough detail in the user story to start developing

All stakeholders manage requirements changes during the entire application lifecycle. Together they must:

• Determine how a requirements change affects other requirements
• Figure out which tests are affected by requirements changes
• Decipher if changes introduce new risks and the level of those risks
• Calculate how changes affect development schedule and release

When business analysts work in unison with other SDLC stakeholders using strong requirements management practices, they can reduce changes, defects and delays and potential disruptions in the application lifecycle can be smoothed out.

Everyone in the application lifecycle wins with strong RDM

Positive results from strong RDM are not limited to business analyst's. Concrete requirements definition and management help deliver a product that is more in line with business needs, budgets, and schedule. It does this by helping everyone in the application lifecycle stay on task and add more value to the overall project:

• Business analysts can show stakeholders why certain requirements take precedence over others
• Designers know exactly which application characteristics, such as performance, scalability and usability, to emphasize and why
• Coders understand the level of resources they should devote to developing specific functionalities
• Software analysts can assign testing resources more efficiently based on requirements importance
• Test planners can determine the level of test effort necessary for each requirement. Plus, they can determine if reducing or increasing test efforts is justified given the business value of each requirement.

If more focus on RDM is encouraged and implemented from the top down, not only are projects more likely to meet intended business metrics, but also all the players involved have a better understanding of what is required of them, what they need to accomplish, and why. Which ultimately leads to a team that is armed with the information it needs to develop software that successfully lines up with business and user expectations.

So what is the industry waiting for? It is time to get a handle on the intricacies of requirements definition management and implement them.

Understanding the phases of RDM

Successful RDM implementation is a phased approach. For business to really get the most out of employing stronger requirements definition management practices, it is important to understand and utilize the specific phases of each. With a working knowledge of each of these phases, it is quite easy to implement more effective RDM throughout the application lifecycle.

Requirements development phases

Elicitation is the stage where business analysts gather the requirements (sometimes called trawling) and deliver them to the product backlog for assessment.. Requirements elicitation practices typically include JAD (joint application development) techniques such as interviews, questionnaires, user observation, workshops, brainstorming, use cases, role-playing, and prototyping and in agile especially this process will involve many contributors.

Elaboration stage adds more depth to the meaning of each requirement or user story maybe breaking it down from epic to user story to task or to technical details. Methods used by the business analyst in this stage include developing use cases in rich text, creating flow diagrams, class models, GUI mock-ups, and assigning business rules. The elaboration phase can also help to address known risk factors and establish/validate the system architecture.

Validation verifies that requirements are complete (and testable). The requirements document is checked for ambiguity, conflicts and errors, and so on and developers and testers should check the "fit criterion" associated with the user story. Techniques used at this stage include discussions, simulations, and face-to-face meetings.

Acceptance is the final stage in the requirements definition lifecycle and occurs only when the requirements have been verified and accepted by all the stakeholders. It is here that the business analysts create a baseline of the requirements and they are allocated to releases and iterations so that technical development can start and test planning begin.

Requirements management phases

Requirements prioritization phase gives hierarchy to a project's requirements set. Requirements should be prioritized based on customer need and business risk.

Establishing each functionality's relative importance enables the greatest product value to be delivered at the lowest cost. Collaboration between the business and IT is key here. IT does not always know which requirements are most important to the business, and the business cannot always judge the cost and technical difficulty associated with each requirement. This phase also adds objectivity to the application lifecycle. Too often individuals believe their requirement is most important due to a context-skewed perception of that requirement.

Traceability deals with the association that exists between requirements and other entities in the lifecycle. These relationships can exist on many levels in the context of requirements (user stories)

• Requirement to requirement
• Requirement to business process
• Request to test
• Requirement to defect

Overall, traceability between requirements and other project artifacts allows a business analyst to manage scope creep and verify all requirements have been met.

Change is a requirement alteration, addition, or deletion. A change can occur at most anytime and for a multitude of reasons. Some of the more common ones are listed here:

• Missed functionality : A stakeholder working with an existing system could simply realize that it is missing a feature - a new user story will likely be added to the backlog
• New defects found: A bug, or more importantly the need to address the bug, should also be considered a requirement.
• Incomplete understanding: The business or IT realizes they do not understand their actual need fully. It is common to show a stakeholder your working system to date only to have them realize what they asked for really is not what they want after all. This is why active stakeholder participation and short iterations are vital.
• Politics: The political landscape within an organization is always dynamic. When the balance of power shifts amongst stakeholders, so may priorities. This often motivates changes to requirements.
• Marketplace changes: For instance, a competitor releases a similar product which implements features your product does not.
• Legislation changes: New legislation may require new features, or changes to existing features, in your software.

The main role of requirements management is to control and manage the impact of changes to the defined operational need so that all stakeholders in the lifecycle have visibility into what alterations have been made.

Status tracking is made possible through traceability. Having the link between requirements and other assets allows the business to get a better idea of the true quality of the application and its ability to go live. Similarly, comparing the number of requirement changes to baseline, and tracking how many defects are associated with requirements, shows the business analyst how accurate requirements were in the first place. Too many changes or defects are an indication that the requirement may be inaccurate-the sooner this is identified the better.

The phases of requirements definition and management may appear tedious. However, the fallout of omitting or glossing over them is infinitely more expensive to business and IT when defects and delays appear. That is why businesses are starting to take a look at applying RDM more systematically and thoroughly.

A different view of the application lifecycle

Why wouldn't business focus on RDM throughout the application lifecycle?

Forward-thinking organizations are already applying RDM across all phases of the application lifecycle. But even more could. Why aren't they?

First, it is quite common in the industry to look at the application lifecycle management (ALM) process through only a technology and development lens. This is seemingly where all of the action is. Second, there are resource investments required to implement strong RDM practices. However, those investments are nowhere near the costly consequences of weak RDM. From my point of view the recipe to success means defining the right requirements to work on and selecting the right technology to achieve the businesses goals within the right timeframes.

However, it doesn't need to be difficult. With software solutions now on the market to help stakeholders manage requirements and many solutions providing hooks into other SDLC tools in particular aimed at bringing the business analyst, the tester and the developer closer together, it has never been easier to implement better RDM practices.

References

[1] B. Boehm and V. Basil, "Software Defect Reduction Top 10 List," IEEE Computer, January 2001

[2] Gartner, From Concept to Production, Software Changes and Configuration Management, April 2008 Management,

[3] NIST 2002 RTI Project 7007.011

[4] voke Inc.'s recent Business Analyst Survey

---

Related Methods & Tools articles

Agile Requirements

Requirements for Outsourcing

Real Reuse for Requirements

Non-Functional Requirements: Do User Stories Really Help?

---

More Requirements, Agile Software Development and Project Management Knowledge

Scrum Expert

Project Management Planet

Click here to view the complete list of archived articles

This article was originally published in the Summer 2010 issue of Methods & Tools