requirement management30

7/29/2019 Requirement Management30

1/18

Requirement management:

Definition

Introduction

The purpose of requirements management is to ensure an organization's documents, verifyand meet the needs and expectations of its customers and internal or external

stakeholders.[1]Requirements management begins with the analysis and elicitation of the

objectives and constraints of the organization. Requirements management further includes

supporting planning for requirements, integrating requirements and the organization for

working with them (attributes for requirements), as well as relationships with other

information delivering against requirements, and changes for these.

The traceability thus established is used in managing requirements to report back

fulfillment of company and stakeholder interests, in terms of compliance, completeness,

coverage and consistency. Traceabilities also support change management as part of

requirements management in understanding the impacts of changes through requirementsor other related elements (e.g., functional impacts through relations to functional

architecture), and facilitating introducing these changes.[2]

Requirements management involves communication between the project team members

and stakeholders, and adjustment to requirements changes throughout the course of the

project.[3]To prevent one class of requirements from overriding another, constant

communication among members of the development team is critical. For example, in

software development for internal applications, the business has such strong needs that it

may ignore user requirements, or believe that in creatinguse cases, the user requirements

are being taken care of.

What is business requirement?

The termsBusiness Requirement, User Requirement,Functional Requirementand just

plainRequirementare generally used interchangeably.

A requirement is defined as a condition or capability to which a system must conform. It

can be

any of the following:

A capability needed by a customer or user to solve a problem or achieve an objective

A capability that must be met or possessed by a system to satisfy a contract, standard,

specification, regulation, or other formally imposed document

A restriction imposed by a stakeholder.
http://en.wikipedia.org/wiki/Requirements_management#cite_note-Stellman05-1http://en.wikipedia.org/wiki/Requirements_management#cite_note-Stellman05-1http://en.wikipedia.org/wiki/Requirements_management#cite_note-Stellman05-1http://en.wikipedia.org/wiki/Requirements_management#cite_note-2http://en.wikipedia.org/wiki/Requirements_management#cite_note-2http://en.wikipedia.org/wiki/Requirements_management#cite_note-2http://en.wikipedia.org/wiki/Requirements_management#cite_note-PMBOK08-3http://en.wikipedia.org/wiki/Requirements_management#cite_note-PMBOK08-3http://en.wikipedia.org/wiki/Requirements_management#cite_note-PMBOK08-3http://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Requirements_management#cite_note-PMBOK08-3http://en.wikipedia.org/wiki/Requirements_management#cite_note-2http://en.wikipedia.org/wiki/Requirements_management#cite_note-Stellman05-1


2/18


3/18

Methodologies and Approach

Requirements are developed using a structure approach calledRequirements

Management.

Requirements managementis the process ofdocumenting,analyzing,tracing,prioritizingand agreeing on requirements and then

controlling change and communicating to relevant stakeholders. It is a continuous process

throughout a project. A requirement is a capability to which a project outcome (product or

service) should conform.

The Requirements Management Process generally consists of 4 steps. These steps are

typically known as 1) Gathering; 2) Analyzing; 3) Organizing; and 4) Validating.

The Gathering, Analyzing, Organizing and Validating steps are considered the

Analysis part of the overallSystem Development Lice-Cycle (SDLC)approach tosoftware development.

There is also an ongoing managing activity which ensures that the requirements are

aligned with various modules and test scripts which are being developed as part of the

project. The process used for managing this alignment is known astraceability and

uses aRequirements Traceability Matrix.A good Requirements Definition approach

can also be used to support theProject Managementactivities of the project.

What are good Business Requirements?How are they structured?

Good Requirements are written independent of the system or potential system that

would be built to satisfy the need.

AGood Business Requirements Structureis made up of four distinct parts:

1. the user2. the result3. the object4. the qualifier

