Global Testing Services (GTS) : Test Effort Calculator (Tec) Detailed Specifications

Test Effort Calculator
Detailed Specifications
Version 1.13
GLOBAL TESTING SERVICES (GTS)
TEST EFFORT CALCULATOR (TEC)

DETAILED SPECIFICATIONS
59306615.doc 08-Jan-09 16:32

Internal Use Only Page 1 of 123
2 Test Effort Calculator
Version 1.13
Comments
Business PL Arjan Struik
Project Manager: Kemal Kilic
Requirements Provider: GTS
Owner of this specification GTS
Name of application or IT system to be built TEC Test Effort Calculator
Vers. No. Date Author, Unit Code Status Comment

0.1 12.09.2008 Gaurav Sinhal/Ajit Sahu Initial
Gaurav Sinhal/ Ajit Sahu
0.4 25.09.2008 Initial Going to details. ongoing
Andreas Ewertz
Andreas Ewertz
Andreas Ewertz
Andreas Ewertz
0.8 07.10.2008 Initial Incorporated review comments
Andreas Ewertz
0.9 09.10.2008 Initial Incorporated review comments
Andreas Ewertz
0.92 14.10.2008 Draft Incorporated review comments
Andreas Ewertz
0.93 15.10.2008 Andreas Ewertz Draft Changes in the Ordering layer
0.95 22.10.2008 AS, PVA, KK, AE Draft Review Phase
1.00 07.11.2008 KK, AE Final Finalized for review by TMs
1.10 02.12.2008 AE Final Spliting Efforts for Releases included
1.11 05.12.2008 AE Final Baseline
Version Date Changed from Comment

0.2 28.10.20088 Review comments from Arjan
Struik for section 2.1
Incorporated
0.3 19.09.2008 Incorporation of data model.
Review comments from Arjan for section 2.2 and 2.3
0.4 25.09.2008  Start introducing use cases in chapter 2. Adding a
glossary and an abbreviation section in appendix. In
appendix a template section for use case is
included.
0.5 30.09.2008  Introducing more use cases. Mainly in sections. 2.2
And 2.3. Adding a chapter database model.
0.6 02.10.2008  Nearly completed the use cases for engine and
order level. Also included the use case for Quality
center interface.
59306615.doc 08-Jan-09 16:32

Version 1.13
Version Date Changed from Comment

0.7 03.10.2008  Adaptations on different parts of the document.
Introducing use cases in chapter 2.1.
0.8 07.10.2008  Review comments from Kilic Kemal Incorporated
0.9 09.10.2008  Incorporated the UC tree Diagram
 Additional comments from Kilic Kemal
Incorporated
0.91 11.10.2008 KK  correction of UC's
 New Uc-Diagram
0.92 14.10.2008  New usecase for Export to PDF functionalily.
Details of Show Order usecase with the snapshots
 Additional corrections to UCs
0.93 15.10.2008  Adaptions in the ordering layer
0.931 15.10.2008 KK  Correction of Use Case diagram
 Small Changes on Use Cases
0.932 18.10.2008 KK  Graph for Complexity Levels
0.95 22.10.2008 AS, PVA, KK, AE  Changes from review included.
0.96 29.10.2008 AE  Screen Layouts added
0.965 30.10.2008 KK  General Specification included
1.00 07.11.2008 KK, AE  Review of Use Cases
 Introducing Currency Use Cases
 Deleting Category Use Cases
 Five Rules per Charging Model
 Description of tables in chapter 4.2
 Update Usecase diagram
1.10 02.12.2008 AE  Spliting Efforts for Releases, Adapting Use Cases
 Section "Order Requirements" added to chapter 1
 Section" Process to get an approved
calculation" added to chapter 2.4
 Changes in the Screen Shots
 " Needed Informations for Introduction Phase"
in chapter appendix
1.11 05.12.2008 AE  Reporting of orders and projects refined
1.12 19.12.2008 AE  Adaption on Business Rules for
UC233-Edit Charging Model
1.13 08.01.2009 AE  Trying to keep specification in sync with the
changed items coming up with CTS Queries.
Changed pages:
Welcome.html New page
No-permission.html New page
Create-order.html Deputy added
Edit-order.html Deputy added
Create-user.html Deputy deleted
Edit-user.html Deputy deleted
 Section "Appendix / Additional Screens"
introduced
59306615.doc 08-Jan-09 16:32

Version 1.13
59306615.doc 08-Jan-09 16:32

Version 1.13
TABLE OF CONTENTS
GLOBAL TESTING SERVICES (GTS)..................................................................................................................1
TEST EFFORT CALCULATOR (TEC) DETAILED SPECIFICATIONS....................................................1
TABLE OF CONTENTS........................................................................................................................................4
1 INTRODUCTION.......................................................................................................................................7
1.1 DESCRIPTION.........................................................................................................................................7
1.2 STRUCTURE OF APPLICATION..........................................................................................................7
1.2.1 Use Case Diagrams...........................................................................................................................8
1.3 ORDER REQUIREMENTS...................................................................................................................11
1.3.1 Order design and cost spliting.........................................................................................................11
1.3.2 Order reporting................................................................................................................................13
1.3.3 Order persistency............................................................................................................................13
1.3.4 Order status.....................................................................................................................................13
1.4 PARENT CHILD RELATIONSHIP......................................................................................................14
2 DETAILED FUNCTIONAL SPECIFICATIONS.................................................................................18
2.1 GENERAL SPECIFICATION...............................................................................................................18

2.2 OPERATOR LAYER SPECIFICATIONS............................................................................................19
2.2.1 Sequence of Use Cases in the Operator Layer................................................................................19
2.2.2 UC101 – List User Groups..............................................................................................................20
2.2.3 UC102 – Create User Group...........................................................................................................21
2.2.4 UC103 – Edit User Group...............................................................................................................23
2.2.5 UC104 – Delete User Group...........................................................................................................25
2.2.6 UC111 – List Users.........................................................................................................................27
2.2.7 UC112 – Create User......................................................................................................................29
2.2.8 UC113 – Edit User..........................................................................................................................30
2.2.9 UC114 – Delete User......................................................................................................................32
2.2.10 UC121 – List Cost Types................................................................................................................33
2.2.11 UC122 – Create Cost Type.............................................................................................................35
2.2.12 UC123 – Edit Cost Type.................................................................................................................36
2.2.13 UC124 – Delete Cost Type.............................................................................................................38
2.2.14 UC131 – List Vendors....................................................................................................................39
2.2.15 UC132 – Create Vendor..................................................................................................................41
2.2.16 UC133 – Edit Vendor.....................................................................................................................42
2.2.17 UC134 – Delete Vendor..................................................................................................................44
2.3 ENGINE LAYER SPECIFICATIONS...................................................................................................46
2.3.1 Data Model......................................................................................................................................46
2.3.2 Overview of Use Cases in the Engine Layer..................................................................................47
2.3.3 UC221 – List Services....................................................................................................................48
2.3.4 UC222 – Create Service..................................................................................................................49
2.3.5 UC223 – Edit Service.....................................................................................................................51
2.3.6 UC224 – Delete Service..................................................................................................................52
2.3.7 UC231 – List Charging Models......................................................................................................53
2.3.8 UC232 – Create Charging Model...................................................................................................55
2.3.9 UC233 – Edit Charging Model.......................................................................................................56
2.3.10 UC234 – Delete Charging Model...................................................................................................58
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.11 UC241 – List Parameters................................................................................................................59

2.3.12 UC242 – Create Parameter.............................................................................................................61
2.3.13 UC243 – Edit Parameter.................................................................................................................62
2.3.14 UC244 – Delete Parameter.............................................................................................................64
2.3.15 UC253 – Edit Rules........................................................................................................................65
2.3.16 UC261 – List Currencies.................................................................................................................67
2.3.17 UC262 – Create Currency...............................................................................................................69
2.3.18 UC263 – Edit Currency...................................................................................................................70
2.3.19 UC264 – Delete Currency...............................................................................................................72
2.4 ORDER LAYER SPECIFICATIONS....................................................................................................73
2.4.1 Process to get an approved calculation...........................................................................................73
2.4.2 Overview of Use Cases in the Order Layer....................................................................................75
2.4.3 UC301 – List Orders.......................................................................................................................75
2.4.4 UC302 – Create Order....................................................................................................................77
2.4.5 UC303 – Edit Order........................................................................................................................78
2.4.6 UC304 – Delete Order....................................................................................................................82
2.4.7 UC305 – Show Order......................................................................................................................83
2.4.8 UC306 – Copy Order......................................................................................................................88
2.4.9 UC307 – Approve Order.................................................................................................................89
2.4.10 UC308 – Close Order......................................................................................................................90
2.4.11 UC322 – Create Program................................................................................................................91
2.4.12 UC323 – Edit Program....................................................................................................................94
2.4.13 UC342 – Create Release.................................................................................................................95
2.4.14 UC343 – Edit Release.....................................................................................................................97
2.4.15 UC344 – Delete Release.................................................................................................................99
2.4.16 UC362 – Create Project................................................................................................................100
2.4.17 UC363 – Edit Project....................................................................................................................102
2.4.18 UC364 – Delete Project................................................................................................................104
2.4.19 UC365 – Show Project..................................................................................................................105
2.4.20 UC368 – Select Models................................................................................................................107
2.4.21 UC373 – Edit Parameters..............................................................................................................109
3 EXPORT FUNCTIONALITY...............................................................................................................112
3.1 UC41 – EXPORT TO PDF...................................................................................................................112

3.1.1 Description....................................................................................................................................112
3.1.2 Actor / Actors................................................................................................................................112
3.1.3 Pre-conditions...............................................................................................................................112
3.1.4 Post-conditions..............................................................................................................................112
3.1.5 Actions / Basic Flow.....................................................................................................................112
3.1.6 Data Structure...............................................................................................................................112
3.1.7 Business Rules..............................................................................................................................113
3.1.8 Exceptions.....................................................................................................................................113
3.1.9 Open Issues...................................................................................................................................113
3.1.10 Screen Layouts..............................................................................................................................113
4 DATABASE.............................................................................................................................................114
4.1 DATABASE MODEL..........................................................................................................................114

4.2 OBJECT DESCRIPTIONS...................................................................................................................114
4.2.1 Charging........................................................................................................................................114
4.2.2 Contact..........................................................................................................................................115
59306615.doc 08-Jan-09 16:32

Version 1.13
4.2.3 Cost...............................................................................................................................................115
4.2.4 Order.............................................................................................................................................115
4.2.5 Parameter......................................................................................................................................116
4.2.6 Rule...............................................................................................................................................116
4.2.7 Type..............................................................................................................................................117
4.2.8 User...............................................................................................................................................117
4.2.9 Vendor...........................................................................................................................................117
4.2.10 Helping Tables..............................................................................................................................117
5 APPENDIX..............................................................................................................................................119
5.1 OPEN ISSUES......................................................................................................................................119

5.2 REFERENCES......................................................................................................................................119
5.3 INCREMENTS FOR NEXT RELEASES OF TEC.............................................................................119
5.4 GLOSSARY..........................................................................................................................................120
5.5 ABBREVIATIONS..............................................................................................................................121
5.6 TEMPLATE FOR USE CASES...........................................................................................................121
5.6.1 UCxxx – Use Case Name..............................................................................................................121
5.7 NEEDED INFORMATIONS FOR INTRODUCTION PHASE..........................................................122
5.8 Additional Screens................................................................................................................................123
59306615.doc 08-Jan-09 16:32

Version 1.13
1 Introduction
This document describes the specifications for the Test Effort Calculator (TEC). This chapter gives a short
introduction on the tool, which is specified in this document.
1.1 Description
GTS plans to introduce a tool which calculates the costs of test efforts in a standardized, transparent and
reproducible way. This tool will be available via intranet to all relevant persons. The tool will be mainly used by
GTS line management and test management. It allows defining and sizing of test service orders. An order can
consist of a number of projects which itself can be grouped in releases and programs. To each project a number
of charging models can be assigned, which calculates the cost for a specific part of the project. The results of an
estimation are reportable on various levels.
1.2 Structure of Application

The Test Effort Calculator application is divided into three application layers as given below.
Layer Module
Operator  Profiles and Rights Management
 Vendor Management
 User Management
Engine  Parameter Management
 Service Management
 Charging model (configuration) management
 Rule Management
Order  Order Management
The brief description of the three layers is as provided below:

Operator Layer handles the Creation of User Groups and assigning of Permissions to these User Groups. It also
inputs the data corresponding to various vendors who work with GTS. The users are created and assigned to the
required User Groups.
Engine Layer handles the management of Parameters, Rules and the configuration of Charging models using
the declared parameters and calculation rules. These charging models are assigned to the various services
provided by GTS conform the service provisioning catalogue, and as administrated in this Layer. These services
can be chosen for effort sizing in Order Management
Order Layer handles the configuration of individual GTS orders by setting their level, defining specific services
and generating the effort sizing of GTS orders. Users (e.g. assigned Test or Line Managers) are doing this for the
projects they are responsible for. Orders will following a standard 4-eyes approval process.
Each of the sections mentioned above have been described in detailed functional specifications.
59306615.doc 08-Jan-09 16:32

