PROPOSAL

FOR THE DEVELOPMENT OF AN

IEEE REQUIREMENTS ENGINEERING STANDARD,

TO REPLACE IEEE 830-1998 AND IEEE 1233-1998

Rob Schaaf

software.management@prodigy.net

1-203-222-0735

11/30/03 2

GOAL OF THIS PRESENTATION

An agreement that will serve as

the basis for a project to develop an

IEEE requirements engineering standard

CONTENTS

Personal introduction

Purpose, scope and concepts of standard

Outline of standard

Project to develop standard

Next steps

11/30/03 3

DISCLAIMER

• In its present, initial version, this presentation concentrates on the choice of key operational concepts for the proposed standard.

• The standard’s outline is sketched only in the broadest strokes as it would have little value if there were disagreement about the choice of concepts.

• If agreement on concept is likely, a next version of this presentation will expand on the outline – and on the project plan to develop the standard.

11/30/03 4

PERSONAL INTRODUCTION

• 35+ years in complex, software-intensive systems

• 1/3 with IBM, 1/3 with ITT, and 1/3 as independent advisor

• Systems: operating, communications, control, information, tools

• Development, acquisition and operation

• Systems engineering, requirements, architecture, validation

• Balloter of IEEE standards for 10+ years

• Member of working groups: P830, P1074, P1220

11/30/03 5

NOTATIONS

830+1233 Symbol for the IEEE standard to be

developed

P830+1233 Project to develop 830+1233 as proposed

here

12207 ISO/IEC 12207:1995 and Amendment 1

15288 ISO/IEC 15288:2002

11/30/03 6

PURPOSE OF 830+1233

1. To set the standard of performance for actors involved in

requirements engineering

2. To guide these actors in their activities, including the links

with other life cycle processes

3. To serve as benchmark in (methods of) assessment of an

organization’s requirements engineering capability

ALSO, ‘GRANDFATHER’ GOAL FOR 830+1233To maintain conformance where an actor conformed with

IEEE Std. 830-1998 or IEEE Std. 1233-1998

11/30/03 7

SUBJECT OF REQUIREMENTS ENGINEERING:

A SYSTEM

• Ingredients: hardware, software, people, servicesHardware, people and services are optional

• System structure:- A system consists of parts- A part may consist of parts- A part may be a system

• 830+1233 does not differentiate between ingredientsA piece of software-only is treated as a system as is a combination of hardware and software – one requirements engineering process for all

• 830+1233 leaves freedom to pick scope of a systemConsistent with IEEE 1220, a system may include life cycle activities - development, production, operation, disposal

Each part may be a mix of ingredients

11/30/03 8

SCOPE OF 830+1233

• Sum of the scopes of :– Requirements elicitation (12207 F.1.3.1; also 15288 5.5.2)– System requirements analysis (12207 5.3.2, F.1.3.2; also 15288 5.5.3)– Software requirements analysis (12207 5.3.4, F1.3.4)

• Plus interfaces, primarily with– Acquisition process (12207 5.1, F.1.1; also 15288 5.2.2)– Process implementation (12207 5.3.1; also 15288 5.3.4)– System architectural design (12207 5.3.3, F.1.3.3; also 15288 5.5.4)– Software architectural design (12207 5.3.5, F.1.3.5)– Software integration (12207 5.3.8, F.1.3.7, F1.3.8)– Software qualification testing (12207 5.3.9)– System integration (12207 5.3.10 , F1.3.9, F.1.3,10; also 15288 5.5.6, 5.5.7)– System qualification testing (12207 5.3.11; also 15288 5.5.9)– Reuse processes (12207 F.3.5, F.3.6, F.3.7)– Project management, measurement (12207 F.3.1.3, F.3.1.6; also 15288 5.4)– Configuration management (12207 6.2, F.2.2; also 15288 5.4.7)

11/30/03 9

SCOPE OF 830+1233 – Cont’d

• Requirements engineering applies to development and acquisition