You must include all of these parts to ensure proper understanding of the requirement.
http://www.requirementsauthority.com/requirements-management-process.htmlhttp://www.requirementsauthority.com/requirements-management-process.htmlhttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/Requirement_prioritizationhttp://en.wikipedia.org/wiki/Requirement_prioritizationhttp://en.wikipedia.org/wiki/Requirement_prioritizationhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/requirements-traceability.htmlhttp://www.requirementsauthority.com/requirements-traceability.htmlhttp://www.requirementsauthority.com/requirements-traceability.htmlhttp://www.requirementsauthority.com/rtm.htmlhttp://www.requirementsauthority.com/rtm.htmlhttp://www.requirementsauthority.com/project-management.htmlhttp://www.requirementsauthority.com/project-management.htmlhttp://www.requirementsauthority.com/business-requirement-structure.htmlhttp://www.requirementsauthority.com/business-requirement-structure.htmlhttp://www.requirementsauthority.com/business-requirement-structure.htmlhttp://www.requirementsauthority.com/business-requirement-structure.htmlhttp://www.requirementsauthority.com/project-management.htmlhttp://www.requirementsauthority.com/rtm.htmlhttp://www.requirementsauthority.com/requirements-traceability.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://en.wikipedia.org/wiki/Requirement_prioritizationhttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/Requirements_analysishttp://www.requirementsauthority.com/requirements-management-process.htmlhttp://www.requirementsauthority.com/requirements-management-process.html


4/18

Sure, the solution or system specification may very well be to send an email, but

alternatives should be identified and valuated. For example, one alternative might be

to fax the customer the order confirmation. This may be the best cost effective

solution for the amount of orders received through this channel.

Keeping your requirement at the business level will ensure a better approach toproblem solving and ensuring determining the right solution.

Good Business Requirements must contain one and only one requirement. Do not

create requirement statements which containMultiple Requirements.Multiple

Requirement statements cause too much confusion and are hard to measure. Every

effort must be made to ensure only one single need is expressed in each requirement

statement.

Types of REQUIREMENT

Functional Requirement (Function)

A Functional Requirement is a requirement that, when satisfied, will allow the user to

perform some kind of function. For example:

The customer must place an order within two minutes of registering

For the most part, when people are talking about Business Requirements, they are

referring to Functional Requirements which are generally referred to as

requirements. Functional Requirements have the following characteristics:

uses simple language not ambiguous contains only one point specific to one type of user is qualified describes what and not how

Non-Functional Requirement
http://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.html


5/18

A Non-Functional Requirement is usually some form of constraint or restriction that

must be considered when designing the solution. For example:

The customer must be able to access their account 24 hours a day, seven days a

week.

For the most part when people are talking about Constraints, they are referring to

Non-Functional Requirements. Non-Functional Requirements have the same

following characteristics:

uses simple language not ambiguous contains only one point specific to one type of user is qualified describes what and not how

Non-Functional requirements tend to identify user constraints and system

constraints. Business requirements should be kept pure and not reflect any solution

thinking.

A system constraint is a constraint imposed by the system and not dictated by a

Business Need. Since system constraints are part of a solution, they should be

documented in the System Specifications document. For example:

The system must be unavailable from midnight until 1:00am for backups.

This is a restriction imposed by the system and not a user request.

Some people like to further classify the Non-Functional Requirments into such

categories as Performance Constraints, Design Constraints, Quality Constraints, etc..

This classification can be used if there is deemed to be a benefit.

The Requirements Traceability Matrix (RTM) captures the completeuser and system requirements for the system, or a portion of the system. The RTM captures allrequirements and their traceability in a single document, and is a mandatory deliverable at the conclusion ofthe lifecycle.

The RTM is used to record the relationship of the requirements to the design, development, testing andrelease of the software as the requirements are allocated to a specific release of the software. Changes tothe requirements are also recorded and tracked in the RTM. The RTM is maintained throughout the lifecycleof the release, and is reviewed and baselined at the end of the release.It is very useful document to track Time, Change Management and Risk Management in the Software


6/18

Development.Here I am providing the sample template of Requirement Traceability Matrix, which gives detailed idea ofthe importance of RTM in SDLC.

The RTM Template shows the Mapping between the actual Requirement and User

Requirement/System Requirement.

Any changes that happens after the system has been built we can trace the impact of the change on the

Application through RTM Matrix. This is also the mapping between actual Requirement and Design

Specification. This helps us in tracing the changes that may happen with respect to the Design Document

during the Development process of the application. Here we will give specific Document unique ID, which is

associated with that particular requirement to easily trace that particular document.

In any case, if you want to change the Requirement in future then you can use the RTM to make the

respective changes and you can easily judge how many associated test scripts will be changing.

The following is the sample Template of Requirements Traceability Matrix.

The Requirements Management Process is a structured approach for the capture,

organization and management of Business Requirements. These steps are commonly

known as the Analysis phase of theSystems Development Life-Cycle (SDLC).
http://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.html


7/18

The Requirements Management Process typically consists of the following four

