Application 1 – Analysis and Synthesis of Prior Research

U

M a

b

a

A R R A A

K R U S S

1

H w s e d 2 o i a 2 m s f a u s m a

a t e (

0 d

The Journal of Systems and Software 84 (2011) 328–339

Contents lists available at ScienceDirect

The Journal of Systems and Software

j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / j s s

ser requirements modeling and analysis of software-intensive systems

ichel dos Santos Soares a,∗, Jos Vrancken b, Alexander Verbraeck b

Universidade Federal de Uberlândia, P.O. Box 593, 38400-902 Uberlândia, Brazil Delft University of Technology, P.O. Box 5015, NL 2600 GA, Delft, The Netherlands

r t i c l e i n f o

rticle history: eceived 20 July 2010 eceived in revised form 7 October 2010

a b s t r a c t

The increasing complexity of software systems makes Requirements Engineering activities both more important and more difficult. This article is about user requirements development, mainly the activities of documenting and analyzing user requirements for software-intensive systems. These are modeling

ccepted 14 October 2010 vailable online 26 October 2010

eywords: equirements ML ysML

activities that are useful for further Requirements Engineering activities. Current techniques for require- ments modeling present a number of problems and limitations. Based on these shortcomings, a list of requirements for requirements modeling languages is proposed. The proposal of this article is to show how some extensions to SysML diagrams and tables can fulfill most of these requirements. The approach is illustrated by a list of user requirements for a Road Traffic Management System.

© 2010 Elsevier Inc. All rights reserved.

oftware-intensive systems

. Introduction

Software-intensive systems (Wirsing et al., 2008; Tiako, 2008; inchey et al., 2008) are large, complex systems in which soft- are is an essential component, interacting with other software,

ystems, devices, actuators, sensors and with people. Being an ssential component, software influences the design, construction, eployment, and evolution of the system as a whole (ANSI/IEEE, 000). These systems are in widespread use and their impact n society is increasing. Developments in engineering software- ntensive systems have a large influence on the gains in productivity nd prosperity that society has seen in recent years (Dedrick et al., 003). Their complexity is increased due to the large number of ele- ents and reliability factors. Thus, they must be decomposed into

everal smaller components in order to manage complexity and acilitate their implementation and verification. In addition, there is need to increase the level of abstraction, hiding whenever possible nnecessary complexity, by the intense use of models. Examples of oftware-intensive systems can be found in many sectors, such as anufacturing plants, transportation, military, telecommunication

nd health care. More specifically, the type of software-intensive systems that

re investigated in this article are the Distributed Real-Time Sys- ems. The term Real-Time System usually refers to systems with xplicit timing constraints (Gomaa, 2000; Laplante, 2004). Dijkstra 2002) recognized that some applications are concurrent in nature.

∗ Corresponding author. E-mail addresses: [email protected], [email protected] (M.d.S. Soares).

164-1212/$ – see front matter © 2010 Elsevier Inc. All rights reserved. oi:10.1016/j.jss.2010.10.020

In concurrent problems, there is no way of predicting which sys- tem component will provide the next input, which increases design complexity. Moreover, system components, such as sensors and actuators, are often geographically distributed in a network and need to communicate according to specific timing constraints described in requirements documents.

Requirements for software are a collection of needs expressed by stakeholders respecting some constraints under which the soft- ware must operate (Pressman, 2009; Robertson and Robertson, 2006). Requirements can be classified in many ways. The first classification used in this article is related to the level of detail (the second classification is presented in Section 7.1). In this case, the two classes of requirements are user requirements and sys- tem requirements (Sommerville, 2010). User requirements are high-level abstract requirements based on end users’ and other stakeholders’ viewpoint. They are usually written using natural lan- guage, occasionally with the help of domain specific models such as mathematical equations, or even informal models not related to any method or language (Luisa et al., 2004). The fundamental pur- pose of user requirements specification is to document the needs and constraints gathered in order to later develop software based on those requirements.

Systems requirements are derived from user requirements but with a detailed description of what the system should do, and are usually modeled using formal or semi-formal methods and

languages. This proposed classification allows the representation of different views for different stakeholders. This is good Soft- ware Engineering practice, as requirements should be written from different viewpoints because different stakeholders use them for various purposes.

ystem

w t E v ( i S a i p K 2 r 1 t i k a o t b G f d u r s o r

o m a i c r a T m i t t

1

a

s

t r r h i a f f s

1

T g

M.d.S. Soares et al. / The Journal of S

The process by which requirements for systems and soft- are products are gathered, analyzed, documented and managed

hroughout the development life cycle is called Requirements ngineering (Sommerville, 2010). Requirements Engineering is a ery influential phase in the life cycle. According to the SWEBOK Abran et al., 2004), it concerns Software Design, Software Test- ng, Software Maintenance, Software Configuration Management, oftware Engineering Management, Software Engineering Process, nd Software Quality Knowledge Areas. Requirements Engineer- ng is generally considered in the literature as the most critical hase within the development of software (Juristo et al., 2002; omi-Sirviö et al., 2003; Damian et al., 2004; Minor and Armarego, 005). Dealing with ever-changing requirements is considered the eal problem of Software Engineering (Berry, 2004). Already in 973, Boehm suggested that errors in requirements could be up o 100 times more expensive to fix than errors introduced dur- ng implementation (Boehm, 1973). According to Brooks (1987), nowing what to build, which includes requirements elicitation nd technical specification, is the most difficult phase in the design f software. Lutz (1993) showed that 60% of errors in critical sys- ems were the results of requirements errors. Studies conducted y the Standish Group (TSG, 2003) and other researchers (van enuchten, 1991; Hofmann et al., 2001) found that the main factors

or problems with software projects (cost overruns, delays, user issatisfaction) are related to requirements issues, such as lack of ser input, incomplete requirements specifications, uncontrolled equirements changing, and unclear objectives. In an empirical tudy with 12 companies (Hall et al., 2002), it was discovered that, ut of a total of 268 development problems cited, 48% (128) were equirements problems.

Requirements Engineering can be divided into two main groups f activities (Parviainen et al., 2004): (i) requirements develop- ent, including activities such as eliciting, documenting, analyzing,

nd validating requirements, and (ii) requirements management, ncluding activities related to maintenance, such as tracing and hange management of requirements. This article is about user equirements development, mainly the activities of documenting nd analyzing user requirements for software-intensive systems. hese are modeling activities that are useful for further Require- ents Engineering activities. The assumption in this article is that

mproving requirements modeling may have a strong impact on he quality of later requirements activities, such as requirements racing, and in the design phase.

.1. Research question

The main research question to be answered in this article is given s follows:

How to improve user requirements modeling and analysis for oftware-intensive systems?

This question is mainly answered through the early introduc- ion of graphical models, which are used to document and analyze equirements. The identification and graphical representation of equirements relationships facilitate that traces are made. This elps in uncovering the impact that changes in requirements have

n the system design. Requirements are important to determine the rchitecture. When designing the architecture, at least part of the unctional requirements should be known. In addition, the non- unctional requirements that the architecture has to conform with hould be made explicit.

.2. Article outline

