1. 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

2. 11/30/032 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

3. 11/30/033 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.

4. 11/30/034 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

5. 11/30/035 NOTATIONS 830+1233Symbol for the IEEE standard to be developed P830+1233Project to develop 830+1233 as proposed here 12207ISO/IEC 12207:1995 and Amendment 1 15288ISO/IEC 15288:2002

6. 11/30/036 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+1233 To maintain conformance where an actor conformed with IEEE Std. 830-1998 or IEEE Std. 1233-1998

7. 11/30/037 SUBJECT OF REQUIREMENTS ENGINEERING: A SYSTEM Ingredients: hardware, software, people, services Hardware, 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 ingredients A 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 system Consistent with IEEE 1220, a system may include life cycle activities - development, production, operation, disposal Each part may be a mix of ingredients

8. 11/30/038 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)

9. 11/30/039 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

10. 11/30/0310 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 documents 1 - Room for representation in models or mixed forms - Actually, little normative emphasis on the form of representation

11. 11/30/0311 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.

12. 11/30/0312 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

13. 11/30/0313 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’

14. 11/30/0314 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

15. 11/30/0315 A SYSTEM IN ITS ENVIRONMENT ENVIRONMENT SYSTEM BACK-UP

16. 11/30/0316 ORIENTATION OF NEEDS ENVIRONMENT “irrespective of the system boundary” BACK-UP

17. 11/30/0317 ORIENTATION OF REQUIREMENTS SYSTEM “focus on a system in its environment – they form a delineation of the system” BACK-UP

18. 11/30/0318 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

19. 11/30/0319 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

20. 11/30/0320 SAMPLE TYPES OF NEEDS AND REQUIREMENTS Environmental factors Usability Operability Installability Security Safety Privacy Integrity Property rights Merchantability Regulatory compliance Standards compliance International factors Auditability AND SO ON Functionality Timeliness Cost Profitability Quality Accuracy Performance Capacity Responsiveness Efficiency Effectiveness Reliability Availability Serviceability Robustness Completeness Maintainability Configurability Flexibility Scalability Adaptability Portability Interoperability Extendibility Compatibility Simplicity Modularity Reusability Testability Trainability Note that there are types not (directly) related to the external behavior of the system-to-be BACK-UP

21. 11/30/0321 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 situations 1 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

22. 11/30/0322 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

23. 11/30/0323 OUTLINE OF 830+1233 1.Overview Purpose and scope of the standard Purpose and scope of requirements engineering 2.References 3.Definitions 4.Concepts System Stakeholder Need Requirement Representation Other actors: requirements engineer; requirements owner 5.Activities and outcomes A.Guidelines for conformance with IEEE 12207 Amendment 1 of ISO 12207 ISO 15288

24. 11/30/0324 OUTLINE OF CLAUSE 5: ACTIVITIES AND OUTCOMES 1.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

25. 11/30/0325 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

26. 11/30/0326 P830+1233 Jan ’04Availability of my expanded outline + project plan Feb ’04SESC ExCom review and decision to proceed Mar ’04Publication of expanded outline, request for comments 2Q’04Constitution of working group, publication of 1 st full draft 3Q’042 nd full draft 4Q’043 rd full draft 1H’05Sponsor ballot USE OF TIME

27. 11/30/0327 NEXT SESC ExCom decision to proceed up to Feb 2004 My summary of the present teleconference