Progetto finale corso Requirements Engineering

FUN4. must

The system provide a rating system which let users to give FUNCTIONAL

feedbacks, by using a text area and a likert scale

FUN5. should

The system make an avarage of the ratings given to a FUNCTIONAL

particular item by all the users, within 3 seconds.

NFR5. must

The system be accessible, in less than 1 minute, by all NON FUNCTIONAL

the users through an Internet connection, over the HTTP protocol.

FUN6. shall

The system show to the user (once he/she has selected FUNCTIONAL

a result from the research) the feedbacks written by other users.

FUN7. must

The system allow to the user to book an accomodation at FUNCTIONAL

the selected place.

FUN8. must

The system allow to the user to book surfing lessons in a FUNCTIONAL

specified place.

FUN9. must

The system provide to the user the possibility to check

where a surf school and the accomodation are located, by using a FUNCTIONAL

search bar.

NFR6. must

The system use Google API. In this way, it lets the users

to check the location of surf schools and accomodations, by showing NON FUNCTIONAL

them on a world-map. 16

Requirement Type

FUN10. must

The system provide four authentication levels (common

user, event organizer, surf teacher and equipment provider), based on FUNCTIONAL

the role of the user going to use the platform.

FUN11. must

The system provide search menu for surf spots including

3 levels: continent, country and surf spot. This is achieved by using FUNCTIONAL

a drop down menu.

FUN12. must

The system provide to the user the list of events in FUNCTIONAL

particular location (of user’s choice) within 10 seconds.

FUN13. must

The system provide the possibility for the user to sign-up

into the system using his/her Facebook account, if it is the first time FUNCTIONAL

he is using the system.

FUN14. must

The system provide a search menu for surf events and a FUNCTIONAL

possibility for user to sort events by location, type of events, price.

FUN15. The system must provide the user with possibility to see who FUNCTIONAL

else is registered for an event.

FUN16. must

The system provide the user with the map of surf spots FUNCTIONAL

in requested area.

FUN17. must

The system provide the user with the recommendation of FUNCTIONAL

nearby spots.

FUN18. must

The system provide the possibility for the user to upload FUNCTIONAL

photos and videos related to specific surf spot by drag and drop method.

FUN19. shall

The system show to the user a calander where are posted the FUNCTIONAL

surf events in the selected days.

FUN20. must

The system allow to the user to buy/sell surf equipment. FUNCTIONAL

FUN21. must

The system allow to the user to book surf events. FUNCTIONAL

FUN22. shall

The system give recommendations to the user based on FUNCTIONAL

history of search, history of bookings and user’s geolocation.

Table 4: Set Of Requirements

3 Part II Goal-

In this section of the document, it will be explained and illustrated the

Oriented analysis. actor diagram, goal diagram

It will follow: the the

class diagram.

and the

In the model designed, we have analyzed each both hard goals and soft goals.

We can say that all the hard goals have clear criteria for deciding when they are

satisfied. Turning into the soft-goals, all of them do not have any clear criteria

to decide if they can be satisified or not. traceability

The section will end with the definition and explanation of the

matrices. 17

3.1 Actor diagram analysis

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

Which are the main stakeholders and existing systems (actors)?

• Mainly, the system is composed by the following actors: Surfers, Equip-

ment providers, Surf school, Surf event organizer;

What’s their role in the part of the organization we are consid-

• ering?

– It is the main actor responsible for booking a surf destination

Surfer:

where he can go to surf. He can choose to buy the equipment he needs

and join the events he wants to take part of during his vacation;

– It is the shop (or shops) which posts all the

Equipment provider:

offers available related to the equipment the surfer can think to buy.

They are both first hand and second hand online shops;

– It is the place/places where the sufer can book surf

Surf school:

lessons and can ask for an accomodation during his vacation;

– It refers to the people who has the puropose of

Surf event organizer:

organizing surf events which can be joined by surfers.

What are the goals and soft goals of these actors?

• – has one hard goal:

Surfer Organize a surf vacation

– has one hard goal:

Equipment provider Provide equipment

– has one hard goal:

Surf school Give lessons

– has one hard goal:

Surf event organizer Organize events

How can they achieve them? (can they do it by themselves? Do

• they have the plan and resources needed?) All the actors need to

use a web platform. It will connect all of them, helping them to achive

their goals.

Does an actor depend on another one to achieve its goals? The

• needs to contact the to get the equipment he

surfer Equipment provider

wishes and to sell the used one.

provide some locations where the surfer can go and stay over

Surf school

the nights. Also, it also offers lessons to the surfer.

The creates events which the surfer can join during

Surf event organizer

his staying.

3.2 Actor dependency diagram - Early req.

Actor dependency diagram - Early

In the Figure 5, it is shown the

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

are: and the All

Surfer, Equipment provider, Surf school Surf event organizer.

the relationships between them are shown: and

goals, softgoal resources.

18

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 requir