Revision: Requirements Management Wiki Home

Introduction

The goal of this effort is to define a common set of resources, formats and RESTful services for the use in Requirements Definition and Management tools and use by (for example) systems engineering or ALM tools that will enable the effective use of requirements across a development life-cycle.

Requirements Management (RM) resources define the requirements or capabilities of a system or the outcome of some programme of work. We use the term system entirely generally and without prejudice to software, hardware, IT, regulatory, business etc.

Requirements are the basis for defining what the system stakeholders (users, customers, suppliers and so on) need from a system and also what the system must do in order to meet those needs, and how the surrounding processes must be orchestrated so that quality, scope and timescale objectives are satisfied. The discipline of requirements management involves many activities including elicitation, definition, documentation, analysis, decomposition, validation and justification; it involves managing changes to requirements and establishing and reasoning about their interrelationships. In involves the creation of assets which are invariably related to other systems and processes. RM is inherently multi-disciplinary and across the life-cycle; it brings together all assets across the life-cycle, ascribing them meaning, captures their dependencies and interrelationships and ultimately, captures the way in which they together produce the desired system.

Requirements management activities

• Elicitation, definition and communication introduce requirements in such a way that relevant stakeholders can understand and agree that the system will meet their needs.
• Gathering requirements and related assets into a coherent set, for example as a set of requirements documents, as part of forming a precise overarching specification of the system. Such a set of requirements is often part of a contractual agreement between parties, for example.
• Analysis aids the understanding of requirements and enables the expression of refactored, decomposed, refined, elaborated, or clarified requirements. Assets such as system models may be created during such analysis.
• The need to validate the system induces the need to create test requirements that demonstrate that all requirements have been met, and thus, for example, that contractual obligations have been discharged.
• The need to deal with ambiguity, complexity or testability of a requirement leads to lower-level, related derived artefacts. These derived artefacts may be requirements, or they could be from some other system, such as change requests, diagrams stored in a PLE system and so on.
• The recording and management of the links created as part of each of these processes is central to understanding the meaning of requirements, assessing the impact of proposed or actual change and, through the recording of rationale information, validation that lower-level requirements are correctly derived from higher-level requirements.
• The need to plan the scope of a release or milestone in order that the requirements that are to be met are known and meaningful and will meet the stakeholders’ needs.

Traceability analysis

Impact analysis exploits the links created during such derivation and analysis in order to understand the ramifications of actual or proposed changes to higher-level requirements. In this way the impact to the system, or aspects of its delivery can be assessed and acted upon.

Derivation analysis exploits links in order to inform cost/benefit analysis processes, or to understand the rationale for some parts of the system, and the ramifications of actual or proposed change to those parts.

Coverage analysis informs planning and progress processes and it also provides verification information on the satisfaction of a requirement by other assets, and contributes validation information to the quality processes that are responsible for the creation and management of test requirements and other test-related assets.

In each of these kinds of trace analysis, the type of links being analyzed is significant, as is the justification argument which describes why that link is present.

Management of change and auditing

Changes to requirements reflect changing needs or system behaviours. Trace analysis informs change processes, as do other life-cycle characteristics, such as stability of the requirement. Auditing processes may be used to support accountability for historical changes.

Requirements across the life-cycle

Requirements are the engineering language used to define not only the needs of the system stakeholders but also the performance and constraints of the system itself. As such, most other lifecycle activities are either based on requirement data or heavily influence the requirement baseline of a development project. Once you have established processes for requirements management, change management, quality, and model-driven development, the next logical step is to integrate them in a collaborative ALM environment. This helps organisations not only break down silos, but can also accelerate process maturity. For example, this approach can make it easier to demonstrate overall solution compliance and produce cross discipline metrics that support more informed decision making.

Requirements Driven Development

When development activities are enabled using integrated requirements data, they provide focus, traceability and impact analysis. Developers can address issues and priorities without the need to access multiple repositories for information. Achieving process maturity in ALM depends on having a reliable, on-demand view of progress across the entire project in both agile development initiatives and traditional waterfall approaches. Round-trip traceability enables analysis of the contents of each build, baseline, and release. Teams can see exactly which requirements, change requests, and development tasks have been implemented and which have not. In addition, the ALM platform displays the differences between different baselines. As such, teams can see what has changed. This approach makes it easier to demonstrate accountability, ensure security, and complete audits.

Requirements Driven Testing

One of the biggest challenges to testing maturity is to confine testing at the end of development when bugs are most costly to fix, resources are low, and time is short. With the ability to map requirements directly to test cases, test engineers can see exactly what requirements and features they should be testing, as well as who made changes and when. Teams can check to see that requirements match specifications, customer requests, regulations, and standards early in development. Testers can also describe the tests associated with each requirement as soon as these are defined to ensure that testability considered when writing requirements.

Model Driven Development (MDD)
Integrated MDD helps development teams better manage system complexity by focusing on high-level design and development of application architecture and software using a graphical language. This enables team to translate requirements to a system model depicting functionality and to validate its behaviour through simulation. Often analysis of the results yields a route for further development and test. Incorporating MDD into the ALM environment reduces the gap between the project requirements and the final implementation. The ability to visualize requirements and trace them throughout the lifecycle improves understanding and project-wide impact analysis.

Approach

The specifications will be developed iteratively by first prioritizing scenarios and focusing on a minimal set of key scenarios. Once these scenarios have been satisfied by specification and proof of implementation, more scenarios will be considered.

Published Specifications

OSLC RM Specification 1.0

OSLC RM Specification 2.0

Specifications

Supporting Documents

Milestones

Note: iterative specification validation will be occuring as the drafts evolve before finalization. The goal is to not develop the specification in abstract; but to do it in parallel with implementations. We will identify the integration opportunities to validate the spec in order for it to be finalized. Review comments on “Draft” documents are to be added to the “Reviewer Comments” page.

Status

Meeting agendas and minutes

Feedback

Specification comments and issues

Mailing Lists

Requirements Management
General Open Services

Discussion Topics

Standardised Link Types

Scenarios

Requirements Management Scenarios

Terminology

We’re building a glossary of terms and definitions