What is Requirements Management? – Jama Software

So, how do you manage requirements? The most successful teams work from a defined requirements management process. Defining the requirements management process is important because requirements change throughout a project. When this happens, that change needs to pass through the same, repeatable process.

There are four main stages of the requirements management process — planning, development, system verification, and system validation — each with important considerations to the overall project. Change management, while not a stage itself, affects nearly every phase of the requirements management process.

Planning Stage

The product development methodology—waterfall, agile, or Scrum—helps decide how requirements move through the process. Waterfall models are typically linear with development moving from one process area to another with a completed product delivered with the required features and functionality. Agile development, including Scrum, is iterative in nature. In requirements management, agile teams, and those using the Scrum approach, may be working on different sets of requirements concurrently, delivering a product in increments, each increment adding value with additional features or functionality.

No matter which methodology is employed, the Requirements Management Plan (RMP) is the documented process the team uses throughout product development. It contains information like stakeholder roles and responsibilities, which needs and requirement artifacts will be defined, how traceability will be competed and managed, how needs and requirements baseline will be handled, how interactions (interfaces) with external systems and users will be managed, how changes will be managed, how the product will be verified to meet the requirements, and how the product will be validated to meet the needs.

A successful Requirements Management Plan is visible to and has sign off from stakeholders, as it sets the course and expectations for all stakeholders throughout the product development journey.

Needs and Requirements artifacts

Part of the RMP is defining the needs and requirements artifacts that will be created during the requirements management process.

Needs and requirements artifacts include the data and information concerning the needs and requirements and related information. Examples include diagrams, and models, integrated set of needs, set of product requirements, use cases, design documents, testing plans and procedures. Requirements artifacts are used throughout the product development lifecycle to:

• Describe the product being built
• Identify the actions needed to develop the product
• Capture the actions performed during development
• Define the testing needed for system verification and system validation
• Assist with stakeholder review, communications, and engagement

While some organizations will communicate this information in a document form (e.g.,  a Software Requirements Specification (SRS)), the increasing trend is to manage the needs and requirements within a requirements management software application.

The reason organizations are moving towards a data-centric practice of product development is that is hard, for any document-based approach to be flexible and scalable enough for complex agile projects. This is especially true for highly regulated industries that must prove compliance. Due to numerous factors—lack of consistent updating, human error, incomplete data, version control, the need to establish and maintain traceability, etc.—documents simply cannot be relied upon determine whether a need or requirement is fulfilled.

Agile product teams working on complex products in highly regulated industries will have much more success using a requirements management software application to streamline the requirements analysis phase of requirements definition and management. Modern requirements definition and management solutions, like Jama Connect®, define, establish traceability for, manage, and validate complex product requirements automatically, which simplifies not only requirements analysis, but the overall requirements definition and management process as well.

It is imperative that needs and requirements and their artifacts are linked to each other and to additional related artifacts. This can be difficult to achieve using documents, as the manual nature lends itself to myriad errors. This is especially true in the case of complex or highly-regulated products where traceability is a prerequisite for proving compliance.

Needs and Requirements attributes

To keep track of the requirements in a given project, each requirement should have a specific list of attributes. Requirements attributes are used to ensure that requirements are organized and uniquely identified across all requirements artifacts.  The attributes also aid in managing the sets of needs and requirements, enabling reporting and dashboards to be defined to provide accurate and timely status of the project.

It is a best practice that the following requirement attributes are included for all needs and requirements:

• Unique Identifier
• Rationale
• Owner
• Type
• Definition status
• Priority
• Criticality
• Compliance
• Version number
• Change history
• Trace data
• Verification status (for requirements)
• Validation status (for needs)

Needs and Requirements Baseline

A needs and requirements baseline is a point-in-time look at a committed set of agreed-upon, reviewed, and approved needs and requirements – or planned functionality and features – to be included in the product. The purpose is to provide information to stakeholders so they can make informed decisions on and possibly modify the planned functionality and features using change requests.

The RMP defines a baseline strategy including timing and frequency of creation, needs and requirements prioritization (deciding which requirements should be included), publishing, change management, requirements verification, and requirements validation.  In this context needs and requirements verification address the quality of the needs and requirements statements as well as the existence and correctness of the traceability. Needs validation is confirmation with the stakeholders that the integrated set of needs clearly communicates the intent of the stakeholder in terms of what the need the product to do.  Requirements validation is confirmation with the stakeholders that individual requirements and the entire set of requirements clearly communicate the intent of the needs they were transformed from.  The quality of the requirements is dependent upon the quality of the needs from which they were transformed.

Establishing a requirements baseline is important because it implies that:

• Scope has been defined and agreed to – (critical to controlling scope creep!)
• Formal change control begins
• Staffing levels and budgets are set
• Schedule commitments are made

Typically, baselines are stored in software requirements specification (SRS) documents. However, a complex system might need a variety of software, hardware, and interface requirement specifications to encapsulate the baseline’s components. This can be cumbersome to maintain during initial development and downright impossible during change management.

Alternatively, working with baselines in a requirements management solution allows baselines to be defined as a subset of the requirements already stored in the database. This streamlines the process – from prioritization through stakeholder sign-off.