steps:

Gathering Analyzing Organizing Approving

Gatheringis those activities associated with the collection of the business

requirements from the various sources including document andstakeholders.

Analyzingis those activities associated with the negotiation and determination of

what the requirements actually mean and which stakeholders requirements takepriority. It determines which requirements should be addressed in this project.

Organizingis the documentation and organizing of the requirements. Normally

requirements can be classified intofunctional and non-functionalrequirements. The

document created is the User Requirements Document.

Approvingis the confirmation and signoff from thestakeholdersthat these are the

requirements they want to be addressed in this project.

Controllingis a valuable activity that aligns the Requirements Management activities

with other Project Management activities

Controlling requirements:

To be able to Control Requirements you must first have a plan. Your Requirements

Management plan is part of the overall Project Plan.

Requirements Control includes but it not limited to:

1.

Project Scope: This section explains the scope of the project and what areaswill be affected during the project

Activities: What are the activities being used in each of the Requirements

Management steps.
http://www.requirementsauthority.com/gathering-requirements.htmlhttp://www.requirementsauthority.com/gathering-requirements.htmlhttp://www.requirementsauthority.com/stakeholders.htmlhttp://www.requirementsauthority.com/stakeholders.htmlhttp://www.requirementsauthority.com/stakeholders.htmlhttp://www.requirementsauthority.com/analyzing-requirements.htmlhttp://www.requirementsauthority.com/analyzing-requirements.htmlhttp://www.requirementsauthority.com/organizing-requirements.htmlhttp://www.requirementsauthority.com/organizing-requirements.htmlhttp://www.requirementsauthority.com/functional-and-non-functional.htmlhttp://www.requirementsauthority.com/functional-and-non-functional.htmlhttp://www.requirementsauthority.com/functional-and-non-functional.htmlhttp://www.requirementsauthority.com/approving-requirements.htmlhttp://www.requirementsauthority.com/approving-requirements.htmlhttp://www.requirementsauthority.com/stakeholders.htmlhttp://www.requirementsauthority.com/stakeholders.htmlhttp://www.requirementsauthority.com/stakeholders.htmlhttp://www.requirementsauthority.com/control-requirements.htmlhttp://www.requirementsauthority.com/control-requirements.htmlhttp://www.requirementsauthority.com/control-requirements.htmlhttp://www.requirementsauthority.com/stakeholders.htmlhttp://www.requirementsauthority.com/approving-requirements.htmlhttp://www.requirementsauthority.com/functional-and-non-functional.htmlhttp://www.requirementsauthority.com/organizing-requirements.htmlhttp://www.requirementsauthority.com/analyzing-requirements.htmlhttp://www.requirementsauthority.com/stakeholders.htmlhttp://www.requirementsauthority.com/gathering-requirements.html


8/18

Will requirements management training be supplied? What methodologies willbe used?

What gathering techniques will be used (workshops, interviews, documents,etc.)?

Who will attend the various workshops? Who will be interviewed? Whatdocuments will be reviewed?

How will the requirements be analyzed? Will models be used? Or perhaps UseCases?

What software will be used to manage the requirements? What deliverables will be produced? Who will be responsible for signing and approving the requirements document?

Will a meeting or workshop be held for the approval process?

How will changes or additions be handled? How will all this activity be communicated?

Resources: This section will describe what resources need to be allocated to

Requirements Management.

Will there be enough funding in place to support the activities described in the

Activity Section? Will the right people be available at the right time? Is there a

financial commitment as well as a time commitment?

Do you require access to existing systems and their documentation?

Do we need special space available such as meeting rooms? Etc.?

2. Schedules: How long will this activity take place? When are people available?Are there time constraints such as holidays or regulatory deadlines

(e.g.January 1, 2000). When are people taking their holidays?

3. Stakeholders: Who will be affected by this project? What are their concerns orproblems? What would they like to see fixed? Are they willing to participate in

the various activities and what are their schedules?

Control Requirements Changes

Once the plan has been completed then it is used to execute the subsequent steps of

the Requirements Management process

.

You must also control subsequent changes and how they will impact the

Requirements Management activities and future SDLC phases.


9/18

How do you go about gathering requirements? So where is it that you go to get all

these Business Requirements you might ask? There are several sources for Business

Requirements.

Key sources are listed here but are not in any particular order:

Stakeholders Documentation Corporate Goals Existing systems Subject Matter Experts

