High Level Non Functional Specification - ComplexWorld

E.02.14-CASSIOPEIA-D1.3-High Level Non Functional Specification

Document information

Project title CASSIOPEIA

Project N° E.02.14 Project Manager Fundación Instituto de Investigación Innaxis Deliverable Name

High Level Non Functional Specification Deliverable ID 1.3 Edition 02.00.00

Template version 02.00.00

Task contributors

Fundación Instituto de Investigación Innaxis

Abstract

Deliverable 1.3 of the WP-E Project 'Complex Adaptive Systems for Optimisation of Performance in ATM' (CASSIOPEIA), is the high level specification of 'non-functional requirements'. Through a management methodology that combines the need to build the functional behaviour of the system with the need to model the associated non-functional requirements, this deliverable presents the non-functional requirements as an integral part of software modelling and development.

Project ID E.02.14 D1.3 High Level Non Functional Specification V2.0 Edition: 02.00.00

2 of 35

Authoring & Approval

Prepared By Name & organisation Position / Title Date David Pérez / Innaxis Project Leader 31OCT11 Yolanda González / Innaxis Consortium Member 31OCT11

Reviewed By Name & organisation Position / Title Date Yolanda González / Innaxis Consortium Member 31OCT11

Approved By Name & organisation Position / Title Date David Pérez / Innaxis Project Leader 21NOV11

Document History

Edition Date Status Author Justification V1.0 31OCT11 Deliverable Y González Initial version for review by

EUROCONTROL V2.0 11NOV11 Deliverable Y González Sections changed:

Deliverable name, executive summary, 1.3, 2.3.3, 2.3.4, 3.3, 4.1.1

IPR (foreground)

This deliverable consists of foreground owned by one or several Members or their Affiliates.


3 of 35

Table of Contents

EXECUTIVE SUMMARY .............................................................................................................................6

1 INTRODUCTION ...................................................................................................................................7

1.1 BRIEF OVERVIEW OF THE DOCUMENT ..................................................................................................7

1.2 INTENDED READERSHIP......................................................................................................................7

1.3 OBJECTIVES OF THE DELIVERABLE......................................................................................................7

1.4 STRUCTURE OF THE DELIVERABLE ......................................................................................................8

2 NFRS MANAGEMENT IN CASSIOPEIA ..............................................................................................9

2.1 UNDERSTANDING NFRS ....................................................................................................................9

2.2 NFRS IN CASSIOPEIA ....................................................................................................................9

2.3 MANAGEMENT OF NFRS IN CASSIOPEIA........................................................................................10

2.3.1 Elicitation ................................................................................................................................10

2.3.2 Domain knowledge .................................................................................................................11

2.3.3 Pre-validation of NFRs through scenarios-based analysis.....................................................12

2.3.4 Representing NFRs ................................................................................................................13

3 NFRS SPECIFICATIONS ....................................................................................................................15

3.1 OVERVIEW ......................................................................................................................................15

3.2 SYSTEM-RELATED NFRS .................................................................................................................16

3.3 PROJECT-RELATED NFRS................................................................................................................23

3.4 USER-RELATED NFRS.....................................................................................................................25

3.5 INTEGRATION WITH THE SCENARIOS..................................................................................................27

4 SOFTWARE REQUIREMENTS ..........................................................................................................30

4.1 SOFTWARE REQUIREMENTS .............................................................................................................30

4.1.1 Preview...................................................................................................................................30

4.1.2 Software development environments discussed ....................................................................30

4.1.3 Evaluation of alternatives .......................................................................................................32

4.1.4 Conclusions ............................................................................................................................33

4.2 HIGH LEVEL ARCHITECTURE .............................................................................................................33


4 of 35

REFERENCES...........................................................................................................................................35


5 of 35

List of tables

TABLE 1. NFRS TEMPLATE .....................................................................................................................................13 TABLE 2. CASSIOPEIA NFRS OVERVIEW.................................................................................................................15 TABLE 3. PORTABILITY ...........................................................................................................................................16 TABLE 4. SCALABILITY ...........................................................................................................................................17 TABLE 5. FLEXIBILITY.............................................................................................................................................18 TABLE 6. EXTENSIBILITY ........................................................................................................................................18 TABLE 7. EFFICIENCY..............................................................................................................................................19 TABLE 8. ROBUSTNESS............................................................................................................................................20 TABLE 9. MODULARITY ..........................................................................................................................................21 TABLE 10. CONFIGURABILITY.................................................................................................................................21 TABLE 11. HARDWARE ...........................................................................................................................................22 TABLE 12. SOFTWARE.............................................................................................................................................22 TABLE 13. LOCATION..............................................................................................................................................23 TABLE 14. INSTALLATION AND DEPLOYMENT ........................................................................................................24 TABLE 15. MAINTENANCE ......................................................................................................................................24 TABLE 16. APPEARANCE AND STYLE ......................................................................................................................25 TABLE 17. HEURISTICS ...........................................................................................................................................26 TABLE 18. USABILITY .............................................................................................................................................26 TABLE 19. LANGUAGE ............................................................................................................................................27 TABLE 20. SCENARIOS AND NFRS ..........................................................................................................................27 TABLE 21. EVALUATION OF ALTERNATIVES............................................................................................................32

List of figures

FIGURE 1. NFRS ANALYSIS IN CASSIOPEIA...............................................................................................................13 FIGURE 2. VERTICAL SCALABILITY ...............................................................................................................................17 FIGURE 3. AN ILLUSTRATIVE EXAMPLE OF AGENT-BASED MODULARITY ......................................................................20 FIGURE 4. HIGH LEVEL ARCHITECTURE.........................................................................................................................34


6 of 35

EXECUTIVE SUMMARY The CASSIOPEIA platform aims to provide policy-makers and stakeholders with a toolset able to deliver meaningful answers to a set of questions of particular interest in the European ATM context. The platform will be able to evaluate the impact of different technological, operational, economic, or policy options on a number of KPAs/KPIs. The selection of relevant features and the degree of detail to be included in the model shall be driven by the kind of scenarios to be assessed and by the type of answers to be delivered and the selection of scenarios will help to detail the different functions that the project needs to implement.

In this scenario and objectives, the requirements of CASSIOPEIA are outlined in deliverables D1.1, D1.2 and D1.3. This deliverable, D1.3, presents the specification for non-functional requirements as an integral part towards the software development tasks.

Although many research projects need strong software development tasks to be accomplished, often non-functional requirements are not presented nor a specific management methodology is part of the project. This brings additional risks to the research activities since some of the functional requirements, core of the specification of the project, could be seriously compromised by a faulty software implementation that may lead to long development delays, strong constraints regarding the hardware or software platform or very strict usability limitations.

This document fills those gaps, minimising potential risks, and provides the CASSIOPEIA project with a toolset to keep track of the different non-functional requirements that may appear throughout the lifetime of the project. Also, this a first detailed set of non-functional requirements that covers the needs that the project development has had at this stage.


7 of 35

1 INTRODUCTION

