Software Requirements Knowledge Area

A requirement is defined as a property that must be exhibited in order to solve some problem of the real world.

The first knowledge sub-area is the requirement engineering process, which introduces the requirements engineering process, orienting the remaining five topics and showing how requirements engineering dovetails with the overall software engineering process. It describes process models, process actors, process support and management, and process quality improvement.

The second sub-area is requirements elicitation, which is concerned with where requirements come from and how they can be collected by the requirements engineer. It includes requirement sources and techniques for elicitation.

The third sub-area, requirements analysis, is concerned with the process of analyzing requirements to:

Requirements analysis includes requirements classification, conceptual modeling, architectural design and requirements allocation and requirements negotiation.

The fourth sub-area is software requirements specification. It describes the structure, quality, and verifiability of the requirements document. This may take the form of two documents, or two parts of the same document with different readership and purposes. The first document is the system requirements definition document, and the second is the software requirements specification. The sub-area also describes the document structure and standards and document quality.

The fifth sub-area is requirements validation whose aim is to pick up any problems before resources are committed to addressing the requirements. Requirements validation is concerned with the process of examining the requirements document to ensure that it defines the right system (i.e., the system that the user expects). It is subdivided into descriptions of the conduct of requirements reviews, prototyping, model validation, and acceptance tests.

The last sub-area is requirements management, which is an activity that spans the whole software life cycle. It is fundamentally about change management and the maintenance of the requirements in a state that accurately mirrors the software to be, or that has been, built. It includes change management, requirements attributes, and requirements tracing.

The above summary was adapted from the Introduction to the IEEE Computer Society's SWEBOK Guide. For more information on the Software Requirements Knowledge Area, read Chapter 2 of the SWEBOK Guide.





IEEE Std 830™-1998


IEEE Recommended Practice for Software Requirements Specifications

The content and qualities of a good software requirements specification (SRS) are described and several sample SRS outlines are presented. This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selection of in-house and commercial software products. Guidelines for compliance with IEEE/EIA 12207.1-1997 are also provided.

IEEE Std 1062™, 1998 Edition

IEEE Recommended Practice for Software Acquisition

A set of useful quality practices that can be selected and applied during one or more steps in a software acquisition process is described. This recommended practice can be applied to software that runs on any computer system regardless of the size, complexity, or criticality of the software, but is more suited for use on modified-off-the-shelf software and fully developed software.

IEEE Std 1228™-1994


IEEE Standard for Software Safety Plans

The minimum acceptable requirements for the content of a software safety plan are established. This standard applies to the software safety plan used for the development, procurement, maintenance, and retirement of safety-critical software. This standard requires that the plan be prepared within the context of the system safety program. Only the safety aspects of the software are included. This standard does not contain special provisions required for software used in distributed systems or in parallel processors.

IEEE Std 1233™, 1998 Edition


IEEE Guide for Developing System Requirements Specifications

Guidance for the development of the set of requirements, System Requirements Specification (SyRS), that will satisfy an expressed need is provided. Developing an SyRS includes the identification, organization, presentation, and modification of the requirements. Also addressed are the conditions for incorporating operational concepts, design constraints, and design configuration requirements into the specification. This guide also covers the necessary characteristics and qualities of individual requirements and the set of all requirements.

IEEE Std 1320.1™-1998


IEEE Standard for Functional Modeling Language—Syntax and Semantics for IDEF0

IDEF0 function modeling is designed to represent the decisions, actions, and activities of an existing or prospective organization or system. IDEF0 graphics and accompanying texts are presented in an organized and systematic way to gain understanding, support analysis, provide logic for potential changes, specify requirements, and support system-level design and integration activities. IDEF0 may be used to model a wide variety of systems, composed of people, machines, materials, computers, and information of all varieties and structured by the relationships among them, both automated and nonautomated. For new systems, IDEF0 may be used first to define requirements and to specify functions to be carried out by the future system. As the basis of this architecture, IDEF0 may then be used to design an implementation that meets these requirements and performs these functions. For existing systems, IDEF0 can be used to analyze the functions that the system performs and to record the means by which these are done.

IEEE Std 1320.2™-1998


IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject)

IDEF1X97 consists of two conceptual modeling languages. The key-style language supports data/information modeling and is downward compatible with the U.S. government’s 1993 standard, FIPS PUB 184. The identity-style language is based on the object model with declarative rules and constraints. IDEF1X97 identity style includes constructs for the distinct but related components of object abstraction: interface, requests, and realization; utilizes graphics to state the interface; and defines a declarative, directly executable Rule and Constraint Language for requests and realizations. IDEF1X97  conceptual modeling supports implementation by relational databases, extended relational databases, object databases, and object programming languages. IDEF1X97 is formally defined in terms of first order logic. A procedure is given whereby any valid IDEF1X97 model can be transformed into an equivalent theory in first order logic. That procedure is then applied to a meta model of IDEF1X97 to define the valid set of IDEF1X97 models.

IEEE Std 1362™-1998


IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document

The format and contents of a concept of operations (ConOps) document are described. A ConOps is a user-oriented document that describes system characteristics for a proposed system from the users' viewpoint. The ConOps document is used to communicate overall quantitative and qualitative system characteristics to the user, buyer, developer, and other organizational elements (for example, training, facilities, staffing, and maintenance). It is used to describe the user organization(s), mission(s), and organizational objectives from an integrated systems point of view.

IEEE Std 1465™-1998


IEEE Standard—Adoption of International Standard ISO/IEC 12119: 1994(E)—Information Technology— Software packages—Quality requirements and testing

Quality requirements for software packages and instructions on how to test a software package against these requirements are established. The requirements apply to software packages as they are offered and delivered, not to the production process (including activities and intermediate products, such as specifications).

IEEE Std 14143.1™-2000


IEEE Adoption of ISO/IEC 14143-1:1998 Information Technology—Software Measurement—Functional Size Measurement—Part 1: Definition of Concepts

This part [volume] of ISO/IEC 14143 defines the fundamental concepts of Functional Size Measurement (FSM) and describes the general principles for applying an FSM Method. This part of ISO/IEC 14143 does NOT provide detailed rules on how to:

  • Measure Functional Size of software using a particular method;

  • Use the results obtained from a particular method;

  • Select a particular method.

This part of ISO/IEC 14143 is applicable when determining if a method for sizing software is an FSM Method. It does not prevent the development of various methods, but rather provides a basis for assessing whether a particular method conforms to FSM. Implementation notes that relate to the IEEE interpretation of ISO/IEC 14143-1:1998 are provided.

About IEEE standard numbers.