There are various techniques which can be used for gathering Requirements. Some ofthese techniques help engage the participants in a meaningful discussion which gets

their thoughts flowing and paints a better picture for what the stakeholder is looking

for.

Workshops reading documents Interviews Prototypes Market Analysis Observations

The focus of the Requirements Gathering activity is to capture all the

requirements. It is not to ensure that the requirements are being expressed

properly nor is it to resolve which requirements takes priority over other

requirements. The Analysis will take care of that. Just capture all the raw

requirements you can and you will weed through them later.

Analyzing Requirements
http://www.requirementsauthority.com/subject-matter-experts.htmlhttp://www.requirementsauthority.com/subject-matter-experts.htmlhttp://www.requirementsauthority.com/subject-matter-experts.htmlhttp://www.requirementsauthority.com/subject-matter-experts.htmlhttp://www.requirementsauthority.com/subject-matter-experts.htmlhttp://www.requirementsauthority.com/subject-matter-experts.htmlhttp://www.requirementsauthority.com/observing-requirements.htmlhttp://www.requirementsauthority.com/observing-requirements.htmlhttp://www.requirementsauthority.com/observing-requirements.htmlhttp://www.requirementsauthority.com/observing-requirements.htmlhttp://www.requirementsauthority.com/observing-requirements.htmlhttp://www.requirementsauthority.com/observing-requirements.htmlhttp://www.requirementsauthority.com/observing-requirements.htmlhttp://www.requirementsauthority.com/observing-requirements.htmlhttp://www.requirementsauthority.com/subject-matter-experts.htmlhttp://www.requirementsauthority.com/subject-matter-experts.html


10/18

Analyzing requirements is one of the most critical activities of the Requirements

Management Process.

The objective of this activity is to make sure you have well formed, well written

business requirements that everyone has agreed to.

Steps that should be done in the Analyzing Requirements activity are:

1. Writing2. Classification3. Prioritization4.Negotiation

Writing

During the Gathering Requirements activity you managed to collect a bunch of raw

requirements.

A good Business Requirement is defined as a true business need and must be

independent of any system. It is composed of four distinct parts: 1) the user; 2) the

capability; 3) the object; and 4) the qualifier. It expresses a single business need.

Classification

Requirements can be classified as eitherfunctional or non-functional.

Functional requirements can be further classified into subject domains such as

shipping, ordering, billing, etc.

Non-Functional requirements can be further classified into such categories as security,

performance, availability, etc.

Prioritization

Analyzing Requirements should alsoprioritizethe requirements based on some

meaningful scale. A scale such as the following should be used:

Mandatory Desirable
http://www.requirementsauthority.com/functional-and-non-functional.htmlhttp://www.requirementsauthority.com/functional-and-non-functional.htmlhttp://www.requirementsauthority.com/functional-and-non-functional.htmlhttp://www.requirementsauthority.com/prioritizing-requirements.htmlhttp://www.requirementsauthority.com/prioritizing-requirements.htmlhttp://www.requirementsauthority.com/prioritizing-requirements.htmlhttp://www.requirementsauthority.com/prioritizing-requirements.htmlhttp://www.requirementsauthority.com/functional-and-non-functional.html


11/18

OptionalThis scale will help determine which requirements can be eliminated if it is decided to

reduce functionality due to cost constraints when designing the solution.

Negotiation

During your Requirements Gathering activity you received many different

requirements from many different stakeholders. Some of these requirements are

contradictory and need to be resolved.

In the Analyzing Requirements activity you must now look for ways to resolve any

conflicting requirements. This requires specialnegotiationtechniques. The objective of

the negotiation is to determine the overriding requirements which best represents the

business needs of the organization.

Organize Requirements

The main purpose of the Organize Requirements activity is to organize the

requirements and to produce a User Requirements document.

Reference Number

Every Business Requirement would have now been classified into various categories.

To better organize requirements we must now assign a reference number that the

requirement will be assigned for the life of the project. (e.g. FR-0010, NR-0025).

Requirement reference numbers will assist in aligning future development artifacts

(functional designs, modules, test scripts, etc.) to the original requirements.

Business Requirements Document

The main purpose of this document is to facilitate the presentation and signoff of the

Business Requirements that have been captured and agreed upon. The Business

Requirements Document also describes the overall Business objectives and goals.

Here is a sample format that could be used.

