computer standards & interfaces - hashemite university · tional standardization bodies, such...

Computer Standards & Interfaces 35 (2013) 380–395

Contents lists available at SciVerse ScienceDirect

Computer Standards & Interfaces

j ourna l homepage: www.e lsev ie r .com/ locate /cs i

A standards-based reference framework for system portability requirements

Alain Abran a,⁎, Khalid T. Al-Sarayreh b, Juan J. Cuadrado-Gallego a,c

a Software Engineering and Information Technology Department, Ecole de technologie superieure (ETS), University of Quebec, Canadab Software Engineering Department, Hashemite University (HU), Jordanc Computer Science Department, University of Alcalá, Spain

⁎ Corresponding author.E-mail address: [email protected] (A. Abran).

0920-5489/$ – see front matter © 2013 Elsevier B.V. Allhttp://dx.doi.org/10.1016/j.csi.2012.11.003

a b s t r a c t
a r t i c l e i n f o
Article history:Received 4 April 2012Received in revised form 4 October 2012Accepted 14 November 2012Available online 4 January 2013

Keywords:Software Engineering RequirementsNon-functional requirementsPortability requirementsCOSMIC-ISO 19761ECSS Standards

In the system requirements phase, the non-functional requirements (NFR) are often captured only generically ata fairly high level, and they do not yet include the levels of detail necessary for the system engineers to allocatethem as specific functionalities to be handled either by the software or the hardware, or a specific combination ofthe two. The European ECSS series of standards for the aerospace industry includes portability requirements asone of sixteen types of non functional requirements (NFR) for embedded and real-time software. A number ofportability-related concepts are dispersed throughout the ECSS, IEEE-830, ISO 9126, ISO 24765, and ISO2382-1 standards to describe, at varying levels of detail, the various types of candidate portability requirementsat the system, software, and hardware levels. This paper organizes these dispersed portability concepts andterms into a standards-based reference framework of system portability requirements. The availability of thisframework can facilitate the early identification and specification of the systemportability NFR and their detailedallocation as specific portability functions to be handled by the specified allocation to hardware or software, or aspecific combination of the two. The approach selected in this research for the structure of this reference frame-work is based on the generic model of software proposed in the COSMIC-ISO 19761model, thereby allowing thefunctional size of the portability requirements allocated to software to be measured.

© 2013 Elsevier B.V. All rights reserved.

1. Introduction

In the system requirements phase, the focus is often on detailing anddocumenting the system functional requirements (FR) and their alloca-tion to the software and hardware parts of the system being designed.Non-functional requirements (NFR) play a critical role in system devel-opment, including their use as selection criteria for choosing among al-ternative designs and ultimate implementations. NFR may also have aconsiderable impact on project effort, and should be taken into accountfor estimation purposes and when comparing project productivities.

Typically, these NFR are described at the system level, not at thesoftware level, and as yet there is no consensus on how to describeand measure them. In practice, they may be viewed, defined,interpreted, and evaluated differently by different people, particularlywhen they are stated briefly and vaguely [1–3]. It is a challenge,therefore, to take NFR into account in software estimation and soft-ware benchmarking, and they are definitely less well understoodthan other cost factors [2,4,5]. Without measurement, it is not aneasy matter to take them as quantitative inputs to an estimation pro-cess or to productivity benchmarking.

In practice, requirements are initially addressed at the system level[6–8], either as high level system functional requirements (system-FR)or as high level system NFR (system-NFR). Normally, such high-level

rights reserved.

requirements must then be detailed and allocated to specifics-relatedfunctions, which may be implemented in hardware or software as soft-ware functional user requirements (software-FUR), for instance — seeFig. 1.

System-FR describe the functions required in a system, whilesystem-NFR describe how those functions must behave in the system[9,10]. In the software requirements engineering step, system-NFR maythen be detailed and specified as software-FUR, to allowa software devel-oper to develop, test, and configure the final deliverables to system users.

Functional requirements are the functions that the system (includingthe software) is to offer, while NFR detail the manner in which thosefunctions are performed. FR are described using subject or predicate con-structions (i.e. noun/verb), such as: “The system can run on two or morekinds of devices, or with two or more kinds of operating systems.” NFRare described using adverbs or modifying clauses, such as: “The systemcan run on two ormore kinds of devices, orwith twoormore kinds of op-erating systems, that are easily or conveniently transported.”

Within the European standards for the aerospace industry (ECSS)[11–15], ISO 9126 [16], IEEE-830 [17], ISO 24765 [18], and ISO 2382-1[19], a number of concepts are provided to describe various types ofcandidate portability requirements at the system, software, and hard-ware levels. However, these standards vary in their views, terminology,and portability coverage.

Currently, there exists no reference framework for the identifica-tion and specification of system portability-NFR from the variousviews documented in international standards or in the literature.

http://dx.doi.org/10.1016/j.csi.2012.11.003

mailto:[email protected]

http://dx.doi.org/10.1016/j.csi.2012.11.003

http://www.sciencedirect.com/science/journal/09205489

System-NFR

Software-FUR

System-FR

Fig. 1. Mapping system requirements to software-FUR.

381A. Abran et al. / Computer Standards & Interfaces 35 (2013) 380–395

Consequently, it is also challenging to measure them when they areallocated as software-FUR and to take them into account quantita-tively for estimation purposes.

This paper focuses on a single type of system-NFR, that is, systemportability requirements. It reports on the work carried out to define areference framework for system portability-NFR based on internationalstandards. The approach adopted in this research for the structure ofthis portability reference framework is based on the generic model ofsoftware proposed in the COSMIC-ISO 19761 [20] standard for themea-surement of software functional size. This approach has been used tobuild other reference frameworks for other types of system-NFR, suchas maintainability, interfaces, and reliability requirements [21–27].

The paper is organized as follows. Section 2 presents related work.Section 3 presents a generic view of software-FUR, as provided in ISO19761. Section 4 identifies the standards that describe portability re-quirements. Section 5 presents the proposed framework for systemportability-NFR. Section 6 presents an example of a detailed referenceframework in a Service Oriented Architecture (SOA) context. Section 7presents an application of this reference framework for measurementpurposes, including a generic instantiation and a specific case study ofsystem portability requirements allocated as software-FUR. Finally, adiscussion and a conclusion are presented in section 8.

2. Related work

In the literature on NFR in systems/software engineering, Moreiraet al. [28], Rosa et al. [29], Park et al. [30], and Glinz [31] proposemethods for classifying NFR early in the software development process,while Kaiya et al. [32] have presented a method for identifying stake-holders and their NFR preferences by means of use case diagrams ofexisting systems. In addition, Paech et al. [33] recommend that FR,NFR, and architecture be tightly co-developed and addressed in a coher-ent and integrated manner, suggesting that NFR be decomposable intomore refined NFR and additional FR, as well as architectural decisions.

More recently, Mylopoulos [34] has promoted Goal-Oriented Re-quirements Engineering, and suggested a specific solution involvingthe establishment of what he calls an Agent-Oriented Software Devel-opment Method, called the Tropos project, which covers not only

Fig. 2. Generic flow of data groups through software from a functional perspective inCOSMIC-ISO 19761 [20].

requirements, but also design phases, and addresses the design ofhigh-variability software for applications such as home care and busi-ness process design.

More recently still, Kassab et al. [35] have proposed solutions for anNFR framework; for example, a sequence of systematic activities with aview to early consideration of identifying, specifying, and separating FRfrom NFR, as well as a discussion on NFR prioritization and risk assess-ment. They also report in [36] an initial solution for determining thefunctional size of NFR based on “soft goal” concepts, using the COSMICmethod, to deal with the problem of quantitatively assessing the NFRmodeling process early in a project.

Some of the early researchers published in the literature on NFR,such as Chung in 1993 [37], present the initial attempts to captureknowledge in this domain. His work was followed by that ofMylopoulos et al. [38], who suggested viewing all requirements asgoals, each goal being an umbrella for related requirements, both func-tional and non functional. Chung [37] aimed tomake NFRmore quanti-tative in nature, while Andrew [39] found that there are often gapsbetween the stakeholder vision and requirements representation.Chung et al. [40] proposed a taxonomy for NFR, indicating that it is un-realistic to expect designers and developers to incorporate an entitythat they cannot readily identify. While taxonomies aim to be inclusiveof the entire set of entities in question, these authors suggested in [40]that a one- or two-level taxonomy would suffice initially, and thatthere are over 161 identifiable types of NFR.

There exist a few more recent references on non functional re-quirements, but not specifically on the portability NFR (see [41] onsecurity NFR), or for limited domains of applicability (such as ServiceOriented — see [42], or the telecom industry — see [43]).