Initially, a subset of a list of user requirements for a Road raffic Management System (RTMS) is presented, using natural lan- uage, to be further modeled and analyzed (Section 2). Current

s and Software 84 (2011) 328–339 329

techniques for requirements modeling are presented in Section 3. A number of problems and limitations related to these tech- niques are discussed in the same section. These shortcomings led to a list of requirements for requirements modeling languages in Section 4 and the proposed approach in Section 5 to fulfill the miss- ing characteristics of the list. From the conclusion of Section 4, the starting point for requirements modeling languages is to use SysML diagrams and tables, which are presented in detail in Sec- tion 6. Then, SysML’s constructions are extended in Section 7 and proposed to model the initial list of user requirements (Section 8). The article ends with discussion (Section 9) and conclusions (Section 10).

2. List of requirements for RTMS

The list of requirements given below is a subset from a document which contains 79 atomic requirements for RTMS (AVV, 2006). The document is a technical auditing work based on an extensive literature study and interviews, in which the stakeholders were identified. The requirements were gathered through interviews with multiple stakeholders.

The stakeholders (and the related number of requirements) were classified as: the Road Users (1), the Ministry of Transport, Public Works and Water Management (2), the Traffic Managers (10), the Traffic Management Center (8), the Task, Scenario and Operator Manager (22), the Operators (4), the Designers of the Operator’s Supporting Functions (15), and the Technical Quality Managers (17). In this article the requirements of the Traffic Man- ager were selected as example to be modeled using SysML diagrams and constructions in Section 8. The requirements are given as fol- lows.

Traffic Manager:

• TM4—It is expected that software systems will be increasingly more intelligent for managing the traffic-flow in a more effective and efficient manner.

• TM5—To optimize traffic flow, it is expected that gradually, region-wide traffic management methods will be introduced.

• TM6—The traffic management systems must have a conve- nient access to region-wide, nation-wide, or even European-wide parameters so that the traffic-flow can be managed optimally.

• TM7—It must be possible for the Traffic Managers/experts to express (strategic) “task and scenario management frames”, con- veniently.

• TM8—The system should effectively gather and interpret all kinds of information for the purpose of conveniently assessing the per- formance of the responsible companies/organizations that have carried out the construction of the related traffic systems and/or infrastructure.

• TM9—The system must support the Traffic Managers/experts so that they can express various experimental simulations and ana- lytical models.

• TM10—The system must enable the Traffic Managers/experts to access various kinds of statistical data.

• TM11—The system must enable the Traffic Managers/experts to access different kinds of data for transient cases such as incidents.

• TM12—The system must provide means for expressing a wide range of tasks and scenarios.

• TM13—The traffic management will gradually evolve from object management towards task and scenario management.

3. Requirements modeling approaches

There are several approaches to modeling requirements. Basi- cally, these approaches can be classified as graphics-based, purely

3 ystems and Software 84 (2011) 328–339

t a

u t e a (

u N g p s a a

m t t i i r o

U n p o i a f r 2 l t t m r d

R g f m s i i t t t S i

a s p

4 s

l t m

Table 1 List of requirements properties and representation techniques.

List of requirements NL SNL XP UC RD T

(M) Graphical modeling © © © � � © (M) Human readable � � � � � � (M) Independent towards methodology � � © � � � (M) Relationship between requirements © © © � � � (M) Relationship requirements/design © © © © � � (M) Requirements risks © © � © © © (M) Identify types of requirements � � � © © © (M) Priority between requirements © � � © © © (M) Non-functional requirements � � � © � � (M) Grouping related requirements � © © � © © (M) Consistency © © © � � � (M) Modifiable � � � � � � (M) Ranking requirements by stability © © � © © © (S) Solve ambiguity © � © © � � (S) Well-defined semantics © � © � � � (S) Machine readable © © © � � � (S) Correctness � � � � � � (S) Completeness � � � � � �

30 M.d.S. Soares et al. / The Journal of S

extual, or a combination of both. Some are generic while others re part of a specific methodology.

The most common approach is to write user requirements sing natural language. The advantage is that natural language is he main mean of communication between stakeholders. How- ver, problems such as imprecision, misunderstandings, ambiguity nd inconsistency are common when natural language is used Kamsties, 2005).

With the purpose of giving more structure to requirements doc- ments, structured natural language is used (Cooper and Ito, 2002). evertheless, structured natural language is neither formal nor raphical, and can be too much oriented to algorithms and specific rogramming languages. Other collateral effects are that structured pecifications may limit too early the programmers’ freedom, and re mostly tailored towards procedural languages, being less suit- ble for some modern languages and paradigms.

User Stories have been used as part of the eXtreme Program- ing (XP) (Beck, 1999) agile methodology. They can be written by

he customer using non-technical terminology, in the format of sen- ences using natural language. Although XP offers some advantages n the Requirements Engineering process in general, such as user nvolvement and defined formats for user requirements and tasks, equirements are still loosely related, not graphically specified, and riented to a specific methodology.

A well-known diagram used for requirements modeling are the se Cases. Even before UML emerged as the main Software Engi- eering modeling language, Use Cases were already a common ractice for graphically representing functional requirements in ther methodologies, such as Object-Oriented Software Engineer- ng (OOSE) (Jacobson, 1992). Use Cases have some disadvantages nd problems (Simons, 1999). They are applied mainly to model unctional requirements and are not very helpful for other types of equirements, such as non-functional ones (Soares and Vrancken, 007). Use Case diagrams lack well-defined semantics, which may

ead to differences in interpretation by stakeholders. For instance, he include and extend relationships are considered similar, or even he inverse of each other (Jacobson, 2004). In addition, Use Cases

ay be misused, when too much detail is added, which may incor- ectly transform the diagrams into flowcharts or making them ifficult to comprehend.

Two SysML diagrams are distinguished as useful mainly for equirements Engineering activities: the SysML Requirements dia- ram and the SysML Use Case diagram (OMG, 2008). One interesting eature of the SysML Requirements diagram is the possibility of

odeling other type of requirements besides the functional ones, uch as non-functional requirements. The SysML Use Case diagram s derived from the UML Use Case diagram without important mod- fications. In addition to these diagrams, SysML Tables can be used o represent requirements in a tabular format. Tabular represen- ations are often used in SysML but are not considered part of he diagram taxonomy (OMG, 2008). Detailed explanation about ysML diagrams and tables for Requirements Engineering are given n Section 6.

A comparison of the aforementioned requirements modeling pproaches is given in the next section. The objective is to identify hortcomings of these approaches, which is used as the starting oint of the proposed approach for a solution, in Section 5.

. Desirable requirements specification properties for oftware-intensive systems

A list of desirable requirements for requirements modeling anguages, together with a mapping of common languages and echniques, is given in Table 1. This non-exhaustive list of require-

ents for requirements modeling languages is based on literature

(S) Verifiable © � © � � � (S) Traceable � � � � � � (S) Type of relationship requirements © © © � � �

review presented in the introduction, on the modeling languages briefly presented in Section 3, and on specific texts about require- ments (IEEE, 1998; Beck, 1999; Luisa et al., 2004; Robertson and Robertson, 2006). This list uses “(M) Must have” and “(S) Should have” for each entry of the table, according to the MoSCoW labels (Page et al., 2003) (Must, Should, Could, Want/Won’t have).