If acquisition, the system may still have to be developed, or it may already exist

• A subject system may be part of a larger system that is also under

development or acquisition

830+1233 addresses the link between requirements engineering of the respective systems

• While users of 830+1233 are obviously free to tailor their use of the

standard, 830+1233 does not provide norms or guidance for tailoring

Conformance is defined as conforming with all must’s and shall’s of 830+1233

11/30/03 10

NATURE OF 830+1233

• Be a standard – fall back: recommended practice

• Normative:

- Outcomes, in a framework of activities

- Linkage with other life cycle activities

• Informative:

- Supporting concepts

- Practical implementation guidance

• Technology independence, including:

- No assumption that requirements are represented in documents1

- Room for representation in models or mixed forms

- Actually, little normative emphasis on the form of representation

11/30/03 11

STAKEHOLDER

A (system) stakeholder is a person with

a legitimate, authoritative interest in the system,

in any of the system’s properties or uses,

or in any part of the system’s life

1. Rising above the duopoly of customer/user and technical community

2. Anything that may influence the success of a system must have a stakeholder

3. No limit on the universe of stakeholder types

4. For a particular system, its set of stakeholders is a function of the system

Ad (2) – If something does not have an obvious stakeholder, a requirements engineer may perform the role. Example: an existing system (or the environment in general) interacting with the subject system.

11/30/03 12

SAMPLE TYPES OF STAKEHOLDERS

– Acquirers, purchasers, customers, owners (of systems acquired)

– Suppliers, contractors, owners (of systems as developed)

– Users, operators, trainers, installers, maintainers

– Engineers, developers, producers, project/process/resource/business principals

– People with interests in :

System properties, e.g. functionality, performance, quality, profitability, timeliness

Production, marketing, sales and service of systems and parts

Other systems interacting with, embracing, or part of, the (target) systems

Training + the documentation and training materials of systems

Legal aspects of systems, e.g. applicable laws, patents

Applicable standards, policies, directives, procedures

The scientific bases of systems

BACK-UP

11/30/03 13

NEED AND REQUIREMENT

• Need, held by a stakeholder: A condition that may or may not

influence a system to be, including a system’s properties,

uses and life

• Requirement: A condition on a system or on a system’s life,

necessary (but, generally, not sufficient) to make the system

as engineered acceptable to its stakeholders

Precursors like:

‘Raw requirement’ and ‘well-formed requirement’

‘User requirement’ and ‘system requirement’

11/30/03 14

COMPARISON I

_______Needs_______

1. In terms of a problem-solution model, a need belongs to the problem space

2. A need is owned by one or more stakeholders

3. Ultimately, needs are satisfied operationally, including the operation of a system-to-be

4. A need may be (and typically will be) irrespective of a system’s boundary

____Requirements____

A requirement addresses a solution – even if it only puts an condition on a solution

The object of a requirement is a system (a system-to-be)

Requirements are met through the development / acquisition of a system

Requirements focus on a system in its environment – they form a (first) delineation of the system

11/30/03 15

A SYSTEM IN ITS ENVIRONMENT

ENVIRONMENT

SYSTEM

BACK-UP

11/30/03 16

ORIENTATION OF NEEDS

ENVIRONMENT

“irrespective of the system boundary”

BACK-UP

11/30/03 17

ORIENTATION OF REQUIREMENTS

SYSTEM

“focus on a system in its environment – they form a delineation of the system”

BACK-UP

11/30/03 18

COMPARISON II

_______Needs_______

5. A need may affect multiple releases of the system

6. Between stakeholders, needs may conflict – don’t try to reconcile needs

7. It may be infeasible to develop, acquire, produce or operate a system that satisfies all needs

8. Representations of needs may not be updated after transformation into system requirements

____Requirements____

A requirement addresses a particular release of the system

In the course of a project, a release’s set of requirements must be made consistent

In the course of a project, the totality of a release’s requirements must be made feasible

Representations of requirements are updated (in a controlled fashion) until the end of system validation

