Royal Greenwich Observatory,
Madingley Road,
Cambridge CB3 OHJ

Telephone  (01223)374000
Fax                (01223)374700
Internet http://www.ast.cam.ac.uk/

CONTENTS

1   Introduction
          1.1   Purpose of this document
          1.2  General points about the software life-cycle

2  The user-requirements definition phase

2.1   Section 2.3.2: determination of operational environment
2.2   Section 2.3.3.2 (g) : verifiability
2.3   Section 2.4.1: user-requirements document
2.4   Section 2.4.4: configuration management for the SR phase
2.5   Section 2.4.6: quality-assurance plan for the SR phase
2.6   Appendix D2: UR16

3.1  Section 3.3.2: specification of software requirements
3.2  Section 3.3.2.2: attributes of software requirements
3.3  Section 3.3.2.3: completeness of software requirements
3.4  Section 3.4.4: configuration-management plan for the AD phase
3.5  Section 3.4.6: quality-assurance plan for the AD phase
3.6  Appendix C2: SRD table of contents

4.1   Section 4.3.1: construction of the physical model
4.2   Section 4.3.4: reviews
4.3   Section 3.4.4: configuration-management plan for the DD phase
4.4   Section 3.4.6: quality-assurance plan for the DD phase

5.1   Section 5.3.1: detailed design
5.2   Section 5.3.2.1: coding
5.3   Section 5.3.2.3.1: unit testing
5.4   Section 5.3.3: reviews
5.5   Section 5.4.3: software user-manual
5.6   Section 3.4.4: configuration-management plan for the TR phase
5.7   Section 3.4.6: quality-assurance plan for the TR phase

6.1   Section 6.3.3: provisional acceptance

8   Software-management plans

     Appendix A.   Document history
 

1  Introduction

1.1  Purpose of this document

Reviews should be carried out as specified in the ESA SES and will normally take the form of a meeting at RGO, Cambridge. The review should include input from ING, which will be via a representative on the review panel.

Interim versions of documents may be circulated to allow early incorporation of comments.

Documents for final review will be distributed in hard-copy or b email, and a deadline of at least two weeks will be allowed for comments to be made. Such comments may be collected in a VAX-notes conference. ³
 
 

2  The user-requirements definition phase

2.1  Section 2.3.2: determination of operational environment

The emphasis should be given to describing the interfaces to the operational environment, rather  than defining them in detail.

The interface-control documents may be produced at this stage, but in some cases it will be appropriate to delay the precise definition until a later phase.

2.2  Section 2.3.3.2 (g) : verifiability

A formal, mathematical proof that a particular requirement is implemented is not generally required.⁴

2.3  Section 2.4.1: user-requirements document