1. Introduction2. Scope3. Business Goals4. Project Constraints5. Functional Requirement
http://www.requirementsauthority.com/stakeholder-negotiation.htmlhttp://www.requirementsauthority.com/stakeholder-negotiation.htmlhttp://www.requirementsauthority.com/stakeholder-negotiation.htmlhttp://www.requirementsauthority.com/stakeholder-negotiation.html


12/18

1. FR-0010 Functional Requirement2. FR-0020 Functional Requirement3. FR-xxxx

6.Non-Functional Requirement1.NF-0010 Non-Functional Requirement2.NF-0020 Non-Functional Requirement3.NF-xxxx

Functions Appendices

1. Models2. Definitions

Approving Requirements

The last activity in defining requirements is approving requirements. You must make

sure that all the requirements are approved and documented and that these

requirements define what it is the stakeholders want.

The main objective of this step is to make sure that ALL the stakeholders agree on

what business requirements the project is going to address and what is in scope for the

project.

This process should include the following types of people:

1. Reviewerspeople reviewing for content and structure and providingfeedback. They are your subject matter experts, the users, quality assurance,

etc.

2. Approverspeople who are formally agreeing to this document as the scopefor the project. These are typically people who have the authority to accept this

change and to allocate resources to the project. This group should include thebusiness owner(s), senior management, project manager, etc.

3. Project TeamThese are the people who will accept this document as theirproblem definition statement. The group should include your programmers,

architects, etc. This is for information only to allow them to start thinking about

the project.
http://www.requirementsauthority.com/cgi-bin/site.pl?url=http%3A%2F%2Fwww.requirementing.comhttp://www.requirementsauthority.com/cgi-bin/site.pl?url=http%3A%2F%2Fwww.requirementing.comhttp://www.requirementsauthority.com/cgi-bin/site.pl?url=http%3A%2F%2Fwww.requirementing.com


13/18

The actual activity of reviewing and approving the requirements needs to be planned

and should contain the following steps:

1. Determine approver distribution list.2. Distribute Business Requirements document to distribution list.3. Solicit feedback and document responses.4. Incorporate specific responses that do not impact other stakeholders.5. Plan and schedule Requirements Approving Workshop.6. Conduct Business Requirements Approving Workshop.7. Address all responses received from Step 3 above.

This is one activity which cannot be overlooked or hurried through. Take your time

and make sure that everyone thoroughly understands each requirement. Review each

response from Step 3 above.

BaselineOnce all the requirements have been reviewed and signed off they must bebaselined. Baselining is the first official version of the Business Requirements. Any

changed to this document, after it has been baselined, will require a change request

and, possibly, more resources.

Managing Requirements

Managing Requirements is the activity that follows the intensive work that goes into

the defining requirements part of theRequirements Management Process.

With approved Business Requirements in hand, we are able to proceed with theprocess ofmanaging the Requirements, which involves the six key phases of

theSystems Development Life Cycle (SDLC):

Analyze- project requirements are defined and evaluated for feasibility

Design- design the specific details of the product or service

Build- the first version of the product or service is produced

Test- the validation of the product or service

Deploy- installation and activation of the approved product or service

Support- ongoing monitoring and maintenance of the product or service

This manage requirements activity ensures that the requirements are aligned with

various modules and the test scripts that are developed as part of the project.

The end result ofmanage requirements is the completion of a project such as the

release of a new product or the implementation of a new service.
http://www.requirementsauthority.com/baseline-requirements.htmlhttp://www.requirementsauthority.com/baseline-requirements.htmlhttp://www.requirementsauthority.com/requirements-management-process.htmlhttp://www.requirementsauthority.com/requirements-management-process.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/requirementing.htmlhttp://www.requirementsauthority.com/systems-development-lifecycle.htmlhttp://www.requirementsauthority.com/requirements-management-process.htmlhttp://www.requirementsauthority.com/baseline-requirements.html


14/18

Requirements Management Skills

Six essential management skills:

Analyze the problem. Understand the user needs. Define the system. Manage the scope of the system. Refine the system definition Manage the changing requirements

Top 10 Reasons for Requirements Management

1. Increase project management effectiveness and cross-functional collaboration capabilities. By identifyingand agreeing on requirements, your team will be taking the first step towards operational excellence.

2. Manage projects more accurately i.e. controlling costs, meeting project due dates, and fending off scope

creep.

3. Ensure that detailed tasks are never lost through the cracks in organization no matter how broad or deep