1.1 Brief overview of the document This document explores relevant features of scenarios and functionalities related to the software implementation, by making use of a requirements management methodology (RMM), in order to establish the non-functional specifications of CASSIOPEIA’s framework.

1.2 Intended readership This report is written for the professional reader and assumes an understanding of air transport and ATM. It also assumes understanding of requirements management methodologies, though this deliverable includes a brief overview on the topic.

Without detriment to appropriate referencing and delineation, the text is not cluttered with explanations of common acronyms or principles.

1.3 Objectives of the deliverable As described in the proposal, CASSIOPEIA aims the construction of a holistic performance framework, able to capture the perspective of different ATM stakeholders through the definition of performance indicators.

However, from the implementation point of view, the specification of a system consist of defining the outward behaviour required of the software, and, additionally, defining of characteristics of the software, in terms of the computational requirements that the software needs to meet. These requirements are not aimed at modifying the functionality of CASSIOPEIA but, on the contrary, defining aspects mainly related to the software implementation, usability and growth capabilities. Therefore, these requirements will consist of number of non-functional requirements (hereafter "NFRs"). The objective of the successive sections of this document is to focus on these characteristics, which should represent specific requirements that the software must meet.

More specifically, this deliverable will:

• identify the most appropriate NFRs for the system which will support CASSIOPEIA;

• complete the requirements collected from survey carried out among stakeholders;

• serve as input for the software analysis and software requirements specification document.

This deliverable has been developed taking into account other activities run in parallel in CASSIOPEIA, due to the linkage of the NFRs with the requirements from deliverables D1.1 and D1.2 (SJU WP-E CASSIOPEIA, 2011), to ensure that the high level specifications of the model are widely satisfied, and with the work accomplished for the deliverable 2.0 (due end of November.2011) and WP.4. This wide coordination has the main goal of ensuring that the execution of the case studies, to be selected during the last quarter of 2011, are covered.

It is not the objective of this document to provide an exhaustive list of NFRs for the whole duration of the CASSIOPEIA project, since this is considered impossible in a project of this kind, as many different decisions to be take regarding the scenarios, functional requirements (hereafter "FRs"), validation, etc will surely require to modify, extend or re-define the NFRs even during the software development phase. However, it is within the goals of this document to provide a structure framework for what NFRs mean in the CASSIOPEIA context and equip the CASSIOPEIA team with an adequate structure to track all NFRs of the project.


8 of 35

1.4 Structure of the deliverable This document is structured in different sections:

Section 1 is the introduction of this document.

Section 2 describes what a NFR means in the CASSIOPEIA context and details how these NFRs are going to be managed in the project.

Section 3 details the NFRs, classified in System-related, Project-related and User-related requirements. Additionally, this section details how the NFRs need to be integrated with the scenario definition.

Section 4 details Platform requirements expanding the hardware and software aspects, and considering specific details about its implementation. Besides, it introduces a preliminary conceptual architecture to frame the platform requirements.

Section 5 lists the references of this document.


9 of 35

2 NFRs MANAGEMENT IN CASSIOPEIA

2.1 Understanding NFRs Users have implicit expectations about how well the software will work. These characteristics include how easy the software is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected conditions arise, including when the software needs to be scaled up to cover larger scenarios in terms of data usage. The NFRs define these aspects about the system, and the usual "non-functional" refers particularly to the fact that these requirement should not link to any specific functionality of the system and should not modify any particular function, neither in a positive or negative way. The NFRs are sometimes referred to as “non-behavioural requirements” or “software quality attributes" (Stellman and Greene ).

Although these attributes of the system cannot be defined in terms of functionality, in most cases the success and acceptance of a system among the users is given by the characteristics defined as non-functional. Important specifications about the speed on how certain function is executed or how scalable the systems are, differentiate the successful software projects from those others that do not get their goals achieve although the functions are properly implemented.

NFRs can also include qualities and constraints. Qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system and, ultimately, make the system usable for the goal.

For instance, a software to be developed with research goals in mind in the ATM context, may be designed to perform certain simulations of the airspace in Europe handling around 20-30,000 flights per day. An ATM analyst may need to run different scenarios to come up with the configuration of certain airspace design. In different software projects with research goals in mind the lack of NFRs has led to simulations that may last many hours until the first results are obtained. Although different FRs may have led to this situation (i.e. many different elements are simulated which leads to strong computational performance needed), the final product may not achieve the goals of the research project, since in practice the ATM analyst could not try many different airspace configurations as, due to the long time per simulation, the effort needed to come up wither the ideal airspace configuration may take more effort than could be actually allocated.

This is the situation that the ATM community actually face when using different commercial airspace and airport simulators with research goals in mind. Trying many different sector capacities, runways throughput, different future aircraft performances, etc, is not doable due to the long time needed to perform those detailed simulations.

Complexity Science (in this context) has the main goal of describing the performance of complex socio-technical systems without running microsimulations but understanding the underlying principles. Although not running microsimulations could ease certain computational requirements, some of the scenarios envision in CASSIOPEIA could lead to functions that impose strong requirements to the system and, therefore, like in any software project, NFRs play an important role.

Literally, quality is understood as the degree of match between the platform requirements (stated or otherwise) and the actual performances of the system. Quality is defined from the point of view of the user’s perception, expectation and goals or needs. Constraints are not subject to negotiation and, unlike qualities, are (theoretically at any rate) off-limits during design trade-offs. Constraints are characteristics of the system or the development organization that limit the development in some way and that also need to be taken into account (Stellman and Greene ).

2.2 NFRs in CASSIOPEIA CASSIOPEIA fits into the long term research initiatives, however, including important innovative aspects of applied research. The CASSIOPEIA work therefore aims at the potential future implementation of a decision making system for certain ATM functions and scenarios. From this point of view, the system


10 of 35

should be easily used by an average ATM analyst and able to be enhanced by other researchers, even with some potential implication of end users.

Due to the scope of WP-E and the resources allocated, it has been decided that the target user of CASSIOPEIA will be an ATM researcher, expert in the different ATM functions and capable of understanding all the different air traffic management configurations without major help for general ATM or software documentation. Additionally, the target user will be computer-savvy and, although the user is not expected to modify the code or needs to be trained in software languages, she/he should be capable of writing basic scripts, use Excel or database files and understand how different models translate into actual computer specifications.

It is understood as well that the target user will have access to a state-of-the-art computing facilities available in the market for research use, including access to broadband facilities with access to modify firewall configuration to allow, potentially, external services that could not be ported locally. Although it is impossible to provide detail specifications about the computing or broadband capabilities needed for CASSIOPEIA at this stage since, ultimately, this will depend on the width of the simulations to be run once the case studies have been selected, CASSIOPEIA will undoubtedly push the requirements in terms of computing and therefore, it is important to set the accessibility to computing facilities that the target user shall have.

Narrowing the target user of CASSIOPEIA to this profile sets the context of the NFRs: it is important to understand that while CASSIOPEIA FRs shall not be compromised by the definition of the target user, the CASSIOPEIA NFRs are basically bounded by the type of user.

