Integrating Requirements

into Software Development

How requirements plays a prominent role in

Microsoft Visual Studio 2005 Team System.

W h i t e Pa p e r
June 2006
 Integrating requirements into software development.

Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Requirements and Rework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Key Requirement Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Requirements Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Strategies for Better Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Assessing Return on Investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

A Practical Requirements Definition and Management Solution for

Microsoft Visual Studio 2005 Team System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

The Borland Approach to Transforming Requirements Definition and Management . . . .16

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

2
 Integrating requirements into software development.

Executive Summary
By now, it is well known that shortcomings in requirements definition and management lead to excessive rework on software
projects and products that fail to achieve full customer satisfaction. A closer look at their own software organizations can help
managers at all levels identify pain points related to how requirements are elicited, analyzed, specified, validated, and managed.

Software requirements definition and management is a communication-intensive activity that involves, at minimum, analysts,
architects, developers, testers, business stakeholders, and end users. Effective communication demands skilled requirements ana-
lysts, effective practices for requirements definition and management, and tools to assist with these critical activities.
The number of vested parties involved with requirements can lead to a variety of communication problems, including miscom-
munication between users and analysts, misunderstandings between analysts and developers, ineffective decision-making, and
inaccurate tracking of requirements status, all of which add extraneous time and cost to software projects.

This paper describes key requirements definition and management issues that affect nearly every software and systems develop-
ment project. Practical strategies and an effective solution to help address many common problem areas are outlined by way of
example, using a day-in-the-life scenario of a fictitious company, AdventureWorks. The roles of project manager, analyst, archi-
tect, and developer are examined when the company uses Microsoft Visual Studio 2005 Team System in conjunction with
Borland CaliberRM for Microsoft Visual Studio 2005 Team System, a comprehensive analyst role for Microsofts develop-
ment suite.

Requirements and Rework

Software development involves roughly 50 percent computing and 50 percent communication. Unfortunately, most teams are
better at computingrequirements, however, are almost entirely about communication. Because there are many links in the
requirements communication chain, a breakdown in any of these links leads to significant problems. For example, if an analyst
misunderstands stakeholder input about requirements, if important requirements information does not surface, or if an analyst
and developer do not share the same understanding about requirements, the resulting product fails to meet customers needs.

The inevitable outcome of requirements errors is time-consuming and costly rework. Experts report that rework can consume
30 to 40 percent of the total effort expended on a software project. Multiple studies have indicated that nearly 50 percent of the
defects identified on software projects can be traced back to errors in the requirements. One analysis of the potential return on
investment from better requirements suggests that requirements errors can consume between 70 and 85 percent of all project
rework costs.1 It can cost up to 110 times more to correct a requirements defect found in operation than it would if that same
defect had been discovered during requirements definition.2

1 Leffingwell, Dean. 1997. Calculating the Return on Investment from More Effective Requirements Management. American Programmer 10(4): 1316. 3
2 Grady, Robert B. 1999. An Economic Release Decision Model: Insights into Software Project Management. In Proceedings of the Applications of Software
Measurement Conference, 227239. Orange Park, Fla.: Software Quality Engineering.
 Integrating requirements into software development.

Even though project teams often think they do not have the time to effectively elicit and capture requirements, they always seem
to find the time, people and money to fix problems found in a delivered product. Therein lies the leverage for improving any
organizations requirements definition and management approaches. When teams use better practices and better tools to facili-
tate requirements communication, fewer defects attributable to requirements errors will be introduced. As a result, rework will
be reduced, thereby improving delivery time and quality with products that better meet business objectives.

Key Requirements Issues

Over the years, five universal truths have surfaced about software requirements definition and management. The following
statements are helpful for software development organizations to keep in mind when considering how best to improve the
requirementsand communicationfor their projects.

If teams dont get requirements right, it doesnt matter how well they execute the rest of the project.
Effective requirements definition enables teams to determine the mix of product capabilities and characteristics that will best
deliver this customer value. Adequately exploring and crafting requirements into a set of product features and attributes, and
refining these during early work, help to ensure customer needs are being met throughout the project lifecycle.

