A standards-based model of system maintainability requirements · maintainability concepts into a...

JOURNAL OF SOFTWARE: EVOLUTION AND PROCESSJ. Softw. Evol. and Proc. (2012)Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/smr.1553

A standards-based model of system maintainability requirements

Khalid T. Al-Sarayreh1,*,†, Alain Abran2 and Juan J. Cuadrado-Gallego3

1Software Engineering Department, Prince Hussein Bin Abdullah II for Information Technology, Hashemite University,Zarqa, Jordan

2Software Engineering Department, University of Quebec (ETS), Montréal, Québec H3C 1K3, Canada3Departamento de Ciencias de la Computación, Universidad de Alcalá, Madrid, Alcalá de Henares 28805, Spain

SUMMARY

The nonfunctional requirements (NFR) are often captured only generically at a fairly high level, and they do notinclude the levels of detail necessary at this stage for the system engineers to allocate them as specific function-alities to be handled either by the software or the hardware, or a specific combination of the two. The EuropeanCooperation for Space Standardization (ECSS) series of standards for the aerospace industry includesmaintainability requirements as one of 16 types of NFR for embedded and real-time software. A number ofmaintainability-related concepts are dispersed throughout the ECSS, ISO 9126, and Institute of Electrical andElectronics Engineers standards to describe, at varying levels of detail, the various types of candidate maintain-ability requirements at the system, software, and hardware levels. This paper organizes these dispersedmaintainability concepts into a standards-based reference model of system maintainability requirements. Theavailability of this reference model can facilitate the early identification of the system maintainability-NFRand their detailed allocation as specific maintainability functions to be handled by the specified allocation tohardware or software, or a specific combination of the two. In the absence of such a reference model, theseNFR are typically handled in practice much later on in the software development life cycle, when at systemtesting time, users and developers find out that a number of maintainability requirements have been overlookedand additional effort has to be expended to implement them. The approach adopted in this research for the struc-ture of this reference NFRmodel is based on the generic model of software functional requirements proposed inthe COSMIC – ISO 19761 model, thereby allowing the functional size of such maintainability requirementsallocated to software to be measured. Copyright © 2012 John Wiley & Sons, Ltd.

Received 1 March 2011; Revised 9 January 2012; Accepted 23 January 2012

KEY WORDS: software engineering; nonfunctional requirements; maintainability requirements; ECSSInternational Standards; maintainability measurement; functional size; COSMIC - ISO 19761

1. INTRODUCTION

Nonfunctional requirements (NFR) play a critical role in system development, which includes their useas selection criteria for choosing among alternative designs and ultimate implementations. They mayalso have a considerable impact on project effort, and should be taken into account for estimationpurposes and in comparing project productivity. Typically, NFR are described at the system level andnot at the software level [1–7]; however, there is no consensus yet on how to describe and measurethese system-NFR. In current practice, they may be viewed, defined, interpreted, and evaluateddifferently by different people, particularly when they are stated vaguely and only briefly [8–10]. It istherefore challenging to take NFR into account in software estimation and software productivitybenchmarking, particularly as they have received less attention in the software engineeringliterature and are definitely less well understood than other cost factors [10]. Measurement is

*Correspondence to: Khalid T. Al-Sarayreh, Software Engineering Department, Hashemite University, 1100 Zarqa, Jordan.†E-mail: [email protected]

Copyright © 2012 John Wiley & Sons, Ltd.

K. T. AL-SARAYREH, A. ABRAN AND J. J. CUADRADO-GALLEGO

essential if NFR are to be taken as quantitative inputs to an estimation or productivity benchmarkingprocess.

In practice, requirements are typically initially addressed at the system level [11–17], either as high-levelsystem functional user requirements (system-FUR), or as high-level system-NFR. The latter must usuallybe detailed, allocated, and implemented in either hardware or software, or both, as software-FUR (softFUR), for instance, see Figure 1.

To distinguish between these types of requirements, system-FUR describe the required functions ina system, whereas system-NFR describe how the required functions must behave in a system. In thesoftware requirements engineering step, system-NFR are analyzed, detailed, and specified assoftware-FUR to allow a software engineer to develop, test, and configure the final softwaredeliverables to system users.

The term ‘functional’ refers to the set of functions the system (including the software) has to offer,whereas the term ‘nonfunctional’ refers to the manner in which such functions are performed. A FUR istypically phrased with a subject and a predicate (i.e., noun/verb), such as ‘The system must print fivereports’. NFR, by contrast, are typically phrased with an adverb or modifying clause, such as ‘Thesystemwill print five reports quickly’, or ‘The systemwill print five reports with a high degree of reliability’.

In the systems/software engineering literature, there are some early works on NFR. Chung [18], forinstance, presented one of the initial attempts to capture knowledge in this domain in 1993. His workwas followed up Mylopoulos et al. [19], who suggested that all requirements must be viewed as goals:each goal would be an umbrella for related functional and NFR. Chung et al. and Andrew [18, 20]aimed to make NFR more quantitative in nature, whereas Andrew [21] found that there are oftengaps between the stakeholder vision and requirements representation. Chung et al. [22] proposed ataxonomy for NFR, indicating that it is unrealistic to expect designers and developers to incorporatean entity that they cannot readily identify. Although taxonomies aim to be inclusive of the entire setof entities in question, Chung et al. in [22] suggested that a one or two-level taxonomy wouldsuffice initially and that there are over 161 identifiable NFR.

Paech et al. [23] recommended that FR, NFR, and architecture be tightly co-developed, andaddressed in a coherent and integrated manner, suggesting that NFR be decomposable into morerefined NFR and additional FR, as well as architectural decisions.

Moreira et al. [24], Rosa et al. [25], Park et al. [26], and Glinz [27] have proposed new methods toclassify NFR early in the software development process, whereas Kaiya et al. [28] have presented amethod to identify stakeholders and their NFR preferences with use-case diagrams of existing systems.

More recently, Mylopoulos [29] has promoted goal-oriented requirements engineering andsuggested a specific solution involving the establishment of an agent-oriented software developmentmethod called Tropos, which covers not only requirements, but also design phases, and addressesthe design of high-variability software for applications such as home care software and businessprocess design.

More recently still, Kassab et al. [29] have proposed some solutions for NFR framework (i.e., asequence of systematic activities with a view to early consideration of identifying, specifying, andseparating FR from NFR, as well as a discussion on NFR prioritization and risk assessment duringRE). They also report in [29] an initial solution for determining functional size using the COSMICmethod on the basis of what they call ‘soft goal’ concepts to deal with the problem of quantitativelyassessing the NFR modeling process early in the project.

In parallel with the work of researchers, the industry has worked on the description of NFR, inparticular through international standardization bodies, such as the European Cooperation for Space

Figure 1. Mapping system requirements to software functional user requirements (system-FUR)

Copyright © 2012 John Wiley & Sons, Ltd. J. Softw. Evol. and Proc. (2012)DOI: 10.1002/smr

A STANDARD MODEL OF MAINTAINABILITY REQUIREMENTS

Standardization (ECSS), the Institute of Electrical and Electronics Engineers (IEEE), and theInternational Organization for Standardization (ISO).

In the ECSS standards for the aerospace industry [30–33], maintainability is identified as one ofsixteen types of NFR, and in the ISO 9126 [34] and IEEE 830 [35] standards, a number of conceptsare provided to describe various types of candidate maintainability requirements at the system,software, and hardware levels.

However, these standards vary in their views, terminology, and coverage of maintainability.Currently, there exists no reference model for the identification and specification of software-FURfor implementing system maintainability requirements (system-NFR) on the basis of the variousviews documented in these international standards and in the literature. Consequently, it ischallenging to measure maintainability-related software-FUR and take them into accountquantitatively for estimating software projects.

The research reported here, which focuses on a single type of NFR, that is, system maintainabilityrequirements, describes the work carried out to define a reference model for system maintainability-NFR on the basis of international standards, including the use of the generic model of software-FURin COSMIC – ISO 19761 [36] as the template for describing measurable functional requirements.Preference has been given to the views, concepts, and vocabulary related to these NFR most widelyused by industry through its standardization infrastructure, rather than those in the literature.Similarly, for structuring and describing models of FUR and for measurement purposes, themeasurement views, concepts, and terminology from the standardization infrastructure have beenadopted, rather than those in the literature.

The paper is organized as follows. Section 2 presents the view of software-FUR expressed in ISO19761, which will be used as the foundation for describing NFR in general and maintainability inparticular. Section 3 identifies the standards describing the maintainability requirements specifically,along with their respective views, concepts, and vocabulary on maintainability. Section 4 proposes astandards-based definition of a reference model of functional requirements for software to implementsystem maintainability-NFR. Section 5 presents an example of a detailed reference model in aservice-oriented architecture (SOA) context. Section 6 presents one application of the referencemodel for sizing system maintainability requirements that may be allocated as software-FUR, aswell as a case study. Finally, a discussion is presented in Section 7.

2. A GENERIC ISO STANDARD FOR SOFTWARE FUNCTIONAL USER REQUIREMENTS

ISO 14143–1 [37] specifies that a functional size measurement (FSM) method must measure software-FUR. In addition, the COSMIC – ISO 19761 [36] standard proposes a generic model of software-FURthat can capture the functionality of any type of software in a measurable way. Figure 2 illustrates thegeneric flow of data that can be observed in software from a functional perspective. From this genericmodel of software-FUR, depicted in Figure 2, the following observations can be made:

Figure 2. Generic flow of data groups through software from a functional perspective in COSMIC – ISO19761

Copyright © 2012 John Wiley & Sons, Ltd. J. Softw. Evol. and Proc. (2012DOI: 10.1002/sm

)r


• Software is bounded by hardware. In the so-called ‘front end’ direction (i.e., the left-hand side ofFigure 2), software used by a human is bounded by I/O hardware, such as a mouse, a keyboard, aprinter, or a display, or by engineered devices, such as sensors or relays. In the so-called ‘backend’ direction (i.e., the right-hand side of Figure 2), software is bounded by persistent storagehardware, such as a hard disk, or RAM or ROM memory.

• Software functionality is embedded within the functional flows of data groups. These data flowscan be characterized by four distinct types of data movements. In the ‘front end’ direction, twotypes of movements (E: Entries and X: Exits) allow the exchange of data with users across aboundary. In the ‘back end’ direction, two types of movements (R: Reads and W: Writes) allowthe exchange of data with the persistent storage hardware.

• Different abstractions are typically used for different measurement purposes. In real-timesoftware, the users are typically the engineered devices that interact directly with the software, thatis, the users are considered the I/O hardware. For business application software, the abstractioncommonly assumes that the user is one or more humans who interact directly with the businessapplication software across the boundary; the I/O hardware is ignored.

As an FSM method, COSMIC is aimed at measuring the size of software on the basis of identifiableFUR. Once identified, those requirements are allocated to hardware and software from the unifyingperspective of a system integrating these two ‘components’. Because COSMIC is aimed at sizingsoftware, only those requirements allocated to the software are currently considered in itsmeasurement procedure.

3. IDENTIFICATION OF STANDARDS DESCRIBING MAINTAINABILITY REQUIREMENTS

This section presents a survey of the maintainability-related views, concepts, and terms in the ECSS[30–33, 38], ISO 9126 [34], and IEEE-830 [35] standards. In it, the standards that currently addressaspects of the software-FUR are identified, which may be derived from system maintainability-FURand NFR (Figure 3). The expected outcome is the identification of the various elements that shouldbe included in the design of a standards-based framework for modeling software-FUR for systemmaintainability. The elements of maintainability are dispersed in a number of system viewsthroughout various ECSS standards and are expressed as either:

• System maintainability-FUR or• System maintainability-NFR.

3.1. European Cooperation for Space Standardization standards: Views and concepts for maintainability

The ECSS is an organization that works to improve standardization within the European space sector.The ECSS frequently publishes standards targeting the contractors working for the European SpaceAgency. The ECSS standards series includes a number of maintainability requirements at the systemlevel. It can be observed that the ECSS focuses on the system-FUR (Appendix A-1) for the earlydevelopment phases, while the system-NFR are typically discussed within the context of laterdevelopment phases, such as the evaluation or testing phases.

Figure 3. Mapping system nonfunctional requirements (system-NFR) to the maintainability functional userrequirements (system-FUR) allocated to software



Maintainability in the ECSS standards is considered part of the integrated support requirements insystem engineering, including related activities and procedures. Table I presents a list of theconcepts and vocabulary used in the set of 13 ECSS standards to describe system-relatedmaintainability requirements. For instance, the ECSS specifies that failure mode, effects, andcriticality (FMECA) must be analyzed for system maintainability. It does not specify, however,whether such requirements must be implemented in software or in hardware, or in a combination ofthe two. The various definitions used in these 13 ECSS documents to describe maintainability at thesystem and software levels are provided in Appendix A-1.

While conducting the survey of all the maintainability concepts and terms described in the ECSS-E-40and ECSS-Q series, and in ECSS-ESA series as the integrated standard for ECSS-E and ECSS-Q, it wasobserved that

• The various maintainability elements are described differently, and at different levels of detail.• The maintainability elements are dispersed throughout these ECSS documents. There is thereforeno integrated view of all types of candidate maintainability requirements.

• There is no obvious link between the maintainability requirements in ECSS-ESA [39] as theintegrated standard and all the other ECSS standards that describe maintainability requirements.

Moreover, the ECSS does not propose a way to measure these maintainability requirements, andwithout measurement, it is challenging to take such NFR as a quantitative input to an estimationprocess, or use it in productivity benchmarking. A summary of the various ECSS definitions relatedto maintainability, as well as its key views and concepts, is presented in Table I.

3.2. Institute of Electrical and Electronics Engineers standards: Views and concepts for maintainability

