Progetto finale corso Requirements Engineering

Figure 5: Actor Diagram - Early Requirements

3.3 Goal diagram analysis

We guided the goal diagram analysis by answering the following questions:

Can a goal/plan be decomposed into sub-goal/plan so that the

• root goal/plan can be achieved only once I’ll have achieved all

the sub-goals (plans)? The plan of is decomposed

organazing a trip

in three sub-goals by using an Each sub-goals are

and decomposition.

decomposed thanks to both and decomposition and in

or decomposition

other sub-goals.

Can a goal/plan be achieved in alternative ways? It has been used

• to let a goal being achived in alternative ways. This

or decompositions

is the case of the following goals: Find equipment, Location requirements

and Event requirements.

What are the plans/resources/softgoals that provide means for

• achieving the goal? They are: By using a platform, Event requirements,

and

Location requirements Equipment requirements collection.

19

Are there goals that can contribute positively or negatively in

• reaching the analyzed goal (plan)? The goals which can contribute

positively in reaching a goal are: Safety payment, Effective organization,

and

Flexibility Enjoyable.

3.4 Goal diagram - Early req.

Goal dependency diagram - Early Re-

In the picture 6, it is shown the

quirements for the analyzed project. The main user actor is the Surfer.

Figure 6: Goal Diagram - Early Requirements

20

3.5 Actor diagram - Late req.

Actor dependency diagram - Late Re-

In the picture 7, it is shown the

quirements for the analyzed project. There are four domain actors, which are:

and the

Surfer, Equipment provider, Surf school Surf event organizer.

system-to-be actor, Surf

In this actor diagram, we have introduced the the

Easy platform. In this way, we have analyzed the dependencies with actors in its

environment identifying system’s functional and non-functional requirements.

Figure 7: Actor Diagram - Late Requirements

21

3.6 Goal diagram of the system-to-be actor - Late req.

Goal diagram - Late Requirements

In the picture 8, it is shown the for

System-to-be actor:

the analyzed project. It is analyzed the In

Surf Easy.

particular, the picture shows which are its goals and how to reach them by using

plans, soft-goal and resources.

Figure 8: Goal Diagram - Late Requirements

22

3.7 Class diagram

In figure 9, it is shown the class diagram for the main entities of the application

domain. We can describe them briefly:

it is the one who has access to the system, after register on it, by

Surfer:

• using user-name and password. He can take part in events, can contact

the surf schools (and buy packages from them). He has the possibility

also to have access to the catalogue of first hand (where he can buy/rent

equipment) and second hand shop (where he can buy/sell and rent equip-

ment). he is responsible of creating an event (with

Event organizer: description,

• and These events are included into a calendar, ac-

date, location price).

cessible by the surfer.

it has packages to offer to the surfers. Packages can include:

Surf school:

• and from the surfer.

events, surf lessons, accomodation item to rent/buy

he is responsable of the managment of a catalogue

Equipment provider:

• where all the items to be rent/sell/bought are listed. The items are

first hand shops,

grouped by sections. In case of they can just sell

second hand shops,

and rent out items. In the case of they can buy,

sell and rent out the items.

Figure 9: Class Diagram

23

3.8 Requirements revision

In this second part of the documentation, several requirements have been

revisited. This due the analysis done till now which pointed out some possible

changes usable to be made. In this way, the system might result more compact

and functional.

In this section, you can find the screenshots of the traciability matrices used

for this assignment.

3.8.1 Traceability matrices

This subsection shows different traciability matrices which help the reader to

understand better the dependencies between requirements and how the previous

requirements have been modified. Finally, a traciability matrix with relations

between requirements and goals is also described.

24

3.8.2 Dependencies between requirements

Traceability matrix

In figure 10 you can see the which shows the dependencies

between requirements. The matrix shows the relations between the requirements

in the row and the ones in the columns. These dependencies mean that some

functionalities of the platform cannot be performed without the presence some

other ones.

Figure 10: Traceability matrix: requirements dependences

25

3.8.3 Changed requirements matrix