Further work could explore the possibility of deploying CASSIOPEIA principles into a decision-making tool, in which the target user might be completely different. Example of potential target users in future work based on CASSIOPEIA principles could be personnel with different operational roles in airspace stakeholders or decision makers in airspace authorities. Those users could be defined from the definition of the scenarios and case studies and might have different NFRs. In general it has to be understood that these potential target users of future development and deployment work would have more strict NFRs, in terms of qualifications (e.g. computer skills, ATM knowledge), usability, access to computing facilities or even broadband access to external (to their facilities) networks.

Additionally, the NFRs in CASSIOPEIA may be modified from the definition of functional behaviour of the system and scenarios to be executed on it. Therefore, work to be done in future stages in CASSIOPEIA may require the re-definition of NFRs. To manage this situation, this document needs to be understood as a first set of NFRs and, if needed, the requirements presented in this document will be re-defined, broaden or simplified as needed. Additionally, the CASSIOPEIA team will maintain the NFRs documentation "live" to be modified and re-issued in the next stages as needed. Should these requirements need to change, a new version of this document will be issued, including a detail tracked changes table.

2.3 Management of NFRs in CASSIOPEIA 2.3.1 Elicitation

The requirements engineering is the phase of a software development project that defines the properties and software structure, including development and management of requirements:

• The development and definition of requirements involves understanding the business requirements, identify the user requirements and translate stakeholders and business requirements to system requirements;

• Requirements Management Methodology involves managing changes in requirements throughout the project lifecycle and maintains consistency between requirements and the whole project.

Taking into account IEEE's guidelines (IEEE, 1998), the CASSIOPEIA project will follow a Requirements Management Methodology (RMM), whose purpose is to evolve the project from the high level


11 of 35

specification to the system implementation in a controlled and coordinated manner. This deliverable in general and this section in particular cover the particular case of NFRs management in CASSIOPEIA.

The earlier phase of requirements engineering is the elicitation. This stage represents the input of stakeholders needs to the system. Requirement gathering consists of identifying business and user needs, and discover the requirements for the system (IEEE, 1998).

In the case of NFRs, the elicitation process has three different sources:

• NFRs derived from the stakeholders consultation process: The elicitation stage for FRs has been executed by means of a specific survey. This interaction mechanism has incorporated the inputs of the different stakeholders, obtaining meaningful answers to questions of particular interest for the European ATM (described in detail in Deliverables 1.1 and 1.2) (SJU WP-E CASSIOPEIA, 2011). Since the survey is aimed to determine relevant questions and identify scenarios of interest for stakeholders, NFRs are not typically involved. An additional reason for not deriving all NFRs from the stakeholders survey is that the target user chosen for CASSIOPEIA (the ATM analyst) is not necessarily the stakeholder that will recommend certain FRs. Nevertheless, certain NFRs could come from this source and the CASSIOPEIA team is aware of this possibility.

• NFRs derived from FRs captured from the stakeholders consultation process: For instance, if a particular FR documents how CASSIOPEIA should compute the emissions by airlines on a flight by flight basis on simulation time, this will impose a requirement on the number of flights to be handled and on the efficiency of the emissions models (i.e. speed of processing).

• Domain knowledge: Most of the NFRs listed in this document are identified from the CASSIOPEIA team domain knowledge on what is to be expected of a tool such as CASSIOPEIA.

2.3.2 Domain knowledge

The CASSIOPEIA team compiled a number of NFRs attending at the domain knowledge. In particular, attending at the domain, the team can appreciate:

NFRs originated from system constraints

System constraints or system qualities are requirements that are set by the environment in which the system will be developed and deployment. Characteristics belong to this classification are the type of infrastructure (hardware, operating system platforms...), legacy applications or the processes that the system will support.

NFR originated from Stakeholders objectives and strategies

Due to the fact that stakeholders will specify mainly FRs, this type will be also the case of most NFRs actually originated from FRs.

NFRs originated from development Organization Constraints

In software development, constraints placed by management methodology typically take the form of required time-to-launch of the platform or allocated development resources. When both variables are fixed, the requirements have to be strictly scoped. In the context of CASSIOPEIA, committed deadlines, partners or resources allocated to each work package could impose certain NFRs that the team will take into account.

NFRs originated from Industry trends

Some of the scenarios chosen in CASSIOPEIA could enjoy already certain tools and models in the market and/or the research community. This is the case to a variety of cases, from aircraft performance models, emissions models, flow models, network models, etc. At some point the CASSIOPEIA team


12 of 35

might decide to re-use or integrate existing modeling of software elements. Therefore, this situation could lead to requirements inherited from other platforms currently on the market/research community.

Legislative and Regulatory environment

Although it is not initially envision due to the innovative research character of this project, compliance with legislation or regulations identified as relevant (licensing, certification requirements...) could impose as well NFRs.

2.3.3 Pre-validation of NFRs through scenarios-based analysis

Whereas FRs are defined by specifications, NFRs can only be satisfied by means of an implemented system (e.g. efficiency, reliability), which leads to the need of a pre-validation strategy. Scenarios are an effective way of validating requirements in CASSIOPEIA as they capture stakeholder interaction and therefore the potential scenarios are proposed as a tool for definition and validation of NFRs.

With a view to suggesting a range of pertinent case study applications, discussions amongst the project team led to the development of an initial short-list of thirteen candidate (potential) case studies. All these scenarios focus the system context and are used to capture the NFRs.

In no implied order of priority, these were summarized in the stakeholder survey as:

• newly designed medium/short-range aircraft, flying lower/slower in order to save fuel / reduce CO2;

• local environmental restrictions limiting airport and terminal airspace capacity;

• changes in delays under scenarios of price bidding for FLs/ slot times, by airlines to ANSPs;

• investigating CDM performance variations with different levels of information sharing;

• ATFM slot allocations as a tradable commodity (airport to airline, or airline to airline);

• tactical, dynamic exchange of departure slots between airlines;

• peak and off-peak pricing in air navigation charges and slots;

• the use of biofuels giving airlines ATC/slot preferences and/or price differentials;

• different ATFM prioritisation strategies / algorithms;

• technological improvements reducing uncertainty in 4D trajectories - network level impact;

• FMS with a Cost Index that includes environmental and variable slot/ATC costs;

• turbofans replaced by propfan engines, with different trajectory optimisations;

• how the timing of sharing actual aircraft operating details influences 4D trajectory planning and execution, and system performance.

The feedback gained through the stakeholder consultation survey (described in Deliverables 1.1 and 1.2) will be used to help in the further refinement of this candidate list. However, the NFRs will be analyzed based on the complete list of potential cases, against the possibility of being implemented in the future. The following flow diagram describes the process:


13 of 35

Figure 1. NFRs Analysis in CASSIOPEIA

The templates for each high level of NFR are described in the following section, providing the process guide as well as NFRs knowledge representation. Although NFRs can be explored by scenario analysis many of them can only be finally validated by system testing or user-system interaction.

