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-17/29/2019 Requirement Management30
2/18
7/29/2019 Requirement Management30
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.html7/29/2019 Requirement Management30
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.html7/29/2019 Requirement Management30
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
7/29/2019 Requirement Management30
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.html7/29/2019 Requirement Management30
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.html7/29/2019 Requirement Management30
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.
7/29/2019 Requirement Management30
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.html7/29/2019 Requirement Management30
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.html7/29/2019 Requirement Management30
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.html7/29/2019 Requirement Management30
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.com7/29/2019 Requirement Management30
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.html7/29/2019 Requirement Management30
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
7/29/2019 Requirement Management30
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/7/29/2019 Requirement Management30
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
7/29/2019 Requirement Management30
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
7/29/2019 Requirement Management30
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/