Institute of Electrical and Electronics Engineers-830 standard [35] includes maintainability as one ofthe NFR types on their list, but does not define it, nor does it provide guidance on how to describeand specify maintainability requirements; neither, of course, does it provide guidance on how tomeasure any of these NFR. Moreover, IEEE-14764 [40] and IEEE-982.1 [41] define maintainabilityrequirements only in terms of the capability of the software product to be modified, withoutmentioning how to describe and specify them.

3.3. ISO 9126: Views and concepts for maintainability

The key view on maintainability in the ISO 9126 series is from the perspective of the quality of thesoftware product. Maintainability is presented as a ‘quality characteristic’ of the software, which isdecomposed into quality subcharacteristics and then into proposed derived measures to quantifythose quality subcharacteristics. The inventory of related concepts and vocabulary on softwaremaintainability, such as analyzability, changeability, and so on, is presented in Table II. The variousdefinitions used in the 13 ECSS documents to describe software maintainability at the software levelare provided in Appendix A-2. A large number of measures are proposed in ISO 9126, but noneaddresses software-FUR, only the maintainability-NFR of the software itself. However, nothingprecludes the use of these concepts at the system level or looking at what functions must be

Table I. Summary of maintainability key view, concepts, and vocabulary in the European Cooperation forSpace Standardization (ECSS) standards.

Key view of maintainabilityConcepts and vocabulary for maintainability requirementsECSS standards

Maintainability forms part of the integratedlogistical support requirements in systemengineering, including activities andprocedures.

Maintainability activities and proceduresMaintainability operationsEnvironmental control and life support system design (ECLSSfailure mode, effects, and criticality analysis (FMECA)failure mode and effects analysis (FMEA)Mean time-to-repair and system downtimeFault detection and isolation capabilitySystem malfunction


)

)r

Table II. Summary of maintainability key views, concepts, and vocabulary in ISO 9126.

Key views of maintainability Concepts & vocabulary for maintainability requirements in ISO 9126

The maintainability quality characteristicdenotes the capability of the softwareproduct to be modified.

Analyzability ModifiabilityAudit trial capability StabilityFailure analysis capability Modification impactStatus monitoring capability Change success ratio

Modifications may include corrections,improvements, or adaptation of thesoftware to changes in theenvironment.

Diagnostic function support TestabilityChangeability Availability of a built-in test functionChange efficiencySoftware change control

Retest efficiency

CapabilityTest restart capability


performed at the software level (i.e., FUR allocation to software) to implement the system-level NFR.A summary of these various definitions is presented in Table II, including the key views and conceptsof ISO 9126 on maintainability.

4. A STANDARDS-BASED MODEL OF SOFTWARE-FUR FOR SYSTEM MAINTAINABILITY

This section identifies the views, concepts, and vocabularies of maintainability dispersed throughoutthe ECSS, IEEE, and ISO standards identified in Section 2 and assembles them into an integratedterminology. These views and concepts are then mapped into a proposed model of software-FUR forsystem maintainability using the reference FUR model proposed in COSMIC. This COSMIC-basedgeneric model then becomes a framework based on these standards for describing the systemmaintainability requirements allocated to software-FUR.

4.1. Mapping maintainability views, concepts, and terms from standards

Mapping the views and concepts of the maintainability requirements from ISO 9126 and ECSSrevealed that a high-level standards-based model of software maintainability requirements is definedby the ISO, whereas a detailed (but dispersed) view of system maintainability requirements isprovided by the ECSS. Table III presents the system maintainability requirements that are presenteither as system requirements in the ECSS standard or as maintainability-related concepts in ISO9126. Each of these could at times be interpreted and specified as software-FUR.

Furthermore, various types of system-related maintainability requirements can be derived from ISO9126. Table IV presents various typical procedures (middle column) associated with systemmaintainability requirements and the corresponding software functions (right-hand column) that maybe specified to implement such procedures for the five types of system maintainability requirements.

4.2. Identification of system maintainability function types allocated to software-FUR

This section identifies the function types allocated to software-FUR for system maintainability and therelationships between them.

4.2.1. System maintainability failure procedure. Figure 4 illustrates a system modeling view (i.e., ahigh-level view) of the data movements for the system maintainability failure procedure (SMFP)(Function Type 1), which is divided into as follows:

Table III. Maintainability requirements in European Cooperation for Space Standardization and ISO 9126.

ID System maintainability requirements ID System maintainability requirements

1 Failure data operation 7 Correct data faults2 Failure data monitoring 8 Correct system defects3 Failure data control 9 Fault prevention of data control4 System failure tasks 10 Fault prevention of system functions5 Failure isolation 11 Fault allocation time6 Failure detection


Table IV. System maintainability requirements and related software functions in ISO 9126.

ID System maintainability System maintainability procedures Software functions for maintainability

1 System analyzability System maintainability failureprocedure (SMFP)

System diagnostic function (SDF)Failure data operation function (FDOF)Failure data monitoring function (FDMF)Failure data control function (FDCF)System failure task function (SFTF)

2 System analyzability& changeability

System registered failureprocedure (SRFP)

Failure detection function (FDF)Failure isolation function (FIF)

3 System changeability System malfunction procedure (SMP) Correct data faults function (CDFF)Correct system defects function (CSDF)

4 System stability System stability procedure (SSP) Fault prevention of data control function(FPDCF)Fault prevention of system function (FPSF)

5 System testability System testability procedure (STP) System time function (STF)Fault allocation time function (FATF)


Co

1. The set of system diagnostic function (SDF), which constitutes a program or software written forthe express purpose of examining the state of the hardware, or for locating problems with thehardware or operating system environment in/on which it is running. It sends data groups tothe failure data operation function (FDOF), failure data monitoring function (FDMF), failure datacontrol function (FDCF), and to the system failure task function (SFTF).

2. The FDOF, which is the collection of failure activities required to operate and execute the systemdiagnostic services. It reads about other services from stored information and writes their resultsinto the system.

3. The FDMF, which keeps track of services in progress. Some information is provided to it fromthe FDOF results using intermediary services. It reads about other services from stored informa-tion and writes their results into the system.

Figure 4. System modeling view of a system maintainability failure procedure (SMFP)

pyright © 2012 John Wiley & Sons, Ltd. J. Softw. Evol. and Proc. (2012DOI: 10.1002/sm

)r


4. The FDCF, which provides or assigns tasks, or brings about changes and verifies their executionto meet deadlines and requirements. It reads about other services from stored information andwrites their results into the system. The FDCF also uses intermediary services to connect theFDMF results, which provide additional information.

5. The SFTF, which provides a complete description of a small unit of work. This descriptionconsists of two parts:

6. A data payload, which parameterizes the task7. Code, which implements the task.

The SFTF reads about other services from stored information and writes their results into the system. In

Figure 4, the intermediary services are represented by a cross in a small circle ( ).The SMFP (Function

Type 1) sends its results throughout the intermediary services to be used by the system stability procedure(SSP) (Function Type 4) and system testability procedure (STP) (Function Type 5).

The FDOF and FDMF in the SMFP (Function Type 1) send their results to the failure detectionfunction (FDF) in the system registered failure procedure (SRFP) (Function Type 2). The FDCF andSFTF in the SMFP (Function Type 1) send their results to the failure isolation function (FIF) in theSRFP (Function Type 2).

Figure 5 illustrates the COSMIC modeling scenario for the data movements for the SMFP. The SDFsends a data group to the failure data operation, data monitoring, and data control functions and systemfailure task function (FDOF, FDMF, FDCF, and SFTF):

1. The FDOF reads data groups about other services from stored information and writes their resultsinto the system as data movements.

2. The FDMF reads data groups about other services from stored information and writes their resultsinto the system as data movements.

3. The FDCF reads data groups about other services from stored information and writes their resultsinto the system as data movements.

4. The SFTF reads data groups about other services from stored information and writes their resultsinto the system as data movements.

Figure 5. COSMIC modeling view of a system maintainability failure procedure (SMFP) (i.e., with COS-MIC data movements)



The FDOF, FDMF, FDCF, and SFTF send and receive data groups to interconnect theirfunctionality or service by using intermediary services, which are represented by a cross inside a

small circle ( ) (Figure 5).

4.2.2. System registered failure procedure. Figure 6 illustrates a system modeling view (i.e., high-level view) of the data movements for the SRFP (Function Type 2):

1. The FDF includes the ability of the system to detect and report a failure by saving the followingresults in the system:•The system correctly indicates a safe condition.•The system correctly indicates a malfunction requiring correction.•The system erroneously indicates a safe condition in the event of a malfunction.•The system provides information about data faults that could occur.

2. The FIF includes the ability of the system to identify the failure by saving the following results inthe system:•System task operations cannot access data.•Data that have been modified during a transaction that has not yet been completed.•Information, provided by the FIF, about system defects that could occur in the future.

The FDF and FIF exchange information through intermediary services to decide, throughdifferent services, which types of defects or faults can appear in the system.

The FDF and FIF receive and send data movements from other function types in the maintainabilitymodel as follows:

1. The FDF receives its functionality based on the FDOF and FDMF results from the SMFP(Function Type 1) (Figure 6).

2. The FIF receives its functionality based on the FDCF and SFTF results from the SMFP (FunctionType 1) (Figure 6).

3. The FDF sends its results to be used by the correct data faults function (CDFF) to the systemmalfunction procedure (SMP) (Function Type 3).

Figure 6. System modeling view of a maintainability system registered failure procedure (SRFP)


SystemMalfunction

Procedure (SMP) Function Type 3

System Maintainability Failure Procedure (SMFP)

Function Type 1

System Registered Failure Procedure (SRFP)

Function Type 2

Failure Data Operation Function

(FDOF)

Failure Data Monitoring Function

(FDMF)

Failure Data Control Function

(FDCF)

System Failure Task Function

(SFTF)

Failure Detection Function

(FDF)

Failure Isolation Function

(FIF)

Storage Area

Correct Data FaultsFunction (CDFF)

Correct System Defects Function

(CSDF)

ENTRY

ENTRY WRITE

READ

ENTRY

ENTRY

WRITE

READ

System Stability Procedure (SSP) Function Type 4

System Testability Procedure (STP) Function Type 5

Figure 7. COSMIC modeling view of a maintainability system registered failure procedure (SRFP) (i.e.,with COSMIC data movements)


4. The FIF sends its results to be used by the correct system defects function (CSDF) to the SMP(Function Type 3).

5. The SRFP (Function Type 2) sends its results throughout the intermediary services to be used bythe SSP (Function Type 4) and STP (Function Type 5).

6. In Figure 6, the intermediary services are represented by a cross in a small circle ( ).

Figure 7 illustrates a COSMICmodeling view of the data movements for the SRFP (Function Type 2):

1. The FDF receives a data group from the FDOF and FDMF.2. The FDF reads and/or writes a data group to/from the storage area or system buffer.3. The FIF receives a data group from the FDCF and SFIF.4. The FIF reads and/or writes a data group to/from the storage area or system buffer.5. The FDF and FIF contact each other by sending and receiving a data group using intermediary services.6. In Figure 7, the intermediary services are represented by a cross in a small circle ( ).

4.2.3. System malfunction procedure. Figure 8 illustrates a system modeling view (i.e., high-levelview) of the data movements for the maintainability SMP (Function Type 3):

1. The CDFF is used when there is an abnormal condition at the component, equipment, or subsys-tem level, which may lead to failure in the functional unit or execution unit. The CDFF providesinformation about asymmetric and symmetric data faults, a result which may be used by asubsequent functionality in the system maintainability requirements allocated to the software.

2. The CSDF is a functionality that is used when a reproducible or catastrophic malfunction occursconsistently under the same circumstances. It provides information about a failure of computersoftware to meet requirements, a result which may be used by a subsequent functionality in thesystem maintainability requirements allocated to the software.

The CDFF and CSDF exchange information through intermediary services to decide, throughvarious services, which types of defects or faults can appear in the system.

The CDFF and CSDF receive and send data movements from other function types in themaintainability model as follows:

1. The CDFF receives its functionality based on the FDF and FIF results.2. The CSDF receives its functionality based on the FIF results.3. The CDFF and CSDF send their results throughout the intermediary services to be used by the

SSP (Function Type 4) and STP (Function Type 5).


System Malfunction Procedure (SMP) Function Type 3


Function Type 2


(FDF)


(FIF)

Correct Data Faults Function

(CDFF)


(CSDF)

StorageArea System Testability

Procedure (STP)

Function Type 5

System Stability Procedure

(SSP) Function Type 4

Figure 8. System modeling view of a system malfunction procedure (SMP)


In Figure 8, the intermediary services are represented by a cross in a small circle ( ).

Figure 9 illustrates a COSMIC modeling view of the data movements for the maintainability SMP(Function Type 3):

1. The CDFF receives data groups from the FDF and FIF.2. The CDFF reads and/or writes a data group to/from a storage area or system buffer.3. The CSDF receives a data group from the FIF.4. The CSDF reads and/or writes a data group to/from a storage area or system buffer.5. The CDFF and CSDF exchange information by sending and receiving a data group using

intermediary services.6. The CDFF and CSDF in Function Type 3 send their results throughout the intermediary services

to be used by the SSP (Function Type 4) and STP (Function Type 5).

In Figure 9, the intermediary services are represented by a cross in a small circle ( ).

4.2.4. System stability procedure. Figure 10 illustrates a system modeling view (i.e., high-level view)for the data movements for the SSP (Function Type 4):



Function Type 2


(FDF)


(FIF)

Correct Data Faults Function

(CDFF)


(CSDF)

Storage Area System Testability

Procedure (STP)

Function Type 5

System Stability Procedure

(SSP) Function Type 4 ENTRY

WRITE

READ

ENTRY

ENTRYWRITE

READ

