1 - Purpose
This document provides the full specification details and design of implementing the requirements specified in Section 2 - Business Requirements. This document is the only reference material to be used in the implementation process. Details which are not included in this document will not be considered in the design and implementation.
2 - Business Requirements
This section describes the overall purpose and also defines the business rules to be adhered to.
2.1 - Business Purpose
Write some lines describing the overall purpose of the requirements.
2.2 - Business Rules
This section is to describe all details about the requirements. Feel free to copy the text from the initial customer requirements description, but make sure that ambiguities are highlighted so that these issues might be discussed. Also, when you need to assume an interpretation, highlight it to make the customer aware that it is your interpretation of their requirements.
3 - Design and Implementation
This section is to describe how to fulfill the requirements as specified in Section 2 - Business Requirements. Changes to or extension of object model as well as data model should be described, and functionality to be provided should be outlined.
The description may be split by business requirement, followed by the design and implementation details, but often you may find it useful to cover the different areas of the application, e.g. Customer Care GUI and other GUI's, Self-care, SOAP, signup process and other processes, payment handling, invoice closure etc. Decide for yourself what suits you the best.
For every part of the design and implementation, write a single line or so about your estimate of work days to be used, including any conditions you may have.
4 - Estimates
All estimates are to be listed and aggregated for easy overview under this heading. Use a table structure as shown below:
Description | Number of work days |
|---|---|
First item | 2 |
Second item | 5 |
Any conditions for the estimates should be highlighted as well.
5 - Special Considerations
If none, please remove this section. Otherwise you may add information here
| Anchor | ||||
|---|---|---|---|---|
|
CDRator
Version 1.3
December 2010
Contents
| Anchor | ||||
|---|---|---|---|---|
|
1.1 - Link to CDRator Jira
1.2 - Logging on to CDRator Jira
2 - Create a 'New Issue'
2.1 - Create 'New issue'
2.2 - Priority of Issue
3 - Search Tasks
3.1 - Find an Issue
3.2 - Manage Filters
3.3 - Quick Search
4 - Follow an Issue
5 - Your CDRator Jira Dashboard
5.1 - Dashboard for the 'project'
5.2 - Personal Dashboard
6 - Reports
| Anchor | ||||
|---|---|---|---|---|
|
Change log:
Date: | Author: | Version: | Changes: | ||||||
21 February 2010 | Jesper Wulff | 1.0 | Doc. created | ||||||
06 April 2010 | SD | 1.1 | Added Change Password in Logging on to CDRator Jira
| ||||||
12 May 2010 | JW | 1.2 | Applied changes according to new flow. | ||||||
02 December 2010 | JW/ABH | 1.3 | Applied changes according to updated flow. |
Terms and Definitions:
Terms/definitions: | Meaning: |
N/A | Not applicable |
TBD | To be defined |
Document Conventions
Some screenshots have been enhanced to better show details and may vary from actual GUIs.
Selections for menu items or buttons are in bold. Example: Select View to view...
Strings of menu selections are shown using ">".Example: Select Programs > Citrix > Management Console
DBTableName, DBTableNameColumn, and PL_SQLProcedure are marked using CDRProgramlisting style.Example: Invoice_detail_lines
Examples of code lines are marked using CDRProgramlistingBoxColor style in a gray color box: Example:
CDRProgramlistingBoxColor
Warnings are marked using CDRRedWarning style:Example:
Warning! This gives important information on avoiding damage or errors.
Notes are marked using CDRNote style:Example:
Note: This refers to something you should take a closer look at before proceeding.