In parallel with the work of researchers, the software industry hasbeen working on the description of NFR, in particular through interna-tional standardization bodies, such as the European Cooperation onSpace Standardization (ECSS), the Institute of Electrical and ElectronicsEngineers (IEEE), and the International Organization for Standardiza-tion (ISO).

In the ECSS standards [11–15], system portability requirements areidentified as one of sixteen types of NFR, and the research reportedhere focuses strictly on these portability-NFR. In addition, in the ISO9126 [16] and IEEE 830 [17] standards, a number of implicit conceptsare provided to describe various types of candidate system portabilityrequirements at the system and software levels in the testing and eval-uation processes.

However, these standards vary in their views, terminology, and cov-erage of portability. Currently, there exists no reference model for theidentification and specification of system portability-NFR based on thevarious views documented in these international standards and in theliterature.

In the work reported here, preference has been given to the views,concepts, and vocabulary most widely used by the industry, asevidenced in its standardization infrastructure, rather than those inthe academic literature. Similarly, for the structuring, description,and measurement of the system-NFR allocated as software-FUR, themeasurement views, concepts, and terminology from the standardi-zation infrastructure have been adopted, rather than those in theliterature.

3. A generic view of software in ISO 19761

It is specified in ISO14143-1 [44] that a functional sizemeasurement(FSM) method must measure software-FUR. More specifically, COSMICISO-19761 [20] proposes a generic model of software-FUR that clarifiesthe boundary between hardware and software. Fig. 2 illustrates the ge-neric flow of data fromhardware to software froma functional perspec-tive. From this generic model of software functional requirements,shown in Fig. 2, we observe the following:

Table 1Portability view and vocabulary in the ECSS standards series.

Key view Concepts and vocabulary

The capability of the system to be transferred fromone environment to another

• Minimum systemdependency• Independence of theoperating system• Minimum hardwaredependency• Obsolescence ofhardware or software• Technical specification ofcomponents

Table 2Portability view and vocabulary in IEEE-830.


Describe portability by specifying the attributesof software that relate to the ease of portingthe software to other host machines and/oroperating systems

• Percentage of componentswith host-dependent code• Percentage of code that ishost-dependent• A proven portable language• A particular compiler or lan-guage subset• A particular operating system

Table 5Portability view and vocabulary in ISO 2382-1.


A program to be executed on various types ofdata processing systems

• Language independence• Data processing system• Isolation of softwaresystem calls

Table 4Portability view and vocabulary in ISO 24765.


A system or component that can be transferredfrom one hardware or software environmentto another.

• Software environment• Hardware environment

382 A. Abran et al. / Computer Standards & Interfaces 35 (2013) 380–395

1. Software is bounded by hardware. In the so-called front-end direc-tion (i.e. the left-hand side in Fig. 2), software used by a humanuser is bounded by I/O hardware, such as a mouse, a keyboard, aprinter, or a display, or by engineered devices, such as sensors or re-lays. In the so-called back-end direction (i.e., the right-hand side ofFig. 2), software is bounded by persistent storage hardware, like ahard disk, and RAM and ROM memory.

2. The software functionality is embedded within the functional flowsof data groups. Such data flows can be characterized by four distincttypes of data movements. In the front-end direction, two types ofmovements (E: ENTRIES and X: EXITS) allow the exchange of datawith the users across a ‘boundary’. In the back-end direction, twotypes ofmovements (R: READS andW:WRITES) allow the exchangeof data with the persistent storage hardware.

3. Different abstractions are typically used for different measurementpurposes. In real-time software, the users are typically theengineered devices that interact directly with the software; that is,the users are the I/O hardware. For business application software,the abstraction commonly assumes that the users are one or morehumanswho interact directly with the business application softwareacross the boundary, i.e. the I/O hardware is ignored.

4. Identification of standards describing portability requirements

This section presents a survey of the portability-related views, con-cepts, and terms used in international standards.

Table 3Portability view and vocabulary in ISO 9126.

Key views • Concepts and vocabulary

• The capability of the software product to betransferred from one environment to another

• An environment that may include theorganizational, hardware, or softwareenvironments

• Sharing of common resources• Independence of softwarein a common environment• Continued use of data• Function inclusiveness• Software runningconcurrently with othersoftware• Replaceability• Co-existence

4.1. ECSS standards: view and vocabulary for portability

The European Cooperation for Space Standardization (ECSS) pub-lishes standards targeting contractors working for the European SpaceAgency (ESA). The ECSS standards series includes a number of portabilityrequirements at the system level. It can be observed that the ECSS focuseson the system-FR for the early development phases, while thesystem-NFR are typically discussed in the context of later developmentphases, such as evaluation or testing.

Portability in the ECSS standards is considered as the capability of thesystem to be transferred from one environment to another. Table 1 pre-sents a list of concepts and vocabulary used in the ECSS standards to de-scribe system-related portability requirements. For instance, the ECSSspecifiesminimumdependency on software and hardware (systempor-tability) and independence of the operating system from hardware andsoftware obsolescence. What it does not specify, however, is whether ornot such requirements must be implemented in software or hardware,or a combination of the two.

While conducting a survey of all the portability concepts and termsdescribed in the ECSS-E-40 and ECSS-Q series, and in ECSS-ESA as theintegrated standard for ECSS-E and ECSS-Q, we observed that:

1. These various portability elements are described differently, and atdifferent levels of detail.

2. The portability elements are dispersed throughout the variousdocuments; therefore, there is no integrated view of all types ofcandidate portability requirements.

3. There is no obvious link for the portability requirements betweenthe ECSS-ESA standard as the integrated standard and all theother ECSS standards that describe portability requirements.

4.2. IEEE-830: view and vocabulary for portability

IEEE-830 [17] lists portability as one of the NFR on their list. The IEEEdescribes portability by specifying the attributes of software that relate to

Table 6System portability requirements in ECSS, ISO, and IEEE.

• Independence of the operating system• Independence of the middleware• Independence of the programming language virtual machine• Independence of browsers• Independence of the database• Distributed Database Management System (DDBMS)• Independence of the client• Independence of the server• Independence of storage• Independence of the network• Isolation of software system calls

Table 7Types of portability requirements, by environment.

Environment 1 Environment n

–Software Components inEnvironment 1

–Software Components in Environment n

○ Independence of the operatingsystem

○ Independence of the operatingsystem

○ Independence of themiddleware

○ Independence of the middleware

○ Independence of theprogramminglanguage virtual machine

○ Independence of the programminglanguagevirtual machine

○Independence of browsers ○ Independence of browsers–Data Components inEnvironment 1

–Data Components in Environment n

○ Independence of the database ○ Independence of the database○ Distributed Data BaseManagementSystem (DDBMS)

○ Distributed Data Base ManagementSystem (DDBMS)

–Hardware Components inEnvironment 1

–Hardware Components inEnvironment n

○ Independence of the client ○ Independence of the client○ Independence of the server ○ Independence of the server○ Independence of storage ○ Independence of storage○Independence of the network ○Independence of the network

Independence of the Operating System Function (IOSF)

Independence of the Middleware Function (IMF)

Independence of the Programming Language Virtual Machine

Function (IPLVMF)

Independence of the Browser Function (IBF)

PersistentStorage

Fig. 3. Software Component Portability functions: system modeling view.


the ease of porting the software to other host machines and/or operatingsystems, and provides some portability concepts— see Table 2. However,the IEEE does not provide guidance on how to describe or specify porta-bility requirements.

4.3. ISO 9126: views and vocabulary for portability

The key view on portability in the ISO 9126 series is from theperspective of the quality of the software product: portability ispresented as a ‘quality characteristic’, then decomposed into qual-ity sub-characteristics, and finally into proposed derived measuresto quantify those quality sub-characteristics. The inventory ofrelated concepts and vocabulary on software portability, such asreplaceability and co-existence, is presented in Table 3.

Table 8Function types and functions for portability requirements thatmay be allocated to software.

Functiontype

Function type name Portability functions

1 Software ComponentPortability

• Independence of the OperatingSystemFunction (IOSF)• Independence of the MiddlewareFunction (IMF)• Independence of the ProgrammingLanguageVirtual Machine Function (IPLVMF)• Independence of the BrowserFunction (IBF)

2 Data Component Portability • Independence of the DatabaseFunction (IDF)• Distributed Data Base ManagementSystem Function (DDBMSF)

3 Hardware ComponentPortability

• Independence of the Client Function(ICF)• Independence of the Server Function(ISF)• Independence of the Storage Function(ISTF)• Independence of the NetworkFunction(INF)

4 Isolation of System CallsPortability

• Isolation of Software System CallsFunction (ISSCF)

4.4. ISO 24765: view and vocabulary for portability