Figure 9. COSMICmodeling view of a systemmalfunction procedure (SMP) (i.e., with COSMIC datamovements)


System Stability Procedure (SSP) (Function Type 4):

Fault Prevention of Data Control Function

(FPDCF)

Fault Prevention of System Function

(FPSF)

Storage Area

System Testability Procedure

(STP) Function Type 5


Function Type 2

System Malfunction Procedure (SMP)

Function Type 3

System Maintainability

Failure Procedure (SMFP)

Function Type 1

Figure 10. System modeling view of a system stability procedure (SSP)


1. The fault prevention of data control function (FPDCF) is used when classifying the types of datafaults being incorporated into a system. The FPDCF provides information about system data faults,a result that may be used by other functionalities, such as SDF or system registered failures andsystem malfunctions in the maintainability systems allocated to software.

2. The fault prevention of system function (FPSF) deals with preventing faults from being incorpo-rated into a system. The FPSF provides information about system faults, a result which may beused by other functionalities, such as SDF, in the maintainability systems allocated to software.

The FPSF and FPDCF exchange information through intermediary services to provide the degree of

system health. In Figure 10, the intermediary services are represented by a cross in a small circle ( ).

The FPSF and FPDCF receive their functionality based on the results of Function Types 1, 2, 3, and 5using intermediary services.

Figure 11 illustrates a COSMIC modeling view of the data movements for the SSP (Function Type 4):

System Stability Procedure (SSP) (Function Type 4):

System Testability Procedure

(STP) Function Type 5


Function Type 2


Function Type 3

System Maintainability

Failure Procedure (SMFP)

Function Type 1Storage

Area

Fault Prevention of Data Control Function

(FPDCF)

Fault Prevention of System Function

(FPSF)

WRITE

READ

WRITE

READ

Figure 11. COSMICmodeling view of a system stability procedure (SSP) (i.e., with COSMIC data movements)



1. The FPDCF sends and receives a data group using intermediary services from/to Function Types1, 2, 3, and 5. It reads and/or writes a data group to/from a storage area or system buffer.

2. The FPSF sends and receives a data group using intermediary services from/to Functions Types1, 2, 3, and 5. It reads and/or writes a data group to/from a storage area or system buffer.

The FPSF and FPDCF exchange information by sending and receiving a data group using intermediary

services. In Figure 11, the intermediary services are represented by a cross in a small circle ( ).

4.2.5. System testability procedure. Figure 12 illustrates a system modeling view (i.e., high-level view)of the data movements for the STP (Function Type 5):

1. The system time function (STF) is a system for describing points in time. It has two layers: the firstencodes a time as a scalar real number for each event in the system, and the second encodes thatnumber as a sequence of bits, or in another form. The STF provides time information about whenthe maintainability failure procedure occurred and the time the failure for each event was registered.This result may be used by other functionalities, such as the system stability function in the maintain-ability systems allocated to software.

2. The fault allocation time function (FATF) is used to provide both the execution time and the requiredmemory for each event in the memory. It provides information about when the maintainabilityfailure occurred: the time of the registered failure for each event, and, when a systemmalfunctions, the faults or defects that occurred. Its result may be used by other functionalities, suchas the system stability function in the maintainability systems allocated to software.

The STF and FATF exchange information through intermediary services. In Figure 12, theintermediary services are represented by a cross in a small circle ( ). The STF and FATF receivetheir functionality based on the results of Function Types 1, 2, and 3 in this model.

Figure 13 illustrates a COSMICmodeling view of the data movements for the STP (Function Type 5):

1. The STF receives a data group from Function Types 1, 2, and 3 in the maintainability model usingintermediary services. It reads and/or writes a data group to/from a storage area or system buffer.

2. An FATF receives a data group from Function Types 1, 2, and 3 in the maintainability model usingintermediary services. It reads and/or writes a data group to/from a storage area or system buffer.

The STF and FATF exchange information by sending and receiving a data group using intermediaryservices. In Figure 13, the intermediary services are represented by a cross in a small circle ( ).

4.3. Model of the Function Type relationships on the basis of system views

Figure 14 presents an overview of the relationships between the function types for systemmaintainability that may be allocated to software-FUR. More specifically, the system maintainabilityrequirements model is composed of 12 functions grouped into five procedural function types. Thedata flow of the model is divided into direct data flows and intermediary data flows:

System Testability Procedure (STP) (Function Type 5):

System TimeFunction (STF)

Fault Allocation TimeFunction (FATF)

Storage Area


Function Type 2System Malfunction Procedure (SMP)

Function Type 3


Function Type 1

Figure 12. System modeling view of a system testability procedure (STP)


System Testability Procedure (STP) (Function Type 5):


Function Type 2



Function Type 1 Storage Area

System Time Function(STF)

Fault Allocation TimeFunction (FATF)

WRITE

READ

WRITE

READ

Figure 13. COSMICmodeling view of a system testability procedure (STP) (i.e., with COSMIC data movements)


1. The SMFP (Function Type 1) can be used to specify the data flows between its five subfunctionsand the data flows with the other functions on the system maintainability model (Figure 14).

2. The SRFP (Function Type 2) can be used to specify the data flows between its two subfunctionsand the data flows with the other functions on the system maintainability model (Figure 14).

3. The SMP (Function Type 3) can be used to specify the data flows between its two subfunctionsand the data flows with the other functions on the system maintainability model (Figure 14).

4. The SSP (Function Type 4) can be used to specify the data flows between its two subfunctionsand the data flows with the other functions on the system maintainability model (Figure 14).

5. The STP (Function Type 5) can be used to specify the data flows between its two subfunctionsand the data flows with the other functions on the system maintainability model (Figure 14).

Figure 15 presents an overview of the relationships between the function types for systemmaintainability that may be allocated to software-FUR, using COSMIC for graphical representation.More specifically,

1. The SMFP model can be used to specify and measure its functional size from the received/sentdata movements from/to SDF, FDOF, FDMF, FDCF, and SFTF (Figure 15).

2. The SRFP model can be used to specify and measure its functional size from the received/sentdata movements from/to FIF and FDF (Figure 15).

3. The SMP model can be used to specify and measure its functional size from the received/sentdata movements from/to CDFF and CSDF (Figure 15).

4. The SS model can be used to specify and measure its functional size from the received/sent datamovements from/to FPDCF and FPSF (Figure 15).

5. The ST model can be used to specify and measure its functional size from the received/sent datamovements from/to STF and FATF (Figure 15).

5. EXAMPLE OF A DETAILED REFERENCE MODEL IN A SERVICE-ORIENTEDARCHITECTURE CONTEXT

A COSMIC reference model of system maintainability requirements is considered as a high-levelmodel of requirements that helps explain and position the variety of maintainability-related functionsdescribed at the system level in the ECSS, IEEE, and ISO standards. However, in practice, such amodel typically does not include detailed information documenting the required data groupsnecessary to unambiguously identify the specific corresponding data movements, and withoutmissing any. Further complicating the specification and measurement tasks is that much of themaintainability functionality could be allocated as services across a number of peer applicationswithin a software system. To tackle this level of detail, the COSMIC group has published adocument providing guidelines for FSM in the context of an SOA [42]. The COSMIC-SOA modelfrom [42] will be used in this section to provide a detailed specification model for systemmaintainability, which can be used to specify and measure the functionality described in Figure 15.



Function Type 3

System Registered Failure Procedure

(SRFP) Function Type 2

System Maintainability Failure Procedures (SMFP) Function Type 1

System Diagnostic Functions

(SDF)

Failure Data Operation Function (FDOF)

Failure Data Monitoring Function (FDMF)

Failure Data Control Function (FDCF)

System Failure Task Function (SFTF)

FailureDetection Function

(FDF)

FailureIsolationFunction

(FIF)

Correct Data Fault

Function(CDFF)

Correct System Defect Function

(CSDF)

Intermediary Services (IS)


Fault Prevention of Data Control Function (FPDCF)

Fault Prevention of System Function (FPSF)

System Testability Procedure (STP) Function Type 5

System Time Function(STF)

Fault Allocation Time Function (FATF)

1

2 3

4 5

Figure 14. Modeling view of system maintainability requirements


The term ‘service’ refers to a set of related software-FUR functionalities. An SOA is a flexible set ofdesign principles used during the system development and integration phases. It is also a process fordefining the architecture, components, modules, interfaces, and data required for a system to satisfyspecified requirements.

A COSMIC measurement model [42] using an architectural model based on COSMIC-SOAprovides a representation of a loosely integrated suite of services that can be used in multiplebusiness domains to measure the functional size of software-FUR.

A COSMIC-SOA model also generally provides a way for measurers of services to proceed byseparating functions into distinct units, or services. These services (and their correspondingmeasures) communicate with each other by passing data along in a well-defined, shared format, orby coordinating an activity between two or more services.

A COSMIC reference model of systemmaintainability requirements allocated to software is consideredas a high-level model of requirements, whereas the COSMIC-SOA model describes the detailedmeasurement model that can be used to specify and measure the functionality described in Figure 15.

5.1. COSMIC-SOA supplementary guideline [42]

COSMIC-SOA offers three types of data architecture movements based on [42] (Table VI).


System Analyzability System Changeability

System Maintainability Failure Procedures (SMEP)

Function Type 1


Function Type 3

System Registered Failure procedure (SRFP)

Function Type 2SYSTEM

DIAGNOSTIC

FUNCTION

SDF


FDOF


FDMF


FDCF


SFTF


FDF

Failure IsolationFunction

FIF

Correct Data Faults

Function CDFF

Correct System Defect

Function CSDF

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

Persistent Storage

Data Movement Types

FunctionalProcess

Intermediary Services R, W

12 3

R,W

R,W

R,W

R,W

R,W

R,W

R,W

R,W

Entry

FU

Exit

5 System Testability Procedure (STP) Function Type 5

System Time Function (STF)




R,W

R,W


R, W

R,W

Intermediary Service (IS)

4

Figure 15. Standards-based model of software-FUR for system maintainability nonfunctional requirements(functional level)


5.2. COSMIC-SOA reference measurement model for system maintainability

This section illustrates the COSMIC-SOA reference measurement model for system maintainabilityrequirements allocated to software. This model is built based on Figure 15 and a role of theCOSMIC-SOA explained in Section 5.1 (See-Figure 16 and Table V).

5.2.1. Measurements of exchange messages for systemmaintainability requirements using COSMIC-SOA.An application A requires some data from a service S. A functional process FA is triggered in the applicationrequesting the data (A), which issues a request message as an Exit. This message is received by the service(which we assume consists of a single functional process FS) as a triggering Entry. The service functionalprocess (FS) replies to FA with a message containing the requested data or an error message.

In COSMIC terminology, the exchange of messages takes place via an Exit/Entry pair of datamovements from/to the requesting application, in this case, Application A (outgoing request/incoming reply). These messages are also seen as an Entry/Exit pair of data movements by thesupplying service S (incoming request/outgoing reply). Application A is a functional user of serviceS, and vice versa.

Figure 16 does not show how the functional process of service S obtains the data that itmust provide to Application A. Service S may obtain the needed data by computation (no


Table V. The three types of data movement architecture in the COSMIC-SOA guideline [42] (‘ApplicationA’ below).

Part A COSMIC-SOA exchange message: An application requiringcommonly used information from another application sendsa request to the service of the application that can handlethe request, or the application may call on its own services.Such a call is also referred to as message. Each message mayconsist of one or more data movements [42].

Figure 16: Exchange messagein [42]

Part B COSMIC-SOA intermediary service: When a functional processof an application service in Application A requires data thatare available via an application service in Application B, thatapplication service calls on a functional process of the intermediaryservice. This service functionality is also needed by otherapplications in the overall SOA framework, as it may itself berealized in the form of a utility service [42].

Figure 17:Intermediary servicesin [42]

Part C COSMIC-SOA data exchange: The data movements areexchanged between components in the same layer, that is,between peer components (where a component may be an applicationor a service). These exchanges can be direct or indirect. A directexchange is, for measurement purposes, identified as an Exit and/orEntry data movement, such as the data movements between serviceA (SA) and service B (SB). An indirect exchange means that aservice in one component writes data to a storage device, which is subsequentlyread by a service in another component. The measurer identifies it as a Writedata movement in service SA and a Read data movement in service SB [42].

Figure 18: Dataexchange in [42]


additional data movements) from persistent storage (requiring a Read), or from anotherapplication or service (needing another Exit/Entry pair), or a combination of any of thesethree possibilities.

Table VI. COSMIC-SOA measurement for a generic instantiation of all maintainability functions of thereference model allocated to software in an SOA context.

Detailed COSMIC-SOA measurement for the reference model of maintainability requirements CFP

A COSMIC-SOA exchange messages (services) 481 Function Type 1(maintainability failure procedure) 162 Function Type 2 (registered failures procedure) 83 Function Type 3 (system malfunction procedure) 84 Function Type 4 (system testability procedure) 85 Function Type 5 (system stability procedure) 8

B COSMIC-SOA intermediary services 1361 Function Type 1 (maintainability failure procedure) 242 Function Type 2 (registered failures procedure) 83 Function Type 3 (system malfunction procedure) 84 Function Type 4 (system testability procedure) 85 Function Type 5 (system stability procedure) 86 Function Type 4 with 5 (system testability with system stability procedure) 327 Function Type 1, 2, 3, with 4 (maintainability failure procedure and registered

failure procedure, system malfunction procedure with system testability procedure)48

C COSMIC-SOA direct and indirect data movements of dataDirect data movements 221 Function Type 1 (maintainability failure procedure) 82 Function Type 2 (registered failure procedure) 83 Function Type 3 (system malfunction procedure) 6Indirect data movements 243 Function Type 1, 2, 3, 4, and 5 (maintainability failure, registered failure,

system malfunction, system testability, and system stability procedures).24

Total size – detailed functional size 230 CFP

CFP, COSMIC function points.


Figure 16. Exchange message in [42] part A in Table V


A message may contain data about one or more objects of interest. Therefore, as with the COSMICmethod, one Exit/Entry pair (or one Entry/Exit pair) must be identified for each object of interest aboutwhich data are conveyed in any message. In SOA, standards that govern what data are to be exchangedin each message type and how they should be formatted are defined – for more details, see [42].

The FUR of a service defines the following:

• The capability (service) it provides to a service requestor,• How to request the capability, and• The form and content of the call message.

The COSMIC reference model of maintainability requirements allocated to software (Figure 15) isdivided into five Functional Types. The SDF (upper left-hand side of Figure 15) is considered as afunctional application and consists of 12 subapplications. The COSMIC reference model is consideredas a high-level requirement for the reference maintainability model. The COSMIC-SOA model formaintainability provides the detailed measurement model for the generic maintainability requirements.The interactions between subapplications and services of the COSMIC-SOA model for maintainabilityrequirements are illustrated on the basis of maintainability function types Figure 17 Figure 18.

5.2.1.1. Function Type 1 maintainability failure procedure. Figure 19 describes the detailedmeasurements for the exchange of data messages between the application level and the serviceslevel for Function Type 1 (i.e., the maintainability failure procedure), and Appendix B-1 containsthe detailed measurement of the reference model of system maintainability requirements for the SDFand their subapplications, A, B, C, and D (i.e., the maintainability failure procedure) in this case,which are triggered in the requesting messages; the service functional process FS replies to FA andthe subapplications with messages containing the requested data or an error message.

5.2.1.2. Function Type 2 registered failure procedure. Figure 20 describes the detailed measurementsfor the exchange of data messages between the application level and the services level for FunctionType 2 (registered failure procedure), and Appendix B-2 contains the detailed measurement for theCOSMIC-SOA model of system maintainability requirements for the registered failure procedureand their subapplications, E and F in this case, which are triggered in the requesting messages; the

Figure 17. Intermediary services in [42] Part B in Table V

Figure 18. Data exchange in [42] Part C in Table V


Figure 19. Interactions of subapplications (A, B, C, and D) with their services for Function Type 1(maintainability failure procedure)

Figure 20. Interactions of subapplications (E and F) with their services for Function Type 2 (maintainabilityregistered failure procedure)


service functional process FS replies to FA and the subapplications with messages containing therequested data or an error message.

5.2.1.3. Function Type 3 system malfunction procedure. Figure 21 describes the detailedmeasurements for the exchange of data message between the application level and the services levelfor Function Type 3 (SMP), and Appendix B-3 contains the detailed measurement for the COSMIC-SOA model of system maintainability requirements for the SMP and their subapplications, G and Hin this case, which are triggered in the requesting messages; the service functional process FS repliesto FA and the subapplications with messages containing the requested data or an error message.

5.2.1.4. Function Type 4 system testability procedure. Figure 22 describes the detailed measurementsfor the exchange of data messages between the application level and the services level for FunctionType 4 (STP), and Appendix B-4 contains the detailed measurement for the COSMIC-SOA modelof system maintainability requirements for the STP and their subapplications, I and J in this case,

Figure 21. Interactions of subapplications (G and H) with their services for Function Type 3 (systemmalfunction procedure)


Figure 22. Interactions of subapplications (I and J) with their services for Function Type 4 (system testabilityprocedure)


which are triggered in the requesting messages; the service functional process FS replies to FA and thesubapplications with messages containing the requested data or an error message.Function Type 5 system stability procedure. Figure 23 describes the detailed measurements forthe exchange of data messages between the application level and the services level forFunction Type 5 (SSP), and Appendix B-5 contains the detailed measurement for theCOSMIC-SOA model of system maintainability requirements for system stability and theirsubapplications, K and L in this case, which are triggered in the requesting messages; theservice functional process FS replies to FA and the subapplications with messages containingthe requested data or an error message.

5.2.2. Measurement of intermediary services for system maintainability requirements using COSMIC-SOA. When a functional process of an application service in Application A requires data that areavailable via an application service in Application B, the former application service calls on afunctional process of the intermediary service, which may complete the following tasks as a separateutility service – for more details, see [42] (See-Figure 17 and table V):

• Control the handling of the request received from a service of Application A.• Translate the ‘language’ of the message from Application A into the ‘language’ of Application B(and possibly Applications C, D, and so on, if the services of other applications are involved) thatmust fulfill the request.

• Call on a functional process of the application service of Application B by means of the translatedmessage.

• Receive the reply message from the functional process of Application B (and possibly replymessages from Applications C, D, etc.).

• Translate the results into a message in the language of Application A.• Send the reply message to (the functional process of the service of) Application A.

Figure 23. Interactions between subapplications (K and L) with their services for Function Type 5 (systemstability procedure)



• Manage exceptional situations.• Log data about the handling of services.

The COSMIC-SOA model for maintainability requirements describes the detailed measurement forthe intermediary services. This section describes the second step of the COSMIC model for the detailedmeasurement of intermediary services between the application and subapplications of the COSMICreference model of maintainability requirements allocated to software to identify the software-FURservices.Function Type 1 maintainability failure procedure. Figure 24 describes the detailed measurements forintermediary services between the application level and the services level for Function Type 1(maintainability failures procedure), and Appendix B-6 contains the detailed measurement betweenintermediary services (SA, SB, SC, and SD).Function Type 2 registered failure procedure. Figure 25 describes the detailed measurements forintermediary services between the application level and the services level for Function Type 2(registered failure procedure), and Appendix B-7 contains the detailed measurement betweenintermediary services (SE and SF).Function Type 3 system malfunction procedure. Figure 26 describes the detailed measurements forintermediary services between the application level and the services level for Function Type 3(SMP), and Appendix B-8 contains the detailed measurement between intermediary services(SG and SH).Intermediary services between Function Type 2 and Function Type 3. Figure 27 describes the detailedmeasurements for intermediary services between the application level and the services level forFunction Types 2 and 3 (registered failure procedure and SMP), and Appendix B-9 contains thedetailed measurement between intermediary services (SE and SG), (SF and SG), and (SF and SH).Function Type 5 system stability procedure. Figure 28 describes the detailed measurements forintermediary services between the application level and the services level for Function Type 5(SSP), and Appendix B-10 contains the detailed measurement of intermediary services (SK and SL).Intermediary services between Function Type 4 and Function Type 5. Figure 29 describes the detailedmeasurements for intermediary services between the application levels and the services level for

Figure 24. Intermediary services between subapplication services (SA, SB, SC, and SD) for Function Type 1(maintainability failure procedure)

Figure 25. Intermediary services between subapplication services (SE and SF) for Function Type 2(registered failure procedure)

Figure 26. Intermediary services between subapplication services (SG and SH) for Function Type 3 (systemmalfunction procedure)


Figure 28. Intermediary services between subapplication services (SK and SL) for Function Type 5 (systemstability procedure)

Figure 27. Intermediary services between subapplication services (SE and SG), (SF and SG), and (SF andSH) for Function Types 2 and 3 (registered failure procedure and system malfunction procedure)



Function Types 4 and 5 (STP and SSP), and Appendix B-11 contains the detailed measurementbetween intermediary services (SI and SK), (SI and SL), (SJ and SK), and (SJ and SL).

Intermediary services between Function Types 1, 2, and 3 with Function Type 4. Figures 30 and 31describe the detailed measurements for the intermediary services between the application level andthe services level for Function Types 1, 2, 3, and 4 (the maintainability failure procedure, registeredfailure procedure, and SMP with the STP), and Appendix B-12 contains the detailed measurementbetween intermediary services for SK and SL, with (SA, SB, SC, SD, SE, SF, SG, and SH).

5.2.3. Measurement of data movements of data exchanges between components for system maintainabilityrequirements using COSMIC-SOA. On the basis of Figure 15, this section presents the possible flows ofdata movements between all functions in the system maintainability requirements (See-Table V andFigure 18).

Function Type 1 maintainability failure procedure. Figure 32 describes the detailed measurements fordirect data movements of services in the application level for Function Type 1(maintainability failureprocedure), and Appendix B-13 contains the detailed measurement between SDF and subapplications(A, B, C, and D).

Function Type 2 registered failure procedure. Figure 33 describes the detailed measurements for directdata movements of services in the application level for Function Type 2 (registered failure procedure),and Appendix B-14 contains the detailed measurement for direct data movements betweensubapplications (A, B, C, and D) and subapplications (E and F).

Function Type 3 system malfunction procedure. Figure 34 describes the detailed measurements fordirect data movements of services in the application level for Function Type 3 (SMP), andAppendix B-14 contains the detailed measurement for direct data movements betweensubapplications (E and F) and subapplications (G and H).

)r

Figure 30. Intermediary services between subapplication services SK, with (SA, SB, SC, SD, SE, SF, SG,and SH)

Figure 29. Intermediary services between subapplication services (SI and SK), (SI and SL) and (SJ and SK),(SJ and SL) for Function Types 2 and 3 (registered failure procedure and system malfunction procedure)


Indirect data movements for all function types for the COSMIC-SOA maintainability model. Figure 35describes the detailed measurements for the indirect data movements of services in the application levelusing the same persistent storage for all the functional services, and Appendix B-15 contains thedetailed measurement for indirect data movements between the 12 subapplications.

6. APPLICATION OF THE REFERENCE MODEL FOR MEASUREMENT PURPOSES

This section presents one application of the standards-based reference model of system maintainability-NFR. The first example presents a generic example where all of the maintainability-NFR functions in


Figure 33. Direct data movements between subapplications (A, B, C, and D) and subapplications (E and F)for Function Type 2 (registered failure procedure)

Figure 31. Intermediary services between subapplication services SL with (SA, SB, SC, SD, SE, SF, SG,and SH).

Figure 32. Direct data movements between the application system diagnostic function (SDF) and subappli-cations (A, B, C, and D) for Function Type 1 (maintainability failure procedure)



Figure 35. Indirect data movements between all subapplications of all function types for the COSMICmaintainability model

Figure 34. Direct data movements between subapplications (E and F) and subapplications (G and H) forFunction Type 3 (system malfunction procedure)


an SOA context would be allocated to software. The second example presents a case study where onlya specific subset of the reference system maintainability-NFR is allocated to software.

6.1. Sizing a generic instantiation of the reference model in an SOA context

The example presented in Table VI is a generic instantiation of all maintainability functions of thestandards-based reference model allocated to software in an SOA context. Specification of software-FUR for system maintainability in any specific project is a specific instantiation of the proposedreference model described in Figure 15. When the software specification document is at the level ofthe movements of data groups, then these functional requirements can be measured directly usingthe COSMIC measurement rules.

Table VI presents the measurement results based on the detailed measurement manual (AppendixB), using a specific instantiation of the maintainability requirements, which would consist of one of



each of the maintainability function types and relationships described in the previous sections and inFigure 15. For example, Table VI illustrates the sizing reference of the generic model of software-FUR for system maintainability.

6.2. Case study: Flight control system

The allocation and specification in any particular project of software-FUR for system maintainability isa specific instantiation of the proposed reference model described in Figure 15. This second examplepresents a case study of the flight control system (FCS) for the Airbus A333/A340 (FCS) [56, 57].The FCS is the system that controls the plane. It consists of mechanical and electronic partscontrolled through real-time flight control software. A specific configuration of the FCS functionsallocated to hardware and software is documented in [56, 57], and the FCS requirements blockdiagram is reproduced in Figure 36; however, the FCS system maintainability-NFR are neitherspecified nor measured.

The requirements set for the FCS in Figure 36 have to be applied to all subsystems. The electronicsand mechanical components have to interpret pilot commands, combine them with all kinds of sensoryinputs, and use them for actuator control and interface displays. They also have to monitor (andeventually reconfigure) the entire system, including themselves. These components should operateindependently. If one of them malfunctions, its tasks should be taken over by the other components.

Actuators are driven by the electronics and mechanical components, and have to position theflight surfaces using the flight control software. Sensors are to be used for all flight surfacesusing the flight control software. The flight control software provides the pilots with flightstatus measurements at all times, such as airspeed, attitude, altitude, horizon, vertical speed,and global positioning system info.

The project stakeholders are the people (or organizations) with an interest in a project (here, theFCS). They can derive some of the maintainability requirements for the FCS from our referencemodel of system maintainability-NFR, which can next be allocated to the software asmaintainability-FUR (Figure 37).

The proposed reference model of the system maintainability-NFR, which lists specific maintainabilityfunctions derived from the content of various standards, is used to bridge the gap between research andpractice in the system requirements engineering phase through the following steps:

Step 1: Specify some maintainability functionality requirements at the (high) system level of the FCScomponents using the proposed standards-based system maintainability model as the referencefor this type of system specifications.

Step 2: Allocate some (or all) of these system maintainability-FUR to software functions to be addedto this updated COSMIC FCS case study.

Specific maintainability requirements derived by project stakeholders

for the FCS Case Study

The standards-based reference model of software-FUR for

system maintainability-NFR

Figure 37. From reference system maintainability nonfunctional requirements (NFR) to specific maintain-ability-NFR for the flight control system (FCS)

Flight Control Software

Sensors

Actuator

Electronics and MechanicalComponents

Position

Translation

Sensor output

Control Signal

Figure 36. Block diagram of the hardware and software components of the flight control system case study[56, 57]



Step 3: Measure the software-FUR for the system maintainability-NFR allocated to software for thisupdated COSMIC FCS case study.

Step 1: Addition of maintainability requirements at the system level. In this example, the stakeholdersrequest three maintainability requirements (R1 to R3) at the system level (see left-hand side ofTable VII). To these, maintainability requirements correspond to 12 maintainability functions (F1 toF12), which are described in the ECSS standards (right-hand side of Table VII).

Step 2: Allocate these system maintainability requirements to software functions to be added to theFCS. For these added system maintainability requirements to be met, the correspondingmaintainability functions have to be allocated to the FCS components: either hardware or software,or both. Table VIII presents the specific allocation to the FCS components of these added standards-based system maintainability functions (Table VIII):

• The maintainability requirement R1 is allocated to the FCS: therefore, R1 is mapped with F1(Figure 38 and Table VIII). This means that the FCS should be a self-testing system (withself-testing parts) that will indicate faults at an early stage.

• The maintainability requirement R2 is allocated to the FCS: therefore, R2 is mapped with F2 and F3(Figure 38 and Table VIII). This means that the FCS should test the flight system and subsystemsduring the operation.

• The maintainability requirement R3 is allocated to the FCS software, and to new software functionsto be added to the hardware sensors and actuators: therefore, R3 is mapped with F4 (Figure 38 andTable VIII). This means that the FCS should be modular.

Figure 38 presents the standards-based model of software-FUR for system maintainability for theupdated FCS on the basis of Figures 36 and 37, and Tables VII and VIII.

Table VIII. Allocation of the three maintainability functional user requirements (FUR) to the flight controlsystem (FCS) components.

IDStandards-basedmaintainability-FUR F R

Software functionsallocated to existingsoftware

Software functionsallocated to hardwarein updated hardware-softwarecomponents

1 Failure data operationfunction (FDOF)

F1 R1 Flight controlsoftware

2 Failure data monitoringfunction (FDMF)


3 Failure data controlfunction (FDCF)


4 System failure taskfunction (SFTF)

F4 R3 Sensors and actuators

Table VII. Addition of three system maintainability requirements (R1, R2 and R3).

Stakeholder maintainability requirements Corresponding ECSS standards maintainability functions

•The flight control system (FCS) should be aself-testing system (with self-testing parts)that will indicate faults at an early stage (R1)

•The FCS should test the flight system andsubsystems during the operation (R2)

•The FCS should be modular (R3)

F1 Failure data operation function (FDOF)F2 Failure data monitoring function (FDMF)F3 Failure data control function (FDCF)F4 System failure task function (SFTF)F5 Failure detection function (FDF)F6 Failure isolation function (FIF)F7 Correct data faults function (CDFF)F8 Correct system defects function (CSDF)F9 Fault prevention of data control function (FPDCF)F10 Fault prevention of system function (FPSF)F11 System time function (STF)F12 Fault allocation time function (FATF)


System Analyzability System Changeability

System Maintainability Failure Procedures (SMEP)

Function Type 1


Function Type 3


Function Type 2SYSTEM

DIAGNOSTIC

FUNCTION

SDF


FDOF


FDMF


FDCF


SFTF


FDF

Failure IsolationFunction

FIF

Correct Data Faults

Function CDFF

Correct System Defect

Function CSDF

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

ENTRY

Persistent Storage

Data Movement Types

FunctionalProcess

Intermediary Services R, W

12 3

R,W

R,W

R,W

R,W

R,W

R,W

R,W

R,W

Entry

FU

Exit

5 System Testability Procedure (STP) Function Type 5

System Time Function (STF)




R,W

R,W


R, W

R,W

Intermediary Service (IS)

4

F1

F2

F3

F4

F5

F6

F8

F7

F9

F10

F11

F12

R1

R2

R2

R3




Sensors and Actuators

Figure 38. System maintainability model for the case study (flight control system)


In Figure 38, the software functions allocated to the existing software (i.e., flight controlsoftware) are functions (F1, F2, and F3) in the model, whereas the software function allocatedto hardware in the updated hardware-software components (i.e., sensors and actuators) is F4 inthe maintainability model.

The allocation of the three new FCS maintainability requirements (R1 to R3), and the correspondingECSS-based functions (F1 to F12) to the hardware and software components, is summarized inTable VIII.

It is important to note that, with the above set of additional system maintainability-NFR, a numberof software functions must be specified and added to the original FCS case study, as well as to some ofthe hardware components that did not initially have any software functions allocated to them (e.g., thesensors and actuators, which were then only receiving and sending signals from the flightcontrol software).

Step 3: Measurement of the software-FUR for the system maintainability-NFR. The measurementviewpoint in this case study is that of the software developer who is interested in quantifying thesystem maintainability requirements that have been added as new software functions to bedeveloped. The measurement purpose is to measure, with the use of the COSMIC method (ISO19761), the entire set of added FUR coming from the system maintainability-NFR allocated to thesoftware for this case study. The measurement scope is this set of system maintainability-NFR



requirements, that is, only functions allocated to the software and not those leading to changes to thehardware itself.

When these maintainability requirements are specified using the structure of the proposed standards-based model of software-FUR for the system maintainability-NFR, they are already aligned with theCOSMIC model of FUR, and the necessary information for measuring their functional size isreadily available.

For illustrative purposes, the following assumption is made in this case study: there is a single datagroup for each maintainability function specified (of course, for a maintainability function specified inan industrial context, more than one data group may be needed). The total functional size according toISO 19761 for all the maintainability-related software functions added to this updated FCS is obtainedby adding all the data movements for each distinct maintainability function.

The bottom line of Table IX presents the measurement results for the system maintainability functionsallocated to the new software functions for the updated FCS case study: 12 COSMIC function points(CFP). The software functional size for the added software functions required to meet the systemmaintainability requirements is equal to 12 CFP.

6.3. Lessons learned

In the system engineering standards for the aerospace industry, the list of maintainabilityrequirements is quite extensive, but there is no integrated view in the form of a referencemaintainability model as proposed in this paper. In practice, as illustrated in the FCS casestudy, the system functions (i.e., system-FUR) are documented but not the NFR, such as themaintainability requirements, which could be allocated to software, for example. Therefore, forthe purpose of illustrating the application of the proposed reference model, we could not comeacross the necessary detailed material, neither from the literature nor from our network ofcontacts in industry. Building the examples to illustrate this application of the reference modelfor measurement purposes has therefore been more time-consuming than in practice becausesuch maintainability requirements had to be elicited and documented prior to the measurementstep. In practice, measurement of well-documented maintainability requirements would proceedfaster. On the other hand, the examples presented consider as an assumption the presence ofsingle data groups in the requirements; in practice, the number of distinct data groups mayvary across maintainability functions and the correct identification of all relevant data groupsmay be time-consuming and error-prone if the documentation is incomplete and neither verifiednor validated.

7. CONCLUSION AND DISCUSSION

Maintainability is typically described initially as NFR at the system level, and systems engineers mustsubsequently apportion these systems requirements very carefully, as either software or hardwarerequirements, to conform to the maintainability requirements of the system. Within the ECSS, ISO9126, and IEEE standards, a number of views and concepts are provided to describe various typesof candidate maintainability requirements at the system, software, and hardware levels.

Table IX. Measurement details for the system maintainability requirements allocated to software functions.

IDStandards-based software-FUR for

maintainability functions F

Data movements identified

E X R W Size in CFP

1 Failure data operation function (FDOF) F1 1 – 1 1 32 Failure data monitoring function (FDMF) F2 1 – 1 1 33 Failure data control function (FDCF) F3 1 – 1 1 34 System failure task function (SFTF) F4 1 – 1 1 3

Functional size 4 – 4 4 12 CFP

CFP, COSMIC function points.



This paper has collected and organized these concepts into a reference model of therequirements for maintainability. This reference model corresponds to a standards-basedframework for modeling software-FUR for system maintainability-NFR. This reference model isbased on the generic model of software proposed in COSMIC – ISO 19761, which allowsmeasurement of the functional size of the software maintainability requirements using thisCOSMIC international standards of measurement.

This paper has introduced a procedure for specifying and measuring software requirements for theinternal and external maintainability needed to address the system’s maintainability requirements. Themain contribution of this paper is our proposed reference model of software-FUR for systemmaintainability, which can be considered as a kind of reference model for the identification ofsystem maintainability requirements and their allocation to software functions implementing suchrequirements. System requirements allocated to hardware have not been addressed in this paper.We include with the model a detailed measurement method using the SOA.

Because the structure of our reference model is based on the generic model of softwareadopted by the COSMIC measurement standards, the necessary information for measuringsoftware functional size is readily available, and an example has been presented of a specificinstantiation of this reference model. Our model of maintainability presented in this paper istherefore standards-based, as it is founded on the following:

1. The ECSS standards for the description of the NFR for system maintainability and2. The COSMIC measurement model of functional requirements.3. The model is independent of software type and the languages in which the software-FUR will be

implemented. As a reference model, it provides:4. A specification model for each type, or all types, of maintainability requirements specified

in these standards; for example, the requirements to be allocated to software: for maintain-ability failure procedures; for system analyzability of registered failures and software/system malfunctions; for system changeability; and for system/software stability andtestability.

5. A specification measurement model for each type, or all types, of maintainability requirements.

Our reference model of system maintainability requirements can provide system engineers withthe following:

• An integrated reference view of system maintainability requirements that system engineers canuse to select the maintainability requirements necessary for the development of a specific system(hardware-software manual).

• A methodology to specify these maintainability-NFR: with this reference model, beginners may notneed years of training before they are able to specify them at this level of detail.

• An integrated model to be used as an input to make decisions on which of these detailedmaintainability-NFR will be allocated to the following: (i) hardware, (ii) software, or (iii) a manualsystem (or a combination of these for a specific context).

For software engineers, the proposed model can also provide them with:

• A reference model that they can use to verify whether or not the system engineers have provided themwith the right selection of system NFR-derived FUR and at the level of detail they require (that is, tobe used as a quality technique as: (i) a means of verification of system maintainability requirementscoverage and description; (ii) as a technique to elicit such requirements in the software requirementsphase, referred to as ‘both NFR and emergent properties’ in Software Engineering Body ofKnowledge – ISO 19759).

• The previous level of detailed inputs requirements early in the project life cycle (that is, inthe software requirements phase, rather than their specification only in the late, softwaretesting phase).

• A way to measure these FUR with COSMIC – ISO 19761, and take them into account in FP-basedsoftware estimation models (thereby avoiding late discovery of mandatory FUR that lead to budgetoverruns and missed deadlines).



The measurement aspects presented in this paper are limited to the system requirements allocated tosoftware. It will be interesting in future work to investigate whether or not this measurement approachcan be extended to all such requirements at the system level (that is, for hardware and manual systemrequirements, as well as software requirements) as well as evaluating the suggested approach through anumber of case studies.

A number of related issues have not been tackled yet and will require further work along tworesearch avenues:

A. Improved models of system-NFR that may be allocated to software-FUR.• The proposed reference model accounts for only the definitions of the maintainability-NFR asdefined by the standards. The resulting model may be incomplete for some application domains,and further work is required to improve the model proposed, as well as the standards themselves.

• Although the proposed reference model can be used to identify and specify system maintainability-NFR and allocate them to software-FUR, it does not document other types of NFR and does notidentify candidate relationships across types of NFR. The known issue that certain solutions couldbe used to achieve multiple NFR at the same time and some solutions could achieve some NFRwhile hurting some other NFR will necessitate, for more in-depth analysis of such interactions,detailed reference models of the other types NFR.

B. Measurement and estimation.• Even though the standards-based reference model is generic, the measurement results for eachspecific application will be distinct: each one will have its own specific instantiation of thereference model.

• Estimation models using the size of software-FUR derived from systems-FUR as their keyindependent variable may be improved by taking into account the size of these othersoftware-FUR derived from system-NFR (maintainability and other types of NFR). Ofcourse, empirical work is needed to collect data and investigate whether or not the perfor-mance of such expanded size-based estimation models is indeed improving.

• Research on estimation models using as inputs the size of software-FUR derived from bothsystems-FUR and system-NFR should investigate not only the initial development phasebut also the system maintenance phase.

APPENDIX A ECSS, ISO 9126 AND IEEE STANDARDS FOR MODELING SYSTEMMAINTAINABILITY REQUIREMENTS.

Appendix A-1: Maintainability, as described by the ECSS standards.

ECSS standards

Copyright © 2012 John Wiley &

Maintainability, as described in the ECSS standards.
ECSS-E-40-Part-2B2005 [31]
Software maintainability requirements shall be applicable tothe software item.

ECSS-E-ST-10C 2009 [33]
A maintainability requirement is considered part of the integratedlogistical support requirements in system engineering, and includesactivities and procedures, e.g., operational allowable envelopes,accessibility, tooling, support materials, parts availability, and deliveries.
ECSS-E-ST-32C-Rev.12008 [43]

The maintenance program includes a maintenance protocol andmeasurable parameters for all operations and during all project phases,including at least the following:•Mean time-to-repair and limited life,•Fault detection and isolation capability,•Spares requirements, and•Ground storage requirements.

ECSS-E-ST-33-01C2009 [44]

The maintenance mechanism shall be documented in specificmechanism specifications (SMS), including maintainabilityrequirements activities and procedures. The SMS for maintainabilityrequirements includes the following:•Fault identification and repair,•Failure modes, and

Sons, Ltd. J. Softw. Evol. and Proc. (2012)DOI: 10.1002/smr

Appendix A-1 (continued)


Copyright © 2012 John Wiley & So

•Environment for maintainability operation.
ECSS-E-ST-34C 2008 [45] Maintainability issues are given particular importance in environment
control and life support systems design (ECLSS). ECLSS includes themaintenance modes of operations, such as faults, failures, and error modes.

ECSS-Q-ST-40C 2009 [46]
The software maintainability requirements shall list any maintainabilityrequirement applicable to the software item.
ECSS-E-ST-70C 2008 [47]ECSS-M-ST-40C-Rev.12009 [48]

Maintainability requirements address critical elements of hardware andsoftware, and indications on maintainability-related factors.