The characteristics proposed in IEEE (1998, Section 4.3) (correct, unambiguous, complete, consistent, ranked for importance, ranked for stability, verifiable, modifiable, and traceable) are related to a good Software Requirements Specification (SRS) document. In this article, these characteristics were used in the context of require- ments modeling languages and techniques.

The reason for each entry of the list is given as follows.

4.1. Must have requirements

The modeling languages must provide graphical means to express requirements. Common graphical models may facilitate the communication of models to stakeholders. Models must be human readable, as the multiple stakeholders involved have to understand the models. In this case a balance is necessary, as the more machine readable requirements are, the less human readable they become. In addition, as multiple stakeholders and designers with different backgrounds are involved, the modeling languages should be as methodology independent as possible.

It is well-known by Software Engineering researchers and prac- titioners that requirements are related to each other (Robertson and Robertson, 2006). These interactions affect various software devel- opment activities, such as release planning, change management and reuse. A study has shown that the majority of requirements are related to or influence other requirements (Carlshamre et al., 2001). Due to this fact, it is almost impossible to plan systems releases only based on the highest priority requirements, without considering which requirements are related to each other.

From a project management point of view, one important characteristic of a requirement is its priority. Prioritizing require- ments is an important activity in Requirements Engineering (Davis, 2003). The purpose is to give an indication of the order in which requirements should be addressed. Another important property of

a requirement from the project management point of view is to identify its risk. For instance, a manager may be interested in identi- fying the impact for a project if a specific requirement is not fulfilled. Risk management is basically the activity concerned with trying to

ystem

d s

a F t i f

i s m d

fi g T 1 ( d o m c m s p i i m

i d

4

a d s

s t l

r g

e t r p d

e i l d b

4

d S f U

M.d.S. Soares et al. / The Journal of S

etect previously risks in a project and preventing problems with pecific plans.

Despite their importance, non-functional requirements are usu- lly not properly addressed in requirements modeling languages. or instance, UML Use Case diagrams are strong in modeling func- ional requirements. The various types of requirements must be dentified in order to provide better knowledge of requirements or the stakeholders.

From the software design point of view, grouping requirements n the early phases of software development helps in identifying ubsystems, components, and relationships between them. As a atter of fact, grouping requirements has a positive effect when

esigning the software architecture. According to IEEE (1998), a SRS should be consistent and modi-

able. In this article, these two properties of a SRS are considered of reat significance, and are grouped with “Must have” requirements. he reason is that inconsistency between documents (Boehm, 973; Pressman, 2009) and difficulty of changing requirements Berry, 2004) are major causes for future problems during software evelopment. A SRS is consistent if it agrees with other documents f the project, such as project management plans and system design odels. Thus, the modeling language must be able to highlight

onflicting requirements and non-conformances between require- ents and design. A SRS is modifiable if its structure and style are

uch that any changes to the requirements can be made easily, com- letely, and consistently while retaining the structure and style. For

nstance, requirements must be expressed individually, rather than ntermixed with other requirements. Thus, the modeling language

ust be able to describe requirements in a well-structured way. Finally, as changing requirements is a source of problems, know-

ng how stable a requirement is, i.e., how ready it is for further esign phases, is essential.

.2. Should have requirements

Ambiguity should be solved, as ambiguity in requirements is major cause of misunderstandings between stakeholders and

esigners. Thus, modeling languages should provide well-defined emantics, which increases machine readability.

According to IEEE (1998), an SRS is correct if every requirement tated is one that the software shall meet. The user can determine if he SRS correctly reflects his/her actual needs. Thus, the modeling anguages should facilitate the user in this activity.

According to IEEE (1998), an SRS is complete if all significant equirements of every type are included. Thus, the modeling lan- uages should be able to specify all types of requirements.

According to IEEE (1998), an SRS is verifiable if there is a cost- ffective process with which a person or machine can check that he software meets the requirement. In general, any ambiguous equirement is not verifiable. Thus, the modeling language should rovide non-ambiguous constructions in order to facilitate that the esigner can create non-ambiguous requirements models.

According to IEEE (1998), an SRS is traceable if the origin of ach of its requirements is clear, and if it facilitates the referenc- ng of each requirement in future development. Thus, the modeling anguage should provide means to trace the requirement through esign phases. In addition, the type of these relationships should e explicit.

.3. Resulting table

Table 1 maps the list of requirements for modeling languages iscussed in this section with the modeling languages discussed in ection 3. In the table, NL stands for natural language, SNL stands or structured natural language, XP stands for the XP User Stories, C stands for both SysML and UML Use Cases, RD stands for SysML

s and Software 84 (2011) 328–339 331

Requirements diagram, and T stands for SysML Tables. We classi- fied the entries as fully supported (�), half supported (�), or not supported (©) (or not easily supported, or poorly supported).

From the table, it is clear that “Must have” requirements, such as “Priority between requirements”, “Requirements risks”, “Identify types of requirements”, and “Ranking requirements by stability” are partially addressed or not addressed at all by most of the stud- ied requirements modeling languages. The next section presents the approach followed in order to try to fulfill all the given require- ments.

Another conclusion from the table is that some “Must have” requirements and the majority of “Should have” requirements are fulfilled or at least partially fulfilled by a combination of the SysML Requirements diagram and SysML Tables. Thus, a possible start- ing pointing to address all requirements is to extend these SysML constructions.

5. Proposed approach

With the explicit choice to use SysML, the proposal starts with detailing SysML capacities for Requirements Engineering (Section 6). In Section 7.1, a classification for each atomic requirement is proposed, avoiding the confusion of which type of requirement is written in the user requirements document. The basic SysML Requirements diagram is extended with new requirements prop- erties such as priority. Individual requirements modeled by the SysML Requirements diagram may be combined depending on their semantics. This can be useful for the early discovery of subsys- tems, in project management activities such as release planning, and to propose the system architecture (Section 7). User require- ments are also represented in a tabular format, which may facilitate requirements tracing during the system life cycle. This is impor- tant to know what happens when related requirements change or are deleted, which improves traceability. Finally, Use Case dia- grams are used to represent the actors involved and the scenarios to be implemented (Section 8). Then, Use Cases are related to SysML Requirements using one of the proposed relationships.

Although the idea in this article is to use graphical models already in the early phases of system development, natural lan- guage is still considered important. Despite its problems, there are also advantages, as natural languages are the primary communica- tion medium between people.

After being structured and graphically represented (Fig. 1) using SysML Tables, SysML Requirements and SysML Use Case diagrams, user requirements are detailed into system requirements, being specified using other models, such as other UML/SysML diagrams or using formal methods.

The SysML constructions (diagrams and tables) for modeling user requirements are explained in detail in the following section.

6. Modeling user requirements using SysML

The SysML Requirements diagram helps in better organizing requirements, and also shows explicitly the various kinds of rela- tionships between different requirements. Another advantage of using this diagram is to standardize the way of specifying require- ments through a defined semantics. The SysML Requirements constructs are intended to provide a bridge between traditional requirements management specifications and the other SysML