Version 1.13
1.2.1 Use Case Diagrams
1.2.1.1 Operator Layer
Operator Layer
Edit User Group User Groups

List User Groups
UC103
UC101
Delete User Group

UC104
Create Usere Group
UC102
User
List Users Edit User
UC111 UC113
Delete User
UC114
Create User
UC112
Actor
Cost Types
List Cost Types Edit Cost Type
UC121 UC123
Delete Cost Type

UC124
Create Cost Type

UC122
Vendor
List Vendors
UC131 Edit Vendor
UC133
Delete Vendor
UC134
Create Vendor
UC132
59306615.doc 08-Jan-09 16:32

Version 1.13
1.2.1.2 Engine Layer
Engine Layer
Services
List Services Edit Services
UC221 UC223
Create Services
UC222
Delete Services
UC224
Charging
List Charging Edit Charging Model
Model UC231 Model UC233
Create Charging Edit Rules

Model UC232 UC253
Delete Charging
Actor Model UC234
Parameter
List Parameter
UC241 Edit Parameter
UC243
Create Parameter
UC242
Delete Parameter
UC244
Currency
List Currencies Edit Currency
UC261 UC263
Create Currency
UC262
Delete Currency
UC264
59306615.doc 08-Jan-09 16:32

Version 1.13
1.2.1.3 Order Layer
Order
Approve Order
Actor 1 UC305 Created Order
UC302
Close Order
UC308
Delete Order
UC304
List Orders
UC301
Actor 2
Show Order
UC305
Copy Order
Edit Order UC306
UC303
Program
Edit Programs
UC323
Create Program
UC322
Release
Edit Release
UC343
Delete Release
UC344
Create Release
UC342
Project
Edit Project
UC363
Create Project
UC362
Select Model
UC368
Delete Project Edit Parameter

UC364 UC373
59306615.doc 08-Jan-09 16:32

Version 1.13
1.3 Order Requirements

The main target of TEC (test effort calculation) application is to calculate for every order in a standardized,
transparent and reproducible way the test efforts. So when we are talking of an order we have the effort
calculation for this order in mind. In this chapter we try to clarify a few requirements for the effort calculation.
1.3.1 Order design and cost spliting

The approach of designing a new effort estimation is a bottom up approach. All necessarry services are identified
and together with charging models assigned to an project. The values of the charging model parameters are filled
in and a calculation can be done. The following list shows the steps in detail.
1. Defining the order/effort-estimation itself, which includes the setting of the base attributes and choosing
a complexity level.
2. Building up the frame of the order depending on the complexity level.
a. Low-project: Defining a project.
b. Medium-release: Defining a release. A "Release-Project" is automatically build under the
release.
c. High-program: Defining a program and at least one release. A "Release-Project" is
automatically build under every release.
3. All required services have to be identified. This services are selected together with at least one charging
model and are assigned to the created project. "Test Management" is a mandatory service for every
project. The charging models define the parameters which are needed for the calculation
4. The parameters of the different charging models have to be filled with values valid for this testing offer.
5. After assigning all values a (first) effort calculation can be done.
The release testing can oftenly include efforts and costs which should not completely be charged to the release
itself. Therefore a release can include additional projects. The additional projects can take parts off the efforts
from the "Release Project" and can include additional efforts. The effort and cost spliting is a top down
approach. Services and charging models and the corresponding amount of the parameter values are first assigned
to the "Release Project" and afterwards splited to additional projects by assigning identical service charging
model combinations to this projects. The effort and cost spliting is realised by the following steps.
6. Additional projects are setup under the release.
7. Services and corresponding charging models are assigned to these projects.
8. The parameters of the different charging models have to be filled with values.
When in an additional project within an release the same service and charging model combination is used as in
the "Release Project" the values of the input parameters in the additional projects are substracted from the
corresponding values in the input parameters of the "Release Project". In this way the efforts from the release
can be split to the additional projects. In the case the substraction of efforts from the "Release Project" guides to
an negativ result of the values in the "Release Project" there has to be a warning.
59306615.doc 08-Jan-09 16:32

Version 1.13
The following two tables are created as an example for this effort spliting. The first table shows an release which
only includes the "Release Project" and its efforts. The second table shows the release with two additional
projects and with splitted and additional efforts.
Release 2008Nov – with all related efforts
Projects Services Charging Person TC Regress TC Regress TC new
Models Days onshore offshore offshore
Release- Test TM_int_CS 10
Project Management
Test Design FB_TD_ext_CTS 50
Regression FB_RT_ext_CTS 100 500
Testing
Functional FB_FT_ext_CTS 30
Testing
Test FB_TA_ext_CTS 10
Automation
Release 2008Nov – with additional projects and splited efforts
Projects Services Charging Person TC Regress TC Regress TC new
Models Days onshore offshore offshore
Release- Test TM_int_CS 7
Project Management
Test Design FB_TD_ext_CT 0
S
Regression FB_RT_ext_CTS 100 500
Testing
Functional FB_FT_ext_CT 10
Testing S
Test FB_TA_ext_CT 5
Automation S
B12345- Test TM_int_CS 1
2008Nov-1 Management
S
Functional FB_FT_ext_CT 20
Testing S
P4321- Test TM_int_CS 2

2008Nov Management
S
Test FB_TA_ext_CT 5
Automation S
Browser TM_int_CS 2
Testing
Services with splited efforts are shown in bold.
59306615.doc 08-Jan-09 16:32

Version 1.13
1.3.2 Order reporting
In the section "Parent Child Relationship" of this chapter you will find pictures which show the structure of an
order for the different complexity levels.
The efforts off an order are calculated by the rules of the charging models. The result of every charging model is
either a currency value or a number for person days.
Internal efforts are always calculated on a time and material model and charged and reported in person days.
External efforts are calculated on different models and are always charged in an currency amount. If the currency
of the charging model/vendor differs from the currency of the order the value has to be converted to the currency
of the order.
For reporting the efforts have to be shown on every structural level (service, project, release, program) of an
order.
For transparency the reports should also include the values of the key parameters for every charging model.
An example for an report is shown in the use case "Show Order" in chapter 2.4.
1.3.3 Order persistency
Orders with all their structural levels are hold in a database. It is possible to create save and afterwards extend or
change an order. The values of parameters which are assigned by service charging model combinations to the
projects of an order are also hold in the database.
The results of an effort calculation which belongs to an order are directly shown in a report. This values are only
calculated for reporting and are not persistent.
1.3.4 Order status
Orders can have three different stati.

 Pending
When an order is created its status is automatically set to pending. During the creation and finalizing
phase the status stays at pending.
 Approved
When the order is finalized it has to be reviewed by a second person (two-person integrity). If this
person is satisfied with the content of the order he set the status to approved. This second person needs
approve rights, which the creator of the order does not have.
 Closed
When all the test work which was included in an order has finished this order will be set to closed. This
change of status will be done by the same person who set it to approved.
Orders with status "approved" and "closed" can not be changed any more. But all details of this orders stay in the
database and can be shown by the same pages, which was used before to edit the details.
In case of "approved" and "closed" orders all "Create", "Delete" and "Save" functionality is disabled and the
input fields are readonly.
59306615.doc 08-Jan-09 16:32

Version 1.13
1.4 Parent Child Relationship

An order can have different complexity levels depending on the amount of tests that have to be done. Every
order is defined with one of three complexity levels. The effort calculation complexity for an individual order
depends upon the order level chosen, being: low – order includes only one project, medium – order includes one
release with several projects or high – order includes a program with several releases. When the level is
identified a program, release or project can be assigned correspondingly. Within every project predefined
services and charging models can be selected. The charging models include the rules for calculating the effort.
Level 1: Low - Project:

A project is a standalone entity and all the calculations for the efforts are based only on the basic input
parameters for the project. I.e. there is no need to allocate any costs related to the project to any other entity. The
project includes regression project, new project and the change requests.
Projekt
Service
Model Rule
Model Rule
Model Rule
Service
Model Rule
Model Rule
59306615.doc 08-Jan-09 16:32

Version 1.13
Level 2: Medium - Release:

A release can have various child projects within itself. Thus the release is the parent of these individual projects.
Release
Projekt_A
Service1
Model Rule
Model Rule
Service2
Model Rule
Projekt_B
Service1
Model Rule
Model Rule
Service2
Model Rule
Below every release there is always one special project (Release Project / Naming convention) which holds the
effort for the release.
59306615.doc 08-Jan-09 16:32

Version 1.13
Level 3: High - Program:

A program can have various releases within itself. Thus the program is the parent of these individual releases.
Program_i
Release_Z
Projekt_A
Service1
Model Rule
Model Rule
Service2
Model Rule
Projekt_B
Service1
Model Rule
Model Rule
Service2
Model Rule
Release_X
Projekt_C
Service1
Model Rule
Model Rule
Service2
Model Rule
Release_Y
Projekt_D
Service1
Model Rule
Model Rule
Service2
Model Rule
The bottom up approach is followed for estimation of efforts for every project. For orders with complexity
medium and high there is also a top down approach which allows to split efforts of the "Release Project" to
additional projects in the same release. For e.g. in case of a release, the user fills up the details for each of the
projects separately. When a service charging model combination of a project correspond to the same
combination of the "Release Project" then this efforts are substracted from the efforts of the "Release Project".
59306615.doc 08-Jan-09 16:32

Version 1.13
Procedure:
1. Level 1: Low - Project
i. A new order is opened by the test manager for complexity level low
ii. The user enters the input details required for the project
iii. The system provides the output for the project
2. Level 2: Medium - Release
i. A new order is opened by the test manager for complexity level medium
ii. The user enters the input details required for the release-project.
iii. The user enters the input details for additional projects 1, 2, 3…n separately under the respective
project
iv. Efforts in identical service charging model combinations are substracted from the release-project.
All the other efforts not borne by the projects are charged to the release-project.
v. The system provides the output for each of the projects and for the release
3. Level 3: High - Program

i. A new order is opened by the test manager for complexity level high
ii. The user introduces one or more releases.
iii. The user enters the input details required for the release-project.
iv. The user enters the input details for additional projects 1, 2, 3…n separately under the respective
project
v. Efforts in identical service charging model combinations are substracted from the release-project.
All the other efforts not borne by the projects are charged to the release-project.
vi. The system provides the output for each of the projects, releases and the program
 Efforts for e.g. Functional Regression testing and technical regression testing could be charged to a
release or a program project.
59306615.doc 08-Jan-09 16:32

Version 1.13
2 Detailed Functional Specifications
2.1 General Specification

In this section you find some general items which are valid for the TEC application.
 The application should be WEB based
 The application should run on Credit Suisse JAP Environment
 The application should be usable for all ressorts, who do offer testing as an service, within CREDIT
SUISSE for their effort estimation. Global usability.
 Because of the global usability every order can have its own currency. This order currency is used for
reporting all efforts of this order in this currency. A charging model assigned to an order can have his
own currency, which depend on the vendor which carries out the service. The efforts of this charging
model have to be converted in to the currency of the order for reporting.
 The TEC application will use JAP user identification and the HTTPS protocol for data exchange
between client and server. Because JAP user identification is used there is no password for user
identification required.
 Database integrity has to be assured. Therefore all entities that are related to an entity which is planed
for deletion must be deleted first.
 Every deletion of an entity has to be confirmed in an additional message window.
"Do you really want to delete! Yes, No."
 The availability of functionality depends on the authorization of the user. The user should see only
functionality which he is authorized to use.
Suggestion for Severity Levels

Severity Level Level of Information Description
1 Error: Message Unexpected behavior of the application e.g.
Please inform adminstrator. application exception, database failure, database
connection
2 Warning: The user enters wrong values or makes an failure.
3 Message: A business rule was violated and an following
action is not possible.
4 Information: The user gets additional information about an
topic.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2 Operator Layer Specifications

This section describes the functionality of the operator layer which includes: Profiles and Rights Management,
Vendor Management and User Management.
In Profiles and Rights Management the User Groups and their applicable Rights on module level can be defined.
There are at most three different rights within one module (Read / Write / Approve). Currently the approve right
is planed to be used only in the Order Management Module. The approve rigth in order management is used to
implement two-person integrity in effort calculation.
Module Affected Items/Objects Rights
Order Management Orders, Programs, Releases, Read, write, approve
Projects
Engine Management Parameters, Services, Charging Read, write
Models, Currencies
User Group Management User Groups Read, write
User Management Users Read, write
Vendor Management Vendors, Cost Types Read, write
An User Group can not have the Write and Approve right at the same time on a single module level. This should
be a system constraint.
There is no approval cycle foreseen for changes in the specific Operator and Engine modules. An approval cycle
is foreseen for Order Management. ==> to be checked with expert reviewers.
2.2.1 Sequence of Use Cases in the Operator Layer

