Software Engineering

WAC: Business Requirements for

AMMS Paperless Work Order Project

Submitted To

Dr. Zubair A. Sheikh, Miss Nida Mumtaz

Name: M.Saad Siddiqui

Roll No: k060110

Date: 2nd April 2010

1

Table of Contents

Project Summary................................................................3

Scenarios............................................................................4

Requirements Traceability Matrix......................................6

Methodology......................................................................7

System Dependability........................................................8

System Architecture...........................................................9

Conclusion........................................................................10

References.........................................................................11

2

Project Summary

Facilities Maintenance department handles all requests through its Maintenance Dispatch Center

(MDC), which uses scheduler utility to sort-out work orders for each crew and print them to

Maintenance Managers. Crew members make notes/papers on work orders and return those papers to

MDC for data entry into database. High volume of work orders causes high volume of paperwork, high

paper costs, data entry delay, data entry errors, false reports, transportation costs, revenue losses and

environmental pollution. “Paperless Work Order Project” is solution to all these problems, in which

paperwork is eliminated to improve business processes of Airport Maintenance Management System.

3

Scenarios

Trouble Calls Work OrderActors:Requester, AOCC, Scheduler, Crew, Maintenance Manager/Senior Mechanic, MDCFeature:Trouble calls work order schedule, assignment, update, review and submissionPre-condition: Requester contacts AOCC or MDCScenarios

Step Action System Reaction1 Requester contacts AOCC/MDC Information recording in T.C Log

Data transmission to AMMS2 Scheduler schedules work order Work order printed for Crew delivery

Assign work order to crew3 Crew updates work order Work order submission to Maintenance

Manager/Senior Mechanic4 Maintenance Manager/Senior

Mechanic reviews the work orderWork order delivery to MDC

5 Data Entry by MDC Save data into AMMS databaseAlternate Scenarios:

None

Post Conditions

Step Description1 Work order status can be checked in scheduler.

Projects Work OrdersActors: Technical Specialists, Scheduler, Crew, Maintenance Manager/Senior Mechanic, MDCFeature: Project work order schedule, assignment, update, review and submissionPre-condition: Technical Specialists sends the requests and schedulesScenarios

Step Action System Reaction1 Technical Specialists sends

requests and schedulesInformation recording in T.C Log

Data transmission to AMMS2 Scheduler schedules work order Work order printed for Crew delivery

Sorts work ordersAssign work order to crew

3 Crew updates work order Work order submission to Maintenance Manager/Senior Mechanic

4 Maintenance Manager/Senior Mechanic reviews the work order

Work order delivery to MDC

4

5 Data Entry by MDC Save data into AMMS databaseAlternate Scenarios:

None

Post Conditions

Step Description1 Work order status can be checked in scheduler.

Shift Close Work Orders – MDC DecisionsActors: Crew, Maintenance Manager/Senior Mechanic, MDCFeature: MDC decides what to do when closing a shiftPre-condition: NoneScenarios

Step Action Software Reaction1 Crew updates work order Work order submission to Maintenance

Manager/Senior Mechanic2 Maintenance Manager/Senior

Mechanic reviews and decides status of work order

Work order delivery to MDC

3 Maintenance Manager indicates that work order is 100% complete

Work order status in AMMS is finalized

Alternate Scenarios:

1: Maintenance Manager indicates that work order is untouched, work order goes back in scheduler Holding Bay2: Maintenance Manager indicates that work order has missing information or is incomplete, work order is sent to Maintenance Manager/Senior Mechanic3: Maintenance Manager indicates that crew wants Technical specialists attention, email is sent to Technical specialists4: Maintenance Manager indicates that maintenance managers/senior mechanics are required back in next shift, work order is assigned back to Maintenance Manager/Senior Mechanic5: Maintenance Manager indicates that work order has incorrect data, and for correction it goes to MDC6: Maintenance Manager indicates that work order has outstanding status(no Work performed), work order goes back to Holding BayPost Conditions

Step Description1 MDC handles work order depending on status set by Maintenance Manager

5

Requirements Traceability Matrix

Req. ID

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10

2.1 D D D D R

2.2

2.3 D D D D D D

2.4 R D D

2.5 D R R

2.6 R R

2.7 D D D

2.8 R D

2.9 D R

2.10 R R

Here, 'D' indicates that requirement in a row depends on requirement in a column.

'R' indicates a weaker relationship between requirements.

For Example:

User Requirements depend on Security Requirements, Data Requirements, Automatic Notifications,

Legal Requirements and is in weak relation with Integration and Scalability Requirements.

6

Methodology

Since it is a huge project and there is much risk involved, waterfall model can not be used as security

requirements and environmental requirements are ambiguous at some places. The requirements may

change and thus waterfall will not be a good option. As there are a large number of crew members

(250) , it does not seem feasible to apply Agile model. In short, Spiral model fits best here, and I will

use Spiral model for this kind of system.

7

– Resource Requirements:

Hand-held devices, firewall server, database servers, automation servers, about 300

kiosks/desktops, Internet connection and at-least 2 rooms for servers.

System Dependability

Availability: about 0.75

Reliability: about 0.75 for 4-5 years

Safety: about 0.2

Security: about 0.1

8

System Architecture

Performance: To increase performance distributed database can be used.

Security: For security besides user login system, a firewall can also be used.

Safety: For safety reasons a number of servers should be used for real-time synchronization.

Availability: Distributed database and more than 1 server will satisfy the availability issues.

Maintainability: Database server should be separate and the server performing automation of

notifications, printing and email should be different.

Client-server model is applicable here, because automation needs to done with respect to email and

printing, also AMMS Database should be accessible to hand-held devices and desktop computers.

9

Conclusion

The system is analyzed, it is found that spiral model should be used for this type of project, it is quiet

dependable and it's architectural design should be client-server.

10

References

http://www.gtaa.com/en/home/

http://images.google.com

http://blog.hydro4ge.com/wp-content/uploads/2007/12/h4_spiral.jpg

http://www.ozdox.com.au/Graphics/Images/Worldox%20Total%20Paperless%20Office.gif

11