SAFE GROUP
REQUIREMENT SPECIFICATION
ACTORS
Primary Actors




Person: someone about who the System has information
User: a person belonging to the community. She/he can use most of the functionalities
of the System, such as writing messages or viewing another person’s
information
Administrator: A privileged user who can manage users insertion and deletion, the
deletion of messages, the creation of polls and can send E-Mails to all the
community
Founder: it is the person who founded the community, and has all the privileges of
the administrator, and can remove other administrators. He also initializes the
community, setting the requested options
Secondary Actors

E-Mail
SUMMARY LEVEL USE CASES
Manage evidences
Level: summary
Intention in context: A User updates the knowledge about other people inside or outside the System, and
can see the evidences already known by the System
Primary actor: User, Administrator
Main success scenario:
Based on the needs:
1. A User submits a new evidence (Submit an evidence)
2. A User justify a bad evidence (Justify a bad evidence)
3. A User adds an opinion about an evidence (Add an opinion about an evidence)
4. A User challenges an evidence (Challenge an evidence)
5. A User watches the list of messages associated with the evidences (Show the Messages)
Provide the safe community
Level: summary
Intention in context: granting that all the Users are trusted
Primary actor: Founder, Administrator, Person, User
Main success scenario:
1. The Founder sets up the community (Initialize the community)
Based on the needs:
1. The Founder promotes a user to administrator (Promote a User to the rank of Administrator)
2. An Administrator removes a bad user (Remove a bad user)
3. A Person asks to become a user (Become a user)
4. A User asks to see the list of persons (see the list of persons)
5. An Administrator sends a message to all the users (send a message to all users)
6. An administrator wants to be demoted to the rank of User (Remove an administrator)
7. The Founder wants to remove a bad administrator (Remove a bad administrator)
2
USER-GOAL USE CASES
Submit an evidence
Level: User-goal
Intention in context: A User adds an evidence to the community
Primary actor: User
Main success scenario:
1. The User asks the System if the person referred to the evidence is already known (Look for a
person)
2. The User inserts the description and the score of the evidence
3. The System gives the confirmation to the user, after creating a new evidence
4. If the person is also a user, the System sends him an E-Mail to inform him about the evidence
5. If the person is also a user, the System checks if that user is to be eliminated (Check user’s score)
6. The use case ends with success
Extensions:
1aa. If the person is not known to the system the user adds the person’s name and surname, country
(chosen from a list), address and one or more RFC822 compliant email addresses
1ab. One or more person’s attribute are not correct. The System asks the user to correct them
Justify a bad evidence
Level: User-goal
Intention in context: A User who received a bad evidence from another User, wants to justify her/his
behavior
Primary actor: User
Main success scenario:
1. The User selects the evidence to reply to (Browse the list of evidences)
2. The User justifies her/his behavior (Reply to a message)
3. The System confirms to the User that her/his justification was successfully inserted
4. The System sends an E-Mail to other Users
5. The use case ends with success
Challenge an evidence
Level: User-goal
Intention in context: A User who received an evidence from another User, wants to challenge the other
User’s opinions
Primary actor: Administrator, User
Main success scenario:
1. The User selects the evidence to reply to (Browse the list of evidences)
2. The User gives all the proofs she/he owns supporting the thesis that this evidence is not true (reply
to a message)
3. The System sends an E-Mail to the Administrators asking her/him to remove it
4. The Administrator removes the evidence
5. The use case ends with success
Extensions:
4a. The Administrator doesn’t think that the evidence is to be eliminated. He doesn’t remove the
evidence
3
Add an opinion about an evidence
Level: User-goal
Intention in context: A User reads another User’s evidence, and wants discuss about her/his opinion.
Primary actor: User
Main success scenario:
1. The User selects an evidence(Browse the list of evidences)
2. The User adds her/his message to the discussion associated with an evidence
3. The System confirm to the User that her/his opinion was successfully inserted
4. The System send an E-Mail to other Users that have discussed in this evidence
5. The use case ends with success
Promote a User to the rank of administrator
Level: User-goal
Intention in context: The Founder promotes a User to the rank of Administrator
Primary actor: Founder
Main success scenario:
1. The Founder chooses the user to be promoted to the rank of administrator
2. The System adds this user to the list of the administrators
3. The System confirms the promotion to the Founder
4. The System sends an E-Mail to the new administrator
5. The use case ends with success
Remove an administrator
Level: User-goal
Intention in context: An administrator asks the Founder to be removed from the community
Primary actor: Founder
Main success scenario:
1. The Founder tells the system which administrator is to be removed
2. The System confirms the removal to the Founder
3. The System sends an E-Mail to the old administrator
4. The use case ends with success
Remove a bad administrator
Level: User-goal
Intention in context: The Founder wants to remove a bad administrator
Primary actor: Founder, Users
Main success scenario:
1. The Founder proposes a poll to eliminate the administrator (Create a poll)
2. Users discuss about that person (Discuss about a person)
3. Users vote the proposed poll (Vote a poll)
4. The Founder tells the system which administrator is to be removed
5. The System confirms the removal to the Founder
6. The Founder removes the user from the community
7. The System confirms the removal to the Founder
8. The System sends an E-Mail to the removed Administrator
9. The use case ends with success
Extensions:
4a. The poll is negative: the Administrator is not removed from the community. The use case ends
with success
4
Initialize the community
Level: User-goal
Intention in context: The Founder sets the options of the System
Primary actor: Founder
Main success scenario:
1. The Founder tells the System if the users can abstain from voting
2. The Founder tells the System if an administrator can delete another administrator
3. The Founder tells the System how many contrary votes are needed to reject the entrance of a
person
4. The Founder tells the System the total score needed to be expelled
5. The Founder tells the System which is the maximum valid scores for an evidences
6. The Founder tells the System which is the minimum valid scores for an evidences
7. The use case ends with success
See the list of persons
Level: User-goal
Intention in context: A User wants to see the list of all the persons belonging to the community
Primary actor: User
Main success scenario:
1. The User ask for the list of the persons
2. The System show the list to the persons divided between users and persons but not users
3. The User chooses one of this persons and ask for details about her/him
4. The System show the details about that person
5. The use case ends with success
Send a message to all users
Level: User-goal
Intention in context: An Administrator sends a message to all the users of the community
Primary actor: Administrator
Main success scenario:
1. The Administrator tells the System the text of the message she/he wants to send
2. The System send an E-Mail to all the users
3. The System tells the Administrator that the E-Mail was sent
4. The use case ends with success
Show the messages
Level: User-goal
Intention in context: A User reads a message
Primary actor: User
Main success scenario:
1. A User asks the system to show her/him the list of the discussions
2. The System shows her/him the list of discussions
3. The User selects a discussion
4. The System shows her/him the list of the messages associated with that discussion
5. The use case ends with success
5
Become a user
Level: User-goal
Intention in context: A Person asks enter into the System
Primary actor: Person, Administrator, User
Main success scenario:
1. The Person fills a form with her/his personal data (name and surname, country, chosen from a
list, address and one or more RFC822 compliant email addresses) and asks the system to become
a part of the community, showing some good evaluations
2. The System send an E-Mail to an Administrator
3. The Administrator checks that the evaluations about that person are in the System
4. The Administrator checks that the evaluations presented by the Person are valid
5. The Administrator opens a discussion about the Person (Create a discussion)
6. Some Users adds its messages to the discussion (Reply to a message)
7. The Administrator starts a pool (Create a poll)
8. The Users who have an opinion about the person (who wants to enter into the community) vote
(Vote a poll)
9. After the expiry of the poll, if the poll is positive, the Administrator tells the System to add the
new User
10. The System confirms the success of the registration
11. The use case ends with success
Extensions:
4a. The Administrator send an E-Mail to the Person telling he that he can’t enter in the System
because his evaluations are not good
4b. The use case ends with success
9a. After the expiry of the poll, the poll is negative. The Administrator send an E-Mail to the Person
telling he that he can’t enter in the System because the poll was against him
9b. The use case ends with success
Remove a bad User
Level: User-goal
Intention in context: An Administrator wants remove a bad User
Primary actor: Administrator, User
Main success scenario:
1. The Administrator analyzes that User (Look for a Person)
2. The Administrator opens a discussion about that User (Create a discussion)
3. Some users add some messages to the discussion (Reply to a message)
4. The Administrator starts a pool (Create a poll)
5. The Users vote (Vote a poll)
6. After the expiry of the poll, the System sends to all the Users a confirmation about the deletion of
the User
7. The use case ends with success
Extensions:
6a1.
After the expiry of the poll, if the poll is in favor of the suspected User, the System
doesn’t delete her/him
6a2.
The use case ends with success
6b1.
The User to be deleted is also an Administrator. The System doesn’t delete him
automatically, but asks the Founder to do that
6b2.
The use case ends with success
6
SUBFUNCTIONAL-GOAL USE CASES
Delete a false evidence
Level: Subfunction
Intention in context: A User inserted a wrong or false evidence and this evidences must be eliminated
Primary actor: Administrator
Main success scenario:
1. The Administrator chooses which evidences must be eliminated
2. The System removes the evidences
3. The System notifies the Administrator that the operation ended successfully
4. The use case ends with success
Create a poll
Level: Subfunction
Intention in context: An Administrator starts a new poll
Primary actor: Administrator
Main success scenario:
1. The Administrator asks the System to create a new poll and specifies the start and end date, the
title and the description of the poll
2. The System sends an E-Mail to all the users asking them to participate in the poll
3. The System notifies the Administrator that the operation ended successfully
4. The use case ends with success
Vote a poll
Level: Subfunction
Intention in context: A User votes a poll
Primary actor: User
Main success scenario:
1. The User looks for poll to be voted
2. The System shows her/him the poll
3. The User gives her/his vote
4. The System notifies the User that the operation ended successfully
5. The use case ends with success
Discuss about a person
Level: Subfunction
Intention in context: A User wants to join a discussion about person
Primary actor: User
Main success scenario:
1. The User chooses the discussion about the person
2. The System shows to the user all the messages associated with that discussion
3. The User tells the System the text and the description of her/his message
4. The System shows the updated list of messages
5. The use case ends with success
7
Create a discussion
Level: Subfunction
Intention in context: A User inserts a new discussion
Primary actor: User
Main success scenario:
1. A User provides the System the subject of the discussion
2. The System shows the discussion to the User
3. The use case ends with success
Reply to a message
Level: Subfunction
Intention in context: A User writes a reply to a message
Primary actor: User
Main success scenario:
1. A User provides the System the subject of the reply
2. A User provides the System the text of the reply
3. The System shows to User the message with her/him reply
4. The use case ends with success
Delete a message
Level: Subfunction
Intention in context: An administrator wants to remove a message
Primary actor: Administrator
Main success scenario:
1. An administrator tells the system to remove a message
2. The System shows the Administrator the list of the messages without the just deleted message
3. The use case ends with success
Check user’s score
Level: Subfunction
Intention in context: The System checks if the user’s score is above the threshold specified during the
initialization of the community
Primary actor: Main success scenario:
1. The System calculates the score of the user
2. If it is above the threshold specified in the System’s policy, it engages the action specified in the
System’s policies
3. The use case ends with success
8
Look for a person
Level: Subfunction
Intention in context: A User asks the System to tell her/him if a person is known to the community and, if
known, selects her/him
Primary actor: User
Main success scenario:
1. The user specifies part of the name and the surname of the person, or the E-Mail address or the
other person’s address
2. The System shows her/him the list of the persons belonging to the System corresponding to the
previous description
3. The User selects one of them
4. The System shows the user all the known details about that person
5. The use case ends with success
Extensions:
2a. The list doesn’t contain the wanted person. The User doesn’t select anybody. The use case ends
with success
2b1. The user requests the System to show the list of all the persons
2b2. The System shows the list of the person
Browse the list of evidences
Level: Subfunction
Intention in context: A User wants to see the opinions of another user
Primary actor: User
Main success scenario:
1. The User inserts part of one or more evidence’s attributes, or person’s attributes
2. The System shows the list of the evidences about this person
3. The User chooses one
4. The System shows it to the User, with the relative discussions
5. The use case ends with success
Extensions:
3a. If there aren’t evidences about that person, the use case ends with success
9
EMail Address
Email address is in
RFC822 format
-email:string
0..1
1
Evidence
Contains
Person
0..*
-score:int
-description:String
Refers to
0..1
1
Discussion
Refers to
-Subject:string
0..1
1
0..1
Refers to
Submits0
0..1
Replies are
associated with a
message
ordinata
0..1
Refers to
1
*
1
-name:string
-surname:string
-Country:string
-Address:string
+calculateScore:Int
1
1
User
Message
-subject:string
-text:string
0..*
Administrator
Poll
0..1
-startDate:date
-endDate:date
-description:String
-title:String
Reply to
Founder
*
+calculateResult:boolean
Policy
1
Refers to
0..1
Vote
0..1
Has Voted
-Value:Enum
-usersCanAbstain:boolean
-adminCanRemoveAdmin:boolean
-percentageOfContraryVotesToReject:int
-usersScoreThreshold:int
-minValidScore:int
-maxValidScore:int
Enum={yes, no, abstained}
percentageOfContraryVotesToReject specifies the percentage of contrary votes to reject the entrance of a person as a user
usersScoreThreshold specifies the threshold after wich the System starts a poll to remove the User
minValidScore and maxValidScore are the boundaries for the minimum and maximum score associated to an evidence
10
<<summary>>
Provide the safe community
Person
User
Email
Administrator
Founder
<<summary>>
Manage evidences
Manage the evidences Use Case
<<user>>
Add an opionion about
an evidence
E-mail
<<include>>
<<user>>
Show the messages
<<include>>
<<include>>
<<user>>
Browse the list of evidences
<<subfunction>>
Reply to a message
<<summary>>
Manages the evidences
<<include>>
<<include>>
<<user>>
Challenge an evidence
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<user>>
Submit an evidence
<<subfunction>>
Delete a message
<<include>>
<<user>>
Justify a bad evidence
<<subfunction>>
Check user's score
<<subfunction>>
Delete a false evidence
Administrator
User
11
Provide a safe community Use Case
Person
<<user>>
Become a User
Administrator
<<user>>
Send a message to all users
<<include>>
<<subfunction>>
Browse the list of evidences
<<include>>
<<subfunction>>
Reply to a message
<<subfunction>>
Create a discussion
<<include>>
<<subfunction>>
Look for a Person
<<include>>
<<include>>
<<include>>
<<user>>
Remove a bad user
<<include>>
<<include>>
<<user>>
Remove a bad Administrator
<<include>>
<<include>>
<<include>>
User
<<include>>
<<include>>
<<include>>
<<subfunction>>
Create a poll
<<include>>
<<subfunction>>
Vote a poll
<<include>>
<<include>>
<<user>>
Remove an Administrator
<<include>>
<<user>>
See the list of Users
<<include>>
<<include>>
<<summary>>
Provides a safe community
<<subfunction>>
Discuss about a Person
<<include>>
Email
<<user>>
Promote a user to the rank of
Administrator
<<include>>
<<user>>
Initialize the community
Founder
12