models. When combined with UML for software design, the requirements constructs provided by SysML can also fill the gap between user requirements specification, normally written in nat- ural language, and Use Case diagrams, used as initial specification of system requirements (Soares and Vrancken, 2008a).

332 M.d.S. Soares et al. / The Journal of Systems and Software 84 (2011) 328–339

g use

s g s t

6

b c d R g c t r e f d

r d

Fig. 1. Approach for modelin

A SysML Requirement can also appear on other diagrams to how its relationship to design. With the SysML Requirements dia- ram, visualization techniques are applied from the early phases of ystem development. The SysML Requirements diagram is a stereo- ype of the UML class diagram, as shown in Fig. 2.

.1. Relationships between requirements with SysML

Implementing all requirements in a single system release may e unattractive because of the high cost involved, lack of suffi- ient staff and time, and even client and market pressures. These ifficulties make prioritization a fundamental activity during the equirements Engineering process. Prioritizing requirements is iving an indication of the order in which requirements should be onsidered for implementation. However, it is not always possible o plan a system release based only on the set of more important equirements due to requirements relationships. A better knowl- dge of requirements relationships may be useful to make more

easible release plans, to reuse requirements and to drive system esign and implementation.

The SysML Requirements diagram allows several ways to rep- esent requirements relationships. These include relationships for efining requirements hierarchy, deriving requirements, satisfying

<<metaclass>> UML4SysML::Class

<<Stereotype>> Requirement

- Text: String - Id: String

Fig. 2. Basic SysML Requirements diagram.

r requirements with SysML.

requirements, verifying requirements and refining requirements. The relationships can improve the specification of systems, as they can be used to model requirements. The relationships: hierar- chy, derive, master/slave, satisfy, verify, refine and trace are briefly explained as follows.

In large, complex systems, it is common to have a hierarchy of requirements, and their organization into various levels helps in dealing with system complexity. For instance, high-level business requirements may be gradually decomposed into more detailed software requirements, forming a hierarchy. Discovering the hier- archy of requirements is an important design step in Requirements Engineering. SysML allows splitting complex requirements into more simple ones, as a hierarchy of requirements related to each other (represented by the symbol ⊕). The advantage is that the complexity of systems is treated from the early beginning of devel- opment, by decomposing complex requirements.

The concept of hierarchy also permits the reuse of require- ments. In this case, a common requirement can be shared by other requirements. The hierarchy is built based on master and slave requirements. The slave is a requirement whose text property is a read-only copy of the text property of a master requirement. The master/slave relationship is indicated by the use of the copy keyword.

The derive relationship relates a derived requirement to its source requirement. During Requirements Engineering activities, new requirements are created from previous ones. Normally, the derived requirement is under a source requirement in the hierarchy. In a requirements diagram, the derive relationship is represented by the keyword deriveReqt.

The satisfy requirement describes how a model satisfies one or more requirements. It represents a dependency relationship between a requirement and a model element, such as other SysML diagrams, that represents that requirement. This relationship is represented by the keyword satisfy. One example is to associate a requirement to a SysML Block diagram.

The verify relationship defines how a test case can verify a requirement. This includes standard verification methods for inspection, analysis, demonstration or test. For example, given a requirement, the steps necessary for its verification can be summa-

rized by a state-machine diagram. The keyword verify represents this relationship.

The refine relationship provides a capability to reduce ambigu- ity in a requirement by relating a SysML Requirement to another

M.d.S. Soares et al. / The Journal of System

Table 2 A SysML hierarchy requirements table.

m b c T r t o r

s s a d a r

6

s t m

c i r r o r w k i s c d m a t t g a t

t t p i b

6

p T T t e

e

Id Name Type

odel element. This relationship is typically used to refine a text- ased requirement with a model. For example, how a Use Case an represent a requirement in a SysML Requirements diagram. he relationship is represented in the diagram by the keyword efine. The refinement is distinguished from a derive relationship in hat a refine relationship can exist between a requirement and any ther model element, whereas a derive relationship is only between equirements.

The trace relationship provides a general purpose relation- hip between a requirement and any other model element. Its emantics has no real constraints and is not as well-defined s the other relationships. For instance, a generic trace depen- ency can be used to emphasize that a pair of requirements re related in a different way not defined by other SysML elationships.

.2. SysML Requirements table

Requirements traceability is an important quality factor in a ystems’s design. Basically, requirements traceability helps in iden- ifying the origin, destination, and links between requirements and

odels created during system development. Identifying and maintaining traces between requirements are

onsidered important activities during Requirements Engineer- ng (Gotel and Finkelstein, 1994; Sahraoui, 2005). The activity of equirements tracing is very useful, for example, to identify how equirements are affected by changes. For instance, in later devel- pment phases a requirement may be removed, and the related equirements may also be deleted or reallocated. Another case is hen a requirement has changed and the stakeholders need to

now how this change will affect other requirements. Traceabil- ty also helps to ensure that all requirements are fulfilled by the ystem and subsystem components. When requirements are not ompletely traced to the specific design elements, there is a ten- ency to lose focus as to the specific responsibility of each design odel. This can lead to costly changes late in the life cycle and can

lso lead to incorrect or missing functionality in the delivered sys- em. As a matter of fact, important decisions on requirements and he correspondent models are better justified when traceability is iven proper attention (Ramesh and Jarke, 2001). One way to man- ge the requirements traceability in SysML is by using requirements ables.

SysML allows the representation of requirements, their proper- ies and relationships in a tabular format. One proposed table shows he hierarchical tree of requirements from a master one. The fields roposed for Table 2 are the requirement’s ID, name and type. There

s a table for each requirement that has child requirements related y the relationship hierarchy.

.3. SysML Use Case diagram

The Use Case diagram shows system functionalities that are erformed through the interaction of the system with its actors. he idea is to represent what the system will perform, not how.

he diagrams are composed of actors, Use Cases and their rela- ionships. Actors may correspond to users, other systems or any xternal entity to the system.

The SysML Use Case diagram is derived without important xtensions from the UML Use Case diagram. The main difference

s and Software 84 (2011) 328–339 333

is the wider focus, as the idea is to model complex systems that involve not only software, but also other systems, personnel, and hardware.

The detailed sequence of events in a use case can be represented in different manners. It is common to describe the sequence of events in structured language based on a pre-defined pattern, or by using Activity diagrams (Almendros-Jimenez and Iribarne, 2005), Sequence diagrams (Almendros-Jimenez and Iribarne, 2007), or Petri nets (Soares and Vrancken, 2008b). Within SysML, a Use Case may also be related to a SysML Requirements diagram. Which of these techniques to use depends on the intended reader and the development phase.

One important limitation of Use Cases diagrams is that their focus is on specifying only functional requirements. Non-functional requirements, such as performance, and external requirements, such as interfaces, which are fundamental in software-intensive systems, are not well-represented by Use Case diagrams.

7. Extensions to SysML Requirements diagram and tables