ECSS-Q-ST-10-09C2008 [49]

A maintainability requirement is considered as a nonconformance item,which can have an impact on the customer’s requirements.

ECSS-Q-ST-20C2008 [50]

The supplier shall ensure that maintenance activities be planned and performed,in order to prove that maintainability requirements are satisfied in the realoperational environment.

ECSS-Q-ST-30C2009 [51]

Maintainability requirements shall be apportioned to set maintainabilityrequirements for lower-level products to conform to the maintenanceconcept and maintainability requirements of the system, and themaintainability analysis shall identify maintainability critical items.

ECSS-E-40-Part-1B2003 [30]

The maintenance process contains the activities and tasks of the maintainer.The objective is to modify an existing software product while preservingits integrity. This process includes the migration and retirement of thesoftware product. The process ends with the retirement of the software product.

ECSS-E-40-Part-1B2003 [30]

The maintainer manages the maintenance process at the project levelfollowing the management process, which is instantiated for software inthis process. This process consists of the following activities:•Process implementation,•Problem and modification analysis,•Modification implementation,•Conducting of maintenance reviews,•Software migration, and

Software retirement.
ECSS-Q-ST-30-02C2009 [52]
Maintainability adopts the functional approach, such as ‘failuremodes and effects analysis’ (FMEA) or ‘failure modes, effects andcriticality analysis’ (FMECA) at all levels. When any design or processchanges are made, the FMEA/FMECA is updated, and the effects ofnew failure modes introduced by the changes are carefully assessed.AlthoughFMEA/FMECA is primarily a reliability task, it provides information andsupport to maintainability, maintenance planning, and ‘failure detection, isolation,and recovery’ design. The FMEA/FMECA results are used by severaldisciplines to ensure the consistency and avoid the proliferation ofrequirements and the duplication of effort within the same program.

ECSS-Q-ST-30-09C2008 [53]

Downtime is relevant to corrective maintenance, preventive maintenance,logistics, and administrative delays.

ECSS-Q-ST-80C2009 [54]

Maintainability requirements shall be used to specify the quality model;in addition, it shall also be defined as a nonfunctional requirementbecause it is essential to satisfy the requirements baseline.

ECSS-S-ST-00C [55]
The ECSS system: description, implementation, and general requirementslist the maintainability requirements and maintenance support performanceas important parts of system dependability, besides availability and reliability.
Appendix A-2: Maintainability, as described in ISO 9126.

ISO 9126 series
Maintainability, as described in ISO 9126. ISO 9126-1 Maintainability is a quality characteristic defined as the capability of
the software product to be modified. Modifications may includecorrections, improvements, or adaptations of the software tochanges in environment, and in requirements and functionalspecifications. ISO 9126 defines maintainability as composed

ns, Ltd. J. Softw. Evol. and Proc. (2012)DOI: 10.1002/smr

Appendix A-1 (continued)


Copyright © 2012 John Wiley & S

of the following quality subcharacteristics: analyzability, changeability,stability, and testability.Analyzability: the capability of the software product to be diagnosedfor deficiencies or causes of failures in the software, or for the identificationof the parts to be modified.Changeability: the capability of the software product to enable a specifiedmodification to be implemented.Stability: the capability of the software product to avoid unexpected effects frommodifications of the software.Testability: the capability of the software product to enable modified softwareto be validated.Maintainability compliance: the capability of the software product toadhere to standards or conventions relating to maintainability.

ISO 9126-2
External maintainability (from the ISO 9126 perspective)•Analyzability◦Audit trial capability◦Failure analysis capability◦Status monitoring capability
•Changeability◦Change efficiency◦Software change control capability

•Stability◦Change success ratio

•Testability◦Availability of a built-in test function◦Retest efficiency

ISO 9126-3
Internal maintainability (from the ISO 9126 perspective)•Analyzability◦Diagnostic function support
•Changeability◦Modifiability

•Stability◦Modification impact

•Testability◦Test restart capability

Appendix A-3: Identification of the data groups and objects of interest in software, maintainability-FUR that may be allocated to software.

Data sources

ons, Ltd.

Objects of interest

J. Softw. Evol. and PDOI:

Data group
System changeability •System malfunction •Defects
•Correct data faults
•Faults •Correct system defects •Failures
System stability
•Fault prevention of data control•Fault prevention of system function
System testability
•System time•Fault allocation time
Data destinations
System analyzability •Maintainability failure procedure
•Failure data operation•Failure data operation monitoring•Failure data control•System failure items

System changeability
•Registered failures•Failure isolation•Failure detection
roc. (2012)10.1002/smr


APPENDIX B. COSMIC-SOA MEASUREMENTMANUAL FOR SYSTEMMAINTAINABILITYREQUIREMENTS.

Appendix B-1: Detailed COSMIC-SOA measurement of exchange messages of the application,subapplication, and services – Function Type 1.

Copyright © 2012 John

Functional process subapplication

Wiley & Sons, Ltd.

CFP
Functional process services
J. Softw. Evol. and Proc. (2DOI: 10.100

CFP
Subapplication A •A functional process FDOF-A is
triggered in the requesting messagesfrom service functional process FS-A

X
A service functional processFS-A receives a messagefrom from a functional processFDOF-A
E

•A functional process FDOF-Areceives data from FS-A

E
•The service functional processFS-A replies to FDOF-Awith a message containing therequested data or an error message
X

Subapplication B
•A functional process FDMF-Bis triggered in the requestingmessages from service functionalprocess FS-B
X
A service functional process FS-Breceives a message from from afunctional process FDMF-B
E

•A functional process FDMF-Breceives data from FS-B

E
•The service functional processFS-B replies to FDMF-B with amessage containing the requesteddata or an error message
X

Subapplication C
•A functional process FDCF-Cis triggered in the requestingmessages from service functionalprocess FS-C
X
A service functional processFS-C receives a message from afunctional process FDCF-C
E

•A functional process FDCF-Creceives data from FS-C

E
•The service functional processFS-C replies to FDCF-C with amessage containing the requesteddata or an error message
X

Subapplication D
•A functional process SFTF-Dis triggered in the requestingmessages from service functionalprocess FS-D
X
A service functional processFS-D receives a message from afunctional process SFTF-D
E

•A functional process SFTF-Dreceives data from FS-D

E
•The service functional processFS-D replies to SFTF-D with amessage containing the requesteddata or an error message
X


CFP Functional process services CFP Subapplication E •A functional process
FIF-E is triggeredin the requestingmessages from servicefunctional process FS-E

X
A service functionalprocess FS-E receivesa message from from afunctional process FIF-E
E

•A functionalprocess FIF-E receivesdata from FS-E

E
•The service functionalprocess FS-E repliesto FIF-E with a messagecontaining the requesteddata or an error message
X

Subapplication F
•A functional processFDF-F is triggeredin the requesting messagesfrom service functionalprocess FS-F
X
A service functional process FS-Freceives a message from a functionalprocess FDF-F
E

•A functionalprocess FDF-Freceives datafrom FS-F

E
•The service functional process FS-Freplies to FDF-F with a messagecontaining the requested data oran error message
X

012)2/smr



Copyright © 2012 John


Wiley & Sons, Ltd.

CFP

CFP
Subapplication G •A functional process
CDFF-G is triggeredin the requestingmessages from servicefunctional process FS-G

X
A service functional processFS-G receives a message froma functional process CDFF-G
E

•A functional processCDFF-G receivesdata from FS-G

E
•The service functional processFS-G replies to CDFF-G witha message containing the requesteddata or an error message
X

Subapplication H
•A functional processCSDF-H is triggeredin the requestingmessages from servicefunctional process FS-H
X
A service functional process FS-Hreceives a message from afunctional process CSDF-H
E

•A functional processCSDF-H receivesdata from FS-H

E
•The service functional processFS-H replies to CSDF-H witha message containing therequested data or an error message
X


CFP Functional process services CFP Subapplication I •A functional process
STF-I is triggeredin the requestingmessages from servicefunctional process FS-I

X
•A service functionalprocess FS-I receivesa message from afunctional process STF-I
E

•A functional processSTF-I receives data fromFS-I

E
•The service functional processFS-I replies to STF-I with amessage containing the requesteddata or an error message
X

Subapplication J
•A functional process FATF-J istriggered in the requestingmessages from servicefunctional process FS-J
X
•A service functional processFS-J receives a message from afunctional process FATF-J
E

•A functional process FATF-Jreceives data from FS-J

E
•The service functional processFS-J replies to FATF-J with amessage containing the requesteddata or an error message
X


CFP Functional process services CFP Subapplication K •A functional process
FBDCF-K is triggeredin the requesting messagesfrom service functionalprocess FS-K

X
•A service functionalprocess FS-K receivesa message from a functionalprocess FBDCF-K
E

•A functional processFBDCF-K receivesdata from FS-K

E
•The service functionalprocess FS-K repliesto FBDCF-K with amessage containing therequested data or anerror message
X

012)2/smr

Appendix B-5 (continued)


Subapplication L

Copyright © 2012 John W

•A functional processFPSF-L is triggeredin the requestingmessages from servicefunctional process FS-L

iley & Sons, Ltd.

X
•A service functionalprocess FS-L receivesa message from afunctional process FPSF-L

E

•A functional processFPSF-L receivsdata from FS-L

E
•The service functionalprocess FS-L repliesto FPSF-L with a messagecontaining the requesteddata or an error message
X

Appendix B-6: Detailed COSMIC-SOA measurement of intermediary services for Function Type 1.

The intermediary services betweensubapplications for Function Type 1

CFP
The intermediary services betweenFS-A and FS-B

A service functional process FS-Asends one data group to intermediaryservice (IS) between service SAand service SB.

X

Subapplication A
Subapplication B •Intermediary service (IS) betweenservice SA and service SB receivesone data groupfrom a service functionalprocess FS-A.
E

•Intermediary service (IS) between serviceSA and service SB sends one data groupto a service functional process FS-B.

X

•A service functional process FS-B receivesone data group from intermediary service(IS) between service SA and service SB.

E

•A service functional process FS-B sendsone data group to intermediary service(IS) between service SA and service SB.

X

•Intermediary service (IS) between serviceSA and service SB receives one data groupfrom a service functional process FS-B.

E

•Intermediary service (IS) between serviceSA and service SB sends one data group to aservice functional process FS-A.

X

•A service functional process FS-A receivesone data group from intermediary service(IS) between service SA and service SB.

E

The intermediary services betweenFS-B and FS-C

•A service functional process FS-B sendsone data group to intermediary service (IS)between service SB and service SC.

X

Subapplication B
Subapplication C •Intermediary service (IS) between service SBand service SC receives one data groupfrom aservice functional process FS-B.
E

•Intermediary service (IS) between serviceSB and service SC sends one data group toa service functional process FS-C.

X

•A service functional process FS-C receivesone data group from intermediary service (IS)between service SB and service SC.

E

•A service functional process FS-C sendsone data group to intermediary service (IS)between service SB and service SC.

X

E

012)2/smr




•Intermediary service (IS) between service SB& service SC receives one data group from aservice functional process FS-C.•Intermediary service (IS) between service SBand service SC sends one data group to aservice functional process FS-B.


X

•A service functional process FS-B receivesone data group from intermediary service (IS)between service SB and service SC.

E

The intermediary services betweenFS-C and FS-D

•A service functional process FS-C sendsone data group to intermediary service (IS)between service SA and service SD.

X

Subapplication C
Subapplication D •Intermediary service (IS) between service SCand service SD receives one data groupfrom a service functional process FS-C.
E

•Intermediary service (IS) between service SCand service SD sends one data group to aservice functional process FS-D.

X

A service functional process FS-D receives onedata group from intermediary service (IS)between service SC and service SD.

E

•A service functional process FS-D sends onedata group to intermediary service (IS) betweenservice SC and service SD.

X

•Intermediary service (IS) between service SC andservice SD receives one data group movementsfrom a service functional process FS-D.

E

•Intermediary service (IS) between service SCand service SD sends one data group to a servicefunctional process FS-C.

X

A service functional process FS-A receives onedata group from intermediary service (IS)between service SC & service SD.

E



CFP
The intermediary servicesbetween FS-E and FS-F

A service functional process FS-E sendsone data group to intermediary service (IS)between service SE and service SF.

X

Subapplication E
Subapplication F •Intermediary service (IS) between service SEand service SF receives one data group froma service functional process FS-E.
E

•Intermediary service (IS) between service SEand service SF sends one data group to a servicefunctional process FS-F.

X

•A service functional process FS-F receives onedata group from intermediary service (IS) betweenservice SE and service SF.

E

•A service functional process FS-F sends onedata group to intermediary service (IS) betweenservice SE and service SF.

X

•Intermediary service (IS) between service SEand service SF receives one data group from aservice functional process FS-F.

E

•Intermediary service (IS) between service SEand service SF sends one data group to a servicefunctional process FS-E.

X

E

012)2/smr




•A service functional process FS-E receives onedata group from intermediary service (IS)between service SE and service SF.





CFP

The intermediary services betweenFS-G and FS-H

•A service functional process FS-G sendsone data group to intermediary service (IS)between service SG and service SH.

X

•Intermediary service (IS) between service SGand service SH receives one data group from aservice functional process FS-G.

E

•Intermediary service (IS) between service SGand service SH sends one data group to a servicefunctional process FS-H.

X

A service functional process FS-H receive onedata group from intermediary service (IS) betweenservice SG and service SH.

E

Subapplication G
Subapplication H •A service functional process FS-H sends onedata group to intermediary service (IS) betweenservice SG and service SH.
X

•Intermediary service (IS) between service SGand service SH receives one data group from aservice functional process FS-H.

E

•Intermediary service (IS) between service SGand service SH sends one data group to a servicefunctional process FS-G.

X