Portability in ISO 24765 [18] is considered as a system or compo-nent that can be transferred from one hardware or software environ-ment to another. Table 4 presents the concepts and vocabulary usedin ISO 24765 to describe system-related portability requirements.While ISO 24765 states that portability in a system environment re-fers to a transfer between software and hardware, it does not specifywhether portability requirements must be implemented in the soft-ware or the hardware, or in a combination of the two. Moreover,ISO 24765 does not provide guidance on how to describe or specifyportability requirements.

4.5. ISO 2382-1: view and vocabulary for portability

Portability in ISO 2382-1 [19] is described as a program to be executedon various types of data processing systems. Table 5 presents a list of the

Fig. 4. Software Component Portability functions: COSMIC modeling view.

image of Fig.�3

Fig. 5. Isolation of System Calls Portability: system modeling view.


concepts and vocabulary used in ISO 2382-1 to describe system-relatedportability requirements. For instance, this standard refers to the porta-bility between a program and a sub part of that program (sub pro-gram) when this program is executed using different dataprocessing systems and system program calls (SPC) or remote pro-cedural calls (RPC) between the program and sub program func-tions, independently of the language. It does not, however, specifywhether such requirements must be implemented in the softwareor the hardware, or in a combination of the two. Moreover, ISO2382-1 does not provide guidance on how to describe or specifythe portability requirements.

5. A standards-based definition of a reference framework forsystem portability requirements

This section maps the portability terminologies found through-out the ECSS, IEEE, and ISO standards into a proposed referenceframework for system portability-NFR, through the use of the ge-neric model of software proposed in the COSMIC-ISO 19761model in Fig. 2. This COSMIC-based generic model can then formthe structure of a framework for describing the system portabilityrequirements.

Fig. 6. System modeling view for sy

5.1. Mapping views and concepts for portability from ECSS, ISO, and IEEEstandards

Based on a synthesis of the various definitions, views, and vocabu-lary presented in the previous section, a list of system portability-NFRis presented in Table 6. It is important to note that Table 6 includes soft-ware, data, and hardware components which are interconnected. If thesystem can run on two or more kinds of devices, or with two or morekinds of operating system that are easily or conveniently transported,then system portability is achieved. So we consider these componentsas environments for the system portability-NFR.

If the system can run on two or more kinds of device, or with two ormore kinds of operating system that are easily or convenientlytransported, we consider these components as environments for thesystem portability-NFR. Then, portability requirements must be identi-fied for each environment (from environment 1 to environment n)when required, and software components, hardware components, anddata components must be allocated to each environment— see Table 7.

These portability functions can be divided into four function types,three of them specified for portability components (software, data,and hardware components) and the fourth for portability environ-ments: Table 8 illustrates these portability function types, based onspecified portability functions. Each function type is discussed in moredetail in the next subsections, first from a system viewpoint, and thenfrom a COSMIC viewpoint.

5.2. Component portability (Function Types 1 to 3): system and COSMICmodeling views

Fig. 3 presents a system modeling view (i.e. a high-level view) ofthe data flows (filled and broken arrows) for the Software Compo-nent Portability functions (Function Type 1):

1. Independence of the Operating System Function (IOSF): a set of rou-tine and program functions that control a system's resources and

stem portability requirements.

image of Fig.�5

image of Fig.�6

1-Software Component Portability2-Data Component Portability

3-Hardware Component Portability

4-Isolation of System Calls Portability

E X

XE

E X

XE

E X

XE

E X

XE

Isolation of Software System Calls Function(ISSCF)

Persistent Storage



Independence of the Programming Language Virtual Machine Function

(IPLVMF)


INTERMEDIARY

Service(IS)

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

R

W

R

W

R

W

R

W

Persistent Storage

Independence of the Client Function (ICF)

Independence of the Server Function (ISF)

Independence of the Storage Function (ISTF)

Independence of the Network Function (INF)

INTERMEDIARY

Service(IS)

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

R

W

R

W

R

W

R

W

E X

XE

E X

XE

Persistent Storage

Independence of the Database Function (IDF)

Distributed Database Management System Function (DDBMSF)

RW

RW

E X

XE

E X

XE

Intermediary Service

Portability Functional Type 1Portability Functional Type 2Portability Functional Type 3Portability Functional Type 4

Boundary

Functional Process

Direct Data Movements (E) ENTRY (X) EXIT

Indirect Data Movements(R) READ (W) WRITE

Persistent St

E X

XE

E X

XE

Fig. 7. COSMIC reference framework of system portability requirements that may be allocated to software.


provide access to its services, i.e. Windows 7, Windows 8, Mac andOSx10.7.

2. Independence of the Middleware Function (IMF): a set of servicesthat allows the multiple functional processes used to connect sys-tem software components to be run on one or more machines inorder to interact. Middleware independence sits “in the middle,”between application software programs that may be working ondifferent independent operating systems, e.g. Android 4.0, andHLA (high level architecture).

3. Independence of the Programming Language Virtual MachineFunction (IPLVMF): provides support for the execution of the com-plete independence of one or more operating systems (OS) in thesame machine, e.g. JVM.

4. Independence of the Browser Function (IBF): a user interface on asystem machine that permits the navigation of objects on theapplication layer, e.g. IE (Internet Explorer).

The relationships between these functions are many-to-many,using intermediary services to complete their functions. IOSF, IMF,IPLVMF, and IBF use:

1. Intermediary services (symbol in Fig. 3: ) for the interaction oftheir functional services, to provide the functional user with theirfunctionality.

2. The same persistent storage to share their system resources datafor the intermediary services used.

Unlabelled image


Fig. 4 illustrates a COSMIC modeling view of the data movementsfor the software component portability function (Function Type 1):

1. IOSF, IMF, IPLVMF, and IBF send and receive data groups to connecttheir service functionalities with another one using an intermedi-ary service.

2. IOSF, IMF, IPLVMF, and IBF read data groups about other servicesfrom persistent storage and write their results as data movementsto the same persistent storage on the system.

The persistent storage and the intermediary services for IOSF, IMF,IPLVMF, and IBF may be used by other Portability Function Types (notillustrated in Fig. 4).

Similar system and COSMIC modeling views can be built for thedata and hardware component portability requirements (FunctionTypes 2 and 3).

5.3. Isolation of system calls portability (Function Type 4): system andCOSMIC modeling views

The relationships between the Isolation of System Calls PortabilityFunction (Function Type 4) and the other functions in Function Types 1to 3 are many-to-many, using intermediary services to complete theirfunctionalities. Fig. 5 presents a system modeling view (i.e. a high-levelview) of the data flows for the Isolating System Calls Portability Function(Function Type 4):

1. Isolating Software System Calls Function (ISSCF): the functionalitymechanism used by an application to request a service from theoperating system (OS). The ISSCF often uses a special machinecode instruction which causes the processor to change mode.This allows the OS to perform restricted actions, such as accessinghardware devices or memory management.

2. The ISSCF provides a control interface between the hardware, soft-ware, and data components of a system. It sits between the OS andthe application to increase the portability of the system, becausemost of the system portability operations interacting with the sys-tem require permissions not available to a user level in FunctionTypes 1, 2, and 3. The ISSCF uses intermediary services (symbolin Fig. 4) for their functional services interaction.

5.4. Reference framework for system portability-NFR

Fig. 6 presents the standards-based reference framework for sys-tem portability-NFR, which is composed of 11 portability functionsgrouped into four function types.

1. The sub model of Software Component Portability (Function Type1) can be used to specify the data flows between the four functionsfor the system software components, and the data flows with otherfunctions in the system portability model — see the upper-leftquadrant in Fig. 6.

2. The sub model of Data Component Portability (Function Type 2)can be used to specify the data flows between two functions forthe system data components and the data flows with other func-tions in the system portability model — see the upper-right quad-rant in Fig. 6.

3. The sub model of Hardware Portability (Function Type 3) can be usedto specify the data flows between the four functions for the systemhardware components and the data flows with other functions in thesystem portability model — see the lower-left quadrant in Fig. 6.

4. The sub model of Isolation of System Calls Portability (FunctionType 4) can be used to specify the data flows between the threeSystem Portability Function Types 1, 2, and 3, where each commu-nication performed between system portability functions requiresthe use of ISSCF — see the lower-right quadrant in Fig. 6.

Fig. 7 presents the COSMIC view of the data movements across the11 portability functions within the 4 function types illustrated inFig. 6. More specifically:

1. The sub model of Software Component Portability (Function Type1) can be used to specify (and measure the functional size of) thesystem software components from the received/sent data groupsfrom/to the IOSF, IMF, IPLVMF, and IBF — see the upper-left quad-rant in Fig. 7.

2. The sub model of Data Component Portability (Function Type 2) canbe used to specify (and measure the functional size of) the systemdata components from the received/sent data groups from/to theIDF and DDBMSF — see the upper-right quadrant in Fig. 7.