SysML is a highly customizable and extensible modeling lan- guage (OMG, 2008). Organizations that develop systems for several different domains may create a profile for each domain. Profiles may specialize language semantics, provide new graphical icons and domain-specific model libraries. When creating profiles, it is not allowed to change language semantics; normally profiles may only specialize and extend semantics and notations.

The basic SysML Requirements diagram is extended in this sec- tion. The purpose is to try to address the identified shortcomings presented in Table 1. The first extension is performed by cre- ating stereotypes of stereotypes, in which case they are named sub-stereotypes (Section 7.2). Sub-stereotypes are similar to class inheritance in UML: they inherit any properties of their super- stereotypes, and add their own. These stereotypes are used to express the different types of user requirements proposed in Sec- tion 7.1. The second extension is to add properties besides the two default ones (Id and Text) (Section 7.3). The third extension is about grouping related requirements (Section 7.4). The last extension is to extend the SysML Table to provide requirements in a tabular format (Section 7.5).

7.1. User requirements classification

A common classification proposed for requirements in the literature is based on the level of abstraction, in which require- ments are classified as functional or non-functional (Robertson and Robertson, 2006). Functional requirements describe the ser- vices that the system should provide, including the behavior of the system in particular situations. Non-functional requirements are related to emergent system properties such as safety, reliability and response time. These properties cannot be attributed to a single system component. Rather, they emerge as a result of integrating system components. Non-functional requirements are also consid- ered quality requirements, and are fundamental to determine the success of a system.

A table of contents of a requirements specification with the following requirements items: external interfaces, functions, per- formance, logical database, design constraints, and software system attributes, is suggested in IEEE (1998). For sake of simplicity, and as

some of the items can be considered non-functional requirements (performance, design constraints and software system attributes), or functional requirements (logical database), the second classifi- cation used in this article (after user vs. system requirements) is as follows (Soares and Vrancken, 2008a):

334 M.d.S. Soares et al. / The Journal of System

F m

•

•

•

7

e c f e t

r a I e S H r

7

n v a e s

g S a o t b e

p r

ig. 3. Extension to SysML Requirements diagram using the proposed user require- ents classifications.

Functional: describes what the system should do, how the sys- tem should react to particular inputs, and how the system should behave in particular situations (the functionalities). Non-functional: are related to emergent system properties, such as reliability and performance. These requirements do not have simple yes/no satisfaction criteria. Instead, it must be determined whether a non-functional requirement has been satisfied. External: a detailed description of all inputs into and outputs from the software system, such as system, user, hardware, software and communication interfaces. It is an important classification to decompose the system into subsystems, helping in the identifi- cation of system architecture.

.2. Types of requirements

Stereotypes are the main mechanism used to create profiles and xtensions to the SysML metamodel. A stereotype extends a meta- lass or another stereotype. A well-known example of a stereotype or the UML metamodel are the classes control, entity and boundary, ach one with its own graphical icon. When used in a class diagram, hese stereotypes improve semantics for the diagram readers.

According to the classification proposed in Section 7.1, three equirements stereotypes are proposed: functional, non-functional nd external interfaces (Fig. 3). The non-functional and External nterface requirements have the property “type” that may have sev- ral tagged values. Examples of possible values are Performance, ecurity and Efficiency for non-functional requirements, and User, ardware, Software and Communication for External Interface

equirements.

.3. Additional properties

Properties add information to elements of the model, and are ormally associated to tagged values encoded as strings. Tagged alues add extra semantics to a model element. Constraints may lso be used as semantic restrictions applied to elements. One xample of a constraint is the association of the “xor constraint” pecifying a restriction (exclusive or).

The Id and Text properties are default to the requirements dia- ram. As an addition, the following properties are proposed: Risk, ource, Priority, Responsible, Version/Date, and Relationship. These dditional properties are not mandatory and may appear in any rder. The requirements engineer may use all of them, some or just he original properties. The following paragraphs suggest a num-

er of tagged values to be attached to each property, and also an xplanation of each new property.

A risk is an uncertain event or condition that, if it occurs, has a ositive or negative effect on a project’s objectives (PMI, 2008). The isk property is related to the requirement risks. There are at least

s and Software 84 (2011) 328–339

two important values to be added that concern risks: the proba- bility of the risk becoming real and the effects of its occurrence. The extensions proposed attaches a tuple R = {P,I} to each require- ment, in which P indicates the probability and I is the impact of the effects of occurring that risk. The suggested values for P are: very low, low, moderate, high and very high. The suggested values for I are: insignificant, tolerable, serious, very serious or catastrophic. Numeric values can also be assigned, but may lead to confusion. The combination of both values can be used as input to strategies to manage project risks.

If the requirement is derived from another requirement, it is useful to know its source. The source property describes where the derived requirement originated. This information is important to trace requirements during system life cycle development.

One approach to prevent future problems, such as delays, is to create tables considering risk, probabilities of occurrence, priority and impact. Then, labels can be given to each requirement, as for instance, colors, which visually help managers to know more about the requirements. Better contingency plans can be created and also special attention given to critical requirements (for instance, improved testing, inspections or the use of formal methods and tools.).

According to the PMBOK (PMI, 2008), knowing which require- ments have high priority is useful for risk analysis and during system development. Prioritizing requirements is giving an indi- cation of the order in which requirements should be addressed. A review of requirements prioritization techniques can be found in (Greer, 2005). Some recommendations on how to prioritize requirements (or triage) can be found in (Davis, 2003). A well- performed prioritization provides better system release planning, based on balancing importance vs. effort. Ranking assignment is the simplest prioritization technique (Greer, 2005). Basically, it consists of dividing requirements into groups, giving to each requirement a label, such as (critical, standard, optional) or the MoSCoW labels. The number of groups may vary, but within a group, all require- ments have the same priority.

At least the main stakeholder directly responsible for the requirement should be known. In case there is more than one responsible stakeholder, the choices are to write all of them, or just write the most important. This information is represented in the responsible property.

The requirements version is useful to show if the require- ment was changed. This property is fundamental, as uncontrolled changes are a source of problems in Requirements Engineer- ing. In addition to the version, the date of creation/change is added.

In order to improve the activity of tracing requirements to design models, a property that relates the specific requirement to models of the design is added. Identifying and maintaining traces between requirements and design are considered important activ- ities in Requirements Engineering (Sahraoui, 2005).

The resulting SysML Requirement with the proposed extensions is depicted in Fig. 4.

7.4. Grouping requirements

By modeling requirements with SysML, system complexity is addressed from the early system design activities. Managing decomposition is a crucial task in order to deal with complexity. Requirements may be decomposed into atomic requirements, and may later even be related in the sense that together they are capa-

ble of delivering a whole feature, i.e., they are responsible for a well-defined subsystem.

SysML Requirements may be part of other SysML Require- ments, as a hierarchy (Soares and Vrancken, 2008a). Related SysML Requirements can be grouped into a single SysML Requirements

M.d.S. Soares et al. / The Journal of Systems and Software 84 (2011) 328–339 335

Fig. 4. Extension to the SysML Requirements diagram.

s s

7

t n t a o R t

8 S

o

a m a n S q f

8

r p

T A

Table 4 Hierarchy requirements table—TM4.

Id Name Type

