System Requirements

System Requirements

System requirements are expanded versions of the user requirements that are used by software engineers as the starting point for the system design. They add detail and explain how the user requirements should be provided by the system. They may be used as part of the contract for the implementation of the system and should therefore be a complete and consistent specification of the whole system.

Ideally, the system requirements should simply describe the external behavior of the system and its operational constraints. They should not be concerned with how the system should be designed or implemented. However, at the level of detail required to completely specify a complex software system, it is impossible, in practice, to exclude all design information.

There are several reasons for this:

1. You may have to design an initial architecture of the system to help structure the requirements specification. The system requirements are organized according to the different sub-systems that make up the system. This architectural definition is essential if you want to reuse software components when implementing the system.
2. In most cases, systems must interoperate with other existing systems. These constrain the design, and these constraints impose requirements on the new system.
3. The use of a specific architecture to satisfy non-functional requirements (such as N-version programming to achieve reliability) may be necessary. An external regulator who needs to certify that the system is safe may specify that an architectural design that has already been certified be used.

• Natural language understanding relies on the specification of readers and writers using the same words for the same concept. This leads to misunderstandings because of the ambiguity of natural language. Jackson (Jackson, 1995) gives an excellent example of this when he discusses signs displayed by an escalator. These said 'Shoes must be worn' and 'Dogs must be carried'. I leave it to you to work out the conflicting interpretations of these phrases.

• A natural language requirements specification is over flexible. You can say the same thing in completely different ways. It is up to the reader to find out when requirements are the same and when they are distinct.

• There is no easy way to modularise natural language requirements, It may be difficult to find all related requirements. To discover the consequence of a change. you may have to look at every requirement rather than at just a group of related requirements.

Natural language is often used to write system requirements specifications as well as user requirements. However, because system requirements are more detailed than user requirements, natural language specifications can be confusing and hard to understand:

Because of these problems, requirements specifications written in natural language are prone to misunderstandings. These are often not discovered until later phases of the software process and may then be very expensive to resolve.

It is essential to write user requirements in a language that non-specialists can understand. However, you can write system requirements in more specialized notations. These include stylized, structured natural language, graphical models of the requirements such as use-cases to formal mathematical specifications.

.