Requirements definition is a discovery and invention process, not just a collection process.
In reality, requirements definition is an exploratory activity; requirements elicitation is an iterative process. Teams that are pre-
pared to iterate most often elicit the most accurate requirements.

Customer involvement is the most critical contributor to software quality.

Various studies confirm that inadequate customer involvement is a leading cause of failure in software projects. . Customer
involvement requires more than a workshop or two early in the projectit necessitates input from customers early and often in
the requirements process.

Change happens; managing change is critical.

It is inevitable that requirements will change as business needs evolve, new users or markets are identified, business rules and
government regulations are revised, and operating environments change. Teams that anticipate and accommodate changes min-
imize disruption and cost to the project and its stakeholders.

Teams are never going to have perfect requirements.

Requirements are never finished or complete. Effective teams define a baseline and then follow a sensible change control process
to modify requirements once a baseline is established.

4
 Integrating requirements into software development.

Requirements Processes
Good requirements practices can accelerate software development. The process of defining business requirements aligns the
stakeholders with shared vision, goals and expectations. Substantial user involvement in establishing and managing changes to
agreed upon requirements increases the accuracy of requirements, ensuring that the functionality built will enable users to per-
form essential business tasks.

Software requirements engineering is comprised of requirements definition and requirements management:

Requirements Definition is the collaborative process of collecting, documenting and validating a set of requirements that
constitute an agreement among key project stakeholders. Requirements definition is further subdivided into the critical
process areas of elicitation, analysis, specification and validation processes.

From a pragmatic perspective, requirements definition strives for requirements that are good enough to allow the team to
proceed with design, construction and testing at an acceptable level of risk. As discussed, the risk is the threat of having to
do expensive and unnecessary rework.

Requirements Management involves working with a well-defined set of product requirements throughout the products
development process and its operational life. It also includes managing changes to that set of requirements throughout
the project lifecycle.

In practice, requirements management includes selecting changes to be incorporated within a particular release and ensur-
ing effective implementation of changes with no adverse impact on project schedule, scope, budget or quality.

An effective requirements definition and management solution creates accurate and complete system requirements, while help-
ing organizations improve communications in an effort to better align IT with business needs and objectives. It includes a set
of industry best practices for each category, as well as tools to enable and accelerate requirements activities.

5
 Integrating requirements into software development.

Strategies for Better Requirements

A variety of practices can help software teams bridge communication gaps and do a better job of understanding, documenting
and communicating customer needs. Figure 1 illustrates, and process areas below describe, several best practices in the cate-
gories of requirements elicitation, analysis, specification, validation and management.

Figure 1. Best practice for each requirements category

1. Requirements Elicitation
Define the product vision and project scope

Identify stakeholders, customers and users

Choose elicitation techniques

Explore user scenarios

2. Requirements Analysis

Create visual analysis models

Build and evaluate prototypes

Prioritize requirements using attributes

6
 Integrating requirements into software development.

3. Requirements Specification

Look for ambiguities in text-based requirements

Store requirements in a shared, central database for better communication. Sophisticated requirements management
tools, such as Borland CaliberRM, make it easy to store and retrieve additional information about different classes of
requirements information. A shared online database can better facilitate communication and collaboration among distrib-
uted teams by being kept current on changes and shifting prioritization.

Trace requirements into design, code, and tests

4. Requirements Validation

Review the requirements

Create test cases from requirements

5. Requirements Management

Manage requirements versions

Adopt a change control process

Perform requirements change impact analysis

Store requirements attributes

Track the status of each requirement

Assessing Return on Investment

To estimate the payback that better requirements can bring to your organization, consider these questions:

What fraction of your own development effort is expended on rework (due to miscommunication)?

How much does a typical customer-reported defect cost your organization? A defect found in system testing?

What fraction of user-reported defects and what fraction of defects discovered during system testing originate in require-
ments errors?

How much of your organizations maintenance costssuch as defect correction and unplanned enhancementscan you
attribute to missing requirements or other requirement defects?

How much do you think your organization could shorten its delivery schedules if your project teams could reduce require-
ments defects by 50 percent?

7
 Integrating requirements into software development.