TM5 Region-wide traffic management Functional TM6 Traffic flow managed optimally Functional

Table 5 Hierarchy requirements table—TM7.

Id Name Type

TM9 Simulation analytical models Functional TM12 Wide range tasks scenarios Functional

Table 6 Hierarchy requirements table—TM9.

The SysML refine relationship can be used to relate requirements

Fig. 5. Grouping requirements.

ub-package (similar to the UML Package diagram, which combines everal class diagrams), creating categories of requirements (Fig. 5).

.5. Extension to the SysML Table

Table 3 shows an example of requirements data expressed in a abular format. The proposed table shows the requirement Id, the ame of the requirement, to which requirement it is related (if any), he type of relationship and the requirement type. This allows an gile way to identify, prioritize and trace requirements. As a matter f fact, whenever a requirement is changed or deleted, the SysML equirements Relationship Tables (SRRT) are useful to show that his can affect other requirements.

. Case study: RTMS user requirements modeling with ysML

In this section, a modeling approach is applied to model the list f user requirements presented in Section 2.

From the Software Engineering point of view, the development nd maintenance of RTMS is a challenge due to many factors. The ost important ones are mentioned as follows. First, requirements

re frequently changed. The major reason is that the area of road etwork control is still largely uncharted territory (Vrancken and oares, 2010). Thus, algorithms, techniques and methods are fre- uently being developed by traffic engineers. In addition, policies or transportation are often being changed as well (Eurostat, 2006).

.1. SysML Requirements diagrams

The associated SysML Requirements diagram for the list of user equirements is depicted in Fig. 6. For the sake of simplicity, not all roperties are included.

able 3 SysML Requirements relationship table.

Id Name RelatesTo RelatesHow Type

Id Name Type

TM10 Access statistical data Functional TM11 Access transient data Functional

8.2. SysML Requirements tables

Tables 4–6 show SysML Requirements tables expressing hierar- chy for requirements TM4, TM7, and TM9.

The other proposed type of table (SRRT), relating requirements and their relationships for each SysML Requirements diagram is presented in Table 7.

8.3. SysML Use Case diagrams

The associated Use Case diagram concerning the Traffic Manager is depicted in Fig. 7.

8.4. Relationship between Use Cases and SysML Requirements diagram

to other SysML models (Soares and Vrancken, 2008a). For exam- ple, the requirements sub-package representing requirements TM5 and TM6 can be associated by the refine relationship to the Use Case Manage region-wide traffic flow, which means that the require-

Table 7 SysML Requirements relationship table for TM.

Id Name RelatesTo RelatesHow Type

TM7 Task/scenario frames {TM5, TM6} trace Functional TM8 Gather/interpret info. TM9 deriveReqt External TM13 Object task/scenario TM12 deriveReqt Functional

336 M.d.S. Soares et al. / The Journal of Systems and Software 84 (2011) 328–339

m for

m L a t g b

9. Discussion

Fig. 6. SysML Requirements diagra

ents are represented by the Use Case. Fig. 8 shows this example. ater, this Use Case can be detailed by including other Use Cases

nd relationships, or even by using other SysML diagrams, such as he Sequence diagram. As a result, one knows which Sequence dia- ram models a specific SysML Requirement, which narrows the gap etween requirements modeling and software design.

Fig. 7. Use Case diagram for Traffic Manager.

Traffic Management Stakeholders.

The list of desirable properties of requirements specification, shown in Table 1, is used again, this time to evaluate the approach

Fig. 8. Example of the refine relationship.

M.d.S. Soares et al. / The Journal of System

Table 8 List of requirements properties and representation techniques.

List of requirements SRDE SRRT

(M) Graphical modeling � � (M) Human readable � � (M) Independent towards methodology � � (M) Relationship between requirements � � (M) Relationship requirements/design � � (M) Requirements risks � � (M) Identify types of requirements � � (M) Priority between requirements � © (M) Non-functional requirements � � (M) Grouping related requirements � � (M) Consistency � � (M) Modifiable � � (M) Ranking requirements by stability � © (S) Solve ambiguity � � (S) Well-defined semantics � � (S) Machine readable � � (S) Correctness � � (S) Completeness � � (S) Verifiable � �

p e f E

S p “ e T m H “

w h p

UML and SysML present additional advantages over the graph-

(S) Traceable � � (S) Type of relationship requirements � �

roposed in this article (see Table 8). In the list, SRDE stands for the xtended version of the SysML Requirement diagram, and SRRT or an extended version of SysML Tables used for Requirements ngineering activities.

From the list, it is clear that the proposed user classification in ection 7.1 and the extensions in Section 7 fulfill almost all the roperties identified in Table 1. The partially fulfilled properties, Well-defined semantics” and “Solve ambiguity”, are not fulfilled ven when the extended SysML Requirements diagram and SysML ables are used. These properties are solvable by increasing for- ality for the modeling language, i.e., by using formal methods. owever, when using formal methods, other properties, such as

human readable” may be lost. In IEEE (1998), a list of characteristics that are expected for a soft-

are requirements document is given. To finalize the evaluation, ow each of these characteristics are addressed by the approach resented in this article is briefly presented as follows:

Correctness: According to IEEE (1998), no technique can ensure correctness. However, the SysML Requirements diagram provides the possibility of relating requirements to other design models, facilitating that the user can determine if the SRS correctly reflects the actual needs.

Unambiguity: Ambiguity can be solved with the use of formal methods (Hinchey et al., 2008). The issue is that natural language is ambiguous, but unavoidable in the early phases of Requirements Engineering.

Completeness: The proposed types for requirements are well-described with the extensions proposed for the SysML Requirements diagram and tables. Thus, all types of requirements can be modeled.

Consistency: Conflicts between requirements can be discovered by explicitly describing their relationships, and the type of each rela-

tionship. In addition, by grouping related user requirements, conflicts within a group of requirements and between groups can be discovered.

s and Software 84 (2011) 328–339 337

Ranked by importance: Typically, not all requirements are equally important. The approach presented in this article fulfill this characteristic by adding two proper- ties to the basic SysML Requirements diagram: Risk and Priority.

Ranked by stability: Stability can be expressed in terms of the number of expected/performed changes to any requirement. This is addressed in this article by controlling version and date of a requirement, through the addi- tional property Version/Date.

Verifiable: As ambiguity is not solved with the appli- cation of SysML, this characteristic is not fully present. However, the advantage of using SysML is the possibility of relat- ing SysML Requirements to formal design models that can be formally verified.

Modifiable: The requirements document is modifi- able if its structure and style are such that any changes to requirements can be made completely, and consistently, while retaining the structure and style. Expressing each requirement separately is highly desirable. This characteristic is addressed in this article by modeling requirements using a well-defined SysML Requirements diagram, and by organiz- ing the relationship between require- ments.

Traceable: A requirement is traceable if its origin is clear and if it is possible to refer to it in future development. The solu- tion proposed in this article is to create SysML Tables expressing the relation- ships between requirements and other design models.