3. The sub model of Data Component Portability (Function Type 3)can be used to specify (and measure the functional size of) the sys-tem hardware components from the received/sent data groupsfrom/to the ICF, ISF, ISTF, and INF — see the lower-left quadrantin Fig. 7.

4. The sub model of the Isolation of System Calls Portability (FunctionType 4) can be used to specify (and measure the functional size of)the ISC from the received/sent data groups from/to the ISSCF— seethe lower-right quadrant in Fig. 7.

6. Example of a detailed reference framework in a service orientedarchitecture (SOA) context

6.1. COSMIC-SOA guidelines

The reference framework proposed in Fig. 6 describes the impor-tant concepts and relationships for system portability requirements,as defined in particular in the ECSS international standards: it is con-sidered a high-level model of requirements that helps explain, andposition, the variety of portability-related functions described at thesystem level in the ECSS, IEEE, and ISO standards. However, in prac-tice, such a high-level model typically does not include detailed infor-mation documenting the required data groups necessary tounambiguously identify the specific corresponding data movements.Further complicating the specification task is that much of the porta-bility functionality could be allocated, for example, as services acrossa number of peer applications within a software system. To tackle thislevel of detail, the COSMIC group has published a document providingguidelines for functional size measurement in the context of aservice-oriented architecture — SOA [45]. The COSMIC-SOA modelfrom ref. [45] is used in this section to provide a detailed specificationmodel for system portability which can be used to specify and mea-sure the functionality described in Fig. 7.

In this section, a COSMIC reference architecturalmodel using an SOAis built to illustrate what is involved in instantiating the referenceframework in practice.

There are many definitions of an SOA, such as:

1. A flexible set of design principles used during systems develop-ment and integration [45]; or

2. A process including the definition of the architecture, components,modules, interfaces, and data for a system to satisfy specified re-quirements [44,45].

The COSMIC-SOA architectural model provides a loosely integratedsuite of services that can be used in multiple business domains to mea-sure the functional size of software-FUR in an SOA environment [45]. Inthis model, the term “service” refers to a set of related software-FURfunctions.

The SOA for COSMIC offers three types of data architecture move-ments based on [45]:

1. COSMIC-SOA exchange messages — see Fig. 8.2. COSMIC-SOA intermediary services — see Fig. 9.

Fig. 8. The interactions between an application and a service [45].

Fig. 9. Application services and an interconnecting.


3. COSMIC-SOA data exchanges between system components — seeFig. 10.

These are discussed below.

6.2. COSMIC-SOA exchange messages for system portability

The COSMIC reference framework of system portability is composedof a set of functions— see Fig. 6. These functions, according to the SOA,provide functional users with a set of services by exchanging messagesin the application layer and a service between two peer pieces ofsoftware-FUR.

In an SOA, an application requiring commonly used informationfrom another application sends a request to the service of the applica-tion that can handle the request, or the application may call upon itsown services. Such a call is also called a “message”. Each message mayconsist of one or more data movements [45].

The model for a common form of message exchange between anapplication and a service is shown in Fig. 8 [45]. It uses the COSMIC ref-erence framework of portability requirements allocated to software forthe exchange of data between two peer pieces of software [45].

6.3. COSMIC-SOA intermediary services for system portability

When a functional process of an application service in applicationA requires data that are available via an application service in applica-tion B, the former application service calls upon a functional processof the intermediary service. This service functionality is also needed

Fig. 10. Direct and indirect exchanges of data between services in peer components[45] intermediary service [45].

by other applications in the overall SOA framework, as it may itselfbe realized in the form of a utility service [45] — see Fig. 9.

6.4. COSMIC-SOA data exchanges for system component portability

Fig. 10 [45] shows the possible flows of data movements betweencomponents in the same layer, i.e. between peer components (wherea component may be an application or a service). It shows direct andindirect exchanges of data between components — one or both formsmay be involved when services communicate. If componentsexchange data directly, then, for measurement purposes, the measur-er will identify Exit and/or Entry data movements, as per the datamovements between service A (SA) and service B (SB). An indirectexchange of data between components means that a service in onecomponent writes data to a storage device, which is subsequentlyread by a service in another component. In this situation, the measur-er will identify a Write data movement in service SA and a Read datamovement in service SB.

6.5. COSMIC reference architectural model using an SOA for systemportability

Fig. 11 presents a COSMIC reference architectural model using anSOA for system portability requirements. This model is built basedon Fig. 7 and the role of the COSMIC-SOA explained in [45] and inFigs. 8 to 10.

The lower-right quadrant of Fig. 11 presents the legend for this figure. Forinstance, the symbol is used to represent the intermediary services, arrowsrepresent datamovements, etc.

This COSMIC-SOA reference architectural model also helps mea-surers of services by separating functions into distinct units, or services.These services communicate with each other by exchanging data in awell-defined, shared format, or by coordinating an activity betweentwo or more services [45].

The COSMIC reference framework of systemportability requirementsin Fig. 7 is considered a high-level model of requirements, while theCOSMIC reference architectural model using an SOA in Fig. 11 describesa detailedmodel that can be used to specify andmeasure the functional-ity described in Fig. 11 when allocated to software-FUR

7. Application of the reference framework for measurementpurposes

This section presents two examples of an application of thestandards-based reference framework of system portability-NFR. The

image of Fig.�9

image of Fig.�10

1-Software Component Portability 2-Data Component Portability

4-Isolation of System CallsPortability

3-Hardware Component Portability


Portability Functional Type 1Portability Functional Type 2


Boundary

Functional Process or

Service

Direct Data Movements(E) ENTRY (X) EXIT


Persistent Storage

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

Isolation of the SoftwareSystem Calls Service

(ISSCS)

Persistent Storage

Independence of the Operating System Service (IOSS)

Independence of the Middleware Service (IMS)

Independence of the Programming Language Virtual Machine Service

(IPLVMS)

Independence of the Browser Service(IBS)

INTERMEDIARY

Service(IS)

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

R

W

R

W

R

W

R

W

Persistent Storage

Independence of the Client Service (ICS)

Independence of the Server Service (ISS)

Independence of the Storage Service (ISTS)

Independence of the Network Service (INS)

INTERMEDIARY

Service(IS)

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

R

W

R

W

R

W

R

W

E X

XE

E X

XE

Persistent Storage

Independence of the Database Service (IDS)

Distributed Database Management System Service

(DDBMSS)

RW

RW

E X

XE

E X

XE


Independence of Middleware

Function (IMF)

Independence of the Programming Language Virtual Machine Function (IPLVMF)

E X

XE

E X

XE

E X

XE


E X

XE


Independence of Server Function (ISF)



E X

XE

E X

XE

E X

XE

E X

XE


E X

XE

E X

XE

Distributed Database Management System Function

(DDBMSF)

Isolation of the Software System Calls Function (ISSCF)

E X

XE

IS1IS2

IS2IS3

IS3IS4

IS4IS5

IS5IS6

IS6IS7

IS7IS8

IS8IS9 IS9IS10

IS10IS11

Fig. 11. COSMIC-SOA reference architectural model of system portability requirement.


first example presents a generic example, where all the portability-NFRfunctions in an SOA context would be allocated to software. The secondexample presents a case study where only a specific subset of the refer-ence framework of system portability-NFR is allocated to software.

7.1. Sizing a generic instantiation of the reference framework in an SOAcontext

The specification of software-FUR for system portability in anyspecific project is a specific instantiation of the proposed referenceframework described in Fig. 11. When the software specificationdocument is at the level of the movement of data groups, thenthese functional requirements can be directly measured using theCOSMIC measurement rules. The measurement example presented

next is illustrative of a reference instantiation of the genericCOSMIC specification and measurement model of software-FUR forsystem portability in an SOA context for a single data group for allthe possible types of flows of data groups identified.

This generic instantiation of the reference framework for systemportability (i.e. an instantiation of Fig. 11) is the specification of asingle instance (i.e. a particular use) of the system portability-NFRat the abstraction level of the functionality and services describedas data movements, in alignment with the COSMIC rules andprinciples.

The measurement example in this section explains how to usethe proposed reference framework of system portability to size a hy-pothetical example composed of all 11 portability functions describedin the reference framework.

image of Fig.�11

Table 9COSMIC-SOA measurement example for the interactions between a functional processand its own service process.

COSMIC-SOA typesData Movementdescription

Data movementtype

Functionalprocess

Serviceprocess

Independenceof theOperatingSystemFunction (IOSF)

Independenceof theOperatingSystemService(IOSS)

• IOSF sends a data group toIOSS

X

• IOSS receives a data groupfrom IOSF

E

• IOSS sends a data group toIOSF

X

IOSF receives a data groupfrom IOSS

E

Functional Size (subtotal):4 CFP

Table 11COSMIC-SOA measurement example for an intermediary service between a functionalprocess with its own functional service process.

COSMIC-SOA intermediaryservices