Figure 11 shows which requirements have been changed, added and deleted. An

exaplanation is described as well.

Figure 11: Traceability matrix: modifications of requirements

26

3.8.4 Dependencies between goals and requirements

Figure 12 shows the dependencies between the requirements identified in the

platform and the main goals/plans in the GO model (late requirements). The

matrix underlines with an "x" when the goal element provide a rationale for the

requirement.

Figure 12: Traceability matrix: dependencies between goals and requirements

27

4 Part III

In this section of the document, it will be presented the system risks identified

in the project and their model with RiskML. Then, it will be presented the

requirements prioritization of a sub-set of 10 chosen requirements. It will follow

a discussion about how the privacy law impact on relevant goals identified in

the platform.

The section will end with the identification of security requirements in the

project and how the requirements have been verified and validated.

4.1 Risk analysis

This section is about risks analysis and how the risks identified in this context

impact the overall project. The main risks (and the relative indicators and

possible treatments) are discussed and shown below.

Customers stop booking services from the platform

1. (for example:

booking surf schools, finding appropriate surf location, buy equipment,

join events). This is a The RiskML model of this risk

security risk.

is shown in the schema 13. The results of this action will impact in a

negative way all the actors involved in the system. The main situations

(and related indicators) which generate the likelihood and significance of

events are the following:

a. Lack of feedbacks for a specific service or seller (this makes possible

the achievement of an event).

Indicators:

i. Counting the number of feedbacks left by users for a specific

service

b. Unsafe payment methods (this makes critical an event).

Indicators:

i. Numbers of complains received by users

ii. Statistics about attacks on web-sites

c. Good feedbacks for a particular seller (this reduce the impact an

event has on the system).

Indicators:

i. Percentage of good feedbacks left by users

Treatments:

Send an e-mail notification to the user (to remind him to leave a

• feedback after he has bought a service)

Use secure protocols for the payment (for example HTTPS)

• 28

Figure 13: Risk 1 - Customers stop booking services from the platform

Problems with pages loading

2. (for example: slow loading time, grapichal

elements not visible in all the browsers, etc.). This is a maintenance risk.

The RiskML model of this risk is shown in Figure 14. The results of this

action will impact in a negative way the system’s user. The main situations

(and related indicators) which generate the likelihood and significance of

events are the following:

a. Slow Internet connection (this makes possible the achievement of an

event).

Indicators:

i. Check the number of users who are using the platform at the

same time

b. High quality images and lots of graphical elements (this makes critical

an event).

Indicators:

i. Check the size of images uploaded by users in the platform

ii. Gather information about usability and minimalist design

c. Newest browsers do not support (or behave in a different way) some

Javascript functions (this makes possible the achievement of an event).

Indicators: 29

i. Make researches to check how to implement same functionalities

in different browsers

ii. Check reports sent by users

Treatments:

Restrict to the user and service providers the possibility to upload

• picture up to a certain size

Suggest to the user which browser is better to be used

• Avoid network congestion

• Figure 14: Risk 2 - Problems with pages loading

30

The server crashes.

3. If this happens, the whole community will stop

working and nobody will be able to do any kind of operations within the

platform. This is a The RiskML model of this risk is

maintenance risk.

shown in Figure 15. The results of this action will impact in a negative

way the whole community that uses the system. The main situations (and

related indicators) which generate the likelihood and significance of events

are the following:

a. Part of the hardware does not work anymore (this makes critical an

event).

Indicators:

i. Check the hardware’s status periodically

ii. Check the server’s logs to determine the hardware’s errors

iii. Statistics and documentation about the most stable servers which

can be used

b. Software errors (this makes critical an event).

Indicators:

i. Statistics and documentation about the most stable servers which

can be used

ii. Make researches to check how to implement same functionalities

in different browsers

Treatments:

Use more performant servers

• Use services which prevent software problems

• Find employees responsible for system’s maintenance

• 31

Figure 15: Risk 3 - The server crashes

From the risks analysis above, there are some new requirements which can

be introduced in the system to make it more stable, secure and performant. The

