Q. Your System Requirements Specification and Software Requirements Specification templates start off in a "4. Requirements" section with "4.1 Identification of External Interfaces", and "4.2 Identification of States and Modes". Why is that?

http://www.ppi-int.com/systems-engineering/specification-structure.php

A.

Technically, it is possible to avoid having the sections "Identification of External Interfaces" and "Identification of States and Modes", and to use a definition of each interface and state and mode in a Definitions section instead. The pros and cons are:

External Interfaces:

Advantages of "Identification of External Interfaces" section 4.1:

  • prevents logical non-sequeta in subsequent references to a given interface, e.g. "The system, in response to a xxx input at the xyz interface, shall .." without having defined a requirement for the system to have such an interface
  • increases ease of understanding of the requirements and requirements section overall, by establishing context. In fact, it is not uncommon to follow the "shall have the following external interfaces .." requirement with an image (not box)-oriented informative (not normative) context diagram
  • accurately states actual requirements
  • avoids contrived definitions "Mains Power Interface means an interface for the purpose of connection of mains power"
  • contractually stronger (We know there are requirements on the Remote Control Interface, but there was no requirement to have one, so we consider that they do not apply).
  • caters for the situation where there is a need for an interface, but the level of risk does not justify the formalization of requirements on that interface.

Disadvantages of "Identification of External Interfaces" section 4.1 (c.f. if replaced by definitions):

  • increases the number of requirements, and related work that is proportional to the number of requirements, e,g. traceability, verification requirements, verification design, verification

States & Modes:

Advantages of "Identification of States and Modes" section 4.2:

  • prevents logical non-sequeta in subsequent references to a given state or mode, e.g. "The system, in File Retrieve Mode, shall .." without having defined a requirement for the system to have such a mode
  • increases ease of understanding of the requirements and requirements section overall, by describing big picture dynamics that are required, before the detail
  • accurately states actual requirements
  • contractually stronger (We know there are requirements in a Self-Test Mode, but there was no requirement to have a self-test mode, so we consider that they do not apply).

Disadvantages of "Identification of States and Modes" section 4.2 (c.f. if replaced by definitions only):

  • increases the number of requirements, and related work that is proportional to the number of requirements, e,g. traceability, verification requirements, verification design, verification

So, it is a trade-off.

Testimonial

"Very good instructor, very thorough and attentive to studentsí questions/queries"

Systems Engineering Course
delegate, Australia

PPI currently presents courses on 6 continents

Map

Featured Course

Requirements Analysis & Specification Writing
Las Vegas, NV

13 - 17 November, 2017

Requirements Analysis and Specification Writing are sciences practiced by many, mastered by surprisingly few. And yet, the payoff from achieving excellence in these areas is large. The two aspects, Requirements Analysis and Specification Writing, are treated as separate but related topics, each in a course of three and two days duration.

Brochure | Register Now

Systems Engineering NEWSLETTER

SyEN makes informative reading for the project professional, containing scores of news and other items summarizing developments in the field of systems engineering and in directly related fields.