dl CRM

dl CRM
Politechnika Poznańska
Instytut Informatyki
dl CRM
Krzysztof Malcherek
Tomasz Przybyla
Robert Suszczyński
Poznań, 2007
Contents
Contents
I
1
Introduction
1
1.1
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3
Definitions, acronyms and abbreviations . . . . . . . . . . . . . . . . . . .
1
1.4
Contact information/SRS team members . . . . . . . . . . . . . . . . . .
2
1.5
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
Overall Description
3
2.1
Product perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Business Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2.1
Main Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2.2
Business Objects . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Product functions: dLibra Team Participant . . . . . . . . . . . . . . . .
6
2.3.1
UC1.1 Log in to the system . . . . . . . . . . . . . . . . . . . . .
6
2.3.2
UC1.2 Add a new client . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.3
UC1.3 Edit client data . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.4
UC1.4 Delete client . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.5
UC1.5 Browse clients . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.6
UC1.6 Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.7
UC1.7 Add a new contract . . . . . . . . . . . . . . . . . . . . . .
10
2.3.8
UC1.8 Edit contract . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.9
UC1.9 Delete contract . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.10 UC1.10 Add a new installation . . . . . . . . . . . . . . . . . . .
12
2.3.11 UC1.11 Edit installation . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.12 UC1.12 Delete installation . . . . . . . . . . . . . . . . . . . . . .
13
2.3.13 UC1.13 Prepare a report . . . . . . . . . . . . . . . . . . . . . . .
14
Product functions: dLibra client . . . . . . . . . . . . . . . . . . . . . . .
15
2.4.1
15
2.3
2.4
UC2.1 Log in to the system . . . . . . . . . . . . . . . . . . . . .
I
II
3
2.4.2
UC2.2 Browse information . . . . . . . . . . . . . . . . . . . . . .
15
2.4.3
UC2.3 Request for license . . . . . . . . . . . . . . . . . . . . . .
15
2.5
User classes and characteristics . . . . . . . . . . . . . . . . . . . . . . . .
16
2.6
Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.7
Operating environment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.7.1
OE1 - Java Virtual Machine . . . . . . . . . . . . . . . . . . . . .
17
2.7.2
OE2 - Web server . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.7.3
OE3 - Web browser . . . . . . . . . . . . . . . . . . . . . . . . . .
18
Nonfunctional Requirements
3.1
Performance requirements
19
. . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1.1
PER1 - Page loading time . . . . . . . . . . . . . . . . . . . . . .
19
3.1.2
PER2 - Database delay . . . . . . . . . . . . . . . . . . . . . . .
19
3.1.3
PER3 - Multiple concurrent users . . . . . . . . . . . . . . . . . .
20
3.2
Safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
SAF1 - Safe database . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3
Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3.1
SEC1 - Secure connection . . . . . . . . . . . . . . . . . . . . . .
20
3.3.2
SEC2 - User authentication . . . . . . . . . . . . . . . . . . . . .
21
Design requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4.1
DR1 - Model-View-Controller architecture . . . . . . . . . . . . .
21
3.4.2
DR2 - User friendliness . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4.3
DR3 - Data transformation . . . . . . . . . . . . . . . . . . . . .
22
Implementation requirements . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.1
3.4
3.5
3.6
3.5.1
IR1 – Programming language . . . . . . . . . . . . . . . . . . . .
22
3.5.2
IR2 – Page rendering . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.5.3
IR3 – Independence from database . . . . . . . . . . . . . . . . .
23
3.5.4
IR4 – Standards . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.6.1
DR1 - Javadoc documentation . . . . . . . . . . . . . . . . . . . .
23
3.6.2
DR1 - Maven reports . . . . . . . . . . . . . . . . . . . . . . . . .
24
Bibliography
25
Chapter 1
Introduction
1.1
Purpose
The purpose of the document is to specify the software requirements. The intended audience for the document comprises representatives of the customer, the
developers (including software architect and tester), writers of the user manual
and other interested parties.
1.2
Scope
DL CRM is to be an Internet-based system which supports managing clients
of dLibra. It will provide ways of adding, editing, deleting and searching clients,
their contracts with PCSS and software installations. System will be capable of
creating reports from given data filters. It will also contain information about
current licenses and provide functions for genaration of new software licenses and
keys. It will communicate with dLibra server, which provides required functionality to perform these tasks. The vision of the project has been described in the
Product Vision document.
1.3
Definitions, acronyms and abbreviations
• dLibra – digital library. Project managed by PCSS, which provides books,
materials in electronic form.
• customer – see PCSS.
• GUI – graphical user interface.
1
1.4. Contact information/SRS team members
2
• PCSS – Poznańskie Centrum Superkomputerowo Sieciowe: customer of
this project.
1.4
Contact information/SRS team members
Information and contact to team members can be found in the Project Management Team document [2].
1.5
Overview
Part II contains overall description of the system. It specifies main product
functions, operational scenarios and operating environment.
Part III contains non-functional requirements.
Chapter 2
Overall Description
2.1
Product perspective
Perspective of dL CRM system has been shown at picture 2.1). All modules of
this prodct will be available via web browsers from Internet (license) or PCSS Intranet (client, transaction and installation modules). Sometimes, communication
with dLibra servers will be necessary (ex. while autenthication process).
2.2
Business Domain Model
2.2.1
Main Actors
• dLibra Team Participant – employee of PCSS. Will have full access to
all modules of the system with privleges to add, modify and delete data.
• dLibra Client – client of PCSS. Will only have access to the license module. This user may request a new licenses and download them.
2.2.2
Business Objects
All Business objects in dlCRM system consist of specific set of attributes.
• dLibra Client
– Name
– Surname
– Phone number
– Email
– Company Name
3
2.2. Business Domain Model
– Website
– REGON
– Address
– Contact
• Contract
– dLibra Client
– Sign date
– End date
– Contract Serial Number
– dLibra Team Participants (Responsible for contract service)
• Installation
– Installation number
– Installation address
– Installation date
– Version
– dLibra Client
– License’s files
• License
– Keys and certicicates files
– Licenses files
• Key (certificate) file
– identifier
– validity
– file content
• License file
– Serial number
– Installation
– Certificate identifier
– validity
– file content
4
5
2.2. Business Domain Model
Figure 2.1: System structure
2.3. Product functions: dLibra Team Participant
2.3
2.3.1
Product functions: dLibra Team Participant
UC1.1 Log in to the system
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant, Client.
Preconditions: User is already registered.
Stakeholders and interests:
dLibra Team Participant – to gain access to the database.
Client – to gain access to the database.
PCSS – allow access to only authorised personnel.
Minimal guarantees: If login data was incorrect, attempt will fail.
Success guarantees: User will be granted an access to the data.
Main Scenario:
1. User selects login option.
2. User provides all required data.
3. System verifies correctness of data.
4. System displays a main page.
Extensions:
3.a. Data is incomplete or incorrect:
3.a.1 System asks for data again.
3.a.2 Back to step 2.
2.3.2
UC1.2 Add a new client
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to add a new client.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: A new client will be added.
Main Scenario:
6
2.3. Product functions: dLibra Team Participant
7
1. User select option for adding new clients.
2. User fills all required personal client data forms.
3. System verifies correctness of data.
4. System adds a new client to the database and informs user about it.
Extensions:
3.a. Data is incomplete or incorrect:
3.a.1 System informs user about problems.
3.a.2 User makes a correction to the data.
3.a.3 Back to step 3.
3.b. Client with same personal data already exists:
3.b.1 System informs user about that fact.
3.b.2 Back to step 1.
4.a. Client can’t be added:
4.a.1 System informs user about reason why client can’t be added.
2.3.3
UC1.3 Edit client data
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to modify client data.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: Changes to the client data will be saved.
Main Scenario:
1. User select option for editing clients.
2. User modifies personal client data.
3. System verifies correctness of data.
4. System saves a new client data to the database and informs user about it.
Extensions:
3.a. Data is incomplete or incorrect:
3.a.1 System informs user about problems.
3.a.2 User makes a correction to the data.
2.3. Product functions: dLibra Team Participant
3.a.3 Back to step 3.
3.b. Client with same personal data already exists:
3.b.1 System informs user about that fact.
3.b.2 Back to step 1.
4.a. Client data changes can’t be saved:
4.a.1 System informs user about reason why client can’t be modified.
2.3.4
UC1.4 Delete client
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to delete client data.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: Client will be deleted.
Main Scenario:
1. User select option for deleting clients.
2. User delete chosen client.
3. System verifies possibility to perform deleting.
4. System saves changes to the database and informs user about it.
Extensions:
3.a. Client cannot be deleted:
3.a.1 System informs user about problems.
3.a.2 User check possibility to perform deleting.
3.a.3 Back to step 3.
2.3.5
UC1.5 Browse clients
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
8
2.3. Product functions: dLibra Team Participant
dLibra Team Participant – to browse client data.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: User will see a list of clients.
Main Scenario:
1. User select option for browsing clients.
2. System displays the list of clients.
User may:
3. filter clients with specified criteria,
4. sort clients,
5. view details about selected client.
Steps 2 - 4 may be preformed many times.
6. Use case ends when users logs out or select different option.
Extensions:
2.a. There are no clients to display:
2.a.1 System displays blank list.
2.a.2 Use case ends.
2.3.6
UC1.6 Search
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to find specific client.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: User will see a list of clients meeting give criteria.
Main Scenario:
1. User select option for searching.
2. User selects subject of search (clients, contracts, installations).
3. System displays list of possible criteria.
4. User creates filter for searching.
5. System search the database and displays the results.
9
2.3. Product functions: dLibra Team Participant
Extensions:
4.a. Chosen criteria are invalid:
4.a.1 System warns user.
4.a.2 Back to step 3.
5.a. No records found:
5.a.1 System displays blank list.
2.3.7
UC1.7 Add a new contract
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to add a new contract.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: A new contract will be added.
Main Scenario:
1.
2.
3.
4.
5.
6.
User select select a client for whom new contract will be added.
User chooses option for adding new contract.
System displays transction form.
User fills all required data.
System verifies information.
Sytem saves contract and bounds it to the selected client.
Extensions:
5.a. Data is incomplete or incorrect:
5.a.1 System informs user about problems.
5.a.2 User makes a correction to the data.
6.a. contract can’t be saved:
6.a.1 System informs user about that fact.
2.3.8
UC1.8 Edit contract
Scope: System.
Level: User goal.
10
2.3. Product functions: dLibra Team Participant
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to add a new contract.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: A new contract will be added.
Main Scenario:
1. User select select a client.
2. User chooses option for editing an existing contract.
3. System displays transction form.
4. User changes desired data.
5. System verifies information.
6. Sytem saves changed contract.
Extensions:
5.a. Data is incomplete or incorrect:
5.a.1 System informs user about problems.
5.a.2 User makes a correction to the data.
6.a. contract can’t be saved:
6.a.1 System informs user about that fact.
2.3.9
UC1.9 Delete contract
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to delete contract data.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: Contract will be deleted.
Main Scenario:
1. User select option for deleting contract.
2. User delete chosen contract.
11
2.3. Product functions: dLibra Team Participant
3. System verifies possibility to perform deleting.
4. System saves changes to the database and informs user about it.
Extensions:
3.a. Contract cannot be deleted:
3.a.1 System informs user about problems.
3.a.2 User check possibility to perform deleting.
3.a.3 Back to step 3.
2.3.10
UC1.10 Add a new installation
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to add a new installation.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: A new installation will be added.
Main Scenario:
1. User select select a client for whom new installation will be added.
2. User chooses option for adding new installation.
3. System displays installation form.
4. User fills all required data.
5. System verifies information.
6. Sytem saves installation and bounds it to the selected client.
Extensions:
5.a. Data is incomplete or incorrect:
5.a.1 System informs user about problems.
5.a.2 User makes a correction to the data.
6.a. Installation can’t be saved:
6.a.1 System informs user about that fact.
12
2.3. Product functions: dLibra Team Participant
2.3.11
UC1.11 Edit installation
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to add a new installation.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: A new installation will be added.
Main Scenario:
1. User select select a client.
2. User chooses option for editing an existing installation.
3. System displays installation form.
4. User changes desired data.
5. System verifies information.
6. Sytem saves changed installation.
Extensions:
5.a. Data is incomplete or incorrect:
5.a.1 System informs user about problems.
5.a.2 User makes a correction to the data.
6.a. Installation can’t be saved:
6.a.1 System informs user about that fact.
2.3.12
UC1.12 Delete installation
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to delete installation data.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
13
2.3. Product functions: dLibra Team Participant
14
Success guarantees: Installation will be deleted.
Main Scenario:
1.
2.
3.
4.
User select option for deleting installation.
User delete chosen installation.
System verifies possibility to perform deleting.
System saves changes to the database and informs user about it.
Extensions:
3.a. Installation cannot be deleted:
3.a.1 System informs user about problems.
3.a.2 User check possibility to perform deleting.
3.a.3 Back to step 3.
2.3.13
UC1.13 Prepare a report
Scope: System.
Level: User goal.
Main actor: dLibra Team Participant.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Team Participant – to prepare a report.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: Report will be created.
Main Scenario:
1. User select option for creating reports.
2. System displays a list of possible fields in the report.
3. User selects fields to be included in the report and rules to filter values from
4.
5.
6.
7.
database.
User order report generation.
System asks for type and localisation of the output file with report.
User selects the type and localisation of the output file with report.
System generates a report.
Extensions:
7.a. Report can’t be saved in given location:
7.a.1 System displays information.
7.a.2 Back to step 5.
2.4. Product functions: dLibra client
2.4
15
Product functions: dLibra client
2.4.1
UC2.1 Log in to the system
See UC1.1 Log in to the system (2.3.1).
2.4.2
UC2.2 Browse information
Scope: System.
Level: User goal.
Main actor: dLibra Client.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Client – to browse data.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: User will see a list of his licenses, keys, contracts and
installations.
Main Scenario:
1. User select option for browsing data.
2. System displays the list of licenses, keys, contracts and installations (grouping by type).
User may:
3. filter data with specified criteria,
4. sort data,
5. view details about selected element.
Steps 2 - 4 may be preformed many times.
6. Use case ends when users logs out or select different option.
Extensions:
2.a. There are no data to display:
2.a.1 System displays blank list.
2.a.2 Use case ends.
2.4.3
UC2.3 Request for license
Scope: System.
Level: User goal.
2.5. User classes and characteristics
16
Main actor: dLibra Client.
Preconditions: User is already logged in.
Stakeholders and interests:
dLibra Client – to generate new license.
PCSS – allow access to only authorised personnel.
Minimal guarantees: Database will not be corrupted.
Success guarantees: User will generate new license key for his software.
Main Scenario:
1. User select option for requesting a new licenses.
2. System displays the list of user’s contracts.
3. User selects one contract for license request.
4. System contact with dLibra server to obtain all necessary data.
5. System validate given data.
6. System store a request new license and informs user about it.
7. PCSS Team Participant approve request for a new license.
8. User downloads the license file.
Extensions:
2.a. There are no contracts:
2.a.1 System displays blank list.
2.a.2 Use case ends.
3.a. Selected contract can not have more licenses:
3.a.1 System informs user about that fact.
3.a.2 Back to step 2.
5.a. Data is not valid:
5.a.1 System informs user about incorrect data.
5.a.2 Back to step 2.
2.5
User classes and characteristics
• dLibra Team Participant – employee of PCSS. Will have access to all
modules of the system with privleges to add, modify and delete data.
• dLibra Client – client of PCSS. Will only have access to the license module. This user may generate new licenses and download them.
• PCSS – organisation which act as client of this system.
• System – system itself. Sometimes dL CRM will communicate with dLibra servers and act as client then.
17
2.6. Constraints
2.6
Constraints
• System should be ready before 01.03.2008.
• System should allow access only for authorized users.
• System should maintain confidentiality of data.
• System should be based on and developed with free technologies or technologies and tools licensed to the customer.
2.7
2.7.1
Operating environment
OE1 - Java Virtual Machine
OE1 - Java Virtual Machine
Description:
Operating system must support Java Virtual Machine in version
1.5 or above [5].
Priority:
High
Status:
Accepted
Source:
Architect
Cost:
Low
Risk:
Low
Verifiable:
High
Connected
with:
2.7.2
OE2 - Web server
OE2 - Web server
Description:
Operating environment must include Apache Tomcat server in
version 5.5 or above [7].
Priority:
Medium
Status:
Accepted
Source:
Architect
Cost:
Low
Risk:
Low
Verifiable:
High
Connected
with:
18
2.7. Operating environment
2.7.3
OE3 - Web browser
OE3 - Web browser
User operating system must contain a web browser: Microsoft
Description:
Internet Explorer version 5 or higher, Mozilla 1.0 or higher,
Netscape Navigator 6.2 or higher.
Priority:
Medium
Status:
Accepted
Source:
Customer
Cost:
Low
Risk:
Low
Verifiable:
High
Connected
with:
Chapter 3
Nonfunctional Requirements
3.1
3.1.1
Performance requirements
PER1 - Page loading time
PER1 - Page loading time
Description:
Loading time of any of system web pages should be under 2
seconds.
Priority:
High
Status:
Pending
Source:
Customer
Cost:
High
Risk:
Medium
Verifiable:
High
Connected
with:
3.1.2
IR2 – Page rendering (3.5.2)
PER2 - Database delay
PER2 - Database delay
Delay when accessing a database shoul be under 1 second. If
Description:
current database is too slow, there should be a way to chenge
it.
Priority:
High
Status:
Pending
Source:
Customer
Cost:
High
Risk:
Medium
Verifiable:
Medium
Connected
with:
IR3 – Independence from database (3.5.3)
19
20
3.2. Safety requirements
3.1.3
PER3 - Multiple concurrent users
PER3 - Multiple concurrent users
Description:
System shall allow at least 15 user to operate it concurrently
Priority:
Medium
Status:
Pending
Source:
Customer
Cost:
Medium
Risk:
Medium
Verifiable:
Medium
Connected
with:
3.2
Safety requirements
3.2.1
SAF1 - Safe database
SAF1 - Safe database
Description:
After system crash database will be restored.
Priority:
High
Status:
Pending
Source:
Customer
Cost:
High
Risk:
Medium
Verifiable:
High
Connected
with:
3.3
Security requirements
3.3.1
SEC1 - Secure connection
SEC1 - Secure connection
Description:
SSL protocol [10] should be used to provide secure connection.
Priority:
High
Status:
Pending
Source:
Customer
Cost:
Medium
Risk:
Medium
Verifiable:
High
Connected
with:
21
3.4. Design requirements
3.3.2
SEC2 - User authentication
SEC2 - User authentication
Each user should be authenticated in order to use application.
Description:
LDAP system will be used for PCSS employees and database
for customers.
Priority:
High
Status:
Pending
Source:
Customer
Cost:
Medium
Risk:
High
Verifiable:
High
Connected
with:
3.4
3.4.1
Design requirements
DR1 - Model-View-Controller architecture
DR1 - Model-View-Controller architecture
Description:
Application shall be designed according to MVC pattern.
Priority:
High
Status:
Pending
Source:
Architect
Cost:
Medium
Risk:
Medium
Verifiable:
High
Connected
with:
3.4.2
DR2 - User friendliness
DR2 - User friendliness
Description:
GUI should be as user friendly as possible (meaning esay to
operate, to understand and functional) [1].
Priority:
High
Status:
Pending
Source:
Customer
Cost:
Medium
Risk:
Medium
Verifiable:
Low
Connected
with:
22
3.5. Implementation requirements
3.4.3
DR3 - Data transformation
DR3 - Data transformation
Description:
Database must be designed in a way which will allow transformation of existing data to the new format.
Priority:
High
Status:
Accepted
Source:
Customer
Cost:
Low
Risk:
Medium
Verifiable:
High
Connected
with:
3.5
3.5.1
Implementation requirements
IR1 – Programming language
IR1 – Programming language
Description:
Application shall be implemented using Java programming language in version 5.0 or higher
Priority:
High
Status:
Pending
Source:
Customer
Cost:
Low
Risk:
Low
Verifiable:
High
Connected
with:
3.5.2
OE1 - Java Virtual Machine (2.7.1)
IR2 – Page rendering
IR2 – Page rendering
Velocity [8] template and HTML shall be used to render pages.
Description:
Making modifications to rendered pages should be possible
without modifying application source code. There should’t be
any HTML tags in the source code.
Priority:
Medium
Status:
Pending
Source:
Customer
Cost:
Medium
Risk:
Medium
Verifiable:
High
Connected
with:
23
3.6. Documentation
3.5.3
IR3 – Independence from database
IR3 – Independence from database
Description:
Hibernate [3] should be used for accessing database to provide
independence from database system.
Priority:
Medium
Status:
Pending
Source:
Customer
Cost:
Medium
Risk:
Low
Verifiable:
High
Connected
with:
3.5.4
DR3 - Data transformation (3.4.3)
IR4 – Standards
IR4 – Standards
Application code shall be written according to Sun Code ConDescription:
ventions for the Java Programming Language [4]. Generated
web pages shall be valid with XHTML 1.0 Strict.
Priority:
Medium
Status:
Pending
Source:
Customer
Cost:
Medium
Risk:
Low
Verifiable:
High
Connected
with:
3.6
3.6.1
Documentation
DR1 - Javadoc documentation
DR1 - Javadoc documentation
Description:
Each public element of application code should be documented
according to Javadoc convention [6].
Priority:
Low
Status:
Pending
Source:
Customer
Cost:
Low
Risk:
Low
Verifiable:
High
Connected
with:
24
3.6. Documentation
3.6.2
DR1 - Maven reports
DR1 - Maven reports
Description:
Each problem reported by Maven PMD report should be
resolved[9].
Priority:
Low
Status:
Pending
Source:
Customer
Cost:
Low
Risk:
Low
Verifiable:
High
Connected
with:
Bibliography
[1]
Wilbert O. Galitz. The Essential Guide to User Interface Design: An Introduction
to Gui Design Principles and Techniques. John Wiley Sons, 1996.
[2]
Krzysztof Malcherek. Project Management Team.
http://cerber.cs.put.poznan.pl/~inf66313/dlCRM/documents/Project_
Management_Team.doc, 2004.
[3]
Red Hat. Hibernate.
http://www.hibernate.org/, 2006.
[4]
Sun Microsystems, Inc. Code Conventions for the Java Programming Language.
http://java.sun.com/docs/codeconv/, 2004.
[5]
Sun Microsystems, Inc. JavaTM 2 Platform Standard Edition 5.0 API Specification.
http://java.sun.com/j2se/1.5.0/docs/api/index.html, 2004.
[6]
Sun Microsystems, Inc. How to Write Doc Comments for the Javadoc Tool.
http://java.sun.com/j2se/javadoc/writingdoccomments/, 2007.
[7]
The Apache Software Foundation. Apache Tomcat.
http://tomcat.apache.org/, 1999-2007.
[8]
The Apache Software Foundation. Velocity.
http://velocity.apache.org/, 1999-2007.
[9]
The Apache Software Foundation. Maven - software project management and comprehension tool.
http://maven.apache.org/, 2007.
[10] Wikipedia, The Free Encyclopedia. Secure Sockets Layer.
http://en.wikipedia.org/wiki/Transport_Layer_Security, 2007.
25
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement