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.
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.
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
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
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
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.
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.
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
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
of change and auditing
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
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
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
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)
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.