Requirements Management

View Description Charter

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. 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, and describes how they together produce the desired system.

Requirements Management Charter

Scope

The goal of this effort is to define a common set of open linked data resources, formats and RESTful services for the use in Requirements Definition and Management tools and use by (for example) systems engineering, ALM or PLM tools that will enable the effective use of requirements across a development life-cycle. We want to promote an open approach which supports a community of stakeholders that have interests in all aspects of requirements management.

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.

Deliverables

The Requirements Management Workgroup will produce:

  • Scenarios – these will guide the priorities and specification contents within the WG
  • Specifications – both maintenance of existing specifications, guidance on usage and new specification
  • Supporting and enabling material – on an as-needed basis to support broad adoption

Relationship to other activities and workgroups

The Requirements Management Workgroup will work with other Workgroups as required, for both scenario and specification development. Some activities may require consultation with and contribution to the Core Workgroup or other domain Workgroups for possible adoption and/or endorsement.

The Requirements Management Workgroup will be an active participant within the Core Workgroup. The Requirements Management Workgroup will be represented at the Core Workgroup by at least one Requirements Management Workgroup participant, either the Workgroup Lead or a delegate.

For more information, see the Workgroup Best Practices.

Target Specification Development Organizations (SDOs)

Specifications developed by this WG may be contributed to these SDOs:

This contribution to these SDOs is dependent on maturing the specifications within this WG and gaining consensus on the contribution. At that point, the WG would make a proposal to the OSLC Steering Committee for such a move. For more information, see the Workgroup Best Practices.

Participation

Agreeing to become a member of the Requirements Management Workgroup implies some amount of time commitment to the Workgroup activities. There is no minimum level of commitment.

It is desirable that each member be willing to contribute in one or more of the following ways:

  • attend the teleconferences
  • participate in off-line mailing list discussions
  • contribute and review scenarios
  • participate in prioritization activities
  • potentially lead the Workgroup and/or meetings
  • contribute specification content in the form of proposals and actual specification text
  • edit and organize the specification
  • address specification issues
  • contribute to a test suite
  • produce implementation feedback in the form of implementation reports

Meetings Frequency and Communications

Meetings are conducted typically by teleconference. The frequency of meetings will vary based on time of year and current cycle of specification development. Additional meetings may be held by a subset of the Workgroup to work on some focused activities.

Meetings should be announced at least 48 hours in advance.
Meeting agendas should be set at least 24 hours in advance.

Mailing list and wikis should be used to capture all work and discussions. This provides Workgroup members that can’t attend meetings the ability to participate and provide feedback.

Decision Policy

Decisions within this Workgroup are consensus driven, facilitated by the Workgroup Lead.

The Workgroup members nominate a Lead. Workgroup members work to reach consensus to select the Lead or co-Leads should be. Having more than one Workgroup Lead is preferred but not required.

Intellectual property

Members of this Workgroup agree to this Workgroup Participation Agreement.