Data Movementdescription

Datamovementtype

Serviceprocess

Serviceprocess

Independencethe ofOperatingSystemService(IOSS)

Independencethe ofMiddlewareService(IMS)

• IOSS sends a data group to IS1IS2 X• IS1IS2 receives a data group fromIOSS

E

• IS1IS2 sends a data group to IMS X• IMS receives a data group fromIS1IS2

E

• IMS sends a data group to IS1IS2 X• IS1IS2 receives a data group fromIMS

E

• IS1IS2 sends a data group to IOSS X• IOSS receives a data group fromIS1IS2

E

Functional Size (subtotal) 8 CFP

Note: IS1IS2 is the first intermediary service in Table 12.


7.1.1. Measurement of exchange services for system portability functionalityusing COSMIC-SOA

According to COSMIC-SOA, each functional process may interactwith its own services by sending and receiving data movements, i.e.Entry and Exit— see Fig. 8. For example, the functional process IOSF in-teracts with its own service process, IOSS. The measurement result forthis operation is equal to 4 CFP for each interaction between a functionalprocess and its own functional service process — see Table 9.

There are 11 system portability function types, each of which inter-actswith its own services, for themeasurement of exchange services forsystem portability using COSMIC-SOA— see Fig. 11. Table 10 illustratesthe COSMIC-SOA total measurement results for interactions betweenthe 11 system portability functional processes and their own serviceprocesses. The total functional size is equal to 44 CFP — see the yellowshaded arrows in Fig. 11.

Table 10COSMIC-SOA measurements of the interactions between the 11 functional processesand their service processes.

FunID

COSMIC-SOA Types of exchange services for System Portability No. of datamovements

Functional Process Service Process

1 Independence of theOperating SystemFunction (IOSF)

Independence of theOperating SystemService (IOSS)

4

2 Independence of theMiddleware Function(IMF)

Independence of theMiddleware Service (IMS)

4

3 Independence of theProgramming LanguageVirtual MachineFunction (IPLVMF)

Independence of theProgramming Language VirtualMachine Service(IPLVMS)

4

4 Independence of theBrowser Function (IBF)

Independence of theBrowser Service (IBS)

4

5 Independence of theDatabase Function (IDF)

Independence of theDatabase Service (IDS)

4

6 Distributed DatabaseManagement SystemFunction (DDBMSF)

Distributed Data BaseManagement SystemService (DDBMSS)

4

7 Independence of theClient Function (ICF)

Independence of theClient Service (ICS)

4

8 Independence of theServer Function (ISF)

Independence of theServer Service (ISS)

4

9 Independence of the StorageFunction (ISTF)

Independence of theStorage Service (ISTS)

4

10 Independence of theNetwork Function (INF)

Independence of theNetwork Service (INS)

4

11 Isolation of the SoftwareSystem Calls Function(ISSCF)

Isolation of the SoftwareSystem Calls Service(ISSCS)

4

Functional size 44 CFP

7.1.2. Measurement of intermediary services for system portabilityservices using COSMIC-SOA

In this section, and based on Fig. 9, when a functional process ser-vice requires data that are available via another functional processservice, the former calls upon a functional process of the intermediaryservice. According to the COSMIC-SOAmodel of measurement for sys-tem portability, the types of data movements required for using theintermediary service are the Entry and the Exit — see Fig. 9.

Table 11 illustrates a measurement example of the data move-ments for one intermediary service of Function Type 1 in Fig. 11(red shaded arrows). For this portability requirement, the measure-ment results are equal to 8 CFP (this example will correspond to thefirst line in Table 12 for IS1IS2, for example).

Tables 12 to 15 illustrate the COSMIC-SOA measurement resultsfor intermediary services for portability Function Types 1 to 4 — seethe red shaded arrows in Fig. 11. These tables present an instantiationof the data movements of a single data group for all the possible flowsof the data groups identified in Fig. 11 to achieve a high level of por-tability between components, while Table 11 provides a COSMIC-SOA

Table 12COSMIC-SOA: measurement of intermediary services for software componentsportability-NFR (function Type 1 in Fig. 11).

IS ID COSMIC-SOA intermediary services No. of datamovements

Functional process Functional process

IS1IS2orIS2IS1

Independence of theOperating System Service(IOSS)


8

IS1IS3orIS3IS1


Independence of theProgramming LanguageVirtual Machine Service(IPLVMS)

8

IS1IS4orIS4IS1



8

IS2IS3orIS3IS2



8

IS2IS4orIS4IS2



8

IS3IS4orIS4IS3



8

Functional Size 48 CFP

Table 13COSMIC-SOA: measurement for intermediary services for data componentportability-NFR (function Type 2 in Fig. 11).

IntermediaryserviceID

Number ofdatamovements

Functionalprocess

Functionalprocess

IS4IS5orIS5IS4

Independenceof the DatabaseService (IDS)

Distributed Data BaseManagement System Service(DDBMSS)

8


Table 15COSMIC-SOA: measurement for intermediary services for Isolation of System Callsportability-NFR (function Type 4 in Fig. 11).

IntermediaryServiceID

COSMIC-SOA Intermediary Services Number ofDataMovements

Functional Process Functional Process

IS8IS9 Isolation ofSoftware SystemCalls Service(ISSCS)

Independence of the OperatingSystem Service (IOSS)

8



8


Independence of theProgramming Language VirtualMachine Service (IPLVMS)

8


Independence of the BrowserService (IBS)

8


Independence of the DatabaseService (IDS)

8


Distributed Data BaseManagement System Service(DDBMSS)

8


Independence of the ClientService (ICS)

8


Independence of the ServerService (ISS)

8


Independence of the StorageService (ISTS)

8


Independence of the NetworkService (INS)

8

Functional size 80 CFP


measurement example for the intermediary service between a func-tional process and its own service process.

Based on the portability model in Fig. 11, the number of interme-diary services for Function types 1 to 4 is equal to:

1. 6, betweenPortability Function Type 1 process services, as illustratedin Table 12.



4. 10, between Portability Function Type 4 process services, as illustratedin Table 15.

Based on the portability design in Fig. 11, intermediary serviceIS1IS2 is equivalent to IS2IS1 through a transitive relationship, andsimilarly for the other intermediary services.

7.1.3. Measurement of direct and indirect data movements for systemportability services using COSMIC-SOA

This section is based on Fig. 10, which illustrates the possible flowsof data between components in the same layer, i.e. between peer com-ponents (where a component may be an application or a service). Thissection shows direct and indirect exchanges of data between compo-nents — one or both forms of which may be involved when servicescommunicate. If components exchange data directly, the measurer willidentify the Exit and/or Entry data movements, as per the data move-ments between service A and service B. An indirect exchange of data be-tween components means that a service in one component writes datawhich are subsequently read by a service in another component. In thissituation, the measurer will identify a Write data movement in the for-mer component and a Read data movement in the latter component.

Specifically, Table 16 illustrates COSMIC-SOA measurement resultsfor the exchange of data movements between the system portability re-quirementsmodel in a functional process or in service architecture layers

Table 14COSMIC-SOA: measurement for intermediary services for hardware componentportability-NFR (Function Type 3 in Fig. 11).

IntermediaryServiceID

COSMIC-SOA types of intermediary services betweenfunctional processes for System Portability FunctionType 3

Numberof datamovements

Functional process Functional process

IS5IS6 orIS6IS5



8

IS5IS7 orIS7IS5



8

IS5IS8 orIS8IS5



8

IS6IS7 orIS7IS6



8

IS6IS8 orIS8IS6



8

IS7IS8 orIS8IS7



8


— see Figs. 10 and 11. This table presents an instantiation of this opera-tion. Themeasurement results are equal to 20 CFP— see the green shad-ed arrows in Fig. 11.

The total functional size of the generic instantiation of the 11 por-tability functions in an SOA environment of services is therefore equalto adding the sizes from Tables 10, 12, 14, 15 and Table 16, that is, 240CFP.

7.2. Case study: valve control system (VCS)

7.2.1. VCS system requirementsTheValve Control System (VCS) case study [46] from the automotive

industry varies the timing of the intake valves by using the hydraulic oilpressure to rotate the camshaft in order to provide optimal air flow inand out of the engine. It is a closed loop system using camshaft sensors,crankshaft sensors, an air flowmeter, and a throttle position, as well asoxygen sensors and air fuel sensors. The system-FR of the VCS casestudy are documented at a high level in ISO 14143-4 [46], which pro-vides various sets of reference user requirements (RUR), usually de-scribed in a textual format.

A specific configuration of the VCS system functions allocated tohardware and software has been published by the COSMIC group,along with the measurement of the functional size of its software-FUR[47]. The VCS software requirements block diagram is reproduced in

Table 16COSMIC-SOA measurements for direct and indirect data groups for system portability.