the requirements may range.

4. Assign responsibility, accountability, tasks, and even plan segregation of duties.

5. Ensure that service and contractual relationships are clearly defined. Originally defined terms and

conditions including obligation dates and milestones can be managed more successfully.

6. Ensure that stakeholders fully understand project scope and complexity across the entire set of

requirements that defines a projects work breakdown structure (i.e. a set of work tasks).

7. The practice of requirements management is an ideal way to integrate processes. By identifying process-

specific requirements you will be able to attack the major issues associated with process hand-offs (i.e.

where one process ends and another begins).

8. The practice of requirements management allows your team to create a baseline; a defined set of

requirements that have been agreed upon.

9. Requirements management discipline helps you to deal with business and technical change. Each

requirement can undergo a formal review before it is accepted into a current project, or scheduled for a

future time period. This allows you to stay focused on a current baseline.

10. The practice of requirements management allows users to understand the importance of requirements

traceability. This enables users to conduct business impact and traceability impact assessments. This is a

critical aspect of managing GRC projects and programs successfully.

1. REQUIREMENT MANAGEMENT TOOLS


15/18

2. Enterprise-level Requirements Management ToolsThese tools are primarily targeted at large, enterprise-level implementations. They

are usually very expensive but are also loaded with features for enterprises.

IBM Rational DOORS Borland CaliberMid-marketRequirements Management Tools

These provide a nice balance between the feature set of enterprise-level tools

listed above and ease-of-use of entry-level tools listed below.

Accompa JamaEntry-level Requirements Management Tools

These tools are affordable andcan be used to manage requirementsin a structured

fashion especially at smaller organizations. There is one caveat these

are notfocused on requirements, but rather on issues/bugs.

Atlassian JIRA FogBugzFree, Open SourceRequirements Management Tools

Are you interested in using open source requirements management tool installed

on your own servers? Check out the following:

aNimble For a more detailed discussion of open source tools, seeOpen Source

Requirements Management Tools

Top-5 Benefits of Requirements Management Tools (RM

Tools)

Here are 5 key benefits you can achieve by using an RM tool instead of just a general-

purpose tool to manage your requirements.

1. Structured Requirements: Requirements management tools enable you to gatherstructured requirements. This basically means you can define attributes youd like to

track for each requirement (such as Requestor, Needed Date, Owner, etc) and then make

sure each requirement has those attributes.
http://www.ibm.com/software/awdtools/doors/http://www.ibm.com/software/awdtools/doors/http://www.borland.com/products/caliber/http://www.borland.com/products/caliber/http://www.accompa.com/http://www.accompa.com/http://www.jamasoftware.com/http://www.jamasoftware.com/http://www.accompa.com/product-management-blog/2012/03/08/can-you-manage-requirements-using-bug-trackers-like-bugzilla-and-jira-the-surprising-answer/http://www.accompa.com/product-management-blog/2012/03/08/can-you-manage-requirements-using-bug-trackers-like-bugzilla-and-jira-the-surprising-answer/http://www.accompa.com/product-management-blog/2012/03/08/can-you-manage-requirements-using-bug-trackers-like-bugzilla-and-jira-the-surprising-answer/http://www.atlassian.com/software/jirahttp://www.atlassian.com/software/jirahttp://www.fogcreek.com/fogbugz/http://www.fogcreek.com/fogbugz/http://sourceforge.net/projects/nimble/http://sourceforge.net/projects/nimble/http://www.accompa.com/requirements-management-blog/2012/04/free-open-source-requirements-management-tool/http://www.accompa.com/requirements-management-blog/2012/04/free-open-source-requirements-management-tool/http://www.accompa.com/requirements-management-blog/2012/04/free-open-source-requirements-management-tool/http://www.accompa.com/requirements-management-blog/2012/04/free-open-source-requirements-management-tool/http://www.accompa.com/requirements-management-blog/2012/04/free-open-source-requirements-management-tool/http://www.accompa.com/requirements-management-blog/2012/04/free-open-source-requirements-management-tool/http://sourceforge.net/projects/nimble/http://www.fogcreek.com/fogbugz/http://www.atlassian.com/software/jirahttp://www.accompa.com/product-management-blog/2012/03/08/can-you-manage-requirements-using-bug-trackers-like-bugzilla-and-jira-the-surprising-answer/http://www.jamasoftware.com/http://www.accompa.com/http://www.borland.com/products/caliber/http://www.ibm.com/software/awdtools/doors/