Aside from obvious cost benefits, improving requirements approaches leads to other valuablethough less tangibleout-
comes. Fewer miscommunications on a software project reduce the overall level of chaos. Less chaos lowers unpaid overtime,
increases team morale, boosts employee retention and improves the teams chances of delivering on time. Best of all, these bene-
fits ultimately lead to higher customer satisfaction.

A Practical Requirements Definition and Management Solution

for Microsoft Visual Studio 2005 Team System
Borland helps global organizations maximize the business value of software and accelerate the path to Software Delivery
Optimization (SDO) by transforming software development into a managed business process to increase control, predictability,
visibility, and efficiency over the entire software delivery process. One of the core processes critical to achieving SDO is effective
requirements definition and management.

The Borland Requirements Definition and Management Solution is the only scalable, integrated enterprise requirements definition
and management solution designed to appropriately align people skills, process improvements, and award-winning technology to
deliver essential capabilities that significantly increase the probability that a project is delivered right the first time.

Borland CaliberRM for Microsoft Visual Studio 2005 Team System is an enterprise requirements management system optimized
for development teams using Microsofts Application Lifecycle Management Tool, Visual Studio 2005 Team System. CaliberRM
provides an analyst role for Microsofts development suite that enables development teams to gather, track and manage require-
ments directly within their Visual Studio 2005 Team System environment. Borland Caliber DefineIT helps ensure that software
requirements are defined completely and accurately from the beginning by providing users and analysts the ability to collaborate in
capturing detailed business scenarios and validating the requirements through visual storyboards. Used together, these Borland
solutions maximize the contribution of the analyst within the development process and enable all stakeholders to collaborate more
effectively. This ensures that the software ultimately delivered aligns effectively with the business demands.

A day in the life of requirements definition and management: AdventureWorks

By way of example, the following story concerns a fictitious company (also used in Visual Studio 2005 Team Systems illustrative
demo) called AdventureWorks. A scenario of requirements refinement and management is described through the roles of
Project Manager, Analyst, Architect and Developer. Lets watch as our story unfolds.

Successful role-based application lifecycle with Microsoft and Borland

AdventureWorks has a large portfolio of software development projects that are underway and in the approval process.
Appreciating that software development is a complex and continually evolving process, AdventureWorks employs a solid devel-
opment environment and philosophy that work well with the companys culture. The company uses Microsoft Visual Studio
2005 Team System as its primary environment because it enables higher productivity by providing a platform that facilitates
team development and integrates with third party tools; in particular, those already adopted by the companys project teams.
Borland Caliber DefineIT and Borland CaliberRM for Microsoft Visual Studio 2005 Team System are used to enable and opti-
mize AdventureWorks Requirements Definition and Management process. Caliber DefineIT ensures that requirements are
defined completely and accurately from the beginning by allowing the simple creation and execution of visual scenarios.
CaliberRM for Visual Studio 2005 Team System is used for its seamless integration with Visual Studio 2005 and because it pro-
vides a comprehensive project analyst role that facilitates collaboration and communication for its projects. AdventureWorks is

8
 Integrating requirements into software development.

dedicated to maximizing its software investments by managing end-to-end software delivery lifecycles, and has adopted IT
management and governance software, Borland Tempo, to help with Demand and
Portfolio Management.

Bob is a project manager at AdventureWorks. He is in charge of several key software development projects for the company. As
project manager, Bob is responsible for the overall success of his projectsdefined as on time, within budget, and delivered to
the customers specification. In order to achieve this, Bob relies heavily on effective communication within his team and timely
execution. His responsibilities as project manager include:

Project scheduling and planning

Project resource management

Work request prioritization and assignment

Project status

Change impact analysis

At the start of his day, Bob logs in to Tempo and immediately gets a list of new requests from the stakeholders on one of his
projects. The Tempo Demand Management feature provides a single location for user communities to make requests of IT, and
ensures that the information required to evaluate and properly respond to these requests is collected and documented up front.
Because the project is still in its early stages and stakeholders are actively collaborating by way of feedback, Bob is not surprised
to see two new requests come in:

Add search functionality

Add credit card validation