2.3.4 Representing NFRs

The NFRs will be represented by means of the following template. The template will describe interactions between user and system, focused on the entire system behaviour. It is typically used to represent FRs. Including a new field for all NFRs associated, qualities can be captured conveniently.

TABLE 1. NFRS TEMPLATE

NFR Id <id>

NFR <Name>

Version <nº>

Description <Summary>

Objectives <Purpose>

Cross-references and dependencies <NFR-nº> ...

Priority <Mandatory, optional>

Metrics <Requirement attributes>

The meaning of the fields is as follows:

• NFR Id: identifier and reference number. Each requirement must be identified by a unique code. In order to achieve quick identification, the ID requirements begin with NFR;

Name convention: NFR-1.a; NFR= Non-Functional Requirement, 1= NFR number, a= first revision

• Name: descriptive name;

• Version: version number;


14 of 35

• Summary: brief description of the requirement;

• Objectives: purpose of the requirement. It describes the objectives associated to the requirement. It allows to know which requirements will meet the objectives proposed and thus justify the existence or purpose of requirement;

• Cross-references and dependencies: other requirements that are critical to successfully implementing the stated requirement, allowing horizontal traceability;

• Priority: priority for the implementation of the requirement;

- Mandatory: mandatory involves that the requirement is an essential feature expected from a tool as CASSIOPEIA.

- Optional: less critical item at a prototyping stage. This kind of requirements is marked as optional or desirable.

• Metrics: metrics for measuring quality. Elements that qualify or quantify the metrics, to facilitate analysis by statistical method. Metrics are used for evaluation and measuring of performance. Metrics is a measurable indicator used for determination of quality. Objectively measured measures are characterized as objectively and easily measurable indicators. They monitor for example the usage time of the system or number of failures. Subjective measures cannot be measured directly and objectively. Some cases of them are usability, integrity or appearance;


15 of 35

3 NFRs Specifications

3.1 Overview With the goal of simplifying the procedure to track the different NFRs and ease the process into the software specification document, the following classification is introduced:

System-related NFRs

Requirements derived from internal qualities of the system and the software and hardware context in which the platform will operate.

Project-related NFRs

Requirements imposed by the development methodologies and project management processes.

User-related NFRs

Requirements related to the stakeholders and the social context in which the system is deployed.

The following table shows and approach to NFRs in CASSIOPEIA.

TABLE 2. CASSIOPEIA NFRS OVERVIEW

System-related NFRs Project-related NFRs User-related NFRs NFR-1.a Portability NFR-11.a Location Look&Feel NFR-14.a

Appearance and style

NFR-2.a Scalability

Development

NFR-12.a Installation and deployment

Interface NFR-15.a Usability

NFR-3.a Flexibility Maintenance NFR-13.a Maintenance and support

Language NFR-16.a Language

Lifecycle

NFR-4.a Extensibility

NFR-5.a Efficiency Performance NFR-6.a Robustness and fault tolerance NFR-7.a Modularity Design NFR-8.a Configurability NFR-9.a Hardware Platform NFR-10.a Software


16 of 35

3.2 System-related NFRs

Lifecycle requirements

Portability Portability is understood as ease to adapt the platform to different operating environments. It defines what features should be software for easy use on another machine or under other operating system. Portability, as a requirement, could be stricter on future stages of CASSIOPEIA if re-use of models or systems is required.

Portability in CASSIOPEIA

TABLE 3. PORTABILITY

NFR Id NFR-1.a

NFR Portability

Version 1

Description The effort required to transfer the program from the initial hardware system environment and / or software to a different environment.

Objectives

The system will aim to achieve the portability of models and scenarios to be reused in different environments.

CASSIOPEIA is expected to be a versatile platform used by different groups of users, however the ATM Analyst has been defined as CASSIOPEIA Target User, as defined in Section 3.2.

The system shall be able to operate on general purpose machines under running Microsoft Windows Operating System.

Cross-references and dependencies Platform

Priority Mandatory

Metrics

It will be useful to track, as a metric of portability, the effort needed (in days) to transfer the program from a system environment to a different environment (e.g. Linux, OSX). Number of target statements, defined as estimation/forecast of the number of target OS to which portability is planned.

Scalability Scalability is defined as the capability to perform under an increased or expanding workload. The vertical scale is the term most commonly used to achieve scalability using better software and faster. Scaling involves adding more memory, more processors or faster processors or simply migrating the application on a single computer more powerful. Typically, this method allows an increase in capacity without requiring source code changes. From the administrative point of view, things remain the same as it is still only one equipment to manage.

However, cloud computing techniques may allow the accessibility to larger computing facilities at a fraction of the cost. Cloud computing environments may impose NFRs on the coding languages to be used, modularity, accessibility or even re-usability of existing models or software elements. Therefore, scalability requirements could evolve into different types of requirements very easily.


17 of 35

Figure 2. Vertical scalability

Scalability in CASSIOPEIA

TABLE 4. SCALABILITY

NFR Id NFR-2.a

NFR Scalability

Version 1

Description The system will be able to be expanded to larger or more powerful servers to increase the demand or load.

Objectives

A simulation platform as CASSIOPEIA should ensure that allows future capacities. The key feature of CASSIOPEIA is that the additional load only requires additional resources rather than extensive modification of the application core itself. This feature, very oriented to the workload and hardware, is closely linked to the concept of extensibility.

From the point of view of scenarios and the estimated workload for execution, CASSIOPEIA will aim to support running different scenarios and strategies simultaneously. In the case of the data, the tool design will use high resolutions and multiple scales of operation, to give users as much information as possible in the simulation.

The focus of the application to an agent-based model requires a scalability requirement, allowing an increase in the number of agents (usually agent-based systems require a large amount of execution resources). The scalable design of the architecture will provide the means to build and execute complex models, such as agent-based.

Cross-references and dependencies N/A

Priority Optional at a prototyping stage, but must be tracked.

Metrics

A number of scalability metrics shall be tracked when the software development phase starts. In particular, the following list of metrics is suggested. Other metrics may be added to the list at further stage:

* Number of connections it can support * Disk I/O throughput * Network throughput * CPU speed * Number of transactions per second


18 of 35

Flexibility Flexibility refers to ease to accept changes or ease to be changed by the Target User.

Flexibility in CASSIOPEIA

TABLE 5. FLEXIBILITY

NFR Id NFR-3.a

NFR Flexibility

Version 1

Description System's ability to adapt to variable situations and environments and to support changes in business policies and business rules. A flexible system is one that is easy to reconfigure or is adapted on response to different user requirements and system.

Objectives

It is intended that the system to be as flexible as possible. The objective will be to ensure the independence of the case, that is, the system not to be committed to the target scenarios, but make it as reusable as possible for other case studies.

The design, development, testing, and deployment of the platform will consider that the functionalities of the system can be enhanced or changed by the stakeholders, this means that the system should be easy to be modified: E.g. a normal user (with some good programming knowledge) should be able to create new agents or modify existing ones.

