The form/table for the functional requirements:
An attempt to clarify what should go with each label:
Description - short description of the function. Should also include actions here, if you don't have a separate section for them.
Inputs - describes inputs (from user or the system (storage))
Source - where the inputs come from
Outputs - describes outputs
Destination - where the outputs go (usually screen, printer)
Action - the actions to be taken, include error checking, alternate paths
Requires - what information is needed for computation (if not already mentioned elsewhere in the table) OR
what external interface (API) it uses. Actions the user must perform do NOT go here.
Pre-condition - what must be true before the function is called. This should be true in order for the function to be enabled. Error cases, invalid data, etc. do NOT go here.
Post-condition - what is true after the function is called, should be verifiable, include changes to storage/memory/data.
You may add (or remove) labels as you see fit, but try to be consistent among the different functions.
You are NOT required to use the form/table format.
Refund request:
[This is an optional replacement for the description of 9. Refund Request from the PostageWebsiteReq.pdf document (the original description of the 10 functions). You may use this updated version, or the original description as the basis for your requirements.]
This allows the user to ask to refund a postage purchase. Only labels printed with delivery confirmation (a tracking number) can be refunded via this function. The user should be offered a list of the postage printed in the last 10 days. They should be able to narrow the list using a filter (i.e. by date or zip code). They can then select one label to be invalidated and refunded.
The implementation of this function will involve a call to request a refund from usps for the given label (using the tracking number). The actual refund should occur within the next two weeks (after the request). The update to the PPW user's account (posting the refund) can be delayed by the PPW until the refund is obtained from USPS.
Package types, mail classes, and weights:
I recommend including this information somewhere in the SRS to indicate how to determine the possible values for Package type, Mail class and weight:
Mail Classes:
Express Mail
Priority Mail
First Class Mail
Parcel Post
Media Mail
Package Types:
Envelope
Package
Flat Rate Envelope
Flat Rate Box (small, medium, large)
Regional Rate (box A, box B, box C)
Weights
The user should be offered a range of ounces or pounds, as appropriate based on package type and mail class.
To determine which package types are available in each mail class, and to determine which weight units and ranges for each valid combination of package type and mail class, see the USPS price list, Notice 123:
http://pe.usps.com/text/dmm300/Notice123.htm
Password restrictions:
Password must be at least 8 characters long and contain atleast one of each of the following:
Uppercase letter
Lowercase letter
Special character or number.
Username: No restrictions (just that they must be unique). A string.
The performance requirements are as follows:
System login/logout shall take less than 5 seconds.
Print Postage function shall be processed within 10 seconds.
Other requests shall be processed within 5 seconds.
System shall support 400 simultaneous users.
The APIs
I recommend indicating somewhere in the document which PPW functions depend on which API (if any), USPS.com or the credit card processor. This information could be included in each functional requirement, or it could go under 3.1.3, Software Interfaces (or wherever you list the external software interface requirements). You do NOT need to say which particular function from the APIs below is used for each PPW function (but you may if you want to).
Mock USPS.com API
Assume user account is that of the Postage Printing Website owner, already established with USPS.com
- Get Postage Label
input: sender name and address,
recipient name and address,
package type,
mail class,
weight,
DeliveryConfirmation requested (bool),
Ship date,
user account number and password
output: status: success or failure,
cost of postage,
label (jpg image),
tracking number (if any)
- Calculate Postage Rate
input: sender zip code,
recipient zip code,
package type,
mail class,
weight,
DeliveryConfirmation requested (Y/N)
output: status: success or failure,
cost of postage
- Refund Request
Electronic Refunds are available for items where Delivery Confirmation was used and it is within
10 days of the original printing. Your postage account will be credited the refund amount in about 14 days.
input: tracking number,
user account number and password,
output: acknowledgment of request
- Status Request (Tracking)
input: tracking number
output: status information,
including delivery time and date and zip code.
- Address validation
input: sender name and address
output: sender name and address (potentially modified)
error code (0 is success, negative numbers are specific errors)
Mock Credit Card Processing API
Assume merchant account # is that of the Postage Printing Website owner, already established with the credit card processor.
- Process Payment
input: buyer credit card info:
type of card, name on card, number, exp date, security code
amount to charge
merchant acount #
merchant account password
output: Status: approved or declined
Transaction ID
- Process Refund
input: Transactin ID
refund amount (less than or equal to original amount)
merchant acount #
merchant account password
output: Status: success or failure
Diagrams/models:
Section 2.1: include a context diagram (see lecture 5A, slides 8+9)
Section 3.4 Logical Database requirements: call it "Logical structure of the data" instead.
section 3.4.1 Types of information used: Follow the example for contents
section 3.4.2 Data Entities and their Relationships: call it "Data model" instead.
Put a class diagram here (see lecture 5B, slides 7+8)
- have a box like Fig 5.10 with name and attributes and types for each class.
- include a diagram like 5.9, or list the relationships (with involved classes) after the class boxes
External software interfaces:
As we discussed in class, you may assume the postage printing website will access functions from usps.com to handle postage-related functions that the postage printing website is unable to perform ("printing" or generating the labels with postage, calculating postage, validating addresses, etc). Also, the postage printing website will need to access functionality from an online credit card processor. These are requirements that should be included in Section 3.1.