Bobs highest priority at this point is to manage his portfolio of requests and projects by determining how these new requests
rank in priority as compared to other requests already in the system. Tempo provides Bob with a much more objective and less
time-consuming process than the companys former ad hoc, manually intensive process for gathering data and calculating
return on investment (ROI). With Tempo, Bob can clearly see that these new requests rank higher than others by viewing a
selection of key charts and graphs that indicate critical determinants such as ROI, Cost Benefit, and Risk Analysis. With a con-
cise understanding of the level of urgency, Bob immediately approves these requests for analysisthe next stage in the IT
request processwith a couple of clicks of the mouse. (Figure 2 shows a screen shot of this approval.) In the meantime, Tempo
sends an e-mail alert to Bobs project analyst, Penny.

9
 Integrating requirements into software development.

Figure 2. Tempos IT process automation capabilities streamline the request evaluation and approval process by enforcing
policy, and support reliable and consistent execution via automated online and e-mail alerts to specific users when action is
required. This improves the teams efficiency and responsiveness.

In her role as project analyst, Penny, like Bob, manages several of AdventureWorks ongoing software projects. Pennys chief
responsibility is to make sure that each projects customer requirements are clearly, accurately, and completely elicited, specified,
validated, and communicated so that the software is delivered right the first time. To that end, the analysts collaboration with
all key stakeholders, including the development team, is critical to the success of the project. As she starts her day at
AdventureWorks, Penny logs into Microsoft Outlook and notices two project requests for Bobs project. Pennys top priority is
to ensure that the requirements for Bobs new requests are defined completely and accurately before passing it on to the project
architect.

Pennys first course of action is to elicit the details of these requests from the project stakeholders, so she calls a meeting with
the users who created the requests. Penny uses Caliber DefineIT during the meeting to collaboratively capture user scenarios in
business language. After the initial meeting, Penny adds details to the scenarios using artifacts such as screenshots, prototypes,
Microsoft Excel spreadsheets and Microsoft Word docs to deliver well-defined and understandable requirements. Armed with
these detailed scenarios, she holds subsequent meetings with the stakeholders (as many as needed within 24 hours of the first
meeting) to execute storyboards to aid in the review process. With these, stakeholders can effectively determine if the require-
ments are accurate and complete, as shown in Figure 3. Although this process may take a couple of days, AdventureWorks has
learned that time spent producing validated requirements with stakeholders during the requirements definition phase saves sig-
nificantly more time and money in rework later in the project. Once the requests are validated, Penny publishes the search func-
tionality and credit card validation requests into the CaliberRM central repository enabling all team members instant access to
the most up-to-date requirements.

10
 Integrating requirements into software development.

Figure 3. Business stakeholders can clearly envision the system by reviewing software requirements through execution of
visual storyboards. This leads to accurate and complete requirements that communicate the voice of the customer through-
out the software delivery cycle.

Penny reviews the new requirements in the CaliberRM repository and alerts the projects architect by adding the two work
items into Visual Studio 2005 Team System directly from CaliberRM (as shown in figure 4). The work items are also linked back
to the requirements in CaliberRM so the architect can easily find the associated details for each.

Figure 4. The analyst leverages the rich requirements management environment in CaliberRM so that architects,
developers,and testers have immediate access to requirements details from the CaliberRM client for Visual Studio 2005
Team System.

11
 Integrating requirements into software development.

Bill is the architect of Bobs project. Bill has designed the architecture for this AdventureWorks project using Visual Studio 2005
Team System. His primary objective is to ensure that all application designs adhere to the companys architectural standards,
including the use of Web Services in conjunction with the companys service-oriented architecture (SOA) initiative.
Additionally, Bill must translate requirements into work items in such a way that developers understand their responsibilities
and stay focused. As Bill gets started on his day, the first task at hand is to review the work items list where he notices a new
entry linked to CaliberRM requirements (as shown in figure 5). To get a clear understanding of what the impact these require-
ments will have on the architecture and what work will be entailed in building these features, Bill reviews the requirements from
within Visual Studio 2005.

Figure 5. Requirements can be linked to work items so that team members can instantly retrieve the details of requirements
related to their assigned work items.