•A service functional process FS-G receives onedata group from intermediary service (IS) betweenservice SG and service SH.

E

Appendix B-9: Detailed COSMIC-SOA measurement of intermediary services for Function Types 2and 3.

The intermediary servicesbetween subapplications forFunction Types 2 & 3

Functional Process Services
CFP
The intermediary services betweenFS-E and FS-G

A service functional process FS-E sendsone data group to intermediary service (IS)between service SE and service SG.

X

Subapplication E
Subapplication G •Intermediary service (IS) between service SEand service SG receives one data group froma service functional process FS-E.
E

•Intermediary service (IS) between service SEand service SG sends one data group to a servicefunctional process FS-G.

X

•A service functional process FS-G receives onedata group from intermediary service (IS) betweenservice SE and service SG.

E

•A service functional process FS-G sends onedata group to intermediary service (IS) betweenservice SE and service SG.

X

•Intermediary service (IS) between service SE andservice SG receives one data group from a servicefunctional process FS-G.

E

X

012)2/smr




•Intermediary service (IS) between service SEand service SG sends one data group to a servicefunctional process FS-E.•A service functional process FS-E receives onedata group from intermediary service (IS) betweenservice SE and service SG.


E

The intermediary services between FS-F and FS-C
•A service functional process FS-F sends one datagroup t to intermediary service (IS) between serviceSF and service SG.
X

•Intermediary service (IS) between service SF andservice SG receives one data group from a servicefunctional process FS-F.

E

•Group A service functional process FS-Greceives one data group from intermediaryservice (IS) between service SF and service SG.

X

•A service functional process FS-G sendsone data group to intermediary service (IS)between service SF and service SG.

E

•Intermediary service (IS) between service SFand service SG receives one data group froma service functional process FS-G.

X

•Intermediary service (IS) between service SFand service SG send one data group to a servicefunctional process FS-F.

E

•A service functional process FS-F receives onedata group from intermediary service (IS) betweenservice SF and service SG.

X
Subapplication F Subapplication G E
The intermediary services between FS-C and FS-D
•A service functional process FS-F sends onedata group to intermediary service (IS) betweenservice SF and service SH.
X

Subapplication F
Subapplication H •Intermediary service (IS) between service SF andservice SH receives one data group from a servicefunctional process FS-F.
E

•Intermediary service (IS) between service SFand service SH sends one data group to a servicefunctional process FS-H.

X

•A service functional process FS-H receives onedata group from intermediary service (IS) betweenservice SF and service SH.

E

A service functional process FS-H sends onedata group to intermediary service (IS) betweenservice SF and service SH.

X

•Intermediary service (IS) between service SF andservice SH receives one data group from a servicefunctional process FS-H.

E

•Intermediary service (IS) between service SF andservice SH sends one data group to a servicefunctional process FS-F.

X

•A service functional process FS-F receives onedata group from intermediary service (IS) betweenservice SF and service SH.

E


The intermediary servicesbetween subapplications forFunction Type 5

CFP
The intermediary services betweenFS-K and FS-L

•A service functional process FS-K sends onedata group to intermediary service (IS) betweenservice SK and service SL.

X

012)2/smr



•Intermediary service (IS) between service SK andservice SL receives one data group from a servicefunctional process FS-K.


E

•Intermediary service (IS) between service SK andservice SL sends one data group to a servicefunctional process FS-L.

X

•A service functional process FS-L receives one datagroup from intermediary service (IS) between serviceSK and service SL.

E

Subapplication K
Subapplication L •A service functional process FS-L sends one datagroup to intermediary service (IS) between serviceSK and service SL.
X

•Intermediary service (IS) between service SK andservice SL receives one data group from a servicefunctional process FS-L.

E

•Intermediary service (IS) between service SK andservice SL sends one data group to a servicefunctional process FS-K.

X

•A service functional process FS-K receives one datagroup from intermediary service (IS) between serviceSK and service SL.

E

Appendix B-11: Detailed COSMIC-SOA measurement of intermediary services for Function Types 4and 5.

The intermediary servicesbetween subapplicationsfor Function Types 4 & 5

Functional Process Services
CFP
The intermediaryservices betweenFS-I and FS-K

•A service functional process FS-I sends one datagroup to intermediary service (IS) between serviceSI and service SK.

X

Subapplication I
Subapplication K •Intermediary service (IS) between service SI andservice SK receives one data group from a servicefunctional process FS-I.
E

•Intermediary service (IS) between service SI andservice SK sends one data group to a servicefunctional process FS-K.

X

•A service functional process FS-K receives onedata group from intermediary service (IS) betweenservice SI and service SK.

E

•A service functional process FS-K sends onedata group t to intermediary service (IS)between service SI and service SK.

X

•Intermediary service (IS) between serviceSI and service SK receives one data groupfrom a service functional process FS-K.

E

•Intermediary service (IS) between service SIand service SK sends one data group to aservice functional process FS-I.

X

•A service functional process FS-I receives onedata group from intermediary service (IS)between service SI and service SK.

E

The intermediary services betweenFS-I and FS-L

•A service functional process FS-I sends onedata group to intermediary service (IS) betweenservice SI and service SL.

X

Subapplication I
Subapplication L •Intermediary service (IS) between service SI andservice SL receives one data group from a servicefunctional process FS-I.
E

•Intermediary service (IS) between service SI andservice SL sends one data group to a servicefunctional process FS-L.

X

E

012)2/smr



•A service functional process FS-L receives onedata group from intermediary service (IS)between service SI and service SL.•A service functional process FS-L sendsone data group to intermediary service (IS)between service SI and service SL.


X

•Intermediary service (IS) between service SIand service SL receives one data group froma service functional process FS-L.

E

•Intermediary service (IS) between service SIand service SL sends one data group to aservice functional process FS-I.

X

•A service functional process FS-I receivesone data group from intermediary service(IS) between service SI and service SL.

E

The intermediaryservices betweenFS-J and FS-K

•A service functional process FS-J sendsone data group to intermediary service (IS)between service SJ and service SK.

X

•Intermediary service (IS) between service SJand service SK receives one data group from aservice functional process FS-J.

E

•Intermediary service (IS) between service SJand service SK sends one data group to aservice functional process FS-K.

X

•A service functional process FS-K receivesone data group from intermediary service (IS)between service SJ and service SK.

E

Subapplication J
Subapplication K •A service functional process FS-K sendsone data group to intermediary service (IS)between service SJ and service SK.
X

•Intermediary service (IS) between service SJand service SK receives one data group froma service functional process FS-K.

E

•Intermediary service (IS) between service SJand service SK sends one data group to aservice functional process FS-J.

X

•A service functional process FS-J receivesone data group from intermediary service(IS) between service SJ and service SK.

E

The intermediary servicesbetween FS-J and FS-K

•A service functional process FS-J sendsone data group to intermediary service(IS) between service SJ and service SL.

X

•Intermediary service (IS) between serviceSJ and service SL receives one data groupfrom a service functional process FS-J.

E

Subapplication J
Subapplication L •Intermediary service (IS) between serviceSJ and service SL sends one data groupto a service functional process FS-L.
X

•A service functional process FS-L receivesone data group from intermediary service (IS)between service SJ and service SL.

E

•A service functional process FS-L sends onedata group to intermediary service (IS) betweenservice SJ and service SL.

X

•Intermediary service (IS) between service SJand service SL receives one data group froma service functional process FS-L.

E

•Intermediary service (IS) between service SJand service SL sends one data group to aservice functional process FS-J.

X

•A service functional process FS-J receives onedata group from intermediary service (IS)between service SJ and service SL.

E

012)2/smr


Appendix B-12: Detailed COSMIC-SOA measurement of intermediary services for Function Types 1,2, 3, and 4.

The intermediary servicesbetween subapplications forFunction Types 1, 2, 3, & 4




CFP

The intermediaryservices between

•A service functional process FS-Ksends one data group to intermediaryservice (IS) between service SK andservice SA, SB, SC, SD, SE, SF, SG, SH

X

FS-K and FS-A
•Intermediary service (IS) between serviceSK and service SA, SB, SC, SD, SE, SF, SG,SH receives one data group from a servicefunctional process FS-K.
E
FS-K and FS-B
FS-K and FS-C
•Intermediary service (IS) between service SKand service SA, SB, SC, SD, SE, SF, SG, SHsends one data group to a service functional processFS-A, FS-B, FS-C, FS-D, FS-E, FS-F, FS-G, FS-H .
X
FS-K and FS-DFS-K and FS-E
FS-K and FS-F
•A service functional process FS-A, FS-B, FS-C,FS-D, FS-E, FS-F, FS-G, FS-H receives onedata group from intermediary service (IS)between service SK and service SA, SB, SC,SD, SE, SF, SG, SH.
E
FS-K and FS-GFS-K and FS-H
Subapplication K
Subapplication A •A service functional process FS-A, FS-B, FS-C,FS-D, FS-E, FS-F, FS-G, FS-H sends one datagroup to intermediary service (IS) betweenservice SK and service SA, SB, SC, SD,SE, SF, SG, SH.
X

B
•Intermediary service (IS) between service SKand service SA, SB, SC, SD, SE, SF, SG, SHreceives one data group from a service functionalprocess FS-A, FS-B, FS-C, FS-D, FS-E, FS-F,FS-G, FS-H
E
CD
E
•Intermediary service (IS) between service SK andservice SA, SB, SC, SD, SE, SF, SG, SH sendsone data group to a service functional process FS-K.
X
F
G
•A service functional process FS-K receives one datagroup from intermediary service (IS) between serviceSK and service SA, SB, SC, SD, SE, SF, SG, SH.
E
H
The intermediary services between
FS-L and FS-A •A service functional process FS-L sends one data
group to intermediary service (IS) between serviceSL and service SA, SB, SC, SD, SE, SF, SG, SH

X
FS-L and FS-B
FS-L and FS-C
•Intermediary service (IS) between service SL andservice SA, SB, SC, SD, SE, SF, SG, SH receivesone data group from a service functional process FS-L.
E
FS-L and FS-D
FS-L and FS-E
•Intermediary service (IS) between service SL andservice SA, SB, SC, SD, SE, SF, SG, SH sendsone data group to a service functional process FS-A,FS-B, FS-C, FS-D, FS-E, FS-F, FS-G, FS-H .
X
FS-L and FS-F
FS-L and FS-G
•A service functional process FS-A, FS-B, FS-C, FS-D,FS-E, FS-F, FS-G, FS-H receives one data group fromintermediary service (IS) between service SL and serviceSA, SB, SC, SD, SE, SF, SG, SH.
E
FS-L and FS-H
Subapplication L
Subapplication A •A service functional process FS-A, FS-B, FS-C, FS-D,FS-E, FS-F, FS-G, FS-H sends one data group tointermediary service (IS) between service SL and serviceSA, SB, SC, SD, SE, SF, SG, SH.
X

B
•Intermediary service (IS) between service SL and serviceSA, SB, SC, SD, SE, SF, SG, SH receivesone data group from a service functionalprocess FS-A, FS-B, FS-C, FS-D, FS-E,FS-F, FS-G, FS-H
E
CD
012)2/smr



Copyright © 2012 John W

E

iley & Sons, Ltd.

•Intermediary service (IS) between service SLand service SA, SB, SC, SD, SE, SF, SG, SHsends one data group to a service functionalprocess FS-L.


X
F
G
•A service functional process FS-L receives onedata group from intermediary service (IS) betweenservice SL and service SA, SB, SC, SD, SE, SF,SG, SH.
E
H
Appendix B-13: Detailed COSMIC-SOA measurement of direct data movements for Function Type 1.

Functional process application (direct data movement)
CFP Application with subapplication A, B, C, and D •System diagnostic function sends at least one data
group to failure data operation,
X
•System diagnostic function sends at least one datagroup to failure data monitoring,

X

•System diagnostic function sends at least onedata group to failure data control, and

X

•System diagnostic function sends at least one datagroup to system failure task.

X

•Failure data operation function receives at leastone data group from system diagnostic function.

E*

•Failure data monitoring function receives at least one data group from system diagnostic function.

E*

•Failure data control function receives at least onedata group from system diagnostic function.

E*

•System failure task function receives at leastone data group from system diagnostic function.

E*

Appendix B-14: Detailed COSMIC-SOA measurement of direct data movements for Function Types 2and 3.

Functional process application D (direct data movements)
CFP Subapplications A, B, C, and D withsubapplications E and F
•FDOF-A sends at least onedata group to FIF-E

X

•FDMF-B sends at leastone data group to FIF-E

X

•FDCF-C sends at leastone data group to FDF-F

X

•SFTF-D sends at leastone data group to FDF-F

X

•FIF-E receives at leastone data group from FDOF-A

E*

•FIF-E receives at least one datagroup from FDMF-B

E*

•FDF-F receives at least one data group from FDCF-C
E* •FDF-F receives at least one data group from SFTF-D E*
Appendix B-15: Detailed COSMIC-SOA measurement of indirect data movements for the referencemodel of maintainability requirements.

Functional process application (indirect data movements)
CFP Subapplications A, B, C, D, E,F, G, H, I, J, K, and L
•Service SA writes a data group in the persistentstorage to be used by other services in themaintainability model

W

•Service SA reads a data group from thepersistent storage from another service inthe maintainability model

R

•Service SB writes a data group in the persistent storage tobe used by other services in the maintainability model

W

012)2/smr



Copyright © 2012 John Wiley & Sons, Ltd

•Service SB reads a data group from the persistent storagefrom another service in the maintainability model

