OPS Forum Requirements traceability and software reuse 17.03.2006

European Space Agency M. Jones, F. Delhaise, M. Spada (OPS-GD) and S. Scaglioni (OPS-CQ) Requirements Traceability and Software Reuse: An OPS-GD initiative

Outline

Introduction

Product Life Cycle Management

MDS Reqs management and s/w reuse

Motivation and aims

RENATO, a RE quirements Ma NA gement TO ol

Results: Consolidation of MCS Req.

RENATO extensions

Requirements Management at Ground Segment System Level

Conclusions

Introduction

Products and Knowledge Management

At ESOC, we try to build systems by reusing existing components as far as possible (either from infrastructure or missions)

To this end, we produce and maintain products:

infrastructure such as S2K, TDRS, MCCM, WebRM, GDDS, NIS/NCTRS, GFTS. SLE API, TMTCS, Simsat, Emulator Suite, PSS,…

the mission control systems, simulators and other systems based on the above

The products exist in various releases and have interdependencies e.g. GOCE MCS depends on S2K Rel 4.x,…

There is a big Knowledge Management problem in

Effective reuse

Evolution management

Design

Testing

…

This is not an ESOC Specific problem

Products are also produced and serviced in the commercial world

example DELL personal computers:

global business

many components

many models

ca. 40 suppliers

product line continuously updated to stay ahead of competition

Products and KM (Cont.)

Product Life Cycle Management (PLM)

Companies like DELL use Product Life Cycle Management (PLM) systems to manage all this information

PLM is software to support product life cycles

PLM was developed in the aerospace and automation industries, and has spread to consumer markets such as:

consumer electronics

clothing

food

Pharmaceuticals

PLM enables designers to make new products

reusing parts of previous designs

minimising new parts & suppliers

Products and Knowledge Management Conclusion

In the area of mission data infrastructure and mission data systems, we have a problem of managing product knowledge and product lifecycles

not reasonable to suppose that staff responsible for the products can keep the knowledge in their heads

Affects also decision makers (management, MIG, DSTF) and end users

No ready made PLM system available for our use

This Forum presents two initiatives that focus on a particular part of the problem:

requirements management

MDS Requirements Management and Software Reuse

Motivation To Make Better Software Reuse

Software Reuse

Strategy followed by ESOC for many years

Two main sources for software reuse:

Infrastructure Kernel (SCOS-2000 for MCS and SIMSAT for Simulator)

Software components across missions

At ESOC: each new MDS is based on the Infrastructure Software

“ DELTA” Approach w.r.t. Infrastructure when defining requirements

Identification of potential reuse from previous projects

Software Reuse (Cont.)

Software reuse can lead to:

Cost reduction

Risk reduction

If performed with sufficient caution

SCOS-2000 Requirements Rosetta Mars Express Venus Express

Software Reuse (Cont.)

Reuse across missions is a delicate operation : the combined effort and risk required to reuse the software has to be less than the effort required to implement again from scratch !

Is the software component tested, proven, stable?

Is it of sufficient quality?

Is it easy to customize it?

Is it easy to understand its structure?

Does it fully or partly meet project’s needs?

Avoid building Frankenstein

For each new mission previous missions requirements are carefully reviewed to check applicability

A new set of requirements is specified

These requirements are maintained on an individual repository from which an SRS is generated

Coping with “Similar” Requirements: The traditional approach

Problem : Number of missions (i.e. source of requirements/reusable software)is ever increasing Therefore this task is

more and more complex

expensive

almost impossible to do exhaustively

exchange between DSMs, developers and end-users from different missions is point-to-point, informal and relies on knowledge and availability of individuals

OPS-GD Initiative aims

Investigate ways of making MDS reuse more:

FORMAL

COMPREHENSIVE

MANAGEABLE

A Study was initiated (80K budget) to achieve these aims through:

A thorough review of the existing MDS requirements and the establishment of a set of common requirements

The development of a RE quirements Ma NA gement TO ol ( RENATO )

RENATO A RE quirements Ma NA gement TO ol

The RENATO Tool

Enables and optimises the systematic management of common and mission specific MDS requirements

Supports the production of the SRS

Less effort (the wheel is not reinvented each time)

More consistency across missions

Overall better quality SRS

RENATO is based on Telelogic DOORS

DOORS incorporates a macro-programming language (DXL) which enables to create tailored functionality

RENATO Features

One single Database for all projects

One dedicated module per project

Powerful Classification of requirements to support easy searching

Dynamic linking between requirements from different modules

It combines a database facility for storing requirements and high quality word processing for the text: cut, copy, paste, spell-checking, search, Pictures, Diagrams and Tables

Ability to define & save a “View” = particular Display of the data

RENATO Features (Cont.)

Configuration Control via

Maintenance of Software Change Requests

Definition of Baseline

Export the content of a module to MS Word to generate the SRS document. “WEXP” freeware module has been integrated into RENATO

The usage of WEXP offers an improved version of the standard DOORS output. Example of requirement export:

DBS-FU-150-LPF Note that it is not required to support the import of ‘partial ’ SDB versions. Need Desirable Priority A Traceability OIRD Target delivery D1 Requirement The user shall be able to request the import of the complete SDB Explanation Reuse Yes

RENATO (DOORS) View SRS Chapters Text Graphic Requirements

The Results

Identification of “Common” Requirements

Statistics on Software Reuse

Analysis of MCS Requirements

As a start RENATO holds requirements of all the SCOS-2000 based MCSs in a single database

Result of systematic review of all requirements coming from:

Interplanetary missions: M ars Express, Rosetta, Venus Express

Earth exploration missions: Cryosat, Goce, Aeolus, METOP

Technology missions Smart-1, Lisa Pathfinder

Observatory missions Integral, XMM, Herschel-Planck

Identification of “Common” Requirements

Identification of “common” requirements used by more than one missions

These requirements result from a process of generalisation and consolidation of mission specific requirements through rewording, terms standardisation or parameterisation

Advantages :

SRS authors can now look in a single place to see which requirements are applicable to which missions

Precious feedback for possible extensions of the infrastructure

To deduce statistics on reuse across missions

Common Requirements Example 1 Herschel-Planck module Lisa Pathfinder module Common module OBS-FU-28-COM OBSM shall support 2 types of SCOS-2000 Memory Models: Configuration Tables and Symbol Tables. It shall be possible to attach both a Configuration Table and a Symbol Table to a Memory Image. OBS-FU-C-0.14-001 H/P OBSM shall support 2 types of SCOS-2000 Memory Models, viz. Configuration Tables and Symbol Tables. It shall be possible to attach both a Configuration Table and a Symbol Table to a Memory Image. OBS-FU-R0.8-030 LPF OBSM shall support 2 types of SCOS-2000 Memory Models, Configuration Tables and Symbol Tables. It shall be possible to attach both a Configuration Table and a Symbol Table to a Memory Image.

Common Requirements Example 2 Herschel-Planck module Lisa Pathfinder module Common module TCS-FU-17-COM A command parameter of type 'Parameter ID' shall be encoded as a <XX> bit unsigned integer parameter containing the on-board Parameter ID as extracted from the database for the specified telemetry parameter. TCS-FU-C-5.2-080 A command parameter of type ‘Parameter ID’ shall be encoded as a 16 bit enumerated parameter containing the on-board Parameter ID as extracted from the database for the specified telemetry parameter. TCS-FU-R6.2-110 A command parameter of type ‘Parameter ID’ shall be encoded as a 32 bit unsigned integer (TBC) parameter containing the on-board Parameter ID as extracted from the MIB (table field PCF_PID) for the specified telemetry parameter.

Common Requirements Example 2 View

Link to the Requirement Source

Links are provided to the mission specific sources of the common requirements by means of the DOORS dynamic linking functionality:

Dynamic Link to original Requirements “ common”requirement dynamic link RENATO Common module View

“ Common” Requirements: Results

Common Requirements have been identified for the following MCS subsystems:

Database management

Telemetry monitoring

Spacecraft commanding

Packet Utilization Standard (PUS) service modeling

Mission Planning System

On Board Software Monitoring (OBSM)

“ Common” Requirements: TM SS Example

The following “common” functionality (not part of SCOS) have been identified in the TM SS:

Decompression

Telemetry Replayer

Time Correlation with the use of the OWLT files

Time-Stamping and Time Checks

Extraction of Non-PUS TM through the use of configuration file

“ Common” Requirements: PUS Example

The following “common” functionality have been identified in the Packet Utilization Standard (PUS) service modeling :

Service 1 : TC Verification Service: using live and playback data

Service 3 : Missions often request the functionality to support the generation of the Service 3 commands required to create a new housekeeping / diagnostic packet definition onboard