The procedure for creation of a user group, vendor and user is described as follows:
1. A User Group is created and permissions are set for this user group.
2. The operator defines cost types (roles of users).
3. The operator creates a Vendor and provides related information for the vendor including rates for the
cost types.
4. The operator creates a User and assigns the user to an user group, a cost type and a vendor.
59306615.doc 08-Jan-09 16:32

Version 1.13
In the following table you find an overview of all use cases which are specified in this section.
User Group User Cost Type Vendor
UC101-List User Groups UC111-List Users UC121-List Cost Types UC131-List Vendors
UC102-Create User UC112-Create User UC122-Create Cost UC132-Create Vendor
Group Type
UC103-Edit User Group UC113-Edit user UC123-Edit Cost Type UC133-Edit Vendor
UC104-Delete User UC114-Delete User UC124-Delete Cost UC134-Delete Vendor
Group Type
2.2.2 UC101 – List User Groups
2.2.2.1 Description
Actor clicks the link in the left hand navigation and gets a list of all User Groups.
2.2.2.2 Actor / Actors

Actor with at least the read right for User Group Module.
2.2.2.3 Pre-Condition
User is already logged in.
2.2.2.4 Post-Condition
A page with the following content is displayed:
 A "Create User Group" Button or Link
 A "Delete User Group" Button or Link
 A "Edit User Group" Button or Link
 A list with all User Groups is displayed. This list includes:
o User Groups Name
o Permissions Assigned to User Group
2.2.2.5 Actions / Basic Flow

1. The user clicks the link "List User Groups" in the left hand navigation
2. A list with all User Groups is shown.
2.2.2.6 Data Structure

See Chapter 4.1Database Model.
2.2.2.7 Business Rules
2.2.2.8 Exceptions
Severetity level Level of information Action Text
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.2.9 Open Issues
2.2.2.10 Screen Layouts
2.2.3 UC102 – Create User Group
2.2.3.1 Description
Actor is responsible for setting up and maintaining the user group profiles for restricting the operations in the
Test Effort Calculator. The actor defines a new user group and sets its rights.
There are three different rights per module
 Read
 Write
 Approve
This Rights can be set for the different modules of the TEC application
 Order Management
 Engine Mangement
 User Management
 User Group Management
 Vendor Management
59306615.doc 08-Jan-09 16:32

Version 1.13

Actor with the read and write permission for User Group Module.
The User Group List is displayed.
List of all User Groups is displayed. All the changes are saved in the database.

1. Invoked from Use Case UC101-List User Groups
2. Click on 'Create' Button. A blank text box appears with cursor on the textbox.
3. Enter the name of the new User Group.
4. Select the permissions of the new User Group.
5. Click on 'Save' button. The User group should appear in the list.

 All user group names should be unique.

 An User Group can not have the Write and Approve right at the same time on a single module level.
 It is planed to hold also users without any permissions to the application in the user table. Therefore
there must be a user group without any rights.
2.2.3.8 Exceptions

1 Error Storing changes not UC_102.0_ MsgTXT
possible "Please inform
administrator"
2 Warning User tries to save an UC_102.1_ MsgTXT
existing Name
3 Message User goes back UC_102.3_ MsgTXT
without to save the
Input
2.2.3.9 Open Issues
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.3.10 Screen Layout
2.2.4 UC103 – Edit User Group
2.2.4.1 Description
Actor wants to change the name or the permissions of a User Group

Actor with the read and write rights for User Group Module.
The User Group List is displayed. At least one User Group is present in the List.
The permissions set by the user are saved. All the changes are saved in the database.

1. Invoked from Use Case UC101-List User Groups
2. Click on the 'Edit' Link/Button behind a user group.
3. A the 'Edit User Group' page is displayed with various checkboxes for permissions in each module.
4. Change the name or set permissions by clicking on the desired checkboxes
59306615.doc 08-Jan-09 16:32

Version 1.13
5. Click on 'Save' button. The changed permissions are saved and system navigates to the 'List User
Group' page.


Same as UC102-Create User Group.
2.2.4.8 Exceptions

1 Error Storing changes not UC_103.0_ MsgTXT
possible "Please inform
administrator"
2 Warning User tries to save an UC_103.1_ MsgTXT
existing Name
2 Warning Actor tries to set UC_103.2_ MsgXT
Approve and write
rights on same User
Group
2.2.4.9 Open Issues
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.5 UC104 – Delete User Group
2.2.5.1 Description
Actor is responsible for setting up and maintaining the user group profiles for restricting the operations in the
Test Effort Calculator. The actor wants to delete a user group.

Actor with the read and write rights for User Group Module, like the Root-Administrator or Operator, can delete
User Groups
Actor is on page List User Groups
At least one User Group is present in the List.
User Group is deleted from the list. All the changes are saved in the database.

The actions are as
59306615.doc 08-Jan-09 16:32

Version 1.13
1 Invoked from Use Case UC101-List User Groups

2 Select a User Group
3 Click on 'Delete'.
4 The system displays a warning message with the buttons 'Yes' and 'No'
5 Click on 'Yes' button. User Group is not displayed in the list anymore.
2.2.5.6 Alternate Flow 1

1 Continued after Step 4 in Basic Flow
2 Click on 'No'
3 The selected User Group is not deleted from the list

 The User Group can only be deleted if both the conditions below are true
o No users are assigned to the User Group
o The Root Administrator User Group and its Root Administrator User, both delivered by
default, can not be deleted.
2.2.5.9 Exceptions
Level of information Action Text

Message Actor tries to delete a existing User Group has still users
Group which has still assigned assigned. Delete not possible!
User
Message Actor tries to delete Root This Group is Root Administrator
Administrator Group Group and can not be deleted.
2.2.5.10 Open Issues
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.6 UC111 – List Users
2.2.6.1 Description
Actor clicks the Link in the left hand navigation and gets a list of all Users.

Member of the user group with atleast read rights in the module 'User Management'
User is already logged in.
User Groups should already be defined.
A page with a list with of all users is displayed.

1. The Actor clicks the link "List Users"
2. A list with all Users is shown.
59306615.doc 08-Jan-09 16:32

Version 1.13

 A user must be member of a user group.
2.2.6.8 Exceptions

1 Error User tries to list users. Application Error. Please
Application is not able inform administrator.
to show list.
2.2.6.9 Open Issues
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.7 UC112 – Create User
2.2.7.1 Description
Actor adds a new user to the system. Each of these users is assigned to one of the user groups and gets the access
permissions of that user group. The other details of the user such as vendor, resource type, address etc. are also
captured within this module.
The new users are added using the 'Create' functionality.

Member of the user group with read and write rights in the module 'User Management'
The Vendors and Cost Types are already in the database.
User Groups are defined.
The User List is displayed.
List of all Users is displayed. All changes are saved

1. Invoked from Use Case UC111-List Users
2. Click on 'Create User'
3. Enter the User specification
4. Click on 'Save'
5. The User appear in the list.

 To make sure that a user is stored only once in the database there should be a check and a warning when
an actor tries to store a user with an already existing name.
 It should not be possible to save a new user with an PID that is already existing in the database.
PID must be unique.
 Every user should be member of an user group. Because there are also users without any permissions in
the application there must also be a user group without permissions.
 User identification is done via PKI certification (JAP).
2.2.7.8 Exceptions

1 Error Storing not possible Please inform administrator
2 Warning Actor tries to save an Warning, user with this
user with an already name already exists. Do
existing Name you want to proceed? Yes,
59306615.doc 08-Jan-09 16:32

Version 1.13
No
2 Warning Actor tries to save an Warning, user can not be
user with an already stored. User with PID is
existing PID already in the database.
2.2.7.9 Open Issues
2.2.8 UC113 – Edit User
2.2.8.1 Description
The operator needs to edit user specification details.

The User List is displayed. Atleast one User is present in the List.
59306615.doc 08-Jan-09 16:32

Version 1.13
The changed user details are saved. All the changes are saved in the database.

1. Invoked from Use Case UC111-List Users
2. Actor clicks the 'Edit' link behind a user entry in the list
3. The 'Edit User' page appears.
4. The actor changes the attributes of the user.
5. Click on 'Save' button.
6. The system navigates back to the 'List Users' page

 The resource type and Vendor details for the user can only be changed if the condition below is true
o The user is not assigned to any of the 'pending' orders
2.2.8.8 Exceptions

1 Error Storing changes not Please inform administrator
possible
2 Warning User tries to save a not Change not possible, the
allowed value user is perhaps used in an
pending order.
2.2.8.9 Open Issues

Is (de)activation of Users required, eg for history reasons?
Can/Should this be linked to an approval step?
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.9 UC114 – Delete User
2.2.9.1 Description
Actor wants to delete a user from the list.

The User List is displayed. Atleast one User is present in the List.
User is deleted from the list. All the changes are saved in the database.

The actions are as
1 Invoked from Use Case UC111-List Users
2 Clicks in the list on 'Delete' link behind a user.
59306615.doc 08-Jan-09 16:32

Version 1.13
4 Click on 'Yes' button.
5 The User is not displayed in the list

2 Click on 'No'
3 The selected User is not deleted from the list
4 The User is still displayed in the list

 The User can only be deleted if the condition below is true.

o The user is not assigned to any of the 'pending' orders.
2.2.9.9 Exceptions

1 Error Deletion not possible Please inform administrator

Which error messages, etc.?

See use case UC111-List Users.
2.2.10 UC121 – List Cost Types
2.2.10.1 Description
A user wants to list all currently available cost types.
Other possible wordings for cost types, are resource types or test roles.

Actor has read rights in the module 'Vendor and User Management'.
2.2.10.3 Pre-Conditions
Actor is logged to the system.
2.2.10.4 Post-Conditions
The list of all currently existing cost types is displayed.
 The actor clicks the link 'List Cost Types' in the left hand navigation.
59306615.doc 08-Jan-09 16:32

Version 1.13

See Database Model in chapter 4.1.
 Cost Types are used to distinguish between different per day costs which a vendor offers.
 The values of the per day costs are stored with the vendor. So it is possible to have different rates for
the same type for every vendor.
 A reference to a type and a vendor is also stored with every user. So it is possible to determine also the
per day rate of an user.
2.2.10.8 Exceptions

1 Error User tries to list cost Application Error. Please
types. Application is inform administrator.
not able to show list.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.11 UC122 – Create Cost Type
A user wants to create a new Cost Type.

Actor has read and write rights in the module 'Vendor and User Management'.
The list of current Cost Types is shown.
There is a new Cost Type saved in the database and shown in the list.
 Invoked from Use Case UC121-List Cost Types

 The actor clicks the link/button 'Create Cost Type'. The 'Create Cost Type' page appears.
 The actor enters a name for the new Cost Type
 The actor submits his entrys.

See Database model in chapter 4.1.
 It is planed to have only round about 10 different cost types.

 The cost type names should be unique.
 A new cost type must be made available to every current vendor. The initial value should be set to zero.
This initial value can be changed by editing the vendor.
2.2.11.8 Exceptions

2 Warning Actor tries to save an Warning, storing not
cost type with an possible. Cost type with
already existing Name this name already exists.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.12 UC123 – Edit Cost Type
A user wants to change a Cost Type.

The changed Cost Type saved in the database and shown in the list.
 Invoked from Use Case UC121-List Cost Types

 The actor clicks the link/button 'Edit Cost Type' behind a cost type in the list. The 'Edit Cost Type' page
appears.
 The actor changes the name of the Cost Type
59306615.doc 08-Jan-09 16:32

Version 1.13
 The actor submits his entry.


 When editing the cost type only the name for a resource type / role is changed. All existing values
assigned to vendor should stay.
2.2.12.8 Exceptions

59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.13 UC124 – Delete Cost Type
A user wants to delete a Cost Type.

The Cost Type is deleted in the database and no longer shown in the list.

1. Invoked from Use Case UC121-List Cost Types
2. The actor clicks the link/button 'Delete' behind an cost type in the list.
3. A window with an security query appears. 'Do you really want to delete? Yes, No'
59306615.doc 08-Jan-09 16:32

Version 1.13
4. The actor chooses 'Yes'.

5. The list of cost types is reshown with the cost type missing.
Alternate Flow
1. Proceeded after step 3
2. The actor chooses 'No'.
3. The list of cost types is reshown with the cost type still in place


2.2.13.8 Exceptions

2 Warning User tries to delete a Delete cost type is not
Cost Type which is possible. Cost type is still
still assigned to a user. assigned to the following
users. (user list)

