On the Feasibility of Combining Standards 830 and 1233 Introduction




Yüklə 44.69 Kb.
tarix11.03.2016
ölçüsü44.69 Kb.
On the Feasibility of Combining Standards 830 and 1233

Introduction
Since the beginning of IEEE Software Engineering standards, some 25 years ago, Standard 830 "Software Requirements Specifications", has been one of the most important. Therefore, the topic of this study paper seems astonishing, that "There is no such thing as Software Requirements".
The point is that the requirements for a system exist outside of that system, where they specify functionality, interfaces, environment, reliability and the other "ilities". But software has no external interface because it is totally within computer hardware and so it cannot interface with the outside and so cannot have requirements. Only a system can have requirements. However, some of the system requirements are allocated to and accomplished by software.
How have systems and software designers struggled by with this discrepancy for all this time? The answer is that it was never a problem and is not a problem today because, in almost all systems, it is so obvious what gets done in hardware and what gets done in software, that the assignment of functions is not even mentioned. Nevertheless, an increasing number of systems contain programmable controllers, so it is not always obvious where software is located.
Motivation
But now the subject of merging the IEEE Standards for Software Requirements, 830, and for System Requirements, 1233, is on the front burner. That desire to merge seems to be almost universal. The IEEE Software Engineering Standards Committee has renamed itself the Systems and Software Engineering Standards Committee. The yearly Software Technology Conference has become the Systems and Software Technology Conference. And finally, the Software Requirements section of the Software Engineering Body of Knowledge document (Ref. 1) contains the claim that it is really addressing System Requirements:

". . . requirements engineering is fundamentally an activity of systems engineering rather than one that is specific to software engineering. In this respect the term 'software requirements engineering' is misleading because it implies a narrow scope concerned with the handling of requirements that have already been acquired and allocated to software components."


So why is there such an emphasis on change today? That is an interesting question but beyond the scope of this paper. But, no doubt, it is related to the continuing evolution of the Software Industry.
This study has three objectives:


  • Create a feasibility draft to demonstrate that standards 830 and 1233 can be combined.

  • Do this within the context of the SWEBOK and the umbrella standard, 12207.

  • Include those changes that were specified for the upgrade of 830 itself, namely upgrade it to full standard, incorporate the previous 12207 addendum, and convert the flavor from product-oriented to process-oriented.

  • Realize that this treatment is only appropriate for software-intensive systems.

An IEEE Standard has prescribed high level subdivisions roughly as follows:


Generic Outline of a Standard
Abstract (informative)

Keywords (informative)

Introduction (informative)

1. Overview (normative)

2. References (normative)

3. Definitions (normative)

4. Optional Application of Standard (informative or normative)

5, 6, 7 etc. The Meat of the Standard (normative)

. . .

Appendix A. Glossary (informative)



Appendix B. Bibliography (informative)

Appendix C. Examples (informative)


The essential job of this paper is to propose how to handle the middle of the standard, section "5 and following". The informative sections ahead of that are filled in later to agree with the middle and normative sections 1, 2 and 3 become obvious after the middle is completed. The Appendices at the end are also optional and follow from the middle information.
There are four steps to creating the middle of the standard so as to merge Standards 830 and 1233:

  1. Decide what parts of Standard 1233 should be included and where they should go.

  2. Decide how to handle the interface between the present 830 and 1232, which presently is in neither standard.

  3. Decide what parts of Standard 830 should be included and where they should go.

  4. Decide whether to include in the standard other topics and, if so, where they should go.

These steps are expanded in the following.



Handling Standard 1233
The present outline of Standard 1233 is as follows:
Standard 1233 Outline
1. Overview

1.1. Scope

2. References

3. Definitions

4. Systems Requirements Specifications

4.1. Definition

4.2. Properties

4.3. Purpose

4.4. Intended Use

4.5. Benefits

4.6. Dynamics of System Requirements

5. SyRS Development Process Overview

5.1. Customer

5.2. Environment

5.3. Technical Community

6. Well-formed Requirements

6.1. Definition of a Well-formed Requirement

6.2. Properties of a Requirement

6.3. Categorization

6.4. Pitfalls

7. SyRS Development

7.1. Identify Requirements

7.2. Build a well-formed Requirement

7.3. Organize Requirements

7.4. Present Requirements

A. System Requirements Specification Outline

B. Bibliography

