Specification Architecture Requirement : For an increasing number of systems in the industrial automation functional safety requirements must be fulfilled. The IEC 61508 compliance must be demonstrated for the software development.
On the other hand, there are commercial requirements which often severely limit the product development budget.
The solution lies in an efficient development process that meets the safety-relevant requirements. A prerequisite for a successful implementation of such a process is a deep understanding of the standard and a clear definition of used terms. In the following blog, I discuss the three terms Specification Architecture Requirement.

Specification

Wikipedia defines the following 3 types of specification which are of interest for this blog:
A requirement specification is a set of documented requirements to be satisfied by a material, design, product, or service.
A functional specification is closely related to the requirement specification and may show functional block diagrams.
A design or product specification describes the features of the solutions for the Requirement Specification, referring to the designed solution or final produced solution. Sometimes the term specification is here used in connection with a data sheet (or spec sheet). This may be confusing. A data sheet describes the technical characteristics of an item or product as designed and/or produced. It can be published by a manufacturer to help people choose products or to help use the products. A data sheet is not a technical specification as described in this article.

Requirement

Chris Rupp and Klaus Pohl provide the following definition in there book Requirements Engineering Fundamentals:

1. A requirement is a condition or capability needed by a user to solve a problem or achieve an objective.
2. A requirement is a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A requirement is a documented representation of a condition or capability as in 1) or 2).

The definition of 1. defines that a requirement describes the “WHAT” of a product or system. Such requirements can be documented very well and very easily in textual form in a database.
The definitions given in 2. and 3. contain references to documents. In this case, the content of a requirement depends directly on the content of these documents. In the case of a contract, a standard or a specification describing the architecture of a product / system, the architecture of a product / system becomes a requirement. In addition also legal aspects of the term requirement are dealt with in 2.

Architecture

Wikipedia defines Software Architecture as follows:
Software architecture refers to the fundamental structures of a software system, the discipline of creating such structures, and the documentation of these structures. These structures are needed to reason about the software system. Each structure comprises software elements, relations among them, and properties of both elements and relations, along with rationale for the introduction and configuration of each element. The architecture of a software system is a metaphor, analogous to the architecture of a building.
In contrast to the definition of requirements according to 1., the architecture clearly describes the “HOW” of a software / product / system.
Architecture can usually be easily represented in graphical form. Only boundary conditions or pre- and post-conditions can be better documented in text.

IEC 61508-3

Annex A, IEC 61508-3 defines procedures and measures for the following areas:

• A.1 Specification of the requirements for the safety of the software
• A.2 Software design and software development – software architecture design
• A.4 Software design and software development – Detailed design

The procedures and measures for the architecture described in tables A.2 and A.4 can be assigned easily. To implement an efficient development process, it should be only one software architecture document created. This shall contain:

• An overview of all system components and their relationship to each other
• All software components
• The most important data and control flows between the software components
• A traceability between the software components and the source code modules

In this case, tables A.2 and A.4 can be satisfied with a consistent architecture. A “hard” separation in software architecture design and the detailed design is not effective in most cases and leads to a documentation effort that does not provide any added value for the functional safety of the system.
Procedures and measures for requirements defined by 1) are defined only indirectly in table A.1 in IEC61508-3. You can only apply textual requirements as a measure if you define the requirements templates to be used as a semi- formal method. In the sense of the efficient development process, this approach is highly recommended.

Conclusion: Specification Architecture Requirement

A specification defines a document that can contain both requirements and architecture. The IEC61508 “thinks” not in documents and therefore this term plays no role in the standard.
A conscious distinction between requirements defined by 1. and the architecture is urgently recommended for an efficient development process. If you do so, you automatically define what has to be tested. Only requirements defined by 1) are directly testable. The correctness of the architecture can finally only be determined by reviews. In addition, it is important for an efficient development that several architectures can be used to solve a problem defined in the requirements. Software and system platforms can only be successfully used with this deliberate separation.
For the customer, it is crucial that the product solves his problem (defined in the requirements). The customer should not determine how (architecture) the problem is solved.
Anyway, the world is not black or white. This saying also applies to this topic. In the projects there are always concrete cases in which it is useful to describe architectural elements in requirements. There are also cases where requirements are contained in the architecture. It is important to consider these special cases as such and to implement the above described in the sense of the Paretto principle (80/20 rule).

Related HEICON Blog posts

• How many level of Software requirements are necessary and useful?
• Requirement Engineering – Aspects which even not considerd in theory!
• Requirement Categories – Why they are useful?
• Good safety development process – What is it?

I’ll be glad to help you also with any specific questions about your project. Send an email to: info [at] heicon-ulm.de

An overview of the HEICON services can also be found on the HEICON Homepage.