The system must be designed and built with the highest levels of flexibility regarding the parameterization.

Cross-references and dependencies Extensibility

Priority Optional

Metrics * The effort needed (in days) to implement changes * Number of changes and new requirements

Extensibility Extensibility ensures that future functionalities to the CASSIOPEIA toolset could be easily and quickly implemented.

Extensibility in CASSIOPEIA

TABLE 6. EXTENSIBILITY

NFR Id NFR-4.a

NFR Extensibility

Version 1

Description Easy to adapt the platform software to changes in specifications.

Objectives

The CASSIOPEIA design shall be based on an open architecture that favors system extensibility. Its construction aims to achieve an evolutionary and incremental development, so that new features and related requirements may be incorporated affecting the existing code the lowest as possible.

The system will not be committed to the case studies but will incorporate aspects of reusability. This feature is reinforced by the requirement of modularity and the agent based structure.

In order to improve system extensibility will approach the following objectives:

* Simplicity of design: a simple architecture will always be easier to adapt to changes than a complex architecture.

* Decentralization: the more autonomous are the modules, the higher probability of a change affecting a single module, instead of causing changes in the entire system.


19 of 35

Cross-references and dependencies Flexibility

Priority Optional

Metrics

Although generic metrics for extensibility are impossible to define, specific functionalities envisioned for future evolutions of CASSIOPEIA shall be tracked and evaluated. When possible, architectures that ensure easier, faster implementations of those future functionalities will be chosen.

The following metrics shall be used to track the extensibility to future functionalities, once those have been defined:

* The effort needed (in days) to implement new functionalities

* Number of changes and new requirements

Performance requirements

Efficiency

Efficiency specifies how well the software utilizes scarce computational resources: CPU cycles, disk space, memory, communications channels, etc.

Efficiency in CASSIOPEIA

TABLE 7. EFFICIENCY

NFR Id NFR-5.a

NFR Extensibility

Version 1

Description Degree to which the software makes optimal use of system resources.

Objectives

ATM system exhibits multiple scales and metrics of operation, it provides with huge amounts of data to manage. The system shall handle up and integrating large amounts of heterogeneous data multiple scales of operation, allowing users performing concurrent simulation activities. From the point of view of scenarios and the estimated workload for execution, CASSIOPEIA will aim to support running combinations of different scenarios and strategies executed simultaneously. CASSIOPEIA's focus is aimed at the development of a demonstration software as prototype of the model. Consequently, the reliability requirement is not as restrictive as product for commercial purposes. Upon completion of the project and as part of the study will be an evaluation of the levels of reliability achieved with the prototype.

Cross-references and dependencies N/A

Priority Optional

Metrics

The following metrics could be used to measure efficiency by capacity, degradation of service, timing constrains. * performance processing speed (transactions/sec); * response or usage time; * resource consumption; * total throughput and efficiency; * screen refresh time; * resources used.


20 of 35

Robustness and fault-tolerance A robust system is able to handle error conditions, without failure. This includes a tolerance of invalid data, software defects, and unexpected operating conditions.

Robustness in CASSIOPEIA

TABLE 8. ROBUSTNESS

NFR Id NFR-6.a

NFR Robustness and fault-tolerance

Version 1

Description System's ability to react appropriately under exceptional conditions.

Objectives

Due to the large number of heterogeneous data may appear invalid data to flow into error situations. The simulation platform should include a exception handling system in order to manage these error situations. The distributed design of the agent-based system leads to a more robust and fault tolerant system.

Cross-references and dependencies Modularity

Priority Optional

Metrics * Percentage of time that the system is running without failures.

Design requirements

Modularity Designing the system divided into a set of functional units that interact with each other.

Figure 3. An illustrative example of agent-based modularity


21 of 35

Modularity in CASSIOPEIA

TABLE 9. MODULARITY

NFR Id NFR-7.a

NFR Modularity

Version 1

Description Platform designed in a modular manner with independent functional units.

Objectives

The system will be developed in a modular way facilitating to be expanded or configured. Each module of the program will keep the functional independence. The result should be a versatile and modular model system. CASSIOPEIA will inherit the modularity by agent-based design and independence between different functional system units. Closely linked to scalability. From the point of view of scenarios and models, CASSIOPEIA will aim to manage combinations of different scenarios and strategies. The modular design will allow the reuse of the characteristics of different scenarios and models in the design of new case studies.

Cross-references and dependencies Platform, extensibility, portability

Priority Mandatory

Metrics * System divided in functional units

Configurability Involves the process of deciding and defining de parameters necessary for the execution of the different scenarios.

Configurability in CASSIOPEIA

TABLE 10. CONFIGURABILITY

NFR Id NFR-8.a

NFR Configurability

Version 1

Description Application parameterization.

Objectives

The system shall be configurable based on a range of characteristic parameters of the domain. In principle, CASSIOPEIA shall be developed as a single software element for different case studies. From this perspective, it is important to incorporate features that allow the selection and parameterization of the different scenarios and models.

The system shall have a management interface that includes administration and parameters management for the scenarios available. CASSIOPEIA shall provide all available configuration options through the interface.

The type and content of the parameters shall be collected during the development stage and will be documented by the user manual.

Cross-references and dependencies Flexibility, platform, usability

Priority Mandatory

Metrics * Parameterization of types of data

Platform requirements


22 of 35

It comprises physical devices and development environments of the platform, as follows:

Hardware Type of hardware platform which the system will operate on.

Hardware in CASSIOPEIA

TABLE 11. HARDWARE

NFR Id NFR-9.a

NFR Hardware

Version 1

Description Hardware platform that will support the system.

Objectives

From the hardware perspective, CASSIOPEIA demonstration software system shall be able to operate on general purpose machines under standard operating systems (e.g. Windows).

The definitive hardware and system needs required for launching of CASSIOPEIA will be specified in the analysis and design stage of the system.

Cross-references and dependencies Modularity, extensibility, portability, software

Priority Mandatory

Metrics No general metrics for the platform can be defined at this stage. However, the hardware shall be specified as a NFR to ensure correct visibility and tracking of the requirements in this context to all CASSIOPEIA stakeholders.

Software

Type of development platform which the system will operate on.

Software in CASSIOPEIA

TABLE 12. SOFTWARE

NFR Id NFR-10.a

NFR Software

Version 1

Description Development platform that will support the system.

Objectives

The definitive software and functional needs required for launching of CASSIOPEIA shall be specified in the analysis and design stage of the system.

For the selection of the development platform, this deliverable includes a section in which different alternatives are presented along with a comparative analysis. Initially the following list is proposed by the CASSIOPEIA team:

* object-oriented language;

* version control system;

* automatic compilation script generator;

* database to store scripts and simulation data;

* automatic testing platform;

* data processing tools.

Cross-references and dependencies Modularity, extensibility, portability, hardware

Priority Mandatory

Metrics No general metrics for the software can be defined at this stage. However, the software shall be specified as a NFR to ensure correct visibility and tracking of the requirements in this context to all CASSIOPEIA stakeholders.


23 of 35

The platform NFRs are especially relevant to the CASSIOPEIA project, due to the implications in many other requirements (see cross-references and dependencies) and the limitations that choosing a platform imposes to the development. Therefore, Section 4 of this document extends the definition of these NFRs looking for a finer level of control over these requirements.

3.3 Project-related NFRs

Development requirements Requirements derived from development conditions.

Location Refers to the location in which the development tasks of the application will be performed and the location/s in which the software can be effectively run and case studies analysis performed.

Location in CASSIOPEIA

TABLE 13. LOCATION

NFR Id NFR-11.a

NFR Location

Version 1

Description Location of the development environment.

Objectives

The software implementation will be managed collaboratively. The composition of the consortium, integrated by Innaxis, the University of Westminster and Universidad Politécnica de Madrid, combines key elements of the project, however the geography imposes requirements on the locations for the execution of the software.

The bulk of software development tasks will be assumed by the UPM, and therefore, will be on their premises where the most of the implementation tasks will be executed. Work package manager will keep the interaction with the others involved to ensure that development is aligned with the objectives of CASSIOPEIA and meets the needs of the scenarios outlined in the Deliverables 1.1 and 1.2 (SJU WP-E CASSIOPEIA, 2011) .

As detailed in platform requirements will be necessary to use a version control system that promotes stability and security development. The need to maintain versions of the repository visible to other members may be important for the project. Also, this system will facilitate access to versions by the other members of the consortium.

In the context of execution of software, the CASSIOPEIA software implementation shall be capable of being run at least in the location of the three partners (UPM, INX and UOW) ideally by having one installation of CASSIOPEIA in each site. If the requirements for computation exceed what the partners could provide, alternatives for remote access should be explored and this NFR shall be re-defined to at least ensure that partners will have access to the necessary computing facilities remotely for a minimum of several years since the finalisation of the project.

Additionally, any potential constraint that is introduced in this context should be properly logged and raised to the project members to ensure that it is taken into account to any potential stakeholders that may be a potential future user of the system (e.g. Eurocontrol).

Cross-references and dependencies Flexibility, platform

Priority Mandatory

Metrics N/A


24 of 35

Installation and deployment requirements These requirements impose specific installation restrictions and guidelines. These restrictions can be related to the platform and location for testing, and the installation plans.

Installation in CASSIOPEIA

TABLE 14. INSTALLATION AND DEPLOYMENT

NFR Id NFR-12.a

NFR Installation and deployment

Version 1

Description Installation of the application.

Objectives

Due to the nature of the project, the software platform shall be made at the disposal of the research teams participating in this project. Potentially, a broader research community might be allowed to access the facility in manners and terms defined by intellectual property management strategy of the project.

Taking into consideration the diversity of potential users who can access CASSIOPEIA, it shall not have specific installation requirements and shall be done easily by the target user following the user manual of the tool.

Cross-references and dependencies Flexibility, platform, usability

Priority Mandatory

Metrics N/A

Maintainability requirements Ability of a system to allow changes in its components, services, features and interfaces to the extent that such changes are required when adding or changing functionality, correct errors or supplement new business requirements.

It combines the ability to expand the program (extensibility), adaptability and services as well as configurability, ease of installation of a system and how easily problems can be localized.

Maintainability in CASSIOPEIA

TABLE 15. MAINTENANCE

NFR Id NFR-13.a

NFR Maintainability

Version 1

Description Supporting and maintenance tasks.

Objectives

Since CASSIOPEIA's focus is aimed at the development of a prototype, the maintenance will have documentary nature.

CASSIOPEIA will provide a comprehensive user manual to specify the use and maintenance of the application.

The system must be fully documented, each of the components software must be properly documented both in the source code as in the administration manuals and the user.

Another way of maintenance allowed, closely tied to the extensibility, is through the development of new functional modules within the research tasks.

Cross-references and dependencies Flexibility, usability, configurability, extensibility

Priority Mandatory

Metrics N/A


25 of 35

3.4 User-related NFRs

Look&Feel requirements Look and feel requirements arising from the presentation of the system to users.

Appearance and style The requirements related to the appearance of the system, and the perception by potential users. The style guidelines are focused on standards for the writing and design of the system. The implementation of a style guide provides uniformity in style and formatting of the application.

Appearance and style in CASSIOPEIA

TABLE 16. APPEARANCE AND STYLE

NFR Id NFR-14.a

NFR Appearance and style

Version 1

Description Appearance and style of the application interface.

Objectives

Since CASSIOPEIA will be aimed especially to represent the diversity of stakeholders involved and manage many heterogeneous elements interacting, the design will be fully aligned with the objectives ensuring the correct language treatment of the audience.

The interface will provide a simple environment to facilitating the user interaction with the application. The style of CASSIOPEIA's interface will focus on computer applications and standard operating styles present at common operating systems.

Cross-references and dependencies Usability

Priority Mandatory

Metrics N/A

Interface requirements Requirements that define the interaction between the system and the users.

Usability The usability describes ease-of-use requirements address the factors that constitute the capacity of the software to be understood, learned, and used by its intended users. These requirements make the system conform to the user’s abilities and expectations of the usage experience.

One of the keys to the ease of use is the structural simplicity. A well-designed, built according to a clear structure and well-thought-out, tends to be easier to learn and use than a confusing one. It also includes ease of installation, operation and monitoring.

To quantify usability, the heuristic model by Jakob Nielsen is proposed, based on the principles of user-centred design (J.Nielsen, 1994). This criteria corresponds to:


26 of 35

TABLE 17. HEURISTICS

Nº Heuristic 1 Visibility of system status

2 Match between system and the real world

3 User control and freedom

4 Consistency and standards

5 Error prevention

6 Recognition rather than recall

7 Flexibility and efficiency of use

8 Aesthetic and minimalist design

9 Help users recognize, diagnose, and recover from errors

10 Help and documentation

Usability in CASSIOPEIA

TABLE 18. USABILITY

NFR Id NFR-15.a

NFR Usability

Version 1

Description Ease-of-use requirements address the factors that constitute the capacity of the software to be understood.

Objectives

The target user CASSIOPEIA will be using different terminology than the Complex System community. Ease-of-use is a necessary requirement since the platform should be accessible and user-friendliness. CASSIOPEIA users shall not assume the target users are familiar with software development. It is important to consider the capabilities and knowledge of CASSIOPEIA's audience when implementing the usability requirements, since the users’ characteristics make a difference to their expectations.

The system shall provide error messages and a very detail log that allow the user to clearly identify the type of error.

To enhance usability, the interface will be simple (e.g. from scripts or files), allowing basic tasks for which has been developed.

Usability will focus on a range of heuristic criteria, taken from Jakob Nielsen model (J. Nielsen, 1994) and, in particular, will put more emphasis on the following:

* (3) user control and freedom;

* (4) consistency and standards;

* (5) error prevention;