See screen layout UC121-List Cost Types.
2.2.14 UC131 – List Vendors
Actor clicks the Link in the left hand navigation and gets a list of all Vendors.

Actor with at least the read right for Vendor Module.
The resource types are in place.
A page with a list of all vendors is displayed.
59306615.doc 08-Jan-09 16:32

Version 1.13

1. The user clicks the link "List Vendors"
2. A list with all Vendors is shown (or a empty list is displayed Initial case).

2.2.14.8 Exceptions

1 Error User tries to list Application Error. Please
vendors. Application inform administrator.
is not able to show
list.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.15 UC132 – Create Vendor
Actor can set up and maintain the profile of a vendor e.g. CS Switzerland, Cognizant India, Cognizant
Switzerland, Cognizant Singapore etc. The new vendor is added using the 'Create' functionality.

Member of the user group with read & write rights in the module 'Vendor Management'
The Vendor List is displayed.
Cost Types are in the database.
List of all vendors is displayed. All changes are saved.

1. Invoked from Use Case UC131-List Vendors
2. Actor clicks on 'Create' link/button. The 'Create Vendor' page appears.
3. The actor enters the vendor attributes and other relevant details
4. He clicks on 'Save' button. The Vendor should appear in the list.

 Distinguish between primary and secondary Vendor contact person.

 Vendor should have: company name, company contact address, Currency , VAT percentage
 Per contact person list (mandatory): first and family name, fix line, address,
 Per contact person (free): title, job description, mobile, PO box
 Per vendor multiple resource types can be filled with values (e.g. Onsite1)
 Per resource type the day rate are mandatory or must be set to zero
 VAT rate is a percentage
2.2.15.8 Exceptions
Level of information Action Text

Message Actor tries to save a tbd
existing Vendor Name
Message Not all Mandatory tbd
fields contains a value
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.16 UC133 – Edit Vendor
Actor wants to change the attributes of an vendors.

The Vendor List is displayed. At least one Vendor is present in the List.
The changed vendor details are displayed in the list (when attributes are in the listed attributes). All the changes
are saved in the database.
59306615.doc 08-Jan-09 16:32

Version 1.13

1. Invoked from Use Case UC131-List Vendors
2. Actor clicks in the list of vendors the link 'Edit' behind a vendor. The 'Edit Vendor' page appears.
3. The actor changes the attributes of the vendor.
4. Clicks on 'Save' button.
5. The system navigates back to 'List Vendors' page

 If the per day cost of resource or resource type is changed, it should be reflected in the 'pending'order if
applicable
2.2.16.8 Exceptions

possible
2 Warning User tries to save an tbd
existing Name
59306615.doc 08-Jan-09 16:32

Version 1.13
2.2.17 UC134 – Delete Vendor
Actor wants to delete a Vendor from the list and database.

The Vendor List is displayed. At least one Vendor is present in the List.
No Users should be linked to this Vendor
Vendor is deleted from the list. All the changes are saved in the database.

The actions are as
1 Invoked from Use Case UC131-List Vendors
59306615.doc 08-Jan-09 16:32

Version 1.13
2 Click on one checkbox in the list of the Vendors

3 The actor clicks in the list of vendors on the 'Delete' link/button behind a vendor.
5 Click on 'Yes' button. The Vendor is not displayed in the list

2 Click on 'No'
3 The selected Vendor is not deleted from the list

 The Vendor can only be deleted if the conditions below are true
o No users are assigned to the vendor
o No Cost Types are assigned to the vendor.
o No charging models are assigned to the vendor.
 A Vendor can not be deleted when there are assigned charging models which are used in orders with
status pending or approved
2.2.17.9 Exceptions

1 Error Deletion not possible, Please inform administrator
because of an databse
error
2 Warning Deletion not possible Deletion not possible, there
because there are still may still be users or models
users or models assigned. Please check.
assigned to the vendor

See screen layout UC131-List Vendors.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3 Engine Layer Specifications

The engine is a customizable platform to design the various models for effort calculation. The objective of the
engine is to design various charging models. These charging models can be chosen by the user at an project level
of an order for effort calculation.
It is intended to have different charging models for different services and vendors. Within the charging models
rules for calculation are defined. These rules use parameters. The plan is also to keep the number of parameters
and rules in the different charging models as small as possible. It would be good to have only a single small list
of predefined parameters, from which a subset can be used in all the different charging models.
Within the engine a list of parameters with categories is defined. The categories define where to use the
parameters. The categories define which parameters are displayed for value input on the order level. It is planed
to have only one list of parameters for all charging models. For each charging model, the engine user can create
rules and use the predefined parameters within these rules as variables.
The intention is to keep the number of parameters, rules and charging models as small as possible. This has the
goal to keep the complexity small and to keep the costs in the different projects comparable. This purpose
implies that the number of persons who are allowed to create new parameters and charging models must be
really small.
The user on the order level can change the values of the parameters used in the charging model. For which
values the user has to fill in values on the order level, is defined by the category type of the parameter.
2.3.1 Data Model
Service
(Functional test)
1 Charging Model
(Fix-Price)
n India 1
1
Rule
n India1A
1
1 Parameter Typ Z5
Calculated India 1A
Parameter n Rule
Catagory Z India1B
Parameter Typ Z6
1 1 India 1B
1
Beispiel Berechnungsformel
1 Z1=((A4*C4)+(A5*C5)+(A6*C6)+(A7*C7))/A3
Parameter
Catagory A,B,C,...
1
n Parameter Typ
A,B,C,...
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.2 Overview of Use Cases in the Engine Layer

The procedure for engine configuartion is described as following:
1. The user creates Parameters. A category must be assigned to every parameter.
The categories are "input", "output" and "fix".
2. The user creates Services.
3. The user creates a Charging Model. A charging model can be assigned to one distinct service or is
usable within every service.
4. With each charging model up to five Rules can be defined. Parameters of category "input" can only be
used on the left side, and parameters with category "output" on the right side of the equal sign.
In the following table you find an overview of all use cases which are specified in this section.
Service Charging Model Parameter Rule Currency
UC221-List UC231-List UC241- List UC261-List
Services Charging Models Parameters Currencies
UC222-Create UC232-Create UC242-Create UC262-Create
Service Charging Model Parameter Currency
UC223-Edit UC233-Edit UC243-Edit UC253-Edit Rules UC263-Edit
UC224-Delete UC234-Delete UC244-Delete UC264-Delete
The administration of currencies is also done within the engine management module. Every order has its own
currency in which the calculation for this order has to be done. Additionally every vendor can have its own
currency. So for every calculation of an order there must be a check if a charging model is related to an vendor
which has an other currency. In this case the amount of this charging model has to be recalculated to the
currency of the order.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.3 UC221 – List Services
2.3.3.1 Description
A user wants to list all services which are in the TEC database.

User with at least read rights in the module 'Engine Management'
There are services in the database.
The "List Services" page is shown.
 The actor selects the link/button "List Services" in the left hand navigation.

2.3.3.8 Exceptions

services. Application inform administrator.
is not able to show
list.
2.3.3.9 Open Issues
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.4 UC222 – Create Service
2.3.4.1 Description
A user wants to add a new service to the TEC database.

User with read and write rights in the module 'Engine Management'
The new service is stored in the database. The "List Services" page is shown and the service is in the list.
 The actor clicks the link/button "Create Service". The "Create Service" page appears.
 The actor fills in the name of the service and submits his entry.
59306615.doc 08-Jan-09 16:32

Version 1.13

 Service should have unique names, which itself gives an idea of the offered service. It is not planed to
have an additional description of the service.
2.3.4.8 Exceptions

1 Error Storing Service not Please inform administrator
possible
2 Warning User tries to save an Service with this name is
existing Name already in the database.
Please use an other name.
2.3.4.9 Open Issues
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.5 UC223 – Edit Service
2.3.5.1 Description
A user wants to change the name of an service.

The service is already in the database.
The changed service is stored in the database. The "List Service" page is reshown with the changed name of the
service in the list.
 The actor clicks the link/button "Edit" behind the service. The "Edit Service" page appears.
 The actor changes the name of the service and submits his change.

 Service should have unique names, which itself gives an idea of the offered service.
 If the name of a service is changed all assigned items as charging models or projects should stay in
place.
2.3.5.8 Exceptions

possible
2 Warning User tries to save a not Service with this name is
allowed value already in the database.
Please use an other name.
2.3.5.9 Open Issues
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.6 UC224 – Delete Service
2.3.6.1 Description
A user wants to delete an existing service.

 The service must be in the TEC database.

 There are no charging models assigned to the service.
The service is removed from the database. The "List Services" page is reshown with the service removed.

1. The actor selects the link/button "List Services" in the left hand navigation.
2. The actor clicks the link/button "Delete" behind the service.
59306615.doc 08-Jan-09 16:32

Version 1.13
3. A security query is shown. 'Do you really want to delete this item? Yes, No'.
4. The actor clicks 'Yes'.
5. The list of services is reshown with the deleted entry missing.

1. Continued after Step 3 in Basic Flow
2. The actor clicks on 'No'
3. The list of services is reshown with the entry still in place.

 A service can only be removed, when there are no charging models assigned.
 The must also not be used in currently pending or approved orders.
2.3.6.9 Exceptions

1 Error deletion not possible Please inform administrator
2 Warning User tries to delete an Delete not possible, there
existing Service are still charging models
assigned.

See screen layout UC221-List Services
2.3.7 UC231 – List Charging Models
2.3.7.1 Description
The actor clicks on the Link in the left hand navigation and gets a list of all Charging Models.

Member of the user group with read and write rights in the module 'Engine Management'
The user is already logged in.
There are already services and charging models in the database.
A page with a list of all Charging Models is displayed.
59306615.doc 08-Jan-09 16:32

Version 1.13

1. The user clicks the link "List Charging Models"
2. A list with all Charging Models is shown.

 The name of charging models should be unique.
2.3.7.8 Exceptions

charging models. inform administrator.
Application is not able
to show list.
2.3.7.9 Open Issues
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.8 UC232 – Create Charging Model
2.3.8.1 Description
The actor creates a charging model. Each charging model includes assigned rules which itself use parameters for
calculation. The actor can create various charging models as below.
1. Fixed Bid Estimation Manual: The charging model is essentially the adaptation of the existing estimation
methodology for fixed bid projects. The methodology involves various parameters for calculation of efforts
e.g. Input Fixes, Tech complexity factors, Correction factors, Optimization and Learning Curve etc.
2. Fixed Bid Estimation Automation: This charging model is similar to the manual fixed bid estimation but has
some different set of parameters (valid for automation e.g. Scripting Efforts, Efforts for automation test case
identification etc.)
3. Time and Material Estimation: This is an estimation model for calculation of costs for the services offered
by GTS on T&M basis. The input for the model is the resource type along with the number of person days
for which the resource is allocated to the project.

The list of Charging Models is displayed.
List of all Charging model is displayed. All the changes are saved.

The actions are as
1. Invoked from Use Case UC231-List Charging Models
2. Actor clicks on 'Create Charging Model' link/button. The 'Create Charging Model' page appears.
3. The actor enters or selects the values for the attributes of the Charging Model
4. He clicks on 'Save' button. The 'List Charging Models' page is reshown with the new model in the list.

 All Charging Model names should be unique. e.g. when user tries to save a same Model Name, the
system displays an error message.
 A charging model should be assigned to a single vendor.
 A charging model should be assignable to a single service. But there should also be services that can be
used with every service.
 Vendors and charging models do have a type with values "internal" and "external" this values must be
corresponding for every charging model.
 Charging models with type "internal" do always have the effort type "Time & Material" and the result
of the rules must be person days.
 No approval is needed in the engine module.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.8.8 Exceptions

possible
2 Warning User tries to save an There is already an item
existing Name with that name in the
database. Please enter an
other name.
2.3.8.9 Open Issues
2.3.9 UC233 – Edit Charging Model
2.3.9.1 Description
The actor wants to edit a charging model.
 He can change the base attributes of the charging model.
 He can create, edit and delete calculation rules. This use case includes the use case
'Edit Rules'.
59306615.doc 08-Jan-09 16:32

Version 1.13

The List of Charging Models is displayed. Atleast one Charging Model is present in the List.
Required parameters, vendors, services are defined.
All the parameters and the rules are configured for the model. All the changes are saved.