new requirements are the following:

must

1. The system send an e-mail to the user who booked a specific service

in order to remind him to leave a feedback. It would be helpful for the

community must

2. The system prevent its users to upload images over a certain size

should

3. The system show a message to the users to let him know which

browser is not supported by the platform

32

4.2 Requirements prioritization

In this subsection we will go into the requirements prioritization. For doing so,

we decided to take 10 random requirements (see Table 2.5.5) and analyse their

prioritisation in terms of importance to the user and complexity of implemen-

AHP based pairwise

tation for the developer. As the method we used the

comparison. In order to implement the AHP method for both user and devel-

oper we fill in 2 tables from the different point of view.

Figure 16: Requirements prioritization: importance for the user

After making the normalization of 16, the result of the AHP method showed

that several requirements should be given more priority than the others: FUN8,FUN13,FUN2

because we ranked them as more important for the user or the platform.

33

After this first analysis, we started to focus our attention in the table 17;

identifying the effort required for the developer to develop those requirements.

Figure 17: Requirements prioritization: complexity of implementation for the

developer 34

Once we have normalized both table 16 and 17, we created the diagram in 18.

We built a plot diagram having as "x-axis" the criterion "value for the user" (x-

criterion), and as "y-axis" the development complexity (y-criterion). We plotted

the requirements as (x,y) points depending on their value with respect to the

x-criterion and y-criterion.

Figure 18: Prioritization of requirements

According to the diagram 18 we see that one requirement FUN8 has the most

priority according to the importance for the user and complexity of development

from our point of view. Beside FUN8, there are also FUN7 and FUN2 which

require more effort to be implemented by developers (compared to the other re-

quirements). All the other requirements are not so complex to develop. Overall

speaking the requirements which are more important to the user are also those

ones which require more implementation efforts.

35

4.3 Privacy law

In this subsection we discuss about how the privacy law impact on the relevant

goals in our LR goal model. We then clarified how we ensure to be compliant.

More specifically, privacy law will impact the requirements for the using of

Surf Easy online platform in 3 occasions: 1) registration of a user in the system

(creating a new account), 2) using private user’s data in order to recommend

him/her other services based on user’s previous bookings/orders or geolocation,

3) online payment (sending the secure private and banking information to the

3rd party payment system for making online payments when booking services

on the platform).

4.3.1 Registration of the user account

Surf Easy is an online platform where the user creates an account which will work

for his/her authentication and identification during the work in the platform.

So in order to use the platform and create an account the user should give

some private information, such as name, surname, age, address, telephone and

cellular number, e-mail address, his surfing level and some other data that may

be used for different purposes.

Registration data shall be stored in the user database and will be used for

authentication purposes only. Surf Easy will notify the user whose data will

not be disclosed and will be processed only for the purpose of reaching user’s

goals when using the system. When registering, the user will have to share his

personal data and also will have to read and agree with terms and conditions of

using the system, where the system owners will list all terms and conditions ac-

cording to the current laws as well with notification of safety and non-disclosure

of the personal data. User will have to check the “I agree” button in order to

proceed with the registration. Also the platform will offer the user to subscribe

to the system’s email notifications. According to the E-Communications privacy

directive 2002/58/EC as well as to the data retention directive (2006/24/EC)

one of the main principles is on electronic marketing which requires organisa-

tions to obtain prior consent before sending electronic marketing messages to

consumers (see Section 130). So each user will be asked to confirm his email

subscription to the messages of Surf Easy platform. WIthout user’s agreement

Surf Easy will not send email notifications.

4.3.2 Recommendations of services to the user for booking

Online platform will notify and get consent from the user that his personal data,

geolocation and history of previous choices stored in the system’s database will

be used for recommendation service for future user’s bookings. According to

Section 37 of Legislative Decree no. 196/2003 of Data Protection Code, “a

data controller shall notify the processing of personal data it intends to perform

exclusively if the said processing concerns any of the following:

a. genetic data, biometric data, or other data disclosing geographic loca-

tion of individuals or objects by means of an electronic communications

network; 36