After a short review, it is clear to Bill what needs to be done. For the search functionality requirement, he adds the following
specific work item tasks:

Create backend search logic

Create user interface component

Add search user interface to default page

For the credit card validation, he adds:

Implement Luhn Algorithm

Account for credit card types

Bill also creates traces from the requirements to the new work items so that the developer has all the information needed to
execute these features to the users specification. Bill then performs a couple of design tasks to simplify the developers job and
enforce design standards. The first thing Bill does is create an XML Web Service by simply dragging and dropping within Visual

12
 Integrating requirements into software development.

Studio 2005 Team System, which automatically generates the initial code. The second task of plugging the new XML Web
Services into the existing architecture is also a simple drag, drop, and connect.

Sue is a software developer on Bobs project team. Her job is to write secure, high quality code and Visual Studio 2005
Team System helps by making testing an integrated part of daily development. Sue is alerted to the new work items and require-
ments that Bill has modified and passed along. She has instant access to the most up-to-date work item and requirement data
right from Visual Studio 2005 Team System, which gives her clear direction on how to write her code,
as shown in Figure 6.

Figure 6. CaliberRM for Visual Studio 2005 Team System provides direct access to the latest requirements including user
defined tabs and attributes.

Visual Studio 2005 Team system supports many types of software development. The traditional way is to write the code first,
and then test it. Should Sue choose this approach, Visual Studio 2005 Team System provides the features right at her fingertips
to unit test any code she has written. In addition, she can measure the effectiveness of her tests by looking at code coverage data.

Another approach Sue could use is test-driven development (TDD), which helps design as well as code. This programming
technique is heavily emphasized in Extreme and Agile programming by first writing the tests and then implementing the code
to make it pass. TDD is not a method of testing, but rather a method of designing software. This approach most often results in
a high degree of code coverage; Visual Studio 2005 Team Systems integrated code coverage data can tell Sue exactly what code
she is not testing and if she needs more data. This helps drive the tests with data, instead of having to always hard code it.
Regardless of her coding method, Visual Studio 2005 Team System can help Sue efficiently, write, test, and debug her code.

As each of Bobs team members work through their role in the project, Bob needs to understand the project status at any given
time and be able to report back to management. With CaliberRM for Visual Studio 2005 Team System, all relevant requirements
are linked directly to the work items within Visual Studio 2005 Team System, which allows Bob to see supporting details such
as: how many tasks have been completed for the search functionality item? Who completed the task? Was it tested? When was it
last worked on? This level of detail gives Bob the information he needs to make sure that the project is on track and all stake-
holders are informed.

13
 Integrating requirements into software development.

Because meeting end-user requirements is the primary concern of the company, it is not uncommon for Bob to receive requests
from management asking what impact a new feature might have on the overall cost and delivery schedule of a project.
CaliberRM allows Bob to easily run a report that creates a Traceability Diagram, or graph, that allows him to see a projects
requirements and work items all in one view (as shown in Figure 7). This real-time impact analysis is a method of traceability
visualization that helps management immediately understand the scope of analysis required to gauge the effect of a require-
ments change. Without these CaliberRM capabilities, Bob would have spent many man-hours trying to estimate the financial
and scheduling effects on this project.

Figure 7. As changes to requirements are proposed, CaliberRM clearly shows potential impact to other project assets and
ultimately to project costs and timeline.

Successful requirements refinement and management can be accomplished using the smart combination of Borland RDM solu-
tions with Microsoft Visual Studio 2005 Team System. This hand-in-hand, role-based approach to the critical process of
requirements definition benefits each of the team members in the following way:

Project Manager can:

Take control over demand and project portfolio

Receive qualified requests from user communities

Easily prioritize requests based on critical determinants

Maintain clear insight into project details and status

Provide on-demand status reports, including change impact analysis

14
 Integrating requirements into software development.

Analyst can:
Define requirements accurately and completely

Elicit concise requirements by collaboratively capturing detailed business scenarios and getting instant feedback

Prioritize requests that are critical to delivering highest business value in shortest time

Add detail through use cases, business rules and models, and prototypes

