Software requirement analysis

5.4.2.1

Establishment and documentation of software requirements

5.4.2.1.1

Techniques

The Use Case technique can support this activity and is described in 6.1

5.4.2.1.2

Tools

In the last ten years requirements are increasingly specified and maintained in dedicated requirements engineering tools.

Requirement management tools usually contain some kind of database management facility. Expected capabilities of these tools are:

a. ensuring unique identifiers,

b. attach attributes (i.e. tool-defined or user-defined database fields) to requirements, such as status, importance, delivery version, verification method, creator, importance, risk, requirement category, creation date, last modification date, etc.

c. capturing, modifying, deleting and searching requirements and their attributes, d. support cross referencing and traceability,

e. version control and revision history,

g. interface to documentation tools for document generation to produce requirement specifications,

h. view and multimedia facilities

For medium to large projects and especially for generic projects, a tool to manage requirements is invaluable. This especially applies for complex space systems where several different levels of decomposition are identified, and where requirements are specified and traced accordingly. In these circumstances keeping traces and relations manually becomes unacceptably error-prone and time- consuming.

5.4.2.2

Definition of functional and performance requirements for in flight

modification

-

5.4.2.3

Construction of a software logical model

The ECSS-E-ST-40-C defines the logical model as reported in the following:

a. The logical model is an implementation independent model of software items used to analyse and document software requirements (3.2.13)

b. The logical model is a representation of the technical specification, independent of the implementation, describing the functional behaviour of the software product. It supports the requirements capture, documents and formalizes the software requirements. It also can support an iterative verification process with the customer.

c. The logical model allows in particular to verify that a technical specification is complete (i.e. by checking a software requirement exists for each logical model element), and consistent (because of the model checking).

d. The logical model should be defined using a language with well-defined semantics, which could possibly be executable. Formal methods can then be used to prove properties of the logical model itself and therefore of the technical specification. This does not preclude using any specific method or tool.

e. The logical model can be completed by specific feasibility analyses such as benchmarks, in order to check the technical budgets (e.g. memory size and computer throughput). In case the modelling technique allows for it, preliminary automatic code generation can be used to define the contents of the software validation test specification.

f. If software system co-engineering activities are considered, the logical model could be a refinement of the following system models: data, application function, event and failure

The ECSS-E-ST-40C clause 5.4.2.3 requires that the supplier construct the logical model.

The software logical model is a simplified model of the software application. It makes the software requirements understandable as a whole and not just individually. Depending on the language that expresses it, it can also be used for verification of completeness, consistency, proof or formal verification of some high level properties and generation of test scenarios.

A software logical model should be initially a simplified description that shows the high level essentials, that should show what the software system do, and avoid using implementation details. It should be defined more in depth for new complex functions, for instance, in order to assess the feasibility of requirements, than for reused functions or simple ones. The effort to increase the level of detail of the logical model should be balanced with the expected added value.

The model should be a communication bridge between the software and the system teams, enabling them to understand and agree requirements, and to anticipate the software requirements early within the system definition in the systems engineering processes related to software. This is of primary importance for software. Preserving the adopted system modelling method for software modelling, or assuring the continuity through appropriate model transformations with preservation of properties, represents an asset for the efficiency and correctness of the flow from requirements to implementation. A model is simpler to understand and maintain when it is hierarchical, with consistent decomposition criteria, progressing through level of abstractions. It should be organized around a defined software component model approach (see 6.3.2.4).

The model shows the software functionalities and includes behavioural views. State transitions diagrams support the behavioural view representation that can be used also during the design activities. Alternatively Petri-Nets, SDL or other methods can be used.

The logical model can be built using different methods depending on the software functions (e.g. FDIR) or other characteristics (e.g. automata, modes). Possible methods and/or languages are:

a. functional decomposition, structured analysis, mathematics b. object-oriented analysis (OOA);

c. formal methods;

d. use case and scenarios, e.g. as introduced in UML

See the Annex B for detailed descriptions of such languages and methods.

Although the authors of any particular method will argue for its general applicability, all of the methods appear to have been developed with a particular type of system in mind. Looking at the examples and case histories supports the decision whether a method is suitable.

The experience gives indication on which function benefits better of which method:

a. the control and guidance of satellites, producing cyclically actuation data from sensor data, are best modelled with mathematics, data flows or functional models

b. the mode management of a spacecraft, or the reconfiguration after failure, or some parts of autonomy management, are best modelled with state transitions diagrams.

c. data management systems, in their parts where data flow or state machines alone cannot naturally represent them, are better modelled with UML.

d. the high criticality of the software under development may suggest the application of formal methods.

NOTE Model based engineering is discussed in 6.3.

5.4.2.4

Conduction a software requirement review

-