* (7) flexibility and efficiency of use;

* (8) aesthetic and minimalist design.

With regard to documentation, the user manual will contain enough information for the management and configuration of the platform.

Cross-references and dependencies Appearance

Priority Mandatory

Metrics Measured by heuristics


27 of 35

Language requirements These requirements describe languages, spelling preferences, and language idioms.

Language in CASSIOPEIA

TABLE 19. LANGUAGE

NFR Id NFR-16.a

NFR Language

Version 1

Description Language used by the application.

Objectives Documentation and application interface shall be developed in English.

Cross-references and dependencies Appearance, usability

Priority Mandatory

Metrics N/A

3.5 Integration with the scenarios One of the challenges in the implementation of CASSIOPEIA is to ensure that the model is not unduly constrained by the case studies, whilst remaining flexible enough to accommodate their requirements. There needs to be a certain core functionality at three levels (although these are not mutually exclusive):

• irreducible functionality of the model (critical tasks and procedures - the core coding);

• common functionalities across the case studies (also allowing for some case study attrition);

• functionalities dedicated to other tasks (e.g. WP2.5 trade-offs).

For this reason, many of the NFRs are independent of the selected scenarios and case studies and apply to the entire system. Nevertheless, the scenarios and case studies will define some of the system-related NFRs and will delineate specific aspects of the system. The following table shows key system-related NFRs for each case study candidate.

TABLE 20. SCENARIOS AND NFRS

Aspects of ATM

Nº Case Study NFRs

Regulations (ENV)

1 Newly designed medium/short-range aircraft, flying lower/slower in order to save fuel / reduce CO2

NFR-3.a Flexibility / NFR-8.a Configurability • Possibility of analyzing flight regimes based on

different CO2 metrics. NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.


28 of 35

Aspects of ATM

Nº Case Study NFRs

Regulations (ENV)

2 Local environmental restrictions limiting airport and terminal airspace capacity

NFR-3.a Flexibility / NFR-8.a Configurability • Ability to evaluate different models of growth

under the same program. NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.

Regulations (ECON)

3 Changes in delays under scenarios of price bidding for FLs/ slot times, by airlines to ANSPs

NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.

FLOW CDM SLOTS

4 Investigating CDM performance variations with different levels of information sharing

NFR-3.a Flexibility • Each stakeholder can define their own ad hoc

strategy. NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.

FLOW CDM SLOTS

5 ATFM slot allocations as a tradable commodity (airport to airline, or airline to airline)

NFR-3.a Flexibility • Each airline or airport can define their own ad hoc

strategy for slot interchange. NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.

FLOW CDM SLOTS

6 Tactical, dynamic exchange of departure slots between airlines

NFR-2.a Scalability / NFR-5.a Efficiency • Ability to consider more performance goals and

scenarios. NFR-1.a Portability • Different airlines and operators can use the

platform to evaluate their strategies. NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.

FLOW CDM SLOTS

7 Peak and off-peak pricing in air navigation charges and slots


simultaneously.

FLOW CDM SLOTS

8 The use of biofuels giving airlines ATC/slot preferences and/or price differentials


simultaneously.

FLOW CDM SLOTS

9 Different ATFM prioritisation strategies / algorithms

NFR-2.a Scalability • More detailed prioritisation algorithms, more

variables can be managed at the same time. NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.


29 of 35

Aspects of ATM

Nº Case Study NFRs

Trajectory 10 Technological improvements reducing

uncertainty in 4D trajectories - network level impact

NFR-2.a Scalability / NFR-5.a Efficiency • Allows higher 4D resolution data. NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.

Trajectory 11 FMS with a Cost Index that includes

environmental and variable slot/ATC costs NFR-1.a Portability • FMS may incorporate a simplified version of the

CASSIOPEIA model, taking into account of more variables in the Cost Index calculation


simultaneously.

Trajectory 12 Turbofans replaced by propfan engines, with

different trajectory optimisations NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.

Trajectory 13 How the timing of sharing actual aircraft

operating details influences 4D trajectory planning and execution, and system performance

NFR-2.a Scalability / NFR-5.a Efficiency • Allows higher resolution data in the trajectory

information. NFR-7.a Modularity • Ability to run combinations of different scenarios

simultaneously.

A further iteration of this table will be carried forward to D2.0, where the case study selection is further refined to a final candidate set, taking into account the findings of D1.1 and D1.2 (SJU WP-E CASSIOPEIA, 2011), which are produced in parallel with D1.3.


30 of 35

4 Software requirements This section expands the level of detail for the software platform that will support CASSIOPEIA, which ultimately shall allow the exploitation of CASSIOPEIA models from a computing environment.

With regards to implementation, it is necessary to consider the following aspects:

1. CASSIOPEIA is a research project. In this sense, the scope of software development will be producing a demonstration software with the research community as a target user. Achieving operational computing solution that supports the complexity of the scenarios and models, is the great challenge to be addressed in the project from the computational point of view;

2. The limitation on development time, effort allocated, targeted objectives and, in general, CASSIOPEIA's research goals imposes restrictions on the requirements the team need to impose to the tool. Therefore, those requirements are very different from those expected from a commercial end product, which is not within scope of CASSIOPEIA.

This section introduces a high-level preliminary design of CASSIOPEIA. Although this will surely evolve in the following software design phase, a framework for the final architectural design has been provided to achieve deeper level of detail on the requirements for the platform in which CASSIOPEIA shall run.

4.1 Software requirements 4.1.1 Preview

Following from the NFRs identified for the platform, several alternatives for selecting the development environment of CASSIOPEIA have been analysed. Each of these options offer several advantages in reference to the implementation and, obviously, impose some limitation in what refers to NFRs. In order to accomplish the most suitable environment, an analysis of pros and cons has been carried out for each of the potential development strategies. This section summarize the findings of this analysis that was accomplished through a number of working sessions and telecoms among the parties involved:

The minimum of the software resources to be operational a platform such as CASSIOPEIA is defined through the Platform requirements in the section 3.2 of this deliverable.

4.1.2 Software development environments discussed

4.1.2.1 Matlab

MATLAB is a technical computing language and a high-level interactive environment for algorithm development, data visualization, data analysis and numerical calculation. The name "MATLAB" derives from ''MATrix LABoratory (Matrix Laboratory)". MATLAB was originally written to provide easy access to matrix software developed by the LINPACK and EISPACK projects, which together represent the most advanced matrix calculus programs.

Generally provides components for:

• numerical analysis;

• matrix calculus;

• signal processing;

• graphics.


31 of 35

MATLAB is used for research and to solve practical problems of engineering and mathematics, with a strong emphasis on applications of control and signal processing. MATLAB also provides a number of specific solutions known as TOOLBOX. These solutions are sets of functions that extend the MATLAB environment to solve specific problems. (MathWorks, 2011).

4.1.2.2 Java