. J. Softw. Evol. and Proc. (2DOI: 10.100

R

•Service SC writes a data group in the persistent storage to beused by other services in the maintainability model

W

•Service SC reads a data group from the persistent storagefrom another service in the maintainability model

R

•Service SD writes a data group in the persistent storage to beused by other services in the maintainability model

W

•Service SD reads a data group from the persistent storagefrom another service in the maintainability model

R

•Service SE writes a data group in the persistent storage to beused by other services in the maintainability model

W

•Service SE reads a data group from the persistentstorage from another service in the maintainability model

R

•Service SF writes a data group in the persistent storage to beused by other services in the maintainability model

W

•Service SF reads a data group from the persistentstorage from another service in the maintainability model

R

•Service SG writes a data group in the persistent storage to beused by other services in the maintainability model

W

•Service SG reads a data group from the persistent storagefrom another service in the maintainability model

R

•Service SH writes a data group in the persistent storage to beused by other services in the maintainability model

W

•Service SH reads a data group from the persistentstorage from another service in the maintainability model

R

•Service SI writes a data group in the persistent storage to beused by other service in the maintainability model

W

•Service SI reads a data group from the persistentstorage from another service in the maintainability model

R

•Service SJ writes a data group in the persistent storage to beused by other services in the maintainability model

W

•Service SJ reads a data group from the persistentstorage from another service in the maintainability model

R

•Service SK writes a data group in the persistent storage to beused by other services in the maintainability model

W

•Service SK reads a data group from the persistentstorage from another service in the maintainability model

R

•Service SL writes a data group in the persistent storage to beused by other services in the maintainability model

W

•Service SL reads a data group from the persistent storage fromanother service in the maintainability model

R

REFERENCES

1. Al-Sarayreh KT, Abran A. A generic model for the specification of software interface requirements and measurementof their functional size. 8th ACIS International Conference on Software Engineering Research, Management andApplications, SERA 2010. Montreal, Canada.

2. Al-Sarayreh KT, Abran A. Measurement of software requirements derived from system reliability requirements. 24thEuropean Conference on Object-Oriented Programming (ECOOP 2010), Maribor, Slovenia, EU, 2010, 2010.

3. Al-Sarayreh KT, Abran A. Specification and measurement of system configuration non functional requirements. 20thInternational Workshop on Software Measurement (IWSM 2010), Stuttgart, Germany, 2010.

4. Al-Sarayreh KT, Abran A, Cuadrado-Gallego JJ. A standards-based model for the specification and measurement ofmaintainability requirements. 22nd International Conference on Software Engineering and Knowledge Engineering(SEKE 2010), Redwood City, California, USA, 2010.

5. Abran A, Al-Sarayreh KT, Cuadrado-Gallego JJ. Measurement model of software requirements derived from systemmaintainability requirements. 9th International Conference on Software Engineering Research and Practice (SERP2010), Las Vegas, USA, 2010.

6. Abran A, Al-Sarayreh KT. Measurement of software requirements derived from system operations requirements.20th International Workshop on Software Measurement (IWSM 2010), Stuttgart, Germany, 2010.

012)2/smr


7. Abran A, Al-Sarayreh KT. Standards-based model for the specification of system design and implementationconstraints. 17th International Conference on European Systems and Software Process Improvements (EURO-SPI2010), Industry track, Grenoble Institute of Technology, Grenoble, France, 2010.

8. Chung L, Leite JCP. On Non-functional Requirements in Software Engineering, in Conceptual Modeling: Founda-tions and Applications: Essays in Honor of John Mylopoulos. Springer-Verlag: Berlin Heidelberg, 2009; 363–379.

9. Chung L, et al. Non-functional Requirements in Software Engineering. Springer: Heidelberg, 1999.10. Mylopoulos J, Chung L, Nixon B. Representing and using nonfunctional requirements: A process-oriented approach.

IEEE Transactions on Software Engineering 1992; 18: 483–497.11. Shaw M. Larger scale systems require higher-level abstractions. Software Specification and Design, IEEE Computer

Society 1989; 14: 143–146.12. Davis AM. Software Requirements: Objects, Functions, and States. Prentice-Hall Inc: Englewood Cliffs, New

Jersey, 1993.13. Jacobson I, Booth G, Rumbaugl J. Excerpt from the unified software development process: The unified process.

IEEE Software, Redmond, WA: Microsoft Press, 2003. 1999; 16: 96–102.14. Wiegers K. Software Requirements 2nd edition. Microsoft Press: Redmond, WA, 2003.15. Roman G. A taxonomy of current issues in requirements engineering. IEEE Computer 1985; 18(3): 14–21.16. Boehm BW, et al. Characteristics of Software Quality. North-Holland: Amsterdam-New York-Oxford, 1978.17. Antón AI. Goal identification and refinement in the specification of software-based information systems. PhD Thesis,

Georgia Institute of Technology, 1997.18. Chung KL. Representing and using non-functional requirements for information system development: A process-oriented

approach. Ph.D. Thesis, also Tech. Rpt. DKBS-TR-93-1. Department of Computer Science, University of Toronto, 1993.19. Mylopoulos J, Chung L, Yu E. From object-oriented to goal-oriented requirements analysis. Communications of the

ACM 1999; 42(1): 31–37.20. Jacobs S. Introducing measurable quality requirements: A case study. In RE ′99: Proceedings of the4th IEEE

International Symposium on Requirements Engineering, 1999; 172–179.21. Andrew J. An approach to quantitative non-functional requirements in software development. 34th Annual Govern-

ment Electronics and Information Association Conference, 2000.22. Chung L, et al. Nonfunctional requirements in software engineering. Kluwer Academic Publishing, 2000.23. Paech B, et al. Functional requirements, non-functional requirements and architecture specification cannot be sepa-

rated – A position paper. REFSQ, 2002.24. Moreira A, Araujo J, Brito I. Crosscutting quality attributes for requirements engineering. 14th International Confer-

ence on Software Engineering and Knowledge Engineering, Ischia, Italy, 2002: 167–174.25. Rosa NS, Cunha PRF, Justo GRR. ProcessNFL: A language for describing non-functional properties. 35th HICSS,

IEEE Press, 2002.26. Park D, Kang S. Design phase analysis of software performance using aspect-oriented programming. 5th Aspect-Ori-

ented Modeling Workshop in Conjunction with UML 2004, Lisbon, Portugal, 2004.27. Glinz M. Rethinking the notion of non-functional requirements. 3rd World Congress for Software Quality, Munich,

Germany, 2005.28. Kaiya H, Osada A, Kayjiri K. Identifying stakeholders and their preferences about nfr by comparing use case diagrams of

several existing systems. IEEE International Conference on Requirements Engineering (RE04), 2004: 112–121.29. Mylopoulos J. Goal-oriented requirements engineering. Keynote at the 14th IEEE International Conference on

Requirements Engineering, IEEE Computer Society Press, 2006.30. ECSS-E-40-Part-1B. Space engineering: Software – Part 1: Principles and requirements. European Cooperation for

Space Standardization, The Netherlands, 2003.31. ECSS-E-40-Part-2B. Space Engineering: Software – Part 2: Document requirements definitions. European Cooper-

ation for Space Standardization, The Netherlands, 2005.32. ECSS-Q-80B. Space product assurance: Software product assurance. European Cooperation for Space Standardiza-

tion, The Netherlands, 2003.33. ECSS-E-ST-10C. Space engineering: System engineering general requirements. Requirements & Standards Division

Noordwijk, The Netherlands, 2009.34. ISO/IEC-9126. Software Engineering – Product Quality – Part 1: Quality Model 9126–1. International Organization

for Standardization, Geneva (Switzerland), 2004.35. IEEE-Std-830. IEEE Recommended Practice for Software Requirements Specifications. The Institute of Electrical

and Electronics Engineers: New York, NY, 1998.36. ISO/IEC-19761. Software Engineering – COSMIC v 3.0 – A Functional Size Measurement Method. International

Organization for Standardization: Geneva (Switzerland), 2011.37. ISO/IEC-14143-1. Information Technology – Software Measurement – Functional Size Measurement Part 1: Defini-

tion of Concepts. International Organization for Standardization: Geneva (Switzerland), 2007.38. ECSS-ESA. Tailoring of ECSS, software engineering standards for ground segments, Part C: Document templates.

ESA Board of Standardization and Control (BSSC), 2005.39. ECSS-ESA. Tailoring of ECSS, software engineering standards for ground segments, Part C: Document templates.

ESA Board of Standardization and Control (BSSC), 2005.40. ISO/IEC-14764. Standard for software engineering – Software life cycle processes – Maintenance. Software &

Systems Engineering Standards Committee, IEEE Computer Society, 2006.



41. IEEE-982.1™. IEEE Standard Dictionary of Measures of the Software Aspects of Dependability. Software Engineer-ing Standards Committee, IEEE Computer Society: New York, NY, USA, 2005.

42. COSMIC. The COSMIC method v3.0.1, guideline for sizing SOA software, v1.4. The Common Software Measure-ment International Consortium, 2010.

43. ECSS-E-ST-32C-Rev.1. Space engineering: Structural general requirements. Requirements & Standards DivisionNoordwijk, The Netherlands, 2008.

44. ECSS-E-ST-33-01C. Space Engineering: Mechanisms. Requirements & Standards Division Noordwijk, TheNetherlands, 2009.

45. ECSS-E-ST-34C. Space engineering: Environmental control and life support (ECLS). Requirements & StandardsDivision Noordwijk, The Netherlands, 2008.

46. ECSS-Q-ST-40C. Space product assurance: Safety. Requirements & Standards Division Noordwijk, TheNetherlands, 2009.

47. ECSS-E-ST-70C. Space engineering: Ground systems and operations. Requirements & Standards DivisionNoordwijk, The Netherlands, 2008.

48. ECSS-M-ST-40C-Rev.1. Space project: Management configuration and information management. Requirements &Standards Division Noordwijk, The Netherlands, 2009.

49. ECSS-Q-ST-10-09C. Space product assurance: nonconformance control system. Requirements & Standards Divi-sion Noordwijk, The Netherlands, 2008.

50. ECSS-Q-ST-20C. Space product assurance: Quality assurance. Requirements & Standards Division Noordwijk, TheNetherlands, 2008.

51. ECSS-Q-ST-30C. Space product assurance: Dependability. Requirements & Standards Division Noordwijk, TheNetherlands, 2009.

52. ECSS-Q-ST-30-02C. Space product assurance: Failure modes, effects, and criticality analysis (FMEA/FMECA).Requirements & Standards Division Noordwijk, The Netherlands, 2009.

53. ECSS-Q-ST-30-09C. Space product assurance: Availability analysis. Requirements & Standards Division Noordwijk, TheNetherlands, 2008.

54. ECSS-Q-ST-80C. Space product assurance: Software product assurance. Requirements & Standards DivisionNoordwijk, The Netherlands, 2009.

55. ECSS-S-ST-00C. ECSS system: Description, implementation and general requirements. Requirements & StandardsDivision Noordwijk, The Netherlands, 2008.

56. Airbus A330/A340 Flight Control System case study. System specification, document type A Preliminary ©Univer-sity of Twente, The Netherlands, 2001/2002.

57. Airbus A330/A340 Flight Control System case study. System specification, document type B Preliminary ©Univer-sity of Twente, The Netherlands, 2001/2002.

AUTHORS’ BIOGRAPHIES


Khalid T. Al-Sarayreh is an assistant professor of Software Engineering atHashemite University in Jordan. He has a PhD degree in Software Engineering fromÉcole de Technologie Supérieure (ÉTS)–University of Québec in Canada. He alsohas a Doctoral degree in Computer Information Systems, MSc in ComputerEngineering (Embedded Systems) and BS degree in Computer Science from JordanianUniversities. From 2002 to 2005, he was at the KADDB (King Abdullah II Design andDevelopment Bureau). From 2005 to 2006, he was an Assistant Professor at the JordanUniversity, and from 2006-2008, he was an Assistant Professor at the Faculty ofInformation Technology at the Applied Sciences University (Jordan). His researchinterests include: Software Real-Time Embedded Systems, Computer Networks,Nonfunctional Requirements for Embedded Systems and Applied ArtificialIntelligence.

Alain Abran is a professor and the director of the Software Engineering ResearchLaboratory at the École de Technologie Supérieure (ETS)–Université du Québec.Dr. Abran has more than 20 years of industry experience in information systemsdevelopment and software engineering. Dr. Abran holds a PhD in Electrical andComputer Engineering (1994) from École Polytechnique de Montréal (Canada) andmaster degrees in Management Sciences (1974) and Electrical Engineering (1975)from University of Ottawa. He was the co-executive editor of the Guide to theSoftware Engineering Body of Knowledge project – SWEBOK-ISO 19759. He hasalso been actively involved in software engineering standards as the internationalsecretary for ISO/IEC JTC1 SC7–Software and System Engineering in 2001–2003.He is currently the chairman of the Common Software Measurement InternationalConsortium (COSMIC).




Dr. Juan J. Cuadrado-Gallego Dr. Juan J. Cuadrado-Gallego is profesor titular deuniversidad and the director of the PhD degree in Computer Science at the ComputerScience Department of the Universidad de Alcalá, Madrid, Spain. He is also anassociate professor at the École de Technologie Supérieure, Université du Québec,Montreal, Canada. He was a part of the teaching staff at the Universidad Politécnica,Madrid, Spain, in 2010, at the Otto-von-Guericke Universität, Magdeburg, Germanyin 2009 and 2008, and at the Universitá degli Studi Roma Tre, Roma, Italy, in 2004.Previously, Dr. Juan J. Cuadrado-Gallego was a Profesor at the Universitat Oberta deCatalunya, Barcelona, Spain between 2005 and 2010, at the Universidad de Valladolid,Segovia, Spain in 2004, and at the Universidad Carlos III, Madrid, Spain, between 1997and 2004.


A standards-based model of system maintainability requirements · maintainability concepts into a...

Documents

Transcript of A standards-based model of system maintainability requirements · maintainability concepts into a...