Service 5: Handling of the reception of duplicate on board TM event pkts and ensure that this event is logged and processed once.

Service 11 : Onboard Scheduling Service , A frequent request is to extent the SCOS-2000 OBQM to compare the contents of the TM(11,13) summary schedule packets with the on-board schedule maintained by the OBQM.

Service 13 : Large File Transfer is required by the most recent mission

Service 18 : On-board operations procedures are more and more required.

Requirements exist for all missions in the following categories:

File import and export

Automatic Planning

Manual Planning

Schedule generation

Plan validation

Re-planning

Rules and constraint management

These categories could form the basis of a requirements baseline for a set of mission planning libraries

“ Common” Requirements: Mission Planning Example

Statistics on Reuse Across Mission Families the majority of “ common ” requirements are generic i.e. not associated directly to a single mission family. Note: These statistics are based on the “common” module and are automatically computed by RENATO! 3,56 % Earth Observation 13,04 % Observatory 2,77 % Technology 18,58 % Interplanetary 62,06 % Generic Statistic Distribution Type of Common Requirements

Requirements Management Process Common Requirements Retrofit Reuse MDS Infrastructure New Mission SRs ROS/ MEX/ VEX SRs Cryosat Goce SRs Smart-1 SRs Herschel Planck SRs Lisa Pathinder SRs New Mission Metop-1 SRs

The “common” SRS is a valuable input for both

MDS Data System Manager of specific missions

the MDS infrastructure TO

Requirements Management Process (Cont.)

The utility of this module is kept only if this list of “common” requirements is maintained:

new “common” req. need to be added if reuse by other missions is foreseen

The “common” requirements retrofitted in the SCOS infrastructure, need to be removed from the module after retrofitting.

Future Extensions

Link the Requirements to the entire SW lifecycle

Integration of Test Plans/Reports

Remote Access Facility

Link the Requirements to the entire SW Lifecycle

Link requirements to the design : How? By making use of the interface between DOORS and many leading UML tools. B eing able to draw UML 2.0 diagrams in DOORS will be a very useful enhancement

Link requirements to the code : How? By making use of the interface between DOORS and many leading configuration control systems

Integration of Test Plans / Reports

Three options have been evaluated for tests management:

Option 1 : Store the tests in a different module within RENATO

Option 2 : SVVP, ESOC specific tool based on MS access

Option 3 : Rational Test Manager, IBM Application linked to DOORS using an adaptor

Comparison Results RENATO (DOORS based) SVVP (ESOC MS-Access) Rational Test Manager + Requirements and tests in one applicat. + Test Plan & Report can be handled as a Word document + limit the duplication between missions of tests linked to the same set of requirements + Traceability Matrix - not specifically designed for test plan + specifically designed for test plans - requirements stored in RENATO must be re-imported in the MS-Access Based tool to maintain traceability. + specifically designed for test plans and reports + allows to go towards automatic testing - quite complex for our needs - 3 software are needed: Doors, Doors Test Input Adapter, Test Manager

Requirements Management at Ground Segment System Level

Key Issues at GS System Level

Need for traceability of requirements at all levels

From Customer Requirements (in MIRD) down to Subsystem Requirements (in SRSs, SFIRD etc.)

Essential to demonstrate requirements coverage/compliance

to the Customer

during QA audits

Need to demonstrate/document validation of requirements at all levels

Easier if requirements and validation records in a single system

Need to harmonise validation records across sub-systems

Use of common tools

What does RENATO bring

Need for traceability of requirements at all levels

DOORS usage can be extended to the whole GS

Supports vertical traceability

RENATO can be used at GS Subsystem level

Supports horizontal traceability (across missions/families)

Links to higher requirements levels

The RENATO features supporting reuse can be applied at all GS levels

Need to demonstrate validation of requirements at all levels

RENATO can/should be extended to integrate requirements and validation records

Overview at GS level MIRD SRD SIM SRS FD CR GS System Level GS Sub-System Level Infra. SFIRD Traceability MCS SRS Design Code Validation RENATO

Centralised GS Reqts Management System Missions GS Customers DOORS Server DOORS clients DOORS clients Remote access (DOORSnet or via Citrix Server) Firewall DOORS clients Missions GS End-users Mission GS Subsys Teams Industry Teams MIRDs MIPs SRSs SFIRDs CRs