16/18

2. Save Time: A good requirements management tool can save you a ton of time when itcomes to managing your requirements, as they automate a lot of requirements

management tasks like creating requirements documents.

3. Less Stress:Most PMs/BAs/Engineers whore responsible for gathering and/or trackingrequirements will confess that this task is pretty stressful due to the inherently chaotic

nature of the process. A good RM tool can eliminate a lot of the unnecessary stress

associated with this process.

4. Workflow & Best Practices: Good requirements management software tools have built-inworkflow and best practices for a lot of tasks related to requirements management. This

will help you make your products and projects more successful.

5. Easy to Collaborate: A good requirements management tool will enable you to collaboratewith your internal and external stakeholders efficiently & effectively. General-purpose

tools are not very effective due to lack of requirements-specific collaboration capabilities.

ACCOMPA

We are a fast-growing startup company located in Silicon Valley - in Santa Clara, California (United

States).

Mission:

To help customers build more successful products, more efficiently- by enabling them to continuously

improve every part of their requirements management process.

More than 100 companies in 4 continents - ranging from Fortune-500 companies to growing startups -

rely on our software every single day to meet their requirements management needs.

Here's a small sample of well-known companies who use Accompa to manage their requirements

management processes in a powerful, efficient and repeatable fashion.

Yamaha

Cisco

Adobe

Hp

Citrix

Symantec

Rbs(royal bank of scotland)Intel

genentech

They conducted an in-depth survey of companies who had been using Accompa for at least 12 months.

23 companies participated in our survey.

they asked them to outline the various benefits they've gained from using Accompa to manage their


17/18

requirements, and worked with them to quantify these benefits. We aggregated this data and calculated

the average Return-on-Investment (ROI). Here's what we found...

On Average, These Companies Achieved 17x ROI

Here Is How They Achieved 17x ROI

28%

On average, Accompa users spend 28% of their time on

requirements. This includes gathering, tracking,

collaborating on, and managing requirements - as well as

creating requirements documents.

$106,000

On average, the fully-loaded annual cost of an Accompa

user (Annual salary + Bonus + Benefits + Overhead). This

varies with geography, and is the highest in the western

U.S.

16%

Companies estimated that, on average, Accompa saved

them 16% of their time spent on managing requirements

- compared to their old tools such as Excel, Word or wikis.

$4,749

Annual productivity gains per user from using

Accompa, averaged across all 23 companies. Calculated by

multiplying the three factors above.

$278

Annual investment per user for Accompa. This is the

average annual fee per user, and includes volume discounts

for companies with a large number of user licenses.

17x

Return-on-Investment (ROI) achieved by companies

using Accompa, on average. Calculated using the above two

factors ($4,749 divided by $278).

To be technically correct - the actual ROI is even higher than 17x - as many companies

reported other benefits in addition to productivity gains. These included benefits such as

eliminating missed requirements, sharing up-to-date requirements throughout the

organization, making it easier for customers to input requirements, etc...

But we omitted these additional benefits so that we could: a) Uniformly aggregate the results

across all 23 companies, and b) Present the ROI to you in the simplified, clear format shown


18/18

above. As a result, 17x ROI is a conservative number - and only includes productivity

gains.

CONCLUSION

Requirements definition and management are among the most important

activities in any project, and efforts in this direction can improve and

accelerate ROI. It is also the first process improvement area to focus on, based

on the garbage in, garbage out rule: If the requirements are not clear, any

other effort may just help you produce the wrong product faster.

The first step to better requirements management is to understand the simple

rules that make a requirement good. Training courses and guidance can

help organizations achieve this goal.

Once the basic rules are in place, organizations can further increase the

quality of their requirements by implementing todays best practices. These

process improvement steps are greatly aided by implementing a requirements

management product that not only helps projects to manage requirements

more effectively, but also helps future projects benefit from past and current

lessons.

References

ibm.com/software/rational

www.etesting.com

www.accompa.com

www.projectmanagement.com

www.requirementsauthority.net
http://www.etesting.com/http://www.etesting.com/http://www.accompa.com/http://www.accompa.com/http://www.projectmanagement.com/http://www.projectmanagement.com/http://www.requirementsauthority.net/http://www.requirementsauthority.net/http://www.requirementsauthority.net/http://www.projectmanagement.com/http://www.accompa.com/http://www.etesting.com/

requirement management30

Documents