The proposed approach presented in this article uses two SysML diagrams and SysML Tables. This is necessary because multiple aspects of user requirements modeling are covered, which is useful as multiple stakeholders are involved. Thus, the SysML Use Case provides systems’ view of functional requirements and actors, delimiting the system scope. Requirements relation- ships and properties are graphically represented using the SysML Requirements diagram, and SysML Tables gives a tabular format for requirements.

As UML in general and Use Cases in particular do not support goal-oriented modeling (Moody et al., 2010), future research will focus on comparing the proposed approach presented in this article with other techniques based on Goal-Oriented Modeling, such as i* (Yu, 1997) and KAOS (Dardenne, 1993). Both techniques support graphical modeling of requirements. The KAOS graphical notation is less complex and easier to use than i* and focus more on the late requirements phase (Quartel et al., 2009).

Goal-oriented modeling has been enthusiastically embraced by the Requirements Engineering research community but has so far had negligible impact on practice (Moody et al., 2010). As SysML is a UML profile, and UML is currently the de facto modeling language for software-intensive systems, SysML has already an advantage at least in terms of potential use.

ical notation i*. Unlike i*, which lacks explicit design rationale for its graphical conventions, SysML is well-defined. SysML is confor- mant to an official metametamodel, the MOF (OMG, 2006), while i* semantic constructs and grammatical rules are defined using nat-

3 ystem

u i

1

m s a t U

l f s m h s d r g a r

T r f t s e t o R r o

t s i s t m b a

R

A

A

A

A

A

B

B

B

B

C

38 M.d.S. Soares et al. / The Journal of S

ral language (Moody et al., 2010), which leads to problems of nconsistency, ambiguity, and incompleteness.

0. Conclusions

It is essential to have properly structured and controlled require- ents specifications that are consistent and understandable by

takeholders. This is addressed in this article by presenting an pproach to model and analyze a list of user requirements using he SysML Requirements diagram, the SysML Table, and the SysML se Case diagram.

As usual in system development, changes in requirements are ikely to happen, and using the SysML Requirements diagram is use- ul for developers to manage these changes. For instance, when a takeholder asks for a change in one specific requirement, using the any relationship types that describe traceability between models

elps to uncover possible impacts in other models. The relation- hips are also useful to aid in requirements prioritization in order to ecide which requirements should be included in a certain system elease. Another advantage of using the SysML Requirements dia- ram is to standardize the way of specifying requirements through defined semantics. As a direct consequence, SysML allows the

epresentation of requirements as model elements. In this article, a classification of user requirements is proposed.

hen, the SysML Requirements diagram is introduced and the equirements relationships are detailed. SysML Tables are use- ul to represent decomposition in a tabular form and to improve raceability, which is an important quality factor when designing oftware-intensive systems. The SysML Requirements diagram is xtended with new stereotypes including the proposed classifica- ion, which distinguish requirements as functional, non-functional r external. Some properties not presented in the original SysML equirements diagram are added in order to represent important equirements characteristics. These properties were chosen based n an extensive literature review.

Finally, requirements are important to determine the architec- ure. For instance, external requirements help in delimiting the ystem context in relation with its environment. When design- ng the architecture, at least part of the functional requirements hould be known. In addition, the non-functional requirements that he architecture has to conform with, such as portability, perfor-

ance, and other quality attributes (security, modifiability), should e made explicit. Domain architecture and software architecture re topics for future research.

eferences

bran, A., Bourque, P., Dupuis, R., Moore, J.W., Tripp, L.L. (Eds.), 2004. Guide to the Software Engineering Body of Knowledge—SWEBO, version edition 2004. IEEE Press, Piscataway, NJ, USA.

lmendros-Jimenez, J.M., Iribarne, L., 2005. Describing Use Cases with Activity dia- grams. In: Proceedings of the Metainformatics Symposium, pp. 141–159.

lmendros-Jimenez, J.M., Iribarne, L., 2007. Describing Use-Case relationships with sequence diagrams. Computer Journal 50, 116–128.

NSI/IEEE, 2000. ANSI/IEEE Std 1471 Recommended Practice for Architectural Description of Software-Intensive Systems.

VV, Auditing on RTMS, 2006. Private document made by Adviesdienst Verkeer en Vervoer.

eck, K., 1999. Extreme Programming Explained: Embrace Change. Addison–Wesley Professional, Boston, MA, USA.

erry, D.M., 2004. The inevitable pain of software development: why there is no silver bullet. In: Radical Innovations of Software and Systems Engineering in the Future, Lecture Notes in Computer Science, pp. 50–74.

oehm, B.W., 1973. Software its impact: a quantitative assessment. Datamation 19,

48–59.

rooks, F.P., 1987. No silver bullet: essence and accidents of software engineering. Computer 20, 10–19.

arlshamre, P., Sandahl, K., Lindvall, M., Regnell, B., Natt och Dag, J., 2001. An Indus- trial Survey of Requirements Interdependencies in Software Product Release Planning.

s and Software 84 (2011) 328–339

Cooper, K., Ito, M., 2002. Formalizing a structured natural language requirements specification notation. In: Proceedings of the International Council on Systems Engineering Symposium, Las Vegas, NV, USA, pp. 1–8.

Damian, D., Zowghi, D., Vaidyanathasamy, L., Pal, Y., 2004. An industrial case study of immediate benefits of requirements engineering process improvement at the Australian Center for Unisys Software. Empirical Software Engineering 9, 45–75.

Dardenne, A., van Lamsweerde, A., Fickas, S., 1993. Goal-directed requirements acquisition. Science of Computer Programming 20, 3–50.

Davis, A.M., 2003. The art of requirements triage. Computer 36, 42–49. Dedrick, J., Gurbaxani, V., Kraemer, K.L., 2003. Information technology economic per-

formance: a critical review of the empirical evidence. ACM Computing Surveys 35, 1–28.

Dijkstra, E.W., 2002. Cooperating Sequential Processes. Springer-Verlag, New York, NY, USA, pp. 65–138.

Eurostat, 2006. Keep Europe Moving—Sustainable Mobility for our Continent Mid- term Review of the European Commission’s 2001 Transport White Paper, Technical Report. European Commission—Directorate General Energy and Transport, Last accessed on the 22th of June, 2010.

van Genuchten, M., 1991. Why is software late? an empirical study of reasons for delay in software development. IEEE Transactions on Software Engineering 17, 582–590.

Gomaa, H., 2000. Designing Concurrent Distributed and Real-Time Applications with UML. Addison–Wesley, Boston, MA, USA.

Gotel, O.C.Z., Finkelstein, C.W., 1994. An analysis of the requirements traceability problem. In: International Conference on Requirements Engineering.

Greer, D., 2005. Requirements Engineering for Sociotechnical Systems. IdeaGroup, London, UK.

Hall, T., Beecham, S., Rainer, A., 2002. Requirements problems in twelve companies: an empirical analysis. IEE Proceedings for Software 149, 153–160.

Hinchey, M., Jackson, M., Cousot, P., Cook, B., Bowen, J.P., Margaria, T., 2008. Software engineering and formal methods. Communications of the ACM 51, 54–59.

Hofmann, H.F., Lehner, F., Requirements, 2001. Engineering as a success factor in software projects. IEEE Software 18, 58–66.

