Software Requirments Specification (SRS): What are 'System Interfaces'? [closed]

Question

In the Wikipedia link for SRS, in the 'Product Perspective' section, there is a mention of the term 'System Interfaces'. I am not clear as to what exactly that means. I have looked at a few other SRS samples available online but am not able to piece together an unambiguous definition from the examples. Could someone elaborate on what 'System Interfaces' refer to?

Answer 1

The IEEE 830-1998 standard defines 'Hardware Interfaces' as

'the logical characteristics of each interface between the software product and the hardware components of the system'

Similarly, it defines 'User Interfaces' as

'the logical characteristics of each interface between the software product and its users'.

So, a little reasoning tells us that the 'System Interface' should have been defined as

'the logical characteristics of each interface between the software product and the bigger system'.

That means, 'system interfaces' are not the bigger system's interfaces with the outside world, but the internal interfaces between the software and everything else within the bigger system, which includes user interfaces, hardware interfaces and software interfaces.

Ironically, the 830-1998 is written in a so inconsistent fashion that the recommended section hierarchy is:

2. Overall Description
   2.1. Product perspective
     2.1.1 System Interfaces 
     2.1.2. User Interfaces
     2.1.3. Hardware Interfaces
     2.1.4. Software Interfaces 
...

where 2.1.1 should really be the parent section of 2.1.2 - 2.1.4.

So they gave some vague definitions of the 'system interfaces' section:

This should list each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system.

Whoever wrote this, please try get a B from the 12th grade English composition class!

Anyway, as a non-native speaker, my understanding of IEEE's version of the 'System Interface' is that:

1. Software may be an independent product made for general use (e.g. commercial software, video games, etc.), or it may be a part of a bigger system which contains both software and hardware. For example, a car is a system and the embedded computer software is only a part of the system. Another example is the software in a hospital CT scanner is also a part of the system (the machine).

2. Assuming the system requirement is defined before the software requirement (i.e. top-down approach), think about

a) what functionality your software must have in order to meet the system requirement? (can't forget the bigger picture)

For example, if a automatic driving car system requirement is that 'the car shall detect sudden slow downs of the vehicles in front of the car within 0.1 seconds', then you may need to write a non-functional requirement for your software system such as 'after the software receives the 'sudden slow down' signal from the front sensor, it shall process the signal and make decisions. If it is a confirmed real scenario (not a false alarm) then the software shall send 'hit break' signal to the break system. The decision making and signal sending process shall take no longer than 0.05 seconds.

b) what are the interfaces between your software and everything else within the bigger system?

E.g. your car computer software shall have the following interface with the front sensor:

public int processFrontSensorSignal(Signal signal){
   if (signal.getType() == 1){
      SuddenSlowDownSignalProcessor.process(signal);
   } else if (signal.getType() == 2){
      ...
   }
   else
    ....
}

Such interfaces shall be clearly defined.

If you software is not part of a bigger system, or if it is designed to be a generic software to be run in general systems (e.g. MS Windows applications), then there is little need for specifying the 'System Interfaces' section.