SOFTWARE ENGINEERING USE CASE PROBLEM:

1.Scope: Business

2.Level: User goal

3.Primary actor: Project Manager Order right amount of right supply

Get supply to site at right time

4.Stakeholders, Interests, and Secondary Actors

Site Supervisor Actor Ensure supplies needed in near future available

Purchasing Actor Ensure purchase orders and payments issued

Accts Payable/Receiv Actor Issue proper payment after delivery

Supplier Actor Provide supply to site as contracted; get paid

Shipper Actor Deliver supply to site as contracted; get paid

Site Security Actor Ensure supply is secure and in condition for use

(if required)

Traffic authorities Actor Ensure delivery does not conflict with events

Provide traffic rerouting or control if needed

Customer Offstage Ensure progress on construction

Corporate Offstage Ensure progress on construction

Tax officials Offstage Ensure all taxes and fees are paid

Authentication System

Inventory System

Supplier & Shipper DB System

Project parts DB System

Project records DB System

Corporate accounts System

5.Preconditions

Supply is needed for project immediately or in near future

Item not yet in inventory or amount insufficient

Part(s), supplier and shipper identified

Space to store supply exists, with needed security and other storage conditions

6.Success guarantee

The right part(s) have been ordered, supplied, shipped, delivered and stored as needed

Delivery was on time

The part(s) are in good condition and ready for use when needed

Supplier and shipper have been given receipts and paid

All records have been updated to reflect transaction

7.Main success scenario

Project Manager consults Project Schedule in Project Records DB

Project Manager determines supply/supplies needed

System authenticates Project Manager

Project Manager consults Project Parts DB and identifies Part(s)

Project Manager selects amount for each Part

Project Manager notifies Purchasing with Part Identifier(s), amount(s), and date needed

For each Part {

7.Purchasing identifies Supplier

Purchasing generates Purchase Order and sends to Supplier

Purchasing records Purchase Order in Corporate Accounts DB

Supplier receives Purchase Order

Supplier assembles and packages Part(s) and notifies Purchasing

Supplier identifies Shipper and arranges shipment

Shipper contacts Traffic Authorities to clear plan of delivery, if needed

Shipper loads Part(s) and notifies Project Manager of arrival date and expected time

Shipper delivers and unloads Part(s)

System authenticates Site Supervisor

Site Supervisor certifies on-time receipt of proper Part(s) in good condition

Site Security transfers Part(s) to appropriate storage

Site Supervisor notifies Project Manager

Project Manager records receipt in Project Records DB

Project Manager updates Inventory and notifies Purchasing

Purchasing records delivery in Corporate Accounts DB and notifies Accounts P/R

Accounts P/R arranges and delivers payment for Supplier and Shipper

Accounts P/R records payments in Corporate Accounts DB

Shipper and Supplier acknowledge payment

Accounts P/R records acknowledgements

}

Alternate flows

Project Manager cannot be authenticatedRetry until retryCount exceeded

If successful, re-enter at Step 4

Retry at corporate HQ

Re-enter at Step 4

Part(s) cannot be identified

Need to write a handler for thisfind part, clear with Purchasing

Re-enter at step 5

PM cannot contact Purchasing

No Supplier exists or Supplier cannot be contacted

Identify alternative Supplier

Shorthand [t1]not necessarily a database.

Next two items ditto.

[t2]Could write a use case where choice of shipper and supplier are subfunction use cases

[t3]Standard loop construction

Ignores the likelihood that multiple parts will come from the same Supplier. Could be handled with a nested loop on Supplier and Part.

[t4]Authentication of Purchasing and Accounts P/R is out of scope. Supplier and Shipper are not in-house. This Business Use Case is written from a

Limited [t5]simple if-then conditional flow is OK, especially if its deferral to Alternative Flows makes things more complicated than putting it in

[t6]Project Manager may need re-authentication

***********QUESTION**************

Develop the Alternative Flows for a Fully-Dressed Use Case, for the Order On-Line Supplies Use Case.you should look at Larman's ProcessSale Use Case as well as the partial Fully-Dressed Use Case for RegisterStudent we discussed earlier in the term.

Remember, however, that this is a Business-level use case, so your alternative flows should involve system elements only as actors in the case, and these should (almost always) be those identified as actors in the partially developed use case, posted under Project Documents.