The actions are as
2. Actor clicks on 'Edit' behind an entry in the list of charging models. The 'Edit Charging Model' page
appears.
3. The User changes the base attributes or edits the rules of the charging model.
4. He submits his changes by clicking the 'Save' button.

 Every charging model can include unlimited numbers of rules.

 The result of proceding rules can be used in the following rules. Every rule has a result variable (res#).
 Every rule can have a unlimited number of parameters.
 The result of the last rule is the amount that will be sumed to the cost of the order. This amount will
possibly be recalculated to the currency of the order.
 The result of the last rule must be an currency amount or for internal charging models an amount of
person days.
2.3.9.8 Exceptions

possible
2 Warning User tries to save an There is already an item
existing Name with that name in the
database. Please enter an
other name.
2.3.9.9 Open Issues

The parameter value for input fixes has to be defined while the user selects the 'Input fix' parameters
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.10 UC234 – Delete Charging Model
The actor wants to delete a charging model.

The Charging Model List is displayed. Atleast one Charging Model is present in the List.
All changes are saved in the database. The 'List Charging Model' page is reshown and the model is removed
from the list.

The actions are as
2. The actor clicks the 'Delete' link/button behind the model entry in the list of Charging Models.
59306615.doc 08-Jan-09 16:32

Version 1.13
8. The list of charging models is reshown with the deleted entry missing.

3. The list of charging models is reshown with the entry still in place.

 If the charging model is used in any order with status 'pending' or 'approved' it cannot be deleted from
the system.
2.3.10.9 Exceptions

1 Error deletion not possible Please inform administrator
2 Warning Actor wants to delete Charging model is used in
a model which is used current order and can not be
deleted.

See screen layout UC-231-List Charging Models
2.3.11 UC241 – List Parameters
The actor wants to see the list of all Parameters.

User with read rights in the module 'Engine Management'
The categories must be defined.
The 'List Parameters' page with a list of all parameters is displayed
59306615.doc 08-Jan-09 16:32

Version 1.13

1. Invoked from left hand navigation by clicking the 'List Parameters' link.
2. A list with all Parameters is shown.

 The list of parameters should be kept small to make the calculations easy and comparable.
2.3.11.8 Exceptions

parameters. inform administrator.
to show list.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.12 UC242 – Create Parameter
The actor wants to create a new parameter.

Parameter Categories are defined.
The 'List Parameters' page is reshown and includes the new parameter. All the changes are saved to the database.

The actions are as
1. Invoked from UC241-List Parameters
2. The actor clicks on 'Create Parameter' link/button. The 'Create Parameter' page appears.
3. The actor enters name and description of the parameter and selects a category.
4. He clicks on 'Save' button. The 'List Parameter' page is reshown with the parameter in place.

 The list of parameters should be kept small to make the calculations easy and comparable.
 All parameter names should be unique. I.e. when user tries to save a same name, the system displays an
error message.
 The should be as short as possible for a smart use in formulas.
 The description should give the needed information which values the parameter will hold.
 The attributes name, description and category are all mandatory.
2.3.12.8 Exceptions

2 Warning User tries to save an Item with that name is
already existing already in place. Please
Parameter Name choose an other name.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.13 UC243 – Edit Parameter
The actor wants to change the attributes of an existing parameter.

Atleast one parameter is present in the List.
The 'List Parameters' page is reshown with the changed attributes. All the changes are saved in the database.

The actions are as
1. Invoked from UC241-List Parameters.
2. The actor clicks the 'Edit' link/button behind the parameter entry in the list. The 'Edit Parameter' page
appears.
59306615.doc 08-Jan-09 16:32

Version 1.13
3. The actor changes the attributes of the parameter.

4. He submits his changes by clicking the 'Save' button.

 Parameter names must be unique.

 The name and the Category can only be changed when the parameter is not used in any charging model.
2.3.13.8 Exceptions

possible
2 Warning User tries to save an Item with that name is
already existing already in place. Please
Parameter Name choose an other name.
2 Warning User tries to change Attributes can not be
name or category of a changed because parameter
used parameter is used in atleast one
charging model.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.14 UC244 – Delete Parameter
The actor wants to delete an parameter from the list.

Atleast one parameter is present in the List.
The 'List Parameters' page is reshown with the parameter deleted from the list. All the changes are saved in the
database.

The actions are as
1. Invoked from UC241-List Parameters.
59306615.doc 08-Jan-09 16:32

Version 1.13
2. The actor clicks the 'Delete' link/button behind the entry in the list of the parameters
5. The list of parameters is reshown with the deleted entry missing.

3. The list of parameters is reshown with the entry still in place.

 The parameter can only be deleted if the below condition is true

o If the parameter has not been selected for any of the charging models.
2.3.14.9 Exceptions

1 Error Deletion of Parameter Please inform administrator
not possible
2 Warning User tries to delete a Parameter can not be
used parameter deleted because parameter
is used in atleast one
charging model.

See screen layout UC241-List Parameters.
2.3.15 UC253 – Edit Rules
The actor wants to define or change the rules of an charging model. The rules can be changed using the 'Edit'
functionality.

Categories, parameters, services and at least one charging model are created and stored in the TEC database.
59306615.doc 08-Jan-09 16:32

Version 1.13
The 'Edit Charging Model' page is reshown with the changed rules in a list. All the changes are saved in the
database.

The actions are as
1. Invoked from UC233-Edit Charging Model.
2. The actor clicks the 'Edit Rules' button/link. The 'Edit Rules' page appears.
3. The actor edits the rules of this charging model.
4. He submits his changes by clicking the 'Save' button. The 'Edit Charging Model' page is reshown with
the rules shown in a list.

 Every Charging Model can have up to five rules.

 For every rule there is one given result parameter.
 When calculated this result parameters can be used in the following rules.
 To have low complexity in every rule, the maximum number of parameters in every rule is limited to
eight parameters.
 The result/output parameter of a rule can be used as a parameter in subsequent rules.
 The rules have to be checked for mathematical correctness. It must be assured that every output
parameter that is used in an rule was calculated in a preceding rule.
 The result of the last rule has always to be a number of person days (internal efforts, time & material) or
an amount of money (external efforts).
2.3.15.8 Exceptions

possible
2 Warning User tries to save not Rules can not be stored.
valid rules. Please check rules.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.16 UC261 – List Currencies
A user wants to see a list of all current currencies and exchange rates in the system.

User with read rights in the 'Engine Management' module.
The 'List Currencies' page is shown with all currencies that are currently in the system.

1. The actor clicks the 'List Currencies' link/button in the left hand navigation. The 'List Currencies' page
appears.

See chapter 4.1 Database Model.
59306615.doc 08-Jan-09 16:32

Version 1.13
 The currencies and their exchange rates are used to convert vendor efforts from the currency of the
vendor to the currency of the order.
 The efforts in the order are shown only in the currency of the order.
2.3.16.8 Exceptions

currencies. inform administrator.
to show list.
 The precision of the exchange has to be defined.
2.3.17 UC262 – Create Currency
A user wants to introduce a new currency to the TEC system.
59306615.doc 08-Jan-09 16:32

Version 1.13

User with read and write rights in the 'Engine Management' module.
The 'List Currencies' page is shown.
The currency the user wants to introduce must be in the list of the currency abbreviations.
The 'List Currencies' page is reshown. The new currency is in the list. The new items are stored in the database.

1. Invoked from UC261-List Currencies.
2. The actor clicks the 'Create Currency' link/button. The 'Create Currency' page appears.
3. The actor selects an abbreviation for the new currency from a list and enters exchange rates for the
already included currencies.
4. He submits his entries by clicking the 'Save' button.

2.3.17.8 Exceptions

1 Error User tries to save Application Error. Please
changes. Application inform administrator.
is not able to store.
2 Warning User tries to save Exchange rate can not be
without giving an empty. Please enter rate.
required exchange
rate.
2 Warning User tries to create Currency can not be
and save an already created. Currency is already
created currency. available.
 The precision of the exchange rates has to be defined.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.18 UC263 – Edit Currency
A user wants to change a currency exchange rate in the TEC system.

The 'List Currencies' page is reshown. The currency with changed exchange rates is in the list. The new items are
stored in the database.

6. The actor clicks the 'Edit Currency' link/button. The 'Edit Currency' page appears.
7. The actor changes exchange rates for the already included currencies.
59306615.doc 08-Jan-09 16:32

Version 1.13
8. He submits his entries by clicking the 'Save' button.

2.3.18.8 Exceptions

1 Error User tries to save Application Error. Please
changes. Application inform administrator.
is not able to store.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.3.19 UC264 – Delete Currency
A user wants to delete a currency and the corresponding exchange rates from the TEC system.

The 'List Currencies' page is reshown. The currency is removed from the list. The items are deleted in the
database.

2. The actor clicks the 'Delete Currency' link/button.
5. The list of currencies is reshown with the deleted entry missing.

3. The list of currencies is reshown with the entry still in place.

 A currency can not be deleted, when there is a vendor or order that uses this currency.
2.3.19.9 Exceptions

2 Warning User tries to delete a Currency can not be deleted
currency which is it is used by a vendor or
used by a vendor. order.

See screen layout UC261-List Currencies.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4 Order Layer Specifications

This section provides the details about the order level of the application. The detailed flow of the order is
governed by the models in the engine. However the user at the order level needs to trigger one or more models
designed at the Engine level.
When the user (test manager) logs into the application, he enters the "list orders" screen. A list of all his orders is
displayed along with the status of each order. He can change an order that has status 'pending' but can view any
of the orders to which he has rights (as defined in the user management module 2.1.2).
The users who are responsible for approving orders are allowed to change the status off an order from "pending"
to "approved" and from "approved" to "closed".
If urgent change requests require a change in an already approved order, this order should be copied and saved
under a new name and afterwards adapted. The copied order has again the status "pending" and has to be
approved again.
2.4.1 Process to get an approved calculation

This section shows the general steps which are needed to reach an approved order.
 A test manager logs to the TEC application.
He gets a list of all his orders and the orders of other test managers where he is in the role of an deputy.
 The test manager creates an new order.
He selects the required services and charging models. He fills in the values for the parameters
corresponding to the desired test coverage and the values delivered by Quality Center. This work can be
done in one or more sessions.
 When the order entry is completed he changes the status from "incomplete" to "completed" and informs
his test manager lead to approve the order.
 The test manager lead enters the TEC application and finds a list of orders he is assigned to as an test
manager lead and the orders of other test managers lead where he is in a role of an deputy.
He examins the order. In the case he is satisfied, he sets the status from "pending" to "approved" and
informs the test manager. In the case he is not satisfied he informs the test manager to make necessarry
adaptions.
 The test manager debates the approved order with the IT-PLs and perhapse he has to make changes to
the order.
 If he has to make changes to the order, he copies the existing order and makes the necessarry adaptions.
The copied order does have the name of the old order extended by an date and the status is again
"pending". He again informs the test manager lead to examine the order.
 If the test manager lead is satisfied he will change the status of the order from "pending" to "approved".
 The approved order will be printed and signed. The printed order is archived. The approved order stays
in the TEC application. The status of the approved order will be changed to "closed" when the testing
has finished. The status of the not longer needed first order should also be changed to closed. After a
period of at most one year the closed orders should be deleted from the system.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.2 Overview of Use Cases in the Order Layer

The following list gives an overview, which use cases the author sees currently within this application layer.
Orders Programs Releases Projects
UC301-List Orders
UC302-Create Order UC322-Create Program UC342-Create Release UC362-Create Project
UC303-Edit Order UC323-Edit Program UC343-Edit Release UC363-Edit Project
UC304-Delete Order UC344-Delete Release UC364-Delete Project
UC305-Show Order UC365-Show Project
UC306-Copy Order
UC307-Approve Order
UC308-Close Order UC368-Select Models
UC373-Edit Parameters
2.4.3 UC301 – List Orders
2.4.3.1 Description
A user wants to get an overview off all his orders. A user newly enters the TEC application the list of his orders
is shown in his welcome page.

All users which are members of the user module "Order Management" and do have atleast "Read" rights.
The actor is a valid user of the system.
Output is a list with all orders the particular user is allowed to see. The orders are grouped by the status of the
orders.

1. The user chooses the link/button "List Orders" from the left hand navigation or connects newly to the
application.

No inputs. Only user identification is needed.
 If a user connects new to TEC, he will find a list of all his orders on the welcome page.
Users are mainly test managers and test manager leads. They will see all orders they are responsible for
or where they are in a role of an deputy. Test Managers will also see orders where they are responible
for parts (e.g. release, project) of the order.
59306615.doc 08-Jan-09 16:32

Version 1.13
 It may be necessary to change an already "approved" order, when new change requests have to be
considered. In this case the approved order has to be copied and the new change requests have to be
entered to the copied order, which has to be approved again. The old order has to be closed.
 The source order has still status Approved.
 The Copy becomes status pending.
 In case of "approved" and "closed" orders all "Create", "Delete" and "Save" functionality is disabled
and the input fields are readonly.
2.4.3.8 Exceptions

orders. Application is inform administrator.
not able to show list.
4 information no order for the user is There are currently no
in the database orders in the database
2.4.3.9 Open Issues
 Currently no
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.4 UC302 – Create Order
2.4.4.1 Description
An actor creates a new order. In a form he fills in a name for the order, the name of IT-PL and B-PL, from drop-
down lists he selects a Test Manager, the complexity level (low, medium, high) and a currency for the order. He
saves his entries.

Members of the user module "Order Management" with writing rights for orders.
Test Managers must be in the database.
Page with all orders including the new entered one, which appears in the group with status "pending".

1. Actor clicks the link/button "List Orders". or connects newly to the application.
On the upcoming page he finds a button/link "Create Order".
2. He clicks the button/link "Create Order". A form comes up, where he
a. fills in a name for the order
b. fills in name of IT-PL
c. fills in name of B-PL
d. chooses an user with write rights in the order module (Test Manager). Normally he/she self.
e. chooses an user with approve rights in the order module (Test Manger Lead).
f. chooses a complexity level "low", "medium" or "high"
g. chooses a currency.
h. Status1 is set to "incomplete".
i. Status2 is set to "pending".
3. He saves his entries.

See database model and attributes of table "Order".

1. IT-PLs and B-PLs will not be saved in the TEC database. Their names are filled in manually for
information.
2. Status1 of every order is initially automatically set to "incomplete". This status can only be changed by
users with write rights in the order module.
3. Status2 of every order is initially automatically set to "pending". This status can only be changed by
users with approve rights in the order module.
4. There will be an base currency for every order. Reports are done in this currency.
5. For each order there will be an deputy test manager. Test manager and deputy must differ.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.4.8 Exceptions

1 Error Storing Order not Please inform administrator
possible
2 Warning User tries to save one There is already an item
existing Order Name with this name in the
database. Please choose an
other name.
2 Warning User tries to save Saving not possible. Test
identical users for test manager and deputy must
manager and deputy. be two different persons.
2.4.4.9 Open Issues

Currently not defined
2.4.5 UC303 – Edit Order
2.4.5.1 Description
Actor edits an already existing order. In a form he is able to change the base attributes of an order like name of
the order, name of IT-PL and B-PL. From selection lists with preselected current values he is able to change the
59306615.doc 08-Jan-09 16:32

Version 1.13
Test Manager, Test Manager Lead, the status1 and the currency. The the status2 of the order is only shown and
not changeable.
The user is able to add and remove projects, programs and releases depending on the defined complexity level of
the order. The complexity level is not changeable.
If a user wants to change the complexity level of an order, he has to completely delete the order and build a new
one, with the desired complexity level.

 The order is already in the database and editable for the actor.
 The status of the order is "pending".
 TMs must be in the database.
The "Edit Order" page is reshown with changed details of this order and a list of all projects. The orders are
grouped by releases, if there are releases.

The actions are as
1. The user clicks on the link/buttton "List Orders". The list of orders appears grouped by their status.
2. The user clicks the "Edit" button/link behind the order he wants to change.
a. A form comes up, which contains the base attributes of the order.
b. Additionally there is a list of assigned projects. The appearance of the list will differ depending
on the complexity level of the order and the already assigned program, releases and projects.
Examples below.
3. The user is able to change the base values of the order, he can create and delete programs, releases and
projects.
Alternate appearance of the lists for different scenarios
Complexity level "low" no project assigned to the order:
Project Name Name B-PL Name IT-PL Action
CREATE
Complexity level "low" one project assigned to the order:

Project Name Name B-PL Name IT-PL Action
N1111/Nov08-1 Business Leader IT Leader EDIT, DELETE
Complexity level "medium" no release assigned to the order:

Release Name Project Name Name B-PL Name IT-PL Action Release Action Project
CREATE
Complexity level "medium" one release and no project assigned to the order:
59306615.doc 08-Jan-09 16:32

Version 1.13
FN 8.3 B Leader IT Leader EDIT, DELETE CREATE
Complexity level "medium" one release and one project assigned to the order:
FN 8.3 B Leader IT Leader EDIT CREATE
N1111/Nov08 B1 Leader IT2 Leader EDIT, DELETE
Complexity level "high" no program assigned to the order:

Program Name Name B-PL Name IT-PL Action Program Action Release
CREATE
Complexity level "high" a program, a release and a project assigned to the order:
IBIP PB Leader PIT Leader EDIT CREATE
Nov08 B Leader IT Leader EDIT CREATE
N1111/Nov08 B1 Leader IT2 Leader EDIT, DELETE

The base attributes of the order as described in the use case "Create Order" or in the database description in the
table order.
 IT-PLs and B-PLs will not be saved in the TEC database. Their names are filled in manually for
information.
 The status2 of every order is initially automatically set to "pending" and can only be changed by a
member of the user module "Order Management" with approve rights to status "Approved" or later to
"Closed". This status field is the only field such a member is able to change.
 The complexity level of an order can not be changed.
 Any layer (program or release) within an order can only be deleted if he is empty.
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.5.8 Exceptions

2 Message User tries to save a not tbd
allowed value
2.4.5.9 Open Issues

Screen layout for order with complexity level "medium" and already a release and one project assigned.
59306615.doc 08-Jan-09 16:32

Version 1.13
Screen layout for order with complexity level "high" and program, releases and projects assigned.
2.4.6 UC304 – Delete Order
2.4.6.1 Description
A user wants to delete an existing order.

 There must be an order in the database, which the actor is allowed to delete.
 The status of the order must be "pending".
The current list of orders for this actor is shown with the deleted order missing.
 Actor clicks the button/link "List Orders" or logs newly to the application.
 If there is an "Delete" link/button behind the order of interest the actor clicks this link/button.
 The Order is deleted and disappears from the list.
59306615.doc 08-Jan-09 16:32

Version 1.13
Alternate Flow
 There is no "Delete" link/button behind the order of interest.
 The actor clicks the link/button "Edit" behind the order and delets depending on the level all programs,
releases and projects from the order.
 The actor comes back to the list of orders and will find a "Delete" link/button behind the order.

User identification is needed. Selection of the order.
 Order can only be deleted when all releases and projects which are related to this order are deleted.
2.4.6.8 Exceptions

1 Error Deletion is not Please inform administrator
possible
2 Message Deletion is not Please delete first all
possible, when there Projects, Releases
are still Projects,
Releases or Programs
assigned
2.4.6.9 Open Issues

Currently no

See screen layout UC301-List Orders.
2.4.7 UC305 – Show Order
2.4.7.1 Description
Actor wants to generate a report for an existing order.

Members of the user module "Order Management" with at least reading rights for orders.
2.4.7.3 Pre-condition
 The desired order must be in the database.
 An PDF-File is shown, which includes the information for all layers of the order. Order details are all
base attributes of an order, the releases and the projects which are assigned to the order.
 The costs and the corresponding parameters have to be shown for the complete order, the release and
every project. The format of the report for all three complexity levels is illustrated in the section 'Screen
Layouts'.
59306615.doc 08-Jan-09 16:32

Version 1.13
 Actor clicks the link "List Orders" in the left hand navigation.
 In the list of orders he looks up for the order he is interested.
 He clicks the link "Show" for the order.

User identification is needed. Selection of the order.
 The costs and the corresponding parameters have to be shown for the complete order, the release and
every project.
 The PDF Files can also be printed, so an print functionality is not needed.
 An order report delivers the order details sorted in three different ways
- Sorted by the structure of the order which is releases, projects, services and models
- Sorted by releases, services and models
- Sorted by releases, vendors, service and models
See the Screen Layouts for an example.
2.4.7.8 Exceptions

1 Error Report can not be Please inform administrator
generated
2.4.7.9 Open Issues

Currently no
59306615.doc 08-Jan-09 16:32

Version 1.13
First Page of the report.
59306615.doc 08-Jan-09 16:32

Version 1.13
Second page of the report.
59306615.doc 08-Jan-09 16:32

Version 1.13
Third page of the report.
59306615.doc 08-Jan-09 16:32

Version 1.13
Fourth page of the report.
2.4.8 UC306 – Copy Order
2.4.8.1 Description
A user wants to copy an existing order. This will be necessary when an already approved order has to be
changed.

 Order which will be copied does have status "approved".
 List of orders is refreshed with an new entry in the list of orders with status "pending".
 The name of the new order starts with the old name followed by an timestamp (20081022-1633).
 The actor clicks the link/button "List Orders".

 In the list of approved orders he clicks the link/button "Copy" behind the order he wants to copy.
59306615.doc 08-Jan-09 16:32

Version 1.13
 The list of orders is refreshed and a new entry appears.

Actor must be identified.
 An already approved order can not be changed.

 If there is an change request concerning an already approved order. The order will be copied and saved
with a new name (i.e. name with an additional timestamp(20081022-1633)). The copied order will than
be adapted and approved again. The old order has to be set to closed. The new order has the status
"pending".
2.4.8.8 Exceptions

1 Error Copy not possible Please inform administrator
2.4.8.9 Open Issues

Currently no.

See screen layout UC301-List Orders.
2.4.9 UC307 – Approve Order
2.4.9.1 Description
A user wants to change the status of an order to "approved".

Members of the user module "Order Management" with approving rights for orders.
 The order must be in the database with status "pending". Projects and services must be assigned.
Parameters must be set.
 The actor has checked that the order is complete and consitent.
 Status1 is set to "completed".
 The list of orders is refreshed and the order entry has moved from the pending list to the approved list.
 The actor clicks the link/button "List Orders". The list of orders appear.
 He clicks the link/button "Edit" behind the pending order.
 The "Edit Order" page appears. Because of his rights the actor is allowed to change the status of the
order to "approved".
59306615.doc 08-Jan-09 16:32

Version 1.13
 He submits his change by clicking the "Save" button.

 A security query appears. "Do you really want to change the status of this order? Yes, No." =>Yes
 The "List Orders" page appears with the order moved to the approve orders.

User identification is needed.
 Every order (effort estimation) has to be approved by people with additional rights. Two-person
integrity.
2.4.9.8 Exceptions

1 Error Status change not Please inform administrator
possible
2.4.9.9 Open Issues

Similar to screen layout UC303-Edit Order.
2.4.10 UC308 – Close Order
A user wants to set the status of an approved order to closed.

Members of the user module "Order Management" with approving rights for orders.
 The order is in the database and has the status approved.

 The actor has checked, that all work/testing on the order has been finished.
The order has moved from the list of the approved orders to the closed orders. The status is changed in the
database.
 The actor clicks the link/button "List Orders". The list of orders appears.
 The actor clicks the link/button "Close" behind the approved order.
(this link is only available for actors with approving rights).
 A security query appears. "Do you really want to close this order? Yes, No."
 The list is refreshed and the order has moved to the closed orders.
59306615.doc 08-Jan-09 16:32

Version 1.13

 Orders which are finished will stay in the database for a fix period of time.
2.4.10.8 Exceptions

1 Error Status change not Please inform administrator
possible

Currently no

See screen layout of UC301-List Orders.
2.4.11 UC322 – Create Program
Actor wants to assign a new program to an order, which was created with the complexity level "high-program".

Members of the user module "Order Management" with writing rights.
 A new order with level "high" has been created.
 The "Edit Order" page appears with the new program entry.
IBIP PB Leader PIT Leader EDIT CREATE
 Actor chooses the link/button "List Orders".

A page with the existing orders appears.
 He clicks the button/link "Edit" behind a newly created order with level "high".
The "Edit Order" page appears. If there is no program assigned to the order, there will be a "Create"
link/button on the program line.
 The actor clicks the "Create" link.
 A form appears where the user has to fill in the name of the program. Additionally he can fill in a name
of a B-PL and IT-PL.
 With clicking the "Save" button in the form he submits his input.
59306615.doc 08-Jan-09 16:32

Version 1.13

See database model and attributes of table "Program".
 User identification is needed.
 The name of the program must be entered.
 Orders with level "high" include one single program, with several releases, which itself can contain
several projects.
2.4.11.8 Exceptions

1 Error Program can not be Please inform administrator
saved
2 Message User tries to save one tbd
existing Program
Name

Currently no
59306615.doc 08-Jan-09 16:32

Version 1.13
Screen layout for "Edit Order" with complexity level "high" and no program assigned. "Create" link is shown.
See also use case "Edit Order" with complexity level "high".
Screen for "Create Program".
2.4.12 UC323 – Edit Program
Actor wants to change the attributs of a program which is already assigned to an order.

Members of the user module "Order Management" with writing rights.
 There must be an pending order with complexity level high and an program assigned in the database.
 The "Edit Order" page appears again with refreshed attributes for the program.
 The Actor clicks the link/button "List Orders".

The "List Orders" page appears.
59306615.doc 08-Jan-09 16:32

Version 1.13
 He clicks the link/button "Edit" behind the pending order from which he wants to edit the program
attributes. The "Edit Order" page appears.
 He clicks the button "Edit" behing the program. The "Edit Program" page appears.
 The actor edits the attributes of the program and submits his changes.

 Complexity Level high for an order must be practicable.
2.4.12.8 Exceptions

1 Error Changes can not be Please inform administrator
applied
allowed value

Currently no

Similar to screen layout UC322-Create Program.
2.4.13 UC342 – Create Release
A user wants to assign a new release to an order.

 There must already be an order with complexity level "medium" or "high" and status "pending".
o For complexity level medium.
There must be currently no release assigned to the order.
o For complexity level high.
There is already a program assigned to the order.
 The "Edit Order" page is reshown with the new release and a "Release-Project" included.
 The actor clicks the link/button "List Orders.

59306615.doc 08-Jan-09 16:32

Version 1.13
 The actor clicks the link/button "Edit" behind the pending order where he wants to assign a release.
The "Edit Order" page appears.
 The actor clicks the link/button "Create" in the column "Action-Release" (see use case "Edit Order").
A "Create Release" page appears.
 In the form he inserts a name for release, B-PL, IT-PL and selects a TM. He submits his changes.

See database model and attributes of table "Release".
 Order must have different complexity levels

complexity level medium: only one release is assignable
complexity level high: one program with several releases are assignable
 With every release automatically a "Release Project" is created. B-PL, IT-PL and TM is the same as in
the release. This project holds the efforts of the release and special calculation rules are valid for this
project (see " Order design and cost spliting" in chapter 1).
2.4.13.8 Exceptions

1 Error Release can not be Please inform administrator
saved to the database
existing Release Name

Currently no
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.14 UC343 – Edit Release
A user wants to change a release which is already assigned to an order.

There is a release assigned to the order.
There is already a program and at least one release assigned to the order.
 The "Edit Order" page is reshown with the changed release.
59306615.doc 08-Jan-09 16:32

Version 1.13

 The actor clicks the link/button "Edit" behind the pending order where he wants to change a release.
 The actor clicks the link/button "Edit" in the column "Action-Release" (see use case "Edit Order").
A "Edit Release" page appears.
 In the form he changes the name of the release, B-PL, IT-PL or selects a TM. He submits his changes.

 Only releases of orders with status pending can be changed.

2.4.14.8 Exceptions

1 Error Change can not be Please inform administrator
saved to the database
allowed value

Currently no
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.15 UC344 – Delete Release
A user wants to delete a release which is already assigned to an order with status pending.

There is a release assigned to the order.
The release does not have projects assigned.
There is already a program and at least one release assigned to the order.
One release does not have projects assigned.
 The "Edit Order" page is reshown with the deleted release missing.
59306615.doc 08-Jan-09 16:32

Version 1.13

 The actor clicks the link/button "Edit" behind the pending order where he wants to delete a release.
 The actor clicks the link/button "Delete" in the column "Action-Release" (see use case "Edit Order").

 Only releases of orders with status pending can be deleted.

 All projects except the "Release Project" have to be deleted before the release can be deleted.
2.4.15.8 Exceptions

1 Error Project can not be Please inform administrator
deleted

Currently no

See screen layout for UC303-Edit Order.
2.4.16 UC362 – Create Project
A user wants to assign a new project to an existing order. He fills in a project name, a project name extension, an
IT-PL name, a B-PL name and selects a TM from a list.

The actor must be a member of the user module "Order Management" and must have writing rights.
 An order with status pending exists.

o For complexity level "low"
no project is assigned to the order
o For complexity level "medium"
a release is already assigned to the order
o For complexity level "high"
A program and at least one release is already assigned to the order.
59306615.doc 08-Jan-09 16:32

Version 1.13
 The TM is already in the TEC database included.
The "Edit Order" page is reshown with a new line for the assigned project.

 The actor clicks the link/button "Edit" behind the pending order where he wants to add a project.
 The actor clicks the link/button "Create" in the column "Action-Project" (see use case "Edit Order").
The "Create Project" page appears with a form.
 The actor fills in the base attributes of the project and submits his entries.

See database model and attributes of table "Project".
 The project name (basic name) should correspond to project name in IT-Plan. To make projects
distinguishable in TEC the project name extension is used.
 The combination of project name and project name extension should be unique to make projects in lists
distinguishable.
2.4.16.8 Exceptions

1 Error Project can not be Please inform administrator
stored/created
existing Project Name

59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.17 UC363 – Edit Project
A user wants to change the base attributes of a project which is already assigned to an order, or wants to
add/remove services/charging models. This use case includes the use case "Select Models"

The actor must be a member of the user module "Order Management" and must have writing rights.
 An order with status pending exists.

 A project is assigned to the order.
 Services and their charging models are in place.
 Charging models and their parameters are in place.
 Test managers are in the database.
The "Edit Project" page is reshown with changes.
59306615.doc 08-Jan-09 16:32

Version 1.13

 The actor clicks the link/button "Edit" behind the pending order where he wants to edit a project.
 The actor clicks the link/button "Edit" in the column "Action-Project" (see use case "Edit Order").
The "Edit Project" page appears with a form for the base attributes and a list of assigned services and
charging models.
 The actor changes the base attributes of the project and submits his entries, edit the parameters of an
charging model or rearranges the assigned services/charging models.

User identification and user rights identification is needed.
Attributes of the projects as described in the table "Project" of the database model.
 All effort calculations are done on the project base.

 The name of a "Release-Project" (see use case "Create Release")can not be changed.
2.4.17.8 Exceptions

possible
allowed value

Currently no
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.18 UC364 – Delete Project
The Actor wants to delete a project from an order or release.

 There must already be an order with status "pending" and a project assigned.
 The project does not have any services assigned.
 The "Edit Order" page is reshown with the deleted project missing.

59306615.doc 08-Jan-09 16:32

Version 1.13
 The actor clicks the link/button "Edit" behind the pending order where he wants to delete a project.
 The actor clicks the link/button "Delete" in the column "Action-Project" (see use case "Edit Order").

 Only projects of orders with status pending can be deleted.

 Only projects with no charging models assigned can be deleted.
 The "Release-Project" can only be deleted with the release itself.
2.4.18.8 Exceptions

1 Error Deleting not possible Please inform administrator

Currently no

See screen layout for UC303-Edit Order.
2.4.19 UC365 – Show Project
Actor wants to generate a report for an existing project.

The actor must be a member of the user module "Order Management" and must have read rights.
 An order with arbitrary status exists.

 Services and their charging models are in place.
 Charging models and their parameters are in place.
 Test managers are in the database.
A PDF file with the desired report is shown.
59306615.doc 08-Jan-09 16:32

Version 1.13

 The actor clicks the link/button "Edit" behind the order where he wants to show/report a project.
 The actor clicks the link/button "Show" in the column "Action-Project" (see use case "Edit Order").
A PDF file appears with the project details

User identification and user rights identification is needed.
Attributes of the projects as described in the table "Project" of the database model.
 All effort calculations are done on the project base.
2.4.19.8 Exceptions

1 Error Error when creating Please inform administrator
PDF report file.

Currently no
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.20 UC368 – Select Models
Actor wants to assign services/charging model to an project.

The actor must be a member of the user module "Order Management" and must have write access.
 The order must have status "pending".

 Parameters, and models with rules are in the database.
 The "Edit Project" page is reshown with corresponding changes.

59306615.doc 08-Jan-09 16:32

Version 1.13
 The actor clicks the link/button "Edit" behind the pending order where he wants to make changes.
 The actor clicks the link/button "Edit" in the column "Action-Project" (see use case "Edit Order")
behind the project he wants to change. The "Edit Project" page appears.
 The actor clicks the link/button "Select Models".
The "Select Models" page appears.
 The actor selects the models he wants to assign and submits his change.

2.4.20.8 Exceptions

2 Message tbd tbd
59306615.doc 08-Jan-09 16:32

Version 1.13
2.4.21 UC373 – Edit Parameters
A user wants to set the values for an charging model which is assigned to a project in an order.

The actor must be a member of the user module "Order Management" and must have write access.
 Order with status "pending".

 At least one project and charging model assigned to the order.
 The edited values are stored in the database. The "Edit Project" page is reshown.

59306615.doc 08-Jan-09 16:32

Version 1.13
 The actor clicks the link/button "Edit" behind the pending order where he wants to make changes.
 The actor clicks the link/button "Edit" in the column "Action-Project" (see use case "Edit Order")
behind the project he wants to change. The "Edit Project" page appears.
 The actor clicks the link/button "Edit" in the "Action – Parameter" column.
The "Edit Parameter" page appears.
 The actor enters the values he wants to assign and submits his change.

Parameters which are used in the rules of this charging model.
 Only parameters which are used in the rules of the corresponding charging model must be entered.
2.4.21.8 Exceptions

2 Message tbd
59306615.doc 08-Jan-09 16:32

Version 1.13
59306615.doc 08-Jan-09 16:32

Version 1.13
3 Export Functionality
This functionality is provided for all the pages of TEC. The user can export any page he comes across in the
TEC. The functionality has been described by the usecase below.
At least the following pages should be display and printable (limitation introduced in version 1.13 of this
document):
 GTS Effort Calculator - List Orders
 all pages behind Link " SHOW "
 GTS Effort Calculator - List Parameters
 GTS Effort Calculator - List Services
 GTS Effort Calculator - List Charging Models
 GTS Effort Calculator - List User Groups
 GTS Effort Calculator - List Users
 GTS Effort Calculator - List Cost Types
 GTS Effort Calculator - List Vendors
3.1 UC41 – Export to PDF
3.1.1 Description
The actor can export the application page by clicking on a 'PDF' icon provided on each page of Test Effort
Calculator.
3.1.2 Actor / Actors

Any user working in the TEC is the actor for this usecase.
3.1.3 Pre-conditions
The actor is a valid user of the system.
3.1.4 Post-conditions
The PDF is generated with the contents of the visible page. A print out with the details can be sent to the printer.
3.1.5 Actions / Basic Flow

 The user clicks on 'PDF' button on the page
 PDF page opens; this page has all the contents of the application page
 The PDF is saved and printed on paper
3.1.6 Data Structure

User identification is needed on Operator,Engine and Order layer
59306615.doc 08-Jan-09 16:32

Version 1.13
3.1.7 Business Rules
3.1.8 Exceptions

2 Message
3.1.9 Open Issues

 The desired pages have to be defined.
3.1.10 Screen Layouts
59306615.doc 08-Jan-09 16:32

Version 1.13
4 Database
The persistent data of TEC will be stored in a relational data base. When the application will be mounted by the
JAP Service Team it has to be a Oracle database.
4.1 Database Model

The following picture gives a first idea of the database model which is behind the described use cases of the last
chapter.
The database model is only a first draft, it is not complete and not optimized. But this draft can be a basis for in
depth discussion of a final data base model.
Please be aware, that it is not planed to realize the database in MS Access. The database of choice is Oracle.
With version 1.13 the deputy has moved directly to the order (ID_Deputy_Testmanager) and the Deputy table
was removed.
4.2 Object Descriptions

This section gives an description of the most important objects/tables of the data model in alphabetical order.
4.2.1 Charging
This table holds the information about the charging models. The attributes are as follows:
59306615.doc 08-Jan-09 16:32

Version 1.13
 Name:
The name is beside the ID a unique identifier of every charging model.
 Type_int_ext:
Delivers the possibility to distinguish between "internal" and "external" efforts.
 Type_tm_fix:
Delivers the possibility to distinguish between the two different charging model types "Time &
Material" and "Fix Bid".
 ID_Vendor:
Every charging model is related to a particular vendor. This field implements this relation.
 ID_Service:
A charging model can be related to only one service or can be used for all services. In the first case this
attribute holds the service id, in the second case this attribute is empty.
4.2.2 Contact
The contact table holds the attributes of up to two contact persons of an vendor. The contact persons are
employees of the vendor and may be contacted in case of contract questions. Normally this contact persons are
not users of the TEC application.
4.2.3 Cost
The cost table is a relational table between vendor and type and holds besides the corresponding ids the value of
the per day costs of a special vendor and a special type. This value must be combined with an parameter "cost"
which has a category "fix" (inserted by the engine administrator, not changeable by a TM). Because there can be
several cost type values for a vendor, a calculation like "cost * days" within a rule has to be expanded to
"∑cost*days" with cost or days zero for not used items.
4.2.4 Order
This table holds the orders which are the central entities in the application. The attributes of this entities are as
follows:
 Name:
The name is beside the ID a unique identifier of every order.
 Status:
The is used to define a lifecycle for a order and to implement two-person integrity. Status can be
"pending", "approved" and "closed". The status is pending during the set up phase of an order. After
this phase the order has to be approved by an other person to get valid. During the testing phase the
order status stays to approved and is set to closed when all the testing work is finished.
 Name_IT_PL:
The name of the IT project leader is only hold for information and will be entered directly by the TM
who creates the order.
 Name_B_PL:
The name of the Business project leader is also hold only for information and will be entered directly by
the TM who creates the order.
 ID_Testmanager:
The Testmanager who is responsible for the order. This TM creates the order and is a user of the system
and member of a user group with write rights in the "Order Management" module.
 ID_TestmanagerLead:
The Testmanager Lead is responsible for approving the order. He is a user of the system and member of
a user group with approve rights in the "Order Management" module. He has the permission to change
the Status2 (pending, approved, closed) of the order.
59306615.doc 08-Jan-09 16:32

Version 1.13
 Complexity:
The context of this attribute is described in chapter "1.3 Parent Child Relationchip". This attribute holds
an indicator for the content of the attribute "ID_Level". Only the following combinations are valid:
Complexity: low-project ID_Level: ID_Project
Complexity: medium-release ID_Level: ID_Release
Complexity: high-program ID_Level: ID_Program
 Status1:
Shows the state of work of the order (incomplete, completed).
 Status2:
Status of order (pending, approved, closed) set by the approver (Test manager lead).
 Start:
Holds the start date of the testing activities which are related with this order.
 End:
Holds the end date of the testing activities which are related with this order.
4.2.5 Parameter
The parameter table holds the definition of all parameters. A parameter has a short name, which is used in rules
and on buttons, and a description of the content. The category describes the use of the parameter. Categories are:
 Input:
The value of the parameter depends on the order and charging model (vendor) its value is filled in by
the TM in the order layer of the application.
 Output:
The value of this kind of parameter is calculated in a rule. There is one parameter of this category for
every rule.
 Fix:
The value of the parameter is globally valid. Its value is set and changed by a user with write rights in
the engine module in the engine layer.
The value of all parameters with category fix should be hold immediate in the value attribute of this table. The
values of the other parameters depend on the project, service and charging model and are hold in the
Project_Charging_Parameter table.
The category "Type_tm_fix" is used to distinguish between parameters used in charging models for "Time &
Material" and "Fix Bid" calculations. When the corresponding type for the charging model is set, only
parameters of corresponding type are shown for usage in those charging models. The result parameters for every
rule do have no type.
4.2.6 Rule
This table holds the information about the up to five rules for every charging model. A rule is a formula which
uses the predefined parameters to calculate a result. The value of the result is again saved in a parameter and can
be used in the following rules.
 Position:
Holds a number for the position (one to five).
 Formula:
Is a string representation of the rule.
 ID_Charging_Model:
Holds the relation to the charging model the rule belongs to.
4.2.7 Type
The type is basically used to distinguish different amounts of per day costs for the Time & Material estimation.
So the type does only have a name attribute which describes a role.
59306615.doc 08-Jan-09 16:32

Version 1.13
It is planed to have round about ten different types. First ideas of types are "TM-onshore", "TM-offshore",
"Testmanager", "Accountmanager", etc.
The type table is connected to the cost table, which holds for every vendor and type combination an value of the
per day cost. If an vendor doesn’t offer an distinct type the value for this type is zero.
The type table is also connected to the employee table to assign the per day cost of the employee via the given
type.
4.2.8 User
Every user of the application and additionally employees of an vendors are hold in the user table. Every member
is hold there with his first and second name, his PID and a releation to a resource type and a vendor.
The user identification is done via the JAP/PKI identification.
Every member of the user table must be member of an user group. Because there are also employees of vendors
in the user table there has to be a user group without any permissions.
A user can be member of serveral user groups, but it must be assured, that a user never holds simultaneously the
"write" and "approve" right in the order module. This would break the two-person integrity for the order module.
4.2.9 Vendor
The vendor is an instituition, which offers services and persons to GTS. Most of the direct attributes of the
vendor are hopefully speaking on their own. The attributes are shown in the picture of the database model. All
other attributes are explained in this chapter.
A vendor can have his own VAT and currency. This approach does have the target to support vendors which are
situated in foreign countries. In every effort calculation the currency off the vendor has to be converted to the
currency of the order.
With every vendor two contact persons can be stored.
Connected with every vendor is a not bounded number of employees with their attributes. Because the
employees do have mainly the same attributes as users of the TEC application and users of the TEC application
are mostly also employees they are both hold in the user table. Every user is connected to a vendor and to a type,
which defines the kind of task/role he is able to do.
The vendor does also have a category "Type_int_ext" to check that an charging model with the corresponding
type can only be connected to a vendor with the same type.
4.2.10 Helping Tables

At the moment there are different helping tables in the database model. They are only used for having a single
point where to maintain values used in different positions in the application. Perhapse not all of this tables are
necessary or perhapse it should have more. The following list gives an overview which fixed values should be
available in the application.
Table name Description
Country Holds country names for selection lists.
Status1 Holds status for order. Values are "incomplete" and "completed". This status
can be set by users with write rights in order management.
Status2 Holds status for order. Values are "pending", "approved" and "closed".
This status can only be changed by users with approve rights in order
management.
Complexity Holds complexity level for order. Values are "low – project", "medium –
release" and "high – program".
Type_int_ext Holds Charging Model type. Values are "internal", "external".
Type_tm_fix Holds Charging Model type. Values are "fix bid", "time & material".
59306615.doc 08-Jan-09 16:32

Version 1.13
Currency Abbreviations Holds unique and international valid abbreviations for currencies that can be
used in selection lists in the system. Values are "CHF", "EUR", "USD", etc.
Categories Categories for parameter types. Values are "input", "output" and "fix".
The values are mainly used in selection lists at different positions within the application. Target is to assure that
this values are the same at every point, where they are used. This approach allows to use this values in SQL
statements.
Instead of using tables in the database in some circumstances it could be a better solution to hold this values in
STATIC variables in a PUBLIC FINAL Java class.
59306615.doc 08-Jan-09 16:32

Version 1.13
5 Appendix
5.1 Open Issues
S. Open aspect Responsible person Action needed

no
1 Reporting and Archiving KK See UC41 Export to PDF
2 Screenshots GS/AS/AE Partily integrated in chapter 2
3 Data Model GS/AS/AE Draft in chapter 4
4 Parameter and Rules List KK
5 Operator Level Use cases/QC Manual KK QC Manual no longer needed.

Realisation of interface
canceled.
6 Approve Functionality for each module has to be defined To be decided Two-person integrity only for
order management
7 Interface to CS intranet for getting user details To be decided User identification
8 Will there be use cases for maintaining change rates for AS/KK/AE Use cases in place
currencies
5.2 References
No Document Title Author / Contact / Source

1.
5.3 Increments for next Releases of TEC

There are still a view ideas for additional functionality which could be implemented in the TEC application. This
functionality is currently not described in this specification. To not complitly loss this ideas they are listed and
shortly explained in this section.
5.3.1.1 Date of payment

Every order includes the base attributes begin of test order and end of test order. In a future release of TEC it
could be possible, that the TEC application directly splits the test efforts to dates of payment.
5.3.1.2 Spliting of efforts for programs

In chapter one there is a description how to split efforts between a "Release Project" and additional projects in
this release. For a future release of TEC an similar functionality should be installed to split efforts between
release in an order which is done for a program.
59306615.doc 08-Jan-09 16:32

Version 1.13
5.4 Glossary
In this chapter you will find a short description of important terms used in this document. This chapter was
included to make sure that everybody does have the same idea of a term.
Term Description
Order Request of a client (normally an IT-PL) to GTS.
A TM opens in TEC an order (form) which describes all services to be provided
to the client.
Level Scope of complexity of an order, which currently has three levels
 Low 1–1 project
 Medium 1–n release – project(s)
 High 1 – n – nprogram – release(s) – project(s)
Service Service offered by GTS. e.g.
 Test Design
 Technical Testing
 Language Testing
 Functional Testing
 Functional Regression Testing
 Browser Testing
 Test management
 Test Data Management
 …
Charging Model Type of effort calculation and charging. e.g.
 Time & Material ( a / b / c )
 Fix Bid ( a / b / c )
 …
e.g. The cost for the service "Technical Testing" can be determined by a
calculation cost = <T&M internal PT's> + <T&M external PT's>.
Workflow Specification of the service – charging model combination. For every service in
combination with a selected charging model it will be necessary to define the
values of parameters used in calculation rules. These values will be entered in
successive forms on different screens or fetched from Quality Center.
e.g.
Screen Declared container of selected parameters.
Rule Method which combines parameters and calculates a new value for a parameter.
Parameter Defined placeholder needed in rules and reflecting a value.
Attributes: ID, description, value, unit.
59306615.doc 08-Jan-09 16:32

Version 1.13
5.5 Abbreviations
Here you find a description of often used Abbreviations.
Abbreviation Description
B-PL Business Project Leader
CR Change Request
GTS Global Testing Solutions
IT-PL IT Project Leader
QC Quality Center
TC Test Case
TEC Test Effort Calculator
(Tool described in this specification)
TM Test Manager
UC Use Case
5.6 Template for Use Cases

The following sub sections are a template for a use case description. Every Use Case Description in this
document should follow this structure.
5.6.1 UCxxx – Use Case Name
5.6.1.1 Description
5.6.1.8 Exceptions
5.6.1.9 Open Issues
59306615.doc 08-Jan-09 16:32

Version 1.13
5.7 Needed Informations for Introduction Phase

This section includes items which have to be clarified before the introduction of the TEC application can start.
The informations have to be delivered to realize a first test of the application with realistic inputs.
Item Explanation
List of currencies The currencies are identified by internationally valied abbreviations. This
abbreviations should be unique and selectable. Which currencies should
be maintained by the system.
List of parameters with a short The parameters are necessarry to implement rules and charging models.
name and a description
Values for parameters with These values are necessarry for calculations
category fix
Summary of rules for For not starting at zero the current rules should be available.
implementation in charging models
Test Data To control realistic results
This list is not complete.
59306615.doc 08-Jan-09 16:32

Version 1.13
5.8 Additional Screens
Welcome pages for users which do have no permissions in the order module. The left hand navigation must be
adapted to the rights the user does have. He should only see links he has permission to.
59306615.doc 08-Jan-09 16:32

Version 1.13
Welcome page for persons who did call the TEC URL but who are not registered user of the application.
59306615.doc 08-Jan-09 16:32


Global Testing Services (GTS) : Test Effort Calculator (Tec) Detailed Specifications

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Global Testing Services (GTS) : Test Effort Calculator (Tec) Detailed Specifications

Uploaded by

Copyright:

Available Formats

Test Effort Calculator

GLOBAL TESTING SERVICES (GTS)

TEST EFFORT CALCULATOR (TEC)

59306615.doc 08-Jan-09 16:32

Vers. No. Date Author, Unit Code Status Comment

Version Date Changed from Comment

59306615.doc 08-Jan-09 16:32

Version Date Changed from Comment

59306615.doc 08-Jan-09 16:32

59306615.doc 08-Jan-09 16:32

TEST EFFORT CALCULATOR (TEC) DETAILED SPECIFICATIONS....................................................1

2 DETAILED FUNCTIONAL SPECIFICATIONS.................................................................................18

2.1 GENERAL SPECIFICATION...............................................................................................................18

59306615.doc 08-Jan-09 16:32

2.3.11 UC241 – List Parameters................................................................................................................59

3.1 UC41 – EXPORT TO PDF...................................................................................................................112

4.1 DATABASE MODEL..........................................................................................................................114

59306615.doc 08-Jan-09 16:32

5.1 OPEN ISSUES......................................................................................................................................119

59306615.doc 08-Jan-09 16:32

1.2 Structure of Application

The brief description of the three layers is as provided below:

59306615.doc 08-Jan-09 16:32

1.2.1 Use Case Diagrams

1.2.1.1 Operator Layer

Edit User Group User Groups

Delete User Group

Delete Cost Type

Create Cost Type

59306615.doc 08-Jan-09 16:32

1.2.1.2 Engine Layer

Create Charging Edit Rules

59306615.doc 08-Jan-09 16:32

1.2.1.3 Order Layer

Delete Project Edit Parameter

59306615.doc 08-Jan-09 16:32

1.3 Order Requirements

1.3.1 Order design and cost spliting

59306615.doc 08-Jan-09 16:32

P4321- Test TM_int_CS 2

59306615.doc 08-Jan-09 16:32

1.3.2 Order reporting

1.3.3 Order persistency

1.3.4 Order status

Orders can have three different stati.

59306615.doc 08-Jan-09 16:32

1.4 Parent Child Relationship

Level 1: Low - Project:

59306615.doc 08-Jan-09 16:32

Level 2: Medium - Release:

59306615.doc 08-Jan-09 16:32

Level 3: High - Program:

59306615.doc 08-Jan-09 16:32

3. Level 3: High - Program

59306615.doc 08-Jan-09 16:32

2 Detailed Functional Specifications

2.1 General Specification

Suggestion for Severity Levels

59306615.doc 08-Jan-09 16:32

2.2 Operator Layer Specifications

2.2.1 Sequence of Use Cases in the Operator Layer

59306615.doc 08-Jan-09 16:32