Execute and simulate visual storyboards for clear and accurate requirements definition

Architect can:
Ensure compliance with companys design standards

Provide requirements traceability across the project lifecycle

Keep in synch with developers to keep the team focused on customer specifications

Communicate the voice of the customer at every step

Developer can:
Access the most up-to-date work item and requirement data and eliminate re-work

Stay on task with clear, understandable direction and links to requirements details

Bob is able to have a firm grasp on managing his portfolio of projects using Borland Tempo to see at a glance what new, quali-
fied requests are being asked by his user communities and what priorities these requests should take. He is also able to investi-
gate details and immediately produce the status of any project, including powerful impact analysis data for furthering trade-off
discussions. Our analyst, Penny, can perform concise requirements elicitation and specification by collaboratively capturing user
scenarios with stakeholders using Caliber DefineIT. CaliberRM provides the central repository where validated requests reside,
and Penny can link these to the Microsoft development environment using CaliberRM for Visual Studio 2005 Team System.
Project architect, Bill, also uses CaliberRM to trace requirements to new work items in Visual Studio 2005 Team System so that
the developer, Sue, can choose the appropriate type of software development method she desires to efficiently write, test, and
debug her code.

Microsoft Visual Studio 2005 Team System combines powerful role-based tools, and customizable processes and guidance
to help teams better manage their software development lifecycle. Utilizing the ability to integrate the Borland CaliberRM fami-
ly of requirements definition and management products, teams can maximize the contribution of the analyst within
the development processenabling all stakeholders to collaborate more effectively.

15
 Integrating requirements into software development.

The Borland Approach to Transforming

Requirements Definition & Management
The Borland approach to requirements definition and management is unique in that it takes into account an organizations
process maturity by leveraging industry best practices to evaluate current performance and identify specific areas for improve-
ment. Borland does this by using the proven Borland Accelerate Framework, a disciplined, four-phase improvement approach
that incorporates the five principles of a successful transformation and effectively aligns people, process and technology to max-
imize results.

Using the Framework and best practices process assets as a guide, Borland supports organizations at various stages in their
requirements definition and management transformation.

Phase I, Borland experts help define goals using executive workshops and other activities that result in clearly defined
objectives.

Phase II, Borland experts help organizations architect their approach and prioritize the key solution components, includ-
ing critical process modules, required technology configurations and skill development plans.

Phase III, Borland helps organizations develop, pilot and deploy the enterprise-wide requirements definition and manage-
ment solution defined in Phase II, including implementing the process, installing and configuring the technology and
training users.

Phase IV, Borland helps organizations validate results against the goals defined in Phase I and identify gaps that need to be
addressed in the next improvement cycle.

With the Borland Solution, typical organizations will move from an ad hoc requirements process consisting of manual
processes, word processing documents and ineffective requirements management systemsto a requirements lifecycle focus
with a fully integrated system for managing each core process area described. As a result, organizations can more effectively
define requirements and better manage the constant barrage of requirements changes that occur within the application lifecycle.

Summary
The Borland Solution delivers everything organizations need to successfully implement the five critical Requirements Definition
and Management processes into an organization for maximum impact, quickly and with a minimum of risk.
The solution can be tailored to reflect an organizations maturity and goals, which is crucial to the ultimate success of
any initiative.

The Borland Requirements Definition and Management Solution is an integrated enterprise requirements definition and man-
agement solution that enables stakeholders across the organization to collaborate effectively so that projects are delivered on
time within budget and to specification. CaliberRM for Microsoft Visual Studio 2005 Team System provides a comprehensive
analyst role for Microsofts development suite, and enables development teams to gather, track and manage requirements
directly within their Visual Studio 2005 Team System environment.

Borland is the leading vendor of Open Application Lifecycle Management (ALM) solutions - open to customers' processes, tools and platforms
providing the flexibility to manage, measure and improve the software delivery process.

Copyright 2007 Borland Software Corporation. Borland and all other brand and product names are service marks, trademarks,
or registered trademarks of Borland Software Corporation or its subsidiaries in the United States and other countries. All other marks
are properties of their respective owners. 24728

www.borland.com