Progetto finale corso Requirements Engineering
Anteprima
ESTRATTO DOCUMENTO
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
I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher tito1992 di informazioni apprese con la frequenza delle lezioni di Requirements Engineering e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Trento - Unitn o del prof Perini Anna.
Acquista con carta o conto PayPal
Scarica il file tutte le volte che vuoi
Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato