Software Process Models
The V-Model is Dead. Long Live the V-Model!
Firma zum Thema
Level 3 System Architecture Specification
Purpose: to document the splitting of a system specification to enable better specification of the whole by the specification of sub-systems and how the sub-systems are to interact.
As part of a design process, requirements that have been, or will be, committed to be supplied (level 2) are allocated to be satisfied by parts of the system under development. We shall call this type of information level 3. Based upon the design decisions made at this level, the requirements are either re-written (split or further detailed) or left unchanged according to needs.
The System Architect is responsible for this definition of requirements at level 3. The main requirements work at level 3 can be summarised as four parts:
- Part A is the introduction of interfaces between the parts of the system as defined by the System Architect.
- Part B is requirements are introduced e.g. to specify transforming information between the system interface and the hardware software interface.
- Part C Requirements to be fulfilled by sub-systems need to be written at level 3 to use the information at the sub-system interface. At level 3 the content of requirements describing behaviour can normally have the same content as the requirements at level 2 but the interface used is different.
- Part D specifies the collaboration between the sub-systems.
Level 4 Sub-system Requirements Specification
Purpose: to enable a common understanding of a commitment to supply a particular solution to satisfy the requirements as specified by the System Architecture.
We shall call this type of information level 4. The analysts for each sub-system are responsible. It is easy for the requirements at level 4 to be the same as the requirements at level 3.
The System Architect and Sub-System Analyst working together to ensure agreement can prevent the need to repeat requirements from level 3 to level 4. Extended across the whole information model this way of working has shown savings of between 40 and 80% of the effort needed to define and release requirements.
Level 5a Sub-system Architecture Design Specification
Purpose: to document the splitting of a sub-system specification to enable better specification of the whole by the specification of components and how the components are to interact.
As part of a design process, requirements that have been agreed to be satisfied by the creation of a sub-system (level 4) are allocated to be satisfied by components of the sub-system under development. We shall call this type of information level 5a. Based upon the design decisions made at this level, the requirements are either re-written (split or further detailed) or left unchanged according to needs.
The Sub-System Architect (e.g. SW Architect) is responsible for this.
Level 5b Sub-system Detailed Design Specification
Purpose: to document the detailed design of how a component is to be built to satisfy its requirements.
At level 5b requirements are transformed into design. That is, wishes for results to be achieved are transformed into concrete plans for implementation.
This level is strongly influenced by information and experience from lower levels. Experts in implementation will work with the architects to ensure that what is planned is realistic given the available resources.