COSMIC-SOA functions Data movement description Datamovementtype

Independenceof theOperating SystemFunction (IOSF)

• IOSF reads and writes a datagroup from/to persistent storage.

R & W

Independenceof theMiddleware Function(IMF)

• IMF reads and writes a datagroup from/to persistent storage.

R & W

Independenceof theProgramming LanguageVirtual MachineFunction (IPLVMF)

• IPLVMF reads and writes a datagroup from/to persistent storage.

R & W

Independenceof theBrowser Function (IBF)

• IBF reads and writes a datagroup from/to persistent storage.

R & W

Independenceof the DatabaseFunction (IDF)

• IDF reads and writes a datagroup from/to persistent storage.

R & W

DistributedData BaseManagement SystemFunction (DDBMSF)

• DDBMSF reads and writes a datagroup from/to persistent storage.

R & W

Independence of theClient Function (ICF)

• ICFF reads and writes a data groupfrom/to persistent storage.

R & W

Independence of theServer Function (ISF)

• ISF reads and writes a data groupfrom/to persistent storage.

R & W

Independence of theStorage Function (ISTF)

• ISTF reads and writes a data groupfrom/to persistent storage.

R & W

Independence of theNetwork function (INF)

• INF reads and writes a data groupfrom/to persistent storage.

R & W

Functional Size in CFP 20


Fig. 12: in this COSMIC case study, the software-FUR are specified andmeasured with a software functional size of 12 CFP, while thesystem-NFR are neither specified nor measured. The dotted lines inFig. 12 represent the software boundary.

The proposed standards-based reference framework of the systemportability-NFR is used to help the project stakeholders in the systemrequirements engineering phase, as follows — see Fig. 13:

1. Some of the portability requirements for the project, in this case theVCS, can be derived by the stakeholders from our reference frame-work of systemportability-NFR,which could be allocated to softwareas portability-FUR.

2. Our reference framework for system portability-NFR lists specificportability functions derived from various standards.

Fig. 12. Block diagram of the hardware and software co

Its use with the Valve Control case study is illustrated through thefollowing steps:

1. Step 1: Specify some portability functionality requirements at the(high) system level of the VCS case study, using the proposed ref-erence framework.

2. Step 2: Allocate these system portability requirements as softwarefunctions to be added to some of the components of this VCSsystem.

3. Step 3: Measure the software-FUR for the system portability-NFRallocated to software.

7.2.2. Step 1: Specify some portability requirements at the system levelIn this example, the stakeholders request (in textual language)

four portability requirements (R1 to R4) at the system level, that is,the VSC system:

1. R1: shall be portable with different operating system services.2. R2: shall be portable with different storage services between VCS

components3. R3: shall be portable with the network services used in the system.4. R4: shall be portable with isolation of software system calls ser-

vices between VCS components

These portability requirements correspond to some of the 11 por-tability functions as described in the ECSS standards (see alsoTable 8), that is:

1. R1— Independence of the operating system function (top-left of Fig. 7)2. R2 — Independence of the storage function (next to bottom-left of

Fig. 7)3. R3 — Independence of the network function (bottom-left of Fig. 7)4. R4 — Isolation of the software system calls function (middle-right

of Fig. 7)

7.2.3. Step 2: allocate these system portability requirements to newsoftware functions in the VCS case study

For the purposes of this case study, the four system portability re-quirements are next allocated to the following VCS components— seeTable 17:

1. R1 (Independence of the operating system function): allocated tothe valve control software, i.e. the valve control software mustnow have an independence of operating system function (IOSF).

2. R2 (Independence of the storage function): allocated to the valvecontrol software, i.e. the valve control software must use the loaddata from the ROM, save other data in RAM (as temporarystorage), and store some data in permanent storage, as well assharing among all kinds of storage, to perform their tasks.

mponents of the Valve Control case study in [47].

Specific portabilityrequirements for the VCS

case study derived byproject stakeholders

Standards-basedreference framework ofsystem portability-NFR

Fig. 13. From reference system portability-NFR to specific portability-NFR for the VCScase study.


3. R3 (Independence of the network function): allocated to the valvecontrol software and to new software functions to be added to thesensors and valve control pieces of hardware, i.e. the valve controlsoftware, as well as the hardware for the sensors and the valvecontrol, must use network services from one to anotherindependently.

4. R4 (Isolation of the software system calls function): allocated tothe valve control software. This means that the valve control soft-ware must now provide a control interface between system hard-ware, software, and data for the VCS components to increase theportability of the updated VCS.

It is important to note that, with the above set of additional portabil-ity system-NFR, a number of new software functions must be specifiedand added to the VCS of the original case study, and to someof the hard-ware components that did not initially have any software functions al-located to them (e.g. to the sensor devices, and to the control valvethat, in the initial case study, was strictly hardware receiving a signalfrom the ‘valve control software’).

Fig. 14 presents, in color, the standards-based model of software-FUR for system portability for the updated VCS based in Fig. 11 andwith allocations in Table 17.

7.2.4. Step 4: Measurement of the software-FUR for the systemportability-NFR

Themeasurement viewpoint in this case study is that of the softwaredeveloper, who is interested in quantifying the system portabilityrequirements that have been added as new software functions to be de-veloped. The measurement purpose is to measure, using the COSMICmethod (ISO 19761), the entire set of added FUR coming from the sys-tem portability-NFR allocated to the software for this case study. Themeasurement scope is this set of the system portability-NFR require-ments, that is, only functions allocated to the software and not thoseleading to changes to the hardware itself.

Table 17The selected allocation of portability functions to the VCS components in this example.

Id. Standards-basedportabilityfunctions

Ri Softwarefunctionsallocated toexisting software

Software functions allocated tohardware in updatedhardware-software components

1 Independence ofthe OperatingSystem Function

R1 Valve controlsoftware

2 Independence ofthe StorageFunction


3 Independence ofthe NetworkFunction



R3 Sensors


R3 Control valve

6 Isolation of theSoftware SystemCall Function


When these portability requirements are specified using the struc-ture of the proposed standards-based model of software-FUR for thesystem portability-NFR, they are already aligned with the COSMICmodel of FUR, and the necessary information for measuring theirfunctional size is readily available.

For illustrative purposes, the following assumption is made in thiscase study: there is a single data group for each portability functionspecified (of course, for a portability function specified in an industri-al context, more than one data group may be needed). The totalfunctional size according to ISO 19761 for all the portability-relatedsoftware functions added to this updated VCS system is obtainedby adding all the data movements for each distinct portabilityfunction — see Fig. 14 and Table 18.

The bottom line of Table 18 presents the measurement results forthe system portability functions allocated to the new software func-tions for the updated VCS case study: 28 CFP.

Observations:

1. The software functional size in the initial VCS case study was 12CFP in ref. [47].

2. The software functional size for the added software functions re-quired to meet the system portability requirements is equal to 28CFP.

3. Therefore, the total software functional size of this new version ofthe VCS case study (including the added portability requirementsfor the specified hardware-software configuration) is equal to 12CFP+28 CFP=40 CFP.

8. Conclusion

Portability requirements are typically described initially as nonfunctional requirements (NFR) at the system level, and system engi-neers must subsequently apportion these system requirements verycarefully as either software or hardware requirements to conform tothe portability requirements of the system. Within the ECSS, ISO,and IEEE standards, a number of views and concepts are provided todescribe various types of candidate portability requirements at thesystem, software, and hardware levels.

This paper has presented the results of the analysis of system por-tability requirements of a number of standards (ECSS, IEEE-830, ISO9126, ISO 24765, and ISO 2382-1) which have defined, from differentpoints of view, a number of portability function concepts. This paperhas synthesized those system portability requirements into four dif-ferent function types of system portability-NFR.

Themain contribution of this paper is our proposed standards-basedreference framework for the identification of system portability require-ments. Such a reference framework can be used, for example, for the al-location of system portability requirements to the software functionsthat implement them.

Since the structure of this reference framework is based on themodel of software-FUR adopted by the COSMICmeasurement standard,the information necessary for measuring their functional size is readilyavailable, and two examples have been presented of specific instantia-tions of this framework. Even though the standards-based referencemodel is generic, the measurement results for each specific applicationwill be distinct: each will have its own specific instantiation of themodel.

The proposed specification and measurement model is indepen-dent of the software type and the languages in which the software-FUR will be implemented.

The reference framework of system portability-NFR proposed inthis paper can provide:

1. System engineers:– With an integrated review of the system portability require-

ments that they can use to select those needed for a specific sys-tem to be developed (hardware-software).

image of Fig.�13

Function Type 1 (Software Components Portability)Function Type 2

(Data Components Portability)

Function Type 3: (Hardware ComponentsPortability)

