Vous êtes sur la page 1sur 15

1.

Enonc du problme
E-Team Building
E-Team Building is an information system for a company that is specialized in organizing
team building events. The company`s competitive advantage and its marketing point is maintaining a
long term relationship with their clients and offering professional counseling and advice for the HR
departments. The exercises focus on building team relationships and team leadership.
The company offers both in-site counseling and weekend events that take place in a mountain
resort. For the in-site counseling, a member of the company goes to the client and holds
communication exercises with a single team from the client company. The aims for the exercises are
pre-established with the HR and the assessments after the exercise are also sent to the HR department.
For the events, usually most of the client company members come in the weekend to a
mountain resort and they are organized in different teams than the ones they work into at office. The
splitting into teams takes into consideration previous events so that two aims are followed: discover
new talents by putting members into different roles than before and also strengthening a role, for
example, strengthening the role of a new unit leader.
The system should maintain the list of clients and client personnel, with their assessments and
history in
previous events. The system must allow the owner to graphically view existing team structures and
relations. The system must provide decision support in organizing an event, from booking the location
to preparing the daily program for each team and instructor. The assessments are introduced by the
instructors and validated by the team building company owner before being sent to the HR department
of the client. Lastly the system should be interconnected with the HR departments IT systems in order
to extract personnel files.

2.Business modeling
The main purpose of this chapter is to describe the vision of the organization in which the system
will be distributed and how to apply this vision in order to outline the roles, process and
responsibilities. The most important parts of this chapter are:

Domain model;
Identifying the actors and agents;
Processes and rules;
Business use cases;

2.1. Domain Model


Domain model is a representation of a real world world conceptual classes (entities). The
domain model is created in order to represent the vocabulary and key concepts of the problem domain.
The domain model also identifies the relationships among all the entities within the scope of the
problem domain, and commonly identifies their attributes. A domain model that encapsulates methods

within the entities is more properly associated with object oriented models. The domain model
provides a structural view of the domain that can be complemented by other dynamic views, such
as use case models.

Business Actor: - Cliente- Employees who take part in team building organized by the company.
- HR Company- Human resources department of the company that deals with the
evaluation of participants

Business Agents:
-

Organizateur

Instructeur

2.2. Business Use Case Diagrams


Business use cases are system descriptions of sequences of events that, taken together, lead to
a system doing something useful. These descriptions are done from the users point of view. It is a
description of systems behavior as it responds to a request that originates from outside the system. It
is a complete series of events seen from the point of view of the actor.

3.Activity Diagrams
An activity diagram is designed to provide an accurate definition of the baseline requirements
from a logical, sequential perspective.

The following activity diagrams describe the most important actions that occur while working
with this application:

3.Software
Use Cases

In software and systems engineering, a use case is a list of steps, typically defining interactions
between a role and a system, to achieve a goal. It may also be defined as a sequence of actions,
including variants, a system can realize by interacting with the system actors.

3.1.Use Cases Descriptions


Use case name: Registration
Use case short description: Customer sign up to participate in team building.The organizer take customer
data and enter them into the database to check whether it has participated in the event.

Stakeholders: Organisateur
Business rules: Customer must sign up
Precondition: System starts
Postcondition: new data stored
Main flow:

Organisateur

System

1. requires a new

2. the system presents a

registration

form

3.complete data
5.finalize
registration[A2]

4.
System verifies the data

[A1]
6.store registration

Alternating flux:A1:- data not available:


- shows an error
- leave the system
A2.Organizer is not completed registration
- system abandons registration
- registration
Use case name:Reservation
Use case short description:
The organizer takes customer data and enter them into the database to check whether it has
participated in the event. If the client has not ever participated in such an event and will make a
reservation for the trip to the mountains.
Stakeholders: Organisateur
Regle mtier: The organizer must enter data
Precondition: The system is running; the application is connected to the database (in order to apply
the changes), the organizer is logged in.
Postcondition: the changes will be applied in the database
Main flow:

Organisateur
1.requires a
new

S
Alternating flux: A1:-

rezervation
3choose the place
5.confirm
reservation[A2]

Systme
2. the system
checkswhere the
available places are
4.System marks the place
as occupied - validates
modification[A1]
6.store rezervation

data not available:


shows an error
leave the system

A2.Organizer is not completed registration


- system abandons registration
Stakeholders: Instructeur
Use case short description:Creation du program-Instructorul se va ocupa de a organiza programul
care se va desfasura pe parcusul sederii la munte.Sistemul va stoca acest program in baza de date.
Use case name: Creation du program

Regle mtier: Programul trebuie sa contina cel putin o activitate


Precondition: The system is running; the application is connected to the database (in order to add the
program)
Postcondition: the program will be applied in the database
Main flow:

Instructeur
1.ask for new
program
3.completeaza
datele
5.confirm
modification[A2]

Systme
2.system shows a form
4.System validates the
change[A1]
6.store modification

Alternating flux: A1:-data no available


- shows an error
- came back to step 2
A2.The program exists
- shows an error
- came back to step 2
Use case name: Crer evaluation
Use case short description:Instructorul va creea o evaluare a rezultatelor obtinute iar sistemul o va
salva pentru a putea fi validata de catre departamentul de resurse umane.
Stakeholders: Instructeur
Regle mtier: Evaluarea trebuie sa contina cel putin o intrebare
Precondition: The system is running; the application is connected to the database (in order to add the
evaluation
Postcondition: The evaluation will be applied in the database

Main flow:

Instructeur
1.requires
new
assesment
3.complete datas

Systme
2.system shows a form
4.system validates
modification[A1]
6.modification stored

5.confirm
modification[A2]

Alternating flux:A1:-data no valid:


-shows an error
- came back to step 2
A2.The program was created
-shows an error
-came back to step 2
Use case name: Valider evaluation
Use case short description : HrCompany checks the results of the assessments and the system will
store the modicfications.
Stakeholders: HRCompany
Regle mtier: assessment must exists
Precondition: The system is running; the application is connected to the database (in order to validate
the evaluation)
Postcondition: the evaluation will be applied in the database
Flux:
HRCompany
Systme
1.requires to
show an
assesment
3.corrects the
assesment
5.confirm
modification[A2]

2.system shows the


evaluation
4.system validates the
modification[A1]
6.store modification

Flux alternatif : A1:-datele nu sunt valide:


-prezinta o eroare
- se revine la pasul 2
A2.Programul dj exista
-afiseaza eroare
-se revine la pasul 2

3.3.

SYSTEM FUNCTIONALITIES

System functional requirements are mainly the software use cases presented earlier in the document:

Functionalities
1. System must allow log in for organisateur,instructeur and HRCompany.
2. System must allow filtering dates by some filters like availability
3. System must allow organisateur to update dates
4. System must allow instructeur dactualiser le program et levaluation
5. System must allow making a purchase
6. System must allow the organisateur to give a review
7. System must allow administrator to update shows
8. System stores all the information about the date,program and evaluation

Grade
9
7
6
8.5
10
6
9
9.5

NON FUNCTIONAL REQUIREMENTS:


In the following part, there will be described the system non functional requirements and
their importance for the whole application:
Security: In order to use the system, the organizer, the instructor and the HRCompany must log in.
The password is at least 6 digits long.
Usability: The system can be used by a person with high school training after a two hour tutorial.
Robustness: System verifies all the input data given by the , the organizer, the instructor and the
HRCompany.
Reliability: It can work continuously for a week.
Performance: It can store 500 clients and 200 purchases/bookings simultaneously. It must respond in
at most 5 seconds for every query. It can store 1000 shows. It can be easily upgraded.
Portability: Due to the fact it is mainly a Java application, it can be used on every operating system.

3.4.SYSTEM SEQUENCE DIAGRAM

A system sequence diagram is a picture that shows, for one particular scenario of a use case, the
events that external actors generate, their order, and inter system events. All systems are treated as a
black box. Time proceeds downward and the ordering of the events should follow their order in the
scenario.
The following system sequence diagrams present a certain importance for the current
application:

4.Operation contracts
Operation Name: Enter client data;
Use case: Register client;
Preconditions: Registration was requested and a form was shown.
Postconditions:
-

New object is created: a new membership is created.


New attributes are created (attributes of the Membership)
An association between a client and the new registration is created.

Operation Name: Enter mountain trip data;


Use case: Reservation;
Preconditions: Reservation was required and a new form was displayed.

Postconditions:
-

Object of type reservation is modified. (its attributes will be changed).


List of reservation will be actualized.

5. Design Class Diagram


In software engineering, a design class diagram is a type of static structure diagram that
describes the structure of a system by showing systems classes, their attributes, operations (or
methods), and the relationships among classes. Class diagram is the foundation of modeling objects,
the source for code generation and the target for reverse engineering.

6.Sequence Diagram
The main purpose of a sequence diagram is to define event sequences that result in some
desired outcome. The focus is less on messages themselves and more on the order in which messages
occur.
6.1.Login Sequence Diagram

6.1.2.Register Sequence Diagram

6.1.3 .Booking Sequence Diagram

Vous aimerez peut-être aussi