C. Guidelines for Compliance with IEEE/EIA 12207.1-1997

As stated above, sections 1, 2, 3, A, B and C would be considered later. Therefore we need to examine sections 4, 5, 6 and 7.
Sections 5 and 7 describe the System Requirements process so should certainly be in the combined standard. Section 4 consists of general considerations, probably informative, and should go in the front end of the combined standard, for example section 4 in the general outline above. Section 6 gives properties of system requirements and should be in the combined standard. It should not divide sections 5 and 7, but instead should go after them.
Handling the Interface Between Systems and Software Standard Specification
In the SWEBOK this step is described as the allocation or distribution or partitioning of system requirements to subsystems or components. There it is called "Architectural Design" but I think this would be an unfortunate title because, in our standards, design is the step after requirements and is

typically performed by the software developer not by the customer who creates the requirements. Therefore I propose to call it, in this document, "System Requirements Allocation" and therefore it should be a new section in the combined standard.


Four situations can occur:

  • A systems requirement may not lead to a software requirement.

  • A systems requirement may, without change, really be a software requirement.

  • A systems requirement may map directly into one or more software requirements, in which case this mapping should be documented.

  • A software requirement may have no specific corresponding systems requirement, but rather derive from good design practice and thus from some general systems characteristic.

All these situations need to be considered in the combined standard.


Handling Standard 830
Standard 830 has already been the subject of a revision process that ended unsuccessfully. The outline below is of that draft, not the published standard 830. For that reason the outline is given in somewhat greater detail.
Standard 830 Outline
Abstract

Keywords


Introduction

1. Overview (normative)

2. References (normative)

3. Definitions (normative)

4. Application of this Standard (informative)

Nature of the SRD.

Environment of the SRD.

5. Performing Software Requirements (normative)

5.1. Obtaining or Eliciting Software Requirements Information

5.2. Specifying Software Requirements

5.3. Information that shall not be specified as part of the SRD Activity

5.4. Correctness of Software Requirements

5.5. Compatibility of Software Requirements

5.6. Improving the Software requirements Activity

6. Typical Arrangement of an SRD (informative)

Supporting Information.

Annex A (informative) SRD Templates
Again, the sections up through 3 would go in the front of the combined standard. Section 4 would go in a combined section 4. Section 6 and the Annex would go in the Appendices.
The correspondence of section 5 of Standard 830 is as follows:
Standard 830 Standard 1233

5.1: Obtain & Elicit 7.1: Process

5.2: Specifying 6.1: Well-formed

5.3: Info not specified 6.4: Pitfalls

5.4: Correctness 4.2: Properties

5.5: Compatibility 6.2: Properties

5.6: Process Improve after 7.4
Therefore, all of standard 830 merges rather smoothly into corresponding sections of standard 1233. 830 is more detailed than 1233 but that is a good thing.
What Else
The SWEBOK Requirements chapter states several activities as part of requirements:


  • Requirements Engineering Process: Standard 12207 covers this.

  • Requirements Elicitation: Covered in this proposal and in Standard 1362.

  • Requirements Analysis: Correctness and compatibility of requirements are covered in this proposal.

  • Requirements Specification: Covered in this proposal.

  • Requirements Validation: Validation must be treated outside of the standard. Standards 829, 982.1, 1012, 1028, 1074, 1220 and 1471 relate to it.

  • Requirements Management: Treated in standard 1058.

Proposed Combined Standard Outline
Abstract (informative)

Based on both 830 and 1233


Keywords (informative)

Based on both 830 and 1233


Introduction (informative)

Based on both 830 and 1233


1. Overview (normative)

1.1. Scope

Based on both 830 and 1233

1.2. Purpose

Based on both 830 and 1233

1.3. Field of Application

Based on both 830 and 1233

1.4. Conformance

New conformance statement because a full standard.

From 830 section 1.4.

1.5. Disclaimers

Based on both 830 and 1233


2. References (normative)

Based on both 830 and 1233


3. Definitions (normative)

Based on both 830 and 1233


4. Application of this Standard (informative)

Requirements Engineering Process [from SWEBOK]

Process models [from SWEBOK]

Process actors [from SWEBOK]

Process support [from SWEBOK]

Application of the Standard (informative)

Nature of the SRD [from 830 section 4]

Environment of the SRD [from 830 section 4].

Purpose [from 1233 section 4.3]

Intended Use [from 1233 section 4.4]

Benefits [from 1233 section 4.5]

Dynamics of System Requirements [from 1233 section 4.6]


5. System Specification Process

5.1. SyRS Process Overview

Customer [from 1233 section 5.1]

Environment [from 1233 section 5.2]

Technical Community [from 1233 section 5.3]

5.2. SyRS Development Process Steps

Identify Requirements [from 1233 section 7.1]

Requirements Specification [from SWEBOK]

Requirements Elicitation [from SWEBOK]

Requirements sources [from SWEBOK]

Elicitation technique [from SWEBOK]

Obtaining or Eliciting Software Requirements Information

[from 830 section 5.1]

Build a well-formed Requirement [from 1233 section 7.2]

Organize Requirements [from 1233 section 7.3]

Present Requirements [from 1233 section 7.4]

5.3. SyRS Process Management

Change management [from SWEBOK]

Improving the Software requirements Activity

[from 830 section 5.6]

Requirements Management [from SWEBOK]
6. System Process Requirements Allocation

Allocation to Software [All new]

Allocation to Hardware [All new]

Allocation to Operations [All new]


7. Requirements attributes [from SWEBOK]

Definition of a well-formed requirement

[from 1233 section 6.1]

Categorization [from 1233 section 6.3]

Requirements definition document [from SWEBOK]

Software requirements specification [from SWEBOK]

document structure [from SWEBOK]

document quality [from SWEBOK]

7.1. Types of Requirements [from 830 section 5.2]

Functionality Requirements

Functionality Requirements

Interface Requirements

Performance Requirements

Product Support Requirements

Qualification Requirements

Design & Implementation Constraint Requirements

Interface Requirements

Performance Requirements

Product Support Requirements

Qualification Requirements

Design & Implementation Constraint Requirements

7.2. Correctness of Software Requirements [from 830 section 5.4]

Clarity (lack of Ambiguity)

Completeness

Internal Consistency

Feasibility

Properties [from 1233 section 4.2]

7.3. Compatibility of Software Requirements

[from 830 section 5.5]

Verification

Traceable

Modifiable

Ranked for Importance

Ranked for Stability

Properties [from 1233 section 6.2]

7.4. Requirements Validation [from SWEBOK]

Conduct of requirement reviews [from SWEBOK]

Prototyping [from SWEBOK]

Prototyping [from 830 section 5.1.1]

Model validation [from SWEBOK]

Acceptance tests [from SWEBOK]
7.5 Problems with Specifying Requirements

Requirement tracing [from SWEBOK]

Embedding Design in the SRD. [from 830 section 5.3.1]

Embedding Project Requirements in the SRD.

[from 830 section 5.3.2]

Requirements Analysis [from SWEBOK]

Requirements classification [from SWEBOK]

Conceptual modeling [from SWEBOK]

Requirements negotiation [from SWEBOK]
Annex A Typical Arrangement of an SRD (informative)

[from 830 section 6]

Introduction (Clause 1 of the SRD).

The Overall Description (Clause 2 of the SRD).

Specific Requirements (Clause 3 of the SRD).
SRD Templates

A.1 Template of SRD Clause 3 Organized by Mode (Version I)

A.2 Template of SRD Clause 3 Organized by Mode (Version II)

A.3 Template of SRD Clause 3 Organized by Operator Class

A.4 Template of SRD Clause 3 Organized by Object

A.5 Template of SRD Clause 3 Organized by Feature

A.6 Template of SRD Clause 3 Organized by Stimulus

A.7 Template of SRD Clause 3 Organized by Functional Hierarchy

A.8 Template of SRD Clause 3 Showing Multiple Organizations
Annex B Glossary (informative)
Annex C Bibliography (informative)
----------------------------------
Summary and Conclusions


  1. It is certainly possible to combine standards 830 and 1233

  2. The primary reason to do this is because there is more emphasis on systems today and less on software details.

  3. Combination requires an additional step, namely mapping system requirements to subsystem attributes.

  4. This is only applicable to software-intensive systems.

  5. Regardless of the fact that there would be one standard for systems requirements, including software, it might still be desirable to create two separate documents.

References


1. Guide to the Software Engineering Body of Knowledge (SWEBOK), available from IEEE Computer Society
<8301233.doc>






Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©www.azrefs.org 2016
rəhbərliyinə müraciət

    Ana səhifə