Function Type 4(Isolation of the System Portability Call

Functiona

E X

X E

E X

X E

E X

X E

E X

X E

Isolation of the Software System Calls Function

(ISSCF)

Persistent Storage



Independence of the Programming Language Virtual Machine Function

(IPLVMF)


INTERMEDIARY

Service(IS)

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

R

W

R

W

R

W

R

W

Persistent Storage


Independence of the Server Function (ISF)



INTERMEDIARY

Service(IS)

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

E X

XE

R

W

R

W

R

W

R

W

E X

X E

E X

X E

Persistent Storage


Distributed Database Management System Function

(DDBMSF)

RW

RW

E X

X E

E X

X E




Boundary

Functional Process

Direct Data Movements (E) ENTRY (X) EXIT


Persistent Storage

E X

X E

E X

X E

R1

R2

R3

R4

Valve control software



Valve control softwareSensors

Valve Control

Fig. 14. The VCS added portability requirements within the reference framework of system portability-NFR.


– With a methodology to specify these portability NFR on thebasis of international standards, and the ECSS in particular.

– With an integrated model to be used as input to make decisionson which of these detailed portability NFR will be allocated to: 1—hardware, 2—software, or 3—a combination of these, for a spe-cific context.

2. Software engineers:– With a reference framework that they can use to verify whether

or not the system engineers have provided them with the rightselection of system NFR-derived software-FUR, and at the nec-essary level of detail. This means that this standards-based ref-erence framework can be used as a technique to measure thequality of requirements input to their own work;

– With portability requirements at this level of detail up front inthe project life cycle: that is, at the software requirementsphase, rather than much later, at the software testing phase,which is a common practice in many application domains;

– With the necessary information for measuring the functionalsize of these portability-FUR allocated to software. The proposedspecification and measurement model based on COSMIC ISO19761 is independent of the software type and the languages inwhich the software-FUR will be implemented;

– With the ability to take the functional size of portability-FUR intoaccount in function point-based software estimation models,thereby avoiding late discovery of mandatory software-FUR thatoften leads to budget overruns and missed deadlines.

Table 18The measurement details for the system portability requirements allocated tosoftware functions.

ID Standards-based Software-FUR for portabilityfunctions

R Data movementsidentified

E X R W SizeCFP

1 Independence of the operating system service R1 – – 1 1 22 Independence of the storage services R2 – – 1 1 23 Independence of the network services R3 – – 1 1 24 Independence of the network services R3 – – 1 1 25 Independence of the network services R3 – – 1 1 26 Isolation of the software system call services R4 – – 1 1 27 One Intermediary Service

between R1(in function type 1)and R4 (in function type 4)—see Fig. 14.

R1 andR4

4 4 – – 8

8 One Intermediary Servicebetween R2 and R3(in function type 3) and R4(in function type 4)—see Fig. 14.

R2, R3and R4

4 4 – – 8

Functional size 8 8 6 6 28CFP


The proposed reference framework of the system portability-NFR isdefined at a high level of abstraction (i.e. the specified portability func-tions defined in the standards). It will be interesting in the future to detailsuch portability-specific functions, as well as evaluate the suggested ap-proach through a number of case studies, preferably from industry.

The measurement aspects presented in this paper have been lim-ited to the system requirements allocated to software. It will be inter-esting in future work to investigate whether or not this measurementapproach can be extended to all such requirements at the systemlevel (that is, to all hardware–software–manual requirements, andnot only to software requirements).

A number of related issues have not been tackled yet, andwill requirefurther work, including:

1. Estimation models using the size of software-FUR derived fromsystem-FUR, as their key independent variable may be improvedby taking into account the size of these other software-FUR derivedfrom system-NFR (portability and other types of NFR). Of course,empirical work is needed to collect data and investigate whetheror not the performance of such expanded size-based estimationmodels is indeed improving;

2. Research on estimation models using the size of software-FUR de-rived from both system-FUR and system-NFR as inputs should inves-tigate not only the initial development phase, but also the systemmaintenance phase.

References

[1] M. Noguera, M.V. Hurtado, M.L. Rodríguez, L. Chung, J.L. Garrido, Ontology-drivenanalysis of UML-based collaborative processes using OWL-DL and CPN, Science ofComputer Programming 75 (2010) 726–760.

[2] L. Chung, J. do Prado Leite, On Non-Functional Requirements in Software Engi-neering, Conceptual Modeling: Foundations and Applications, Lecture Notes inComputer Science, 5600, Springer, Berlin/Heidelberg, 2009, pp. 363–379.

[3] W. Ma, L. Chung, K. Cooper, Assessing Component's Behavioral InteroperabilityConcerning Goals, On the Move to Meaningful Internet Systems: OTM 2008Workshops, Lecture Notes in Computer Science, Springer, Berlin/Heidelberg,2008, pp. 452–462.

[4] S. Nary, An NFR-Based Framework for Establishing Traceability between Enter-prise Architectures and System Architectures, 2006, pp. 21–28.

[5] L. Chung, N. Subramanian, System and software architectures, Science of ComputerProgramming 57 (1) (2005) 1–4.

[6] L. Chung, N. Subramanian, Adaptable system/software architectures, Journal ofSystems Architecture 50 (7) (2004) 365–366.

[7] W. Yiqiao, Self-Repair through Reconfiguration: A Requirements EngineeringApproach, 2009, pp. 257–268.

[8] M. John, Goal-Oriented Requirements Engineering, Part II, 14th IEEE InternationalRequirements Engineering Conference (RE'06), 2006, pp. 1–5.

[9] N. Subramanian, L. Chung, Towards standardization of adaptable softwarearchitectures, Computer Standards & Interfaces 25 (2003) 211–213.

[10] B. Cheng, R. de Lemos, H. Giese, P. Inverardi, J. Magee, J. Andersson, B. Becker, N.Bencomo, Y. Brun, B. Cukic, G. Di Marzo Serugendo, S. Dustdar, A. Finkelstein, C.Gacek, K. Geihs, V. Grassi, G. Karsai, H. Kienle, J. Kramer, M. Litoiu, S. Malek, R.Mirandola, H. Müller, S. Park, M. Shaw,M. Tichy, M. Tivoli, D.Weyns, J. Whittle, Soft-ware Engineering for Self-Adaptive Systems: A Research Roadmap, LectureNotes in Computer Science in Software Engineering for Self-Adaptive Sys-tems, 5525, Springer, Berlin/Heidelberg, 2009, pp. 1–26.

[11] ECSS-E-40-Part-1B, Space Engineering: Software — Part 1 Principles andRequirements, European Cooperation for Space Standardization, The Netherlands,2003.

[12] ECSS-E-40-Part-2B, Space Engineeing: Software-part 2 Document RequirementsDefinitions, European Cooperation for Space Standardization, The Netherlands,2005.

[13] ECSS-ESA, Tailoring of ECSS, Software Engineering Standards for GroundSegments, Part C: Document Templates, ESA Board of Standardization and Con-trol (BSSC), 2005.

[14] ECSS-E-ST-10C, Space engineering: system engineering general requirements,Requirements & Standards Division Noordwijk, The Netherlands, 2009.

[15] ECSS-Q-ST-80C, Space Product Assurance: Software Product Assurance, Require-ments & Standards Division Noordwijk, The Netherlands, 2009.

[16] ISO/IEC-9126, Software Engineering — Product Quality — Part 1: Quality Model9126–1, International Organization for Standardization, Geneva (Switzerland),2004.

[17] IEEE-Std-830, IEEE Recommended Practice for Software Requirements Specifica-tions, 1998.

[18] ISO 24765, Systems and software engineering vocabulary, International Organi-zation for Standardization, Geneva (Switzerland), 2008.

[19] ISO 2382–1, Information technology — Vocabulary — Part 1: Fundamental terms,International Organization for Standardization, Geneva (Switzerland), 1993.

[20] ISO/IEC 19761, Software Engineering — COSMIC v 3.0 — A Functional Size Mea-surement Method, International Organization for Standardization, Geneva(Switzerland), 2003.

[21] A. Abran, K.T. Al-Sarayreh, Standards-Based Model for the Specification of SystemDesign and Implementation Constraints, Industrial Proceedings, 17th EuropeanSystems & Software Process Improvement and Innovation, EuroSPI 2010 Confer-ence, Grenoble (France), Delta, Denmark, Sept. 1–3, 2010, pp. 4.7–4.16.

[22] A. Abran, K.T. Al-Sarayreh, Measurement of Software Requirements Derived from Sys-tem Operations Requirements, 20th International Workshop on Software Measure-ment & International Conference on Software Measurement, IWSM/Metrikon/Mensura, Stuttgart, Germany, 2010, pp. 101–114.

[23] K.T. Al-Sarayreh, A. Abran, J.J. Cuadrado-Gallego, Measurement Model of SoftwareRequirements Derived from System Portability Requirements, 9th InternationalConference on Software Engineering Research and Practice (SERP 2010), LasVegas, USA, 2010, pp. 553–559.

[24] K.T. Al-Sarayreh, A. Abran, A Generic Model for the Specification of SoftwareInterface Requirements and Measurement of Their Functional Size, 8th ACISInternational Conference on Software Engineering Research, Management andApplications, SERA 2010, Montreal, Canada, 2010, pp. 217–222.

[25] K.T. Al-Sarayreh, A. Abran, Measurement of Software Requirements Derivedfrom System Reliability Requirements, 24th European Conference onObject-Oriented Programming (ECOOP 2010), ACM Digital Library, Maribor,Slovenia, 2010, pp. 1–6.

[26] K.T. Al-Sarayreh, A. Abran, Specification and Measurement of System Configura-tion Non Functional Requirements, 20th International Workshop on SoftwareMeasurement & International Conference on Software Measurement, IWSM/Metrikon/Mensura, Stuttgart, Germany, 2010, pp. 141–156.

[27] A. Abran, K.T. Al-Sarayreh, J.J. Cuadrado-Gallego, Standards-based Model for theSpecification and Measurement of Maintainability Requirements, 22nd Interna-tional Conference on Software Engineering and Knowledge Engineering(SEKE 2010), Redwood City, California, USA, 2010, pp. 153–158.

[28] A. Moreira, J. Araujo, I. Brito, Crosscutting Quality Attributes for RequirementsEngineering, 14th International Conference on Software Engineering and Knowl-edge Engineering, Ischia, Italy, 2002, pp. 167–174.

[29] N.S. Rosa, P. Cunha, G. Justo, Process NFL: A language for Describing Non-Functional Properties, 35th Annual Hawaii International Conference on SystemSciences (HICSS'02) Hawaii, USA, 9, 2002, p. 282b.

[30] D. Park, S. Kang, Design Phase Analysis of Software Performance UsingAspect-Oriented Programming, 5th Aspect-Oriented Modeling Workshop in Con-junction with UML 2004, Lisbon, Portugal, 2004, pp. 1–6.

[31] M. Glinz, Rethinking the Notion of Non-Functional Requirements, 3rd WorldCongress for Software Quality, vol. 2, Munich, Germany, 2005, pp. 55–64.

[32] H. Kaiya, A. Osada, K. Kayjiri, Identifying Stakeholders and Their Preferencesabout NFR by Comparing Use Case Diagrams of Several Existing Systems, 12thIEEE International Requirements Engineering Conference, September 6–10,2004, Washington, DC, USA, 2004, pp. 112–121.

[33] B. Paech, A. Dutoit, D. Kerkow, A. Von Kneth, Functional requirements, non-functionalrequirements and architecture specification cannot be separated — A position paper,Requirements Engineering: Foundations for Software Quality (REFSQ), Essen,Germany, 2002.

[34] J. Mylopoulos, Goal-oriented Requirements Engineering, Keynote at the 14th IEEEInternational Conference on Requirements Engineering, IEEE Computer SocietyPress, 2006.

[35] M. Kassab, M. Daneva, O. Ormandjieva, Towards an Early Software Effort EstimationBased on Functional and Non-Functional Requirements, International Workshop on

plied Artificial Intelligence.

A. Abran et al. / Computer Standards & Interfaces 35 (2013) 380–3

Software Measurement & International Conference on Software Process and ProductMeasurement (MENSURA), Amsterdam, The Netherlands, 2009.

[36] M. Kassab, O. Ormandjieva, M. Daneva, A. Abran, Non-Functional RequirementsSize Measurement Method (NFSM) with COSMIC-FFP, Software Process andProduct Measurement, Springer-Verlag, 2008, pp. 168–182.

[37] K. L. Chung, "Representing and Using Non-functional Requirements for InformationSystem Development: A Process Oriented Approach," Ph.D. thesis, also Tech. Rpt.DKBS-TR-93-1, Department of Computer Science, University of Toronto, 1993.

[38] J. Mylopoulos, B. Nixon, From Object-Oriented to Goal Requirements, Transac-tions of the ACM, Orlando, USA, 1999, pp. 821–828.

[39] Andrew J. Ryan, An approach to quantitative non-functional requirements in soft-ware development, Systems Engineering — A Key to Competitive Advantage forAll Industries: 2nd European Systems Engineering Conference (EuSEC 2000),Munich, September 13–15, 2000. Herbert Utz Verlag, 2000.

[40] L. Chung, B. Nixon, E. Yu, J. Mylopoulos, Nonfunctional Requirements in SoftwareEngineering, Kluwer Academic Publishing, 2000.

[41] C. Alberts, A. Julia, S. Robert, Risk-Based Measurement and Analysis: Applicationto Software Security, TECHNICAL NOTE CMU/SEI-2012-TN-004 CERT® Program,Carnegie Mellon University, Software Engineering Institute (SEI), Feb. 2012(http://www.sei.cmu.edu).

[42] Y. Odeh, O. Mohammed, A new classification of non-functional requirements forservice-oriented software engineering, software engineering research group,centre for complex cooperative systems, department of computer science andcreative technologies, faculty of environment and technology, university of thewest of England (UWE), united kingdom, 2011.

[43] X. Liu, G. Nektarios, Specification of Non-Functional Requirements and theirTrade- Offs in Service Contracts in the NGOSS Framework, Book chapter 10, IGIGlobal, 2011.

[44] ISO/IEC-14143-1, Information technology — Software measurement — Functionalsize measurement Part 1: definition of concepts, International Organization forStandardization, Geneva (Switzerland), 2008.

[45] COSMIC, The COSMIC Method v3.0.1, Guideline for Sizing SOA Software, v1.4, TheCommon Software Measurement International Consortium, MPC Review, 2010.

[46] ISO-1413-4, Sofware Engineering — Functional Size measurement Part 4: referencemodel, International Organization for Standardization, Geneva (Switzerland), 2006.

[47] Adel Khelifi, Alain Abran, Marie O'Neill, Chantal Roy, Charles Symons, COSMIC,Valve Control Software (VCS), Software Engineering Research Laboratory, Écolede Technologie Supérieure, Université du Québec, 2006.

Alain Abran is a professor and the director of the Soft-ware Engineering Research Laboratory at the École deTechnologie Supérieure (ETS)–Université du Québec(Canada). Dr. Abran has more than 20 years of industryexperience in information systems development andsoftware engineering. Dr. Abran holds a PhD in Elec-trical and Computer Engineering (1994) from ÉcolePolytechnique de Montréal (Canada) and master de-grees in Management Sciences (1974) and ElectricalEngineering (1975) fromUniversity ofOttawa (Canada).He was the co-executive editor of the Guide to theSoftware Engineering Body of Knowledge project—SWEBOK-ISO 19759. He has also been actively involved

in software engineering standards as the international secretary for ISO/IEC JTC1 SC7—Software and System Engineering in 2001–2003. He is currently the chairman of the Com-mon Software Measurement International Consortium (COSMIC).

Khalid T. Al-Sarayreh is an assistant professor ofSoftware Engineering at Hashemite University inJordan. He has a PhD degree in Software EngineeringfromÉcole de Technologie Supérieure (ÉTS)—Universityof Québec (Canada). He also has a Doctoral degree inComputer Information Systems, an MSc in ComputerEngineering (Embedded Systems) and a BS degree inComputer Science from Jordanian universities. From2002 to 2005, he was at the KADDB (King Abdullah IIDesign and Development Bureau). From 2005 to 2006,he was an Assistant Professor at the Jordan University,and from 2006 to 2008, he was an Assistant Professor

39595

at the Faculty of Information Technology at the Ap-plied Sciences University

(Jordan). His research interests include: Software Real-Time Embedded Systems,Computer Networks, Non-functional Requirements for Embedded Systems and Ap-

Dr. Juan J. Cuadrado-Gallego is professor titular deUniversidad Alcalá (Spain) and the director of the PhDdegree in Computer Science. He is also an associate pro-fessor at the École de Technologie Supérieure, UniversitéduQuébec,Montreal, Canada. Hewas a part of the teach-ing staff at the Universidad Politécnica, Madrid, Spain, in2010, at the Otto-von-Guericke Universität, Magdeburg,Germany in 2009 and 2008, and at the Universitá degliStudi Roma Tre, Roma, Italy, in 2004. Previously,Dr. Cuadrado-Gallego was a Profesor at the UniversitatOberta de Catalunya, Barcelona, Spain between 2005and 2010, at the Universidad de Valladolid, Segovia,Spain in 2004, and at theUniversidadCarlos III,Madrid,Spain, between 1997 and 2004.

http://www.sei.cmu.edu

computer standards & interfaces - hashemite university · tional standardization bodies, such...

Documents