A detailed definition of most interfaces to the system may be deferred to the software-requirements phase and need not appear in the URD except in cases where the interfaces are integral to the users`  requirements (i.e. when the requirement for an interface does not arise entirely from the operational environment). In this case, the interfaces must be defined in detail in the URD or in accompanying ICDS.

The URD should, at a minimum, contain a description of the interface to the operational requirement.

The divisional standard for configuration management⁵ may be used.

2.5  Section 2.4.6: quality-assurance plan for the SR phase

The divisional standard quality-assurance plan⁶ may be used.

This requirement becomes: 'The URD shall describe those external interfaces to the system that the user specifies explicitly; the URD may reference these interfaces in ICD’s that exist or are yet to be written.'
 

3  The software-requirements-definition phase

This section list amendments and simplifications to Chapter 3 and appendices C2 and D3 of the ESA standard. Where a section is not mentioned, the original text of the ESA standard applies.

3.1  Section 3.3.2: specification of software requirements

All headings should be kept although some may be stated as being non-applicable. If additional categories can be identified the developers should feel free to use these provided that duplication does not occur.

(b) need should be specified on a scale from 1 to 5 with I being the highest and indicating that the requirement is essential.

(c) priority should be specified on a scale from 1 to 5 with I being the highest and indicating that
the requirement should be delivered soonest.

(e) source should be indicated for each requirement. The source should be from the URD but may
be from other sources, e.g. software-error reports.

(g) verifiability need not be proven.

A traceability matrix should be used to prove completeness. Source requirements need not come solely from the URD⁷

The divisional standard for configuration management⁸ may be used.

The divisional standard quality-assurance plan⁹ may be used.

Subsections 3.1 to 3.4 may be regrouped, for example, around individual requirements:

3.1.n [Requirement xyz]
3.1.n.1 Functional requirements
3.l. n.2 Performance requirements
3.1.n.3 Interface requirements
3.1.n.4 Operational requirements

Subsections 3.5 to 3. 1 0 will probably be global within the scope of the document.
Subsections 3.1 1 to 3.14 may not be applicable due to lack of metrics.

4  The architectural-design phase

This section lists amendments and simplifications to Chapter 4 and appendices C3 and D4 of the ESA standard. Where a section is not mentioned, the original text of the ESA standard applies.

CASE tools should be used in all projects where an appropriate tool is readily available. The  preferred CASE tool is Teamwork.

There should be a number of intermediate, informal reviews of the architectural design as it is produced, although these need not be carried out at each level.

The number of reviews held should reflect the size of the project and be defined either in a divisional standard or in the SRD.

The outputs of the AD phase shall be formally reviewed at the end of the phase. Participants should include software engineers and may include knowledgeable users.

4.3  Section 3.4.4: configuration-management plan for the DD phase

The divisional standard for configuration management¹⁰ may be used.

The divisional standard quality-assurance plan¹¹ may be used.

5  The detailed-design and production phase

This section lists amendments and simplifications to Chapter 5 and appendices C4 and D5 of the ESA standard. Where a section is not mentioned, the original text of the ESA standard applies.#

The use of CASE tools with software produced in FORTH may not be appropriate.

The Starlink coding standards shall apply to all code produced in C or FORTRAN. The coding  standards for FORTH software are to be defined.¹²

Black-box testing shall be carried out on every module, such that the most common paths are executed at least once. Unit testing, as defined in the ESA SES shall be carried out on all modules that are critical to the safety of the system or the operator.

In FORTH systems. each element of each FORTH word produced as part of the detailed design shall be executed at least once.

There should be a number of intermediate, informal reviews of the detailed design as it is produced, although these need not be carried out at each level.

The number of reviews held should reflect the size of the project and be defined either in a divisional standard or in the AD phase.¹³

The outputs of the DD phase shall be formally reviewed at the end¹⁴ of the phase. Participants should include software engineers and may include knowledgeable users.

The SUM may be written by a user rather than by the software engineer. If the SUM is being produced be the software engineer, it should normally be produced at the end of the DD phase.

In some cases, the software will be used by other software engineers (e.g. a graphics-driver package) and in this case t lie document may be called a sub-system user-manual.

The divisional standard for configuration management¹⁵ may be used.

5.7  Section 3.4.6: quality-assurance plan for the TR phase

The divisional standard quality-assurance plan¹⁶ may be used.
 

6  The transfer phase

This is the project phase in which the software is handed over to staff of the ING.

This section lists amendments and simplifications to Chapter 6 and appendices C5 and D6 of the ESA standard. Where a section is not mentioned, the original text of the ESA standard applies.

The ESA standards are not over-elaborate and the whole document template (appendix C6)  and mandatory practices (appendix D6) apply.
 

Provisional acceptance should normally take place following the successful commissioning of  the software on La Palma. There should normally be a 6-month period of operation following provisional acceptance to prove that the software operates as specified and during this time the software producers will provide a 'warranty cover'.

7  The operations and maintenance phase

Chapter 7 and appendices C6 and D7 of the ESA standard apply without amendment.

8  Software-management plans

The plans and activities listed in Part 2, Figure 1.1 of the ESA SES should be produced for  all projects.

Separate plans should be issued for project management, configuration management, verification and validation and quality assurance. The plans may be updated and re-issued at the end of each phase and it is not necessary to produce a completely new set of documents each time.

The configuration management plan and quality assurance plan may be based on an RGO standard  which applies to all projects.
 

1. At the time of writing (12/3/96) no such body has ever been convened - GTR.
2. The review should involve both users and developers - JF.
3. Since this document was written, VAXnotes has fallen out of use at RGO.
    A moderated Usenet newsgroup is a possible alternative - GTR.
4. This was never an ESA requirement - JF.
5. No division standard was ever chosen. SOF-BOM-1 and INT-PF-3 are the leading possibility - GTR.
6. No division standard was ever chosen. I know of no candidates for such a standard - GTR.
7. Every requirement should be traceable to the URD - JF.
8. No division standard was ever chosen. INT-PF-3/SOF-BOM-1 are a plausible candidate - GTR.
9. No division standard was ever chosen. I know of no candidates for such a standard - GTR.
10. No division standard was ever chosen. INT-PF-3/SOF-BOM-1 are a plausible candidate - GTR.
11. No division standard was ever chosen. I know of no candidates for such a standard - GTR.
12. These standards have not been defined - GTR.
13. At the end of the AD phase - JF.
14. The DD/R does not review the DDD, code and SUM: these should be reviewed during the DD phase - JF.
15. No division standard was ever chosen. INT-PF-3/SOF-BOM-1 are a plausible candidate - GTR.
16. No division standard was ever chosen. I know of no candidates for such a standard - GTR.
 

Appendix A.    Document history
 

Issue 1.1 29/05/95 The original addendum to PSS-05 was agreed and circulated within RGO.

Issue 1.1 09/11/95 The text of issue 1. 1 was made into an Interleaf document and archived. Footnotes were added by GTR.

Issue 1.2 12/03/96 Jon Fairclough's comments were added as footnotes.