1. A transformation from needs to requirements is non-deterministic

2. Requirements (not needs) are the basis for stakeholder consensus

11/30/03 19

BREADTH OF NEEDS AND REQUIREMENTS

• In line with the broad concept of stakeholder, the concepts of need and requirement are generalized

• Requirements include ‘constraints’

• No limit on the universe of types of needs and requirements

Need: ANY condition that may or may not influence a system to be, including a system’s properties, uses and life

Requirement: ANY condition on a system or on a system’s life, necessary to make the system acceptable

11/30/03 20

SAMPLE TYPES OF NEEDS AND REQUIREMENTS

Environmental factorsUsabilityOperabilityInstallabilitySecuritySafetyPrivacyIntegrityProperty rightsMerchantabilityRegulatory complianceStandards complianceInternational factorsAuditabilityAND SO ON

FunctionalityTimelinessCostProfitabilityQualityAccuracyPerformanceCapacityResponsivenessEfficiencyEffectivenessReliabilityAvailabilityServiceabilityRobustness

CompletenessMaintainabilityConfigurabilityFlexibilityScalabilityAdaptabilityPortabilityInteroperabilityExtendibilityCompatibilitySimplicityModularityReusabilityTestabilityTrainability

Note that there are types not (directly) related to the external behavior of the system-to-be

BACK-UP

11/30/03 21

DERIVED REQUIREMENTS

• ‘Downstream’ life cycle activities (in particular: design engineering)

may find one or more requirements (or their sum) infeasible – if so,

a feedback loop is triggered to revisit the requirements

• Downstream activities may also find situations1 that add to the

conditions of system acceptance – if so, a feedback loop is

triggered to revisit (to add to) the requirements

“Not all requirements flow directly from needs”

1 Example: “housekeeping” functions

11/30/03 22

REPRESENTATION OF NEEDS AND REQUIREMENTS

• Representation makes needs and requirements concrete

• Room for natural and formal languages

• Use of stakeholder (not system) terms and concepts

• No need for multiple representations of requirements

11/30/03 23

OUTLINE OF 830+12331. Overview

Purpose and scope of the standardPurpose and scope of requirements engineering

2. References

3. Definitions

4. ConceptsSystemStakeholderNeedRequirementRepresentationOther actors: requirements engineer; requirements owner

5. Activities and outcomes

A. Guidelines for conformance with IEEE 12207Amendment 1 of ISO 12207ISO 15288

11/30/03 24

OUTLINE OF CLAUSE 5: ACTIVITIES AND OUTCOMES1. Identifying stakeholders

2. Eliciting stakeholder needs

3. Representing stakeholder needs

4. Transforming needs into requirements

5. Prioritizing requirements

6. Organizing requirements

7. Representing requirements

8. Tracing requirements

9. Verifying requirements

10. Validating requirements

11. Using requirements

1. In design engineering

2. In test engineering

3. In engineering of embracing systems

4. In engineering of embedded systems

12. Changing requirements

13. Reusing requirements

14. Planning, measuring and controlling of requirements engineering

11/30/03 25

P830+1233

• Iterative development of 830+1233, starting with expanded outline

• WG members submit change requests, editor issues new iterations

• WG members qualify through substantive review, change requests

• All based on e-mail – no need for meetings or websites

• My role: working group co-chair and editor

KEY ELEMENTS

“Expanded outline”

Outline of the whole document

PLUS: a few critical clauses written out in full

11/30/03 26

P830+1233

Jan ’04 Availability of my expanded outline + project plan

Feb ’04 SESC ExCom review and decision to proceed

Mar ’04 Publication of expanded outline, request for comments

2Q’04 Constitution of working group, publication of 1st full

draft

3Q’04 2nd full draft

4Q’04 3rd full draft

1H’05 Sponsor ballot

USE OF TIME

11/30/03 27

NEXT

• SESC ExCom decision to proceed up to Feb 2004

• My summary of the present teleconference