Java is a programming language object-oriented that was designed in 1990 by James Gosling, Sun Microsystems, as software for consumer electronics devices and with the aim of creating a language that could run on heterogeneous computer networks (computer networks consist of more than one type of computer, whether PC, MAC's, workstations, etc.).

In the early nineties, Sun Microsystems tried to placed on the market of consumer electronics and develop programs for small electronic devices. Their first proposal was to devise a new programming language as simple as possible, in order that it could be easily adapted to any execution environment. Based on the knowledge and study of many languages , the group decided to gather the essential features that should have a modern programming language and powerful, but eliminating all those functions that were not absolutely essential.

The Java platform consists of the following parts:

• the programming language itself;

• Java Virtual Machine or Java, which allows portability running;

• the Java API, a standard library for language.

(Gosling and Yellin, 2000).

4.1.2.3 C++

C++ is is a general-purpose programming language, derived from C, with a bias towards systems programming that supports efficient low-level computation, data abstraction, object-oriented programming, and generic programming. It was designed by Bjarne Stroustrup in the mid 80's, who developed the programming language to program simulations of events. The main intention was to expand the C programming language mechanisms that allow the manipulation of objects.

The C++ platform consists of three elements:

• the compiler, which translates into machine language the content of the source files;

• the preprocessor, characteristic of C++ and that does not exist in other programming languages. It works on the source program before compilation beginning to perform tasks such as replacing symbolic constants. This speeds up the task of the compiler;

• standard library. To simplify the language, C++ incorporates pre-programmed functions that are stored in object code libraries.

The C++ programming language provides a model of memory and computation that closely matches that of most computers. In addition, it provides powerful and flexible mechanisms for abstraction; that is, language constructs that allow the programmer to introduce and use new types of objects that match the concepts of an application. Thus, C++ supports styles of programming that rely on fairly direct manipulation of hardware resources to deliver a high degree of efficiency plus higher-level styles of programming that rely on user-defined types to provide a model of data and computation that is closer to a human’s view of the task being performed by a computer. (Stroustrup B., 1999).


32 of 35

4.1.3 Evaluation of alternatives

The different sessions to discuss and evaluate the alternatives is summarised in the following table, that shows a list of the advantages and disadvantages identified for each of the proposed alternatives. The discussion on the different options was framed under the NFRs identified for CASSIOPEIA:

TABLE 21. EVALUATION OF ALTERNATIVES

Alternative Advantages Disadvantages Matlab • Usability. Fast encoding and easily in a

very high level language.

• Usability. Graphic environment. Powerful graphics tools and simple.

• Extendibility. Matlab has toolbox for almost all technical areas, including simulation, which means having many algorithms built.

• Features and flexibility for analysis and presentation of results.

• Portability. Matlab applications are completely portable to different platforms (Linux, Macintosh, Windows).

• Efficiency. The graphical environment involves a low processing speed.

• Development. Not a good language for OOP.

• Scalability. Not recommended for large software projects due to the complexity of the code.

• Portability. Licences and cost. It is not a freeware tool.

Java • Maintainability. Libraries tend to be well documented.

• Development. Efficient debugging tools.

• Portability. Easy to develop applications for different platforms and technologies.

• Portability. There are many good open-source tools for developing this language.

• Development. It incorporates all the features and advantages of OOP.

• Robustness. Robust, well-recognized and market positioning.

• Efficiency. Good memory management thanks to the Automatic Garbage Collector.

• Others. Security and integrity. Configurable security context. The Java code is running safely and reliably.

• In general: faster prototyping and implementation is expected from Java than using other frameworks.

• Usability. The User Interface design is not simple. There are tools like JBuilder that can generate simple graphical interfaces, but have an additional cost.

• Efficiency. Interpreted language. The use of virtual machine makes applications run potentially slower than other development frameworks.

• Efficiency. Not fully exploit the capabilities of the operating system on which work.

Alternative Advantages Disadvantages C++ • Robustness. Robust, well-recognized

and market positioning.

• Modularity and reuse. Facilities for modular programs and / or use existing code or libraries

• Efficiency. Being a compiled language is suitable for system-intensive tasks

• Efficiency. The language is very fast in its execution to be compiled

• Development. It incorporates all the features and advantages of OOP.

• Scalability. Recommended for small and large software projects.

• Extensibility. Complex from the point of view of implementation.

• Development. Complicated management of databases.

• Portability. Some components are not free, is not fully open.


33 of 35

4.1.4 Conclusions

After reviewing the alternatives in relation to CASSIOPEIA NFRs, a preliminary decision of the use of Java as development platform has been decided. The wide range of capabilities and libraries of this language is expected to allow a faster implementation than under other frameworks. Faster implementation will probably turned out critical when exploring new scenarios and concepts.

Additionally, the advantages provided by the object-oriented programming in Java, will facilitate the implementation of an agent-based system. Robustness, portability and reusability, make Java a good choice for a tool to be a potential wider use among the research community. Disadvantages linked to efficiency, are not critical since the system is aimed at the development of a demonstration software and not a product for commercial purposes.

This decision is preliminary with the information available at this stage in the project. Nevertheless, if further functional or NFRs appear, other solutions might be consider and the discussion about the framework would be re-open at that stage.

4.2 High level architecture The detail design of the software architecture for CASSIOPEIA is a task to be accomplished in further stages of the project, however, in the context of the specification of NFRs, it was considered of importance to introduce a preliminary conceptual scheme. This scheme was used to frame the requirements of the platform and ensure all project members were aligned regarding the type of system was needed to take on the goals of the project.

The final and detailed design of the system in respect hardware and software aspects will be the subject of future deliveries within Work Package 3.

The following system elements are currently considered:

• Configuration profile, the input with the parameters entered by the user through the interface.

• Database, will store configuration scripts and system output logs.

• Simulation engine, performs modelling process and generation of scenarios depending on the configured parameters.

• Data repository, stores data in different scenarios; in general is the knowledge database.

• Control module, manages the application flow, interprets the input data, access to the knowledge database and sends the instructions to the simulation engine.

The following figure shows the general blocks diagram of CASSIOPEIA and the interaction between the different system elements:


34 of 35

Figure 4. High level architecture


35 of 35

References

Stellman A. and Greene J. (2005), Applied Software Project Management, chapter 6. O’Reilly

IEEE. IEEE Std 830-1998 (1998), IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society

Nielsen J. (1994), Usability Inspection Methods. John Wiley & Sons, New York, NY

MathWorks (2011) MATLAB User’s guide, www.mathworks.com/help/techdoc/

Gosling J., Yellin F., and the Java Team (2000), The Java™ Language Specification Third Edition- Java Sun, ISBN 0-201-63459-7

Stroustrup B. (1999), An Overview of the C++ Programming Language, AT&T Laboratories Florham Park, NJ07932-0971, USA

SJU WP-E CASSIOPEIA (2011) D1.1 – High level functional specification – Model Inputs SJU WP-E CASSIOPEIA (2011) D1.2 – High level functional specification – Model Outputs

High Level Non Functional Specification - ComplexWorld

Documents

Transcript of High Level Non Functional Specification - ComplexWorld