Automated Estimated Delivery Dates (component)

From UG

(Difference between revisions)
Jump to: navigation, search
Line 46: Line 46:
=== User Interface ===  
=== User Interface ===  
-
=== "Normal" Functionality / Use Cases ===
+
=== "Normal" Functionality (Use Cases) ===
-
=== "Abnormal" Functionality / Test Cases ===
+
=== "Abnormal" Functionality (Test Cases) ===
-
+
* '' List unusual scenarios - things that users most of the time would not do but system must handle well ''
== QA ==
== QA ==
Line 55: Line 55:
''This section is to be written by [[QA Engineer]] or [[QA Manager]] or [[Systems Analyst]].
''This section is to be written by [[QA Engineer]] or [[QA Manager]] or [[Systems Analyst]].
-
=== Test Cases ===
 
-
* '' List unusual scenarios - things that user most of the time would not do but system must handle well ''
 
-
* '' Do not list [[Common Test Cases]] - link to them
 
== Look and Feel ==
== Look and Feel ==

Revision as of 20:20, 3 February 2010


Contents

General Info and Scope

  • Classified As: component
  • Parent Mantis: 1726
  • Prerequisites: any articles that must be read before to understand this?

Scope

This covers just this component.

Business Requirements

The purpose of this feature is to estimate delivery date based on known:

  • MOT (all LCL combined, Truck combined into one)
  • Client
  • Orgin Point, Country
  • Destination Point, Country
  • Transit Time in Days

Above record is entered into the system through Admin.

Gen Tab#Automated Estimated Delivery Date is displayed on Gen tab.

If appropriate record exists then system uses the following formula to calculate:

Gen Tab#Automated Estimated Delivery Date = Gen Tab#Notification Date + Transit Time in Days

If not this date is blank.

Notes from Systems Architect

  • This section is defined by Systems Architect. It is written after #Business Requirements are defined.
  • The purpose of this section is to give direction to System Analysts who will write detailed specification.

Rapid Design

  • In some cases (component is non standard) we need to do preliminary not so detailed design before detailed final. And maybe even code it to create Prototype
  • This section does not have to be too detailed or too formalized. We shall not spend too much time on Prototypes - they can change many times.

Detailed Design

Summary

User Interface

"Normal" Functionality (Use Cases)

"Abnormal" Functionality (Test Cases)

  • List unusual scenarios - things that users most of the time would not do but system must handle well

QA

This section is to be written by QA Engineer or QA Manager or Systems Analyst.


Look and Feel


Figures

Figure 1:

Misc

Link to User Guide

Questions

Request For Comments (Suggestions and Ideas)

Known Non Critical Bugs

  • Critical bugs must be posted into Mantis

Implementation: Link To DB

Implementation: Link To Front End Code

Implementation: Link To Back End Code

History of Updates

Links to Archived / Old specs

None.


Tweak: Add truck mode; replace 2 LCL with 1; improve speed; migrate to "Modal design"

Update General Info

Update Description

  • Add truck mode - this is an additional tab
  • replace 2 LCL with 1 - transit Time in Days is defined ones for both LCL modes
  • improve speed
  • migrate to "Modal design" (for Add/Edit)

<Update type>:<Update Summary>

Update General Info

  • mantis: <link> if applicable
  • Update types: Re-design / Tweak / Etc
  • Ideally update all sections of spec (see above) right away. If you have no time to update spec now or multiple people have to be involved then define task here and come back to update later. In this case add links from here to "TBU wiki tag articles" - see above.

Update Description

  • Briefly explain what was done and list links to updated sections.
Personal tools