IEEE, 1998. IEEE Recommended Practice for Software Requirements Specifications, Technical Report.

Jacobson, I., 1992. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison–Wesley Professional, Reading, MA, USA.

Jacobson, I., 2004. Use cases—yesterday, today, and tomorrow. Software and System Modeling 3, 210–220.

Juristo, N, Moreno, A.M., Silva, A., 2002. Is the European industry moving toward solving requirements engineering problems? IEEE Software 19, 70–77.

Kamsties, E., 2005. Understanding ambiguity in requirements engineering. In: Aurum, A., Wohlin, C. (Eds.), Engineering and Managing Software Requirements. Springer-Verlag, Berlin, Germany, pp. 245–266.

Komi-Sirviö, S., Tihinen, M., 2003. Great challenges and opportunities of distributed software development—an industrial survey. In: Proceedings of the Fifteenth International Conference on Software Engineering & Knowledge Engineering (SEKE’2003), pp. 489–496.

Laplante, P.A., 2004. Real-Time Systems Design and Analysis, 3rd ed. John Wiley & Sons, Haboken, NJ.

Luisa, M., Mariangela, F., Pierluigi, I., 2004. Market research for requirements analysis using linguistic tools. Requirements Engineering 9, 40–56.

Lutz, R.R., 1993. Analyzing software requirements errors in safety-critical embedded systems. In: Proceedings of the IEEE International Symposium on Requirements Engineering, pp. 126–133.

Minor, O., Armarego, J., 2005. Requirements, engineering: a close look at indus- try needs and model curricula. Australian Journal of Information Systems 13, 192–208.

Moody, D.L., Heymans, P., Raimundas Matulevičius, R., 2010. Visual syntax does mat- ter: improving the cognitive effectiveness of the i* visual notation. Requirements Engineering 15, 141–175.

OMG, 2006. Meta-Object Facility (MOF) Core Specification—Version 2.0. OMG, 2008. Systems Modeling Language (SysML)—Version 1.1. Page, V., Dixon, M., Bielkowicz, P., 2003. Object-Oriented Graceful Evolution Mon-

itors, Object-Oriented Graceful Evolution Monitors, volume 2817 of Lecture Notes in Computer Science. Springer, pp. 46–59.

Parviainen, P., Tihinen, M., Lormans, M., van Solingen, R., 2004. Requirements Engi- neering: Dealing with the Complexity of Sociotechnical Systems Development. IdeaGroup Inc, pp. 1–20.

PMI, 2008. A Guide to the Project Management Body of Knowledge, 4th ed. PMI, Pennsylvania, USA.

Pressman, R.S., 2009. Software Engineering: A Practitioner’s Approach. McGraw-Hill, Inc., New York, NY, USA.

Quartel, D., Engelsman, W., Jonkers, H., Van Sinderen, M., 2009. A goal-oriented requirements modelling language for enterprise architecture. In: EDOC’09: Pro- ceedings of the 13th IEEE International Conference on Enterprise Distributed Object Computing. IEEE Press, Piscataway, NJ, USA, pp. 1–11.

Ramesh, B., Jarke, M., 2001. Toward reference models for requirements traceability. IEEE Transactions on Software Engineering 27, 58–93.

Robertson, S., Robertson, J., 2006. Mastering the Requirements Process, 2nd ed.

Addison–Wesley Professional, New York, NY, USA.

Sahraoui, A.E.K., 2005. Requirements traceability issues: generic model, method- ology and formal basis. International Journal of Information Technology and Decision Making 4, 59–80.

Simons, A.J.H., 1999. Use cases considered harmful. In: TOOLS 99: Proceedings of the Technology of Object-Oriented Languages and Systems, pp. 194–203.

ystem

S

S

S

S T

T

V

W

Y

M t S i N

M.d.S. Soares et al. / The Journal of S

oares, M.S., Vrancken, J., 2007. Requirements specification and modeling through SysML. In: Proceedings of the 2007 IEEE International Conference on Systems, Man and Cybernetics, pp. 1735–1740.

oares, M.S, Vrancken, J., 2008a. Model-driven user requirements specification using SysML. Journal of Software 3, 57–68.

oares, M.S., Vrancken, J., 2008b. Responsive traffic signals designed with time petri nets. In: Proceedings of the 2008 IEEE International Conference on Systems, Man and Cybernetics, pp. 1942–1947.

ommerville, I., 2010. Software Engineering, 9th ed. Addison–Wesley, Essex, UK. he Standish Group, 2003. CHAOS Chronicles v3.0, Technical Report. The Standish

Group, Last accessed on the 20th of June, 2010. iako, P.F., 2008. Designing Software-Intensive Systems: Methods and Principles,

1st ed. IGI Global, Hershey, NY, USA. rancken, J., Soares, M.S., 2010. Intelligent Road Network Control. Springer, The

Netherlands, pp. 311–325. irsing, M., Banâtre, J.P., Hölzl, M.M., Rauschmayer, A. (Eds.), 2008. Software-

Intensive Systems and New Computing Paradigms—Challenges and Visions, vol. 5380 of Lecture Notes in Computer Science. Springer.

u, E.S., 1997. Towards modelling and reasoning support for early-phase require- ments engineering. In: Proceedings of the International Symposium on Requirements Engineering, Annapolis, MD, pp. 226– 235.

ichel dos Santos Soares obtained a BSc degree in Computer Science from he Federal University of São Carlos, Brazil, in 2000, a MSc degree in Computer cience from the Federal University of Uberlândia, Brazil, in 2004, and a PhD n Software Engineering from the Delft University of Technology, in Delft, The etherlands. Since 2010 he is an Assistant Professor at the Federal University of

s and Software 84 (2011) 328–339 339

Uberlândia, Brazil. His research interests include Modeling and Analysis of Software- Intensive Systems, Software Architecture, Requirements Engineering, and Software Quality.

Jos Vrancken obtained a masters degree in Mathematics from the University of Utrecht, in 1982, and a PhD degree in Computer Science from the University of Amsterdam in 1991. Since 1991, he was employed by the Dutch government as a systems architect in the fields of road traffic and water management. Since 2003, he is an Assistant Professor at Delft University of Technology in the use of IT in the design, maintenance and exploitation of infrastructures, with emphasis on the road and the data communicatons infrastructures.

Alexander Verbraeck is a Full Professor of Systems and Simulation at the Fac- ulty of Technology, Policy and Management of Delft University of Technology, The Netherlands. In addition, he is part-time Research Professor in Supply Chain Man- agement at the R.H. Smith School of Business of the University of Maryland in the USA. He has a BS in Mathematics, and an MSc and PhD in Computer Science, all from Delft University of Technology. His research focuses on discrete-event simulation, serious gaming and training, logistics and transportation, and project management. He is a member of the Center for Project Management at TU Delft, and he is heavily involved in project management research and training for industry. As a co-director

of TU Delft’s serious gaming institute, he researches novel applications of interactive simulation and virtual worlds. Many of his multi-year research projects have been funded by national programs and by the European Union. His applied research in simulation and gaming has been funded by many organizations. He presented over 100 refereed papers at conferences, wrote close to 20 book chapters, and published his work in a number of international journals.