Business Requirements Specification C0711143-01

Electronic Bank Statement C0711143-01

Title

C0711143-01 + Electronic Bank Statement

Ref.numbers

C0711143< TopDesk change number / requirement number >

Related Requirements

Responsible BPM

Jurgen Eeren

Business area

F&A

Process

Supporting Opco Process - Financial Processes

Bank Accounting - incomings - electronic bank statement processing

Requesting party

Philip Valkonet - Oc-Nederland B.V.

T (073) 6 815 626| F (073) 6 815 468| E philip.valkonet@oce.com

Priority:

Must have
Should have
Could have
Would have

Version History
Version

Date

Who

1.0

23-11-2007

Ruud Horst

Draft

Final version approval by GBPM (HQ)

Requirements sheet, version 1.0

1/4

Yes

Status
Review

No

Ruud Horst

Final

Business Requirements Specification C0711143-01

Electronic Bank Statement C0711143-01

Description

The bank statements of the house bank of Oc

Alternatives

Post all lines of all bank statements manually. The number of line items per day is
600 to 700.

Business benefit

Posting 1 line take approximately 50 seconds for an experienced user. 650 x 50

seconds. This is the equivalent of 9,03 hours. This time is reduced to 5 minutes
when the posting can be carried out electronically. Furthermore, the bank
statements are entered without typing errors.

Impact of not
implementing

An additional fte will be necessary.

Cost estimation
responisble
business area
(indicate for business, IT and
Opco the estimated effort in
mandays, preferably from an
impact analysis)

Cost estimation
dependent
business areas
(indicate for business, IT and
Opco the estimated effort in
mandays, preferably from an
impact analysis)

Who

Design

Develop

Test

Business

Several

0,0

0,0

1,0

IT

Several

2,0

3,0

1,0

Opco

Several

0,5

0,0

0,0

Who

Design

Develop

Test

Business

Several

IT

Several

Opco

Several

Acceptance criterion

Supporting material

The bank statement must be readable

The first posting step must be carried out error free (green traffic lights in
FEBA)

Posting log, error log must be produced and be printable

Requirements sheet, version 1.0

2/4

Ruud Horst

Business Requirements Specification C0711143-01

Participating parties Person involved

A C

Opco

Philip Valkonet

CSC Venlo
CSC Poing
BPE
F&A

Ruud Horst

IT
Architect
OMD-s
OMD-p
OMD-c
Reporting /BW
DPA
ASS-L
ASS-S
OTC DS CPM
OTC P&S
P2P
Test Centre
EurOc Basis
Authorisation
Other team
Other application
A = Approval
C = Consulted
I = Informed

Requirements sheet, version 1.0

3/4

Ruud Horst

Business Requirements Specification C0711143-01

Quality criteria checklist for requirements

Quality criteria
1. Correct
2. Feasible
3. Necessary

4. Prioritized
5. Unambiguous

6. Verifiable
7. Complete

8. Consistent
9. Modifiable
10. Traceable

Description
Accurate description of the functionality to be delivered.
Only user representatives can determine the correctness of user requirements.
Possibility to implement each requirement within known capabilities and
limitations of the system and its environment. To avoid infeasible requirements
a system expert should be involved in the elicitation process.
Each requirement should document something the customer really needs or
required for conformance to an external requirement, external interface or
standard.
In other words: Each requirement needs to originate from a source recognized
as having the authority to specify requirements.
Assignment of implementation priority. This represents a function of the value
provided to the customer, the relative cost of implementation and the relative
technical risk associated with implementation.
Only one interpretation should be drawn from a requirement statement. Also,
multiple readers of a requirement should arrive at the same interpretation.
Avoidance of subjective words like: user-friendly, easy, simple, rapid,
efficient, several, improved, maximize, state-of-the-art, etc.
Write each requirement in brief, simple, straightforward language.
Is it possible to devise tests (or inspection or demonstration) to determine if a
requirement is properly implemented in the product.
It is hard to spot missing requirements because they arent there. Therefore:
Organize requirements hierarchically to help reviewers understand
the structure of the functionality described, and therefore easier to
tell if something is missing.
Focus on user tasks rather then system functions. This way it is less
likely to overlook requirements.
Highlight gaps by TBD. Not solved TBD will be risks in the risk
management plan.
No conflicts should exist with other requirements or with higher level (business)
requirements.
Must be able to revise the requirement when necessary and maintain a history
of changes made to each requirement.
Should be able to link each requirement to its source, design elements and test
cases.

Requirements sheet, version 1.0

4/4

Ruud Horst