Rapid Development Method Coursework by May Hnit Oo Khin

Rapid Development Methods COMP 1487

1


2


1. Introduction

As soon as Fashion Belts had offered us a chance to propose our analysis on their computerized
system for Customer Order Processing System (COPS), our development team carried out careful and
detailed analysis of how current COPS is functioning. Then, we documented our analysis by producing a
report.
Another reason why we produced this report is that we want to present the business benefits
which can be achieved through using computerized system. When we analyzed the current manual
system, we observed that there are many problems such as recording wrong data, lacking ability to
immediately give the required information of order, delivery and payment and not knowing within a few
minutes about which departments are handling which customers‟ complaints. But, if computerized system
is used, these problems will be satisfied and the flow of order processing will be smoother than before and
customers‟ complaints can be handled more efficiently. So, we want to present our final analysis to the
managing director Cliff Hanger with the help of this report.
In our report, there will be altogether six sections. Firstly, we will describe to whom this report
must be presented, the reasons for producing this report and what are included in it as introduction.
In section 2, we will demonstrate how we captured functional requirements, i.e. main processes
of COPS and non-functional requirements such as performance, response time, volume, print rate, etc of
the proposed system by using the requirement catalogue.
To make sure that we get the correct system requirements, prototyping technique will be utilized
during JAD workshop. Thus, in section 3, we will express how business prototype, usability prototype,
performance prototype and capability/technique prototype will be used to achieve our dedicated goals.
Apart from this, users to be involved during developing the system are also important since we can obtain
the required information from them and they can assist us in building the right system. So, we will state
how we will assign the responsible staff together with their responsibilities under two categories:
Ambassador User and Advisor User.
Class diagram and Use Case diagram are very useful in identifying the system requirements.
Although both of them will not be user-friendly at first glance, they will be easy to understand later
because they are graphical techniques. They will also be used for business prototypes to approve that our
analysis is correct. Hence, we will give the details of these two diagrams together with our assumptions in
section 4 and section 5 respectively.
Finally, we will conclude this report in section 6 with our perspectives about our analysis.

3


A Requirements Catalogue

Fig 2 – Explanation of Requirement Catalogue
Referenced from (Paul Bocij, Dave Chaffey, Andrew Greasley & Simon Hickie, 2006)

No Descriptions
1 Name of the requirements originator
2 Name of the responsible person who confirms this requirement
3 Unique ID of each requirement catalogue
4 Priority level of each requirement will be defined by using MoSCoW
5 Functional requirements
6 Descriptions of non-functional requirements
7 Target value for non-functional requirements
8 Comments concerned with non-functional requirements
9 Acceptable range of each non-functional requirement
10 Benefits which can be gained by solving this functional requirement
11 Comments/suggested solutions for functional requirements
12 This will show the links to other related documentations

4


2.1 Functional Requirements

Supervisor of Manager of Manufacture R1 Must
Manufacture Department Department

Insert Belt Specifications

 Inputting belt  As soon as data  3 seconds per
specifications is inputted input
 Volume  9 per month  6 per month  Belt Specification can be
large, medium and small size
for each design. 3 new designs
can be produced per month

This will make the system more accurate in recording belt specification. Moreover, since the prices
of belts are different based on colours and sizes, it will be easier to find the prices if this
requirement is solved.

- Size No, Colour No and Belt Design No must be chosen.
- Custom-made style and size should be accepted.
- Do not allow adding new belt specification if either size or colour or belt design is left to
choose.

Order Class and Stock Class

5


Sales Staff Sales Manager R2 Must

Add Customer‟s Details

 Performance  as soon as data is entered  3 seconds per input
 Volume  20 per day  10-15 per day

This will speed up searching for customer information when final demand letters have to be sent or
while order fulfilment is in progress.

Validate customer information and save it into company database.

Order Class, Invoice Class, Delivery Class and Complaint Class

6



Input Order Information

 Performance  within 10 seconds  7-12 seconds  Also check existing customer
 Volume  600 per day  550-650
 Print sales order  10 per minute
 Service hours  Within office hour

This will increase the rate of order processing.

- Customer No must be picked and order information such as belt specification no, colour, size,
design and quantity must be entered.
- If the customer who makes a new order is not an existing customer, add this new customer
information into the database.
- Make checking existing customer as the automatic process when there is a new order.
- When an order is accepted, the available quantity for each ordered item should be checked. If
the ordered quantity exceeds on hand quantity in the stock, order should not be accepted.
- Subtotal for each belt specification and total for all items should be calculated automatically.

Belt Specification Class, Customer Class, Delivery Class, Invoice Class, Sales Staff Class,
Complaint Class

See Appendices Pg - 19
7


2.2 Non-functional Requirements

All users who will use the Cliff Hanger R13 Should
computerized system (Managing Director)

1. Data Security
1.1 To make data secure, authentication and authorization level should be predefined.
 Report Only – Customer Information Department and respective departments which
are going to solve the complaints can view the report only and not other data.
 Update Only – Delivery department will have update only access to Delivery table for
updating delivery status whether „Confirm‟ or „Pending‟ or „Cancel‟.
 Read Only – Accountants from account department will have read only access to
customer table to be able to send final demand letter.
 Complete System Access – Data administrator and executive level will have this
access.
1.2 Transmission of sensitive data between company‟s main server and other workstations on
company LAN must be encrypted to prevent from intruders.
1.3 Every user must be assigned username and password to access the company database.
1.4 Firewall must be used as a gateway between Internet and company intranet.

2. Performance (Response Time)
Processes which are only for inputting data should be completed within 1 second and processes
which have many transactions or things to check should be finished within 8-10 seconds.

3. Usability
As many of users who are going to use the system are novice users, the system should have user
friendly interfaces. The users can learn the system‟s functions within a few days of training.

8


All users who will use the Cliff Hanger R13 Should
computerized system (Managing Director)

4. Capacity
System must handle 40-50 transactions per minute.

5. Reliability
System should be available 24/7/365 days, especially during the office hours. But, it is
acceptable that the system can break down one or two times a year, i.e. 99% must be reliable.

6. Backup and Recovery
Daily back up of data must be automatically created at the predefined interval of time.
Moreover, replica of backup data should be stored in another safe site away from office so that
the confidential data is able to be recovered in case of failures.

7. Hardware and Technical Requirement
High performance PCs and also high performance server which can handle many concurrent
transactions are required.

9


3. Categories of prototype to be developed

We are going to hold initial JAD workshop in the boardroom of Fashion Belts. During the
workshop, prototyping technique included in Dynamic System Development Method is going to be
applied to capture and analyze the user requirements. The main reason why we will utilize this technique
is that it saves time, effort and money since users can not only clearly see the essential functions for the
computerized system which are understood by the developers but also ensure that these user requirements
captured by the developers are accurate and not misinterpreted.
We will make the prototypes for Fashion Belts incremental. In other words, our prototypes will
be aimed to be evolutionary prototypes which will evolve into the delivered COPS for Fashion Belts. To
demonstrate the understanding of the user requirements, we will make use of four categories of prototype.
They are – (1) business prototype, (2) usability prototype, (3) performance and capacity prototypes and
(4) capability/technique prototype.

(1) Business prototype
Business prototype will be created for COPS of Fashion Belts because it can provide the
complete picture of the developers‟ assumptions for the functional requirements which will be available
in the final delivered system. Consequently, users can evaluate which functional requirements are vital for
them. Simultaneously, they can know immediately if an important function is left to take into account. In
addition, developers can modify the functional requirements at once if users complaint that functional
requirements analyzed by the developers do not match with the real business requirements of Fashion
Belts.
For business prototype demonstration session, what users should know is business prototypes are
only intended to meet the user requirements and there is no HCI considerations. Therefore, we will
prepare use case diagram which shows the sequence of main processes, class diagram which expresses
attributes, operations of each class and relationships between classes and requirements catalogue
documenting functional and non-functional requirements to present business prototype.

http://www.scribd.com/doc/35861879/72/Categories-of-prototypes


10


3.1 Classes of users to be involved
By analyzing the scenario of coursework, we can infer that DSDM will be used. If we use
DSDM, two classes of users must be defined. Therefore, we want to assign who are responsible for these
user roles and give some details of their responsibilities and tasks.

Classes of Users and Assigned Persons Specific Responsibilities
General Responsibilities
 Ambassador User Chief Information  We have seen that the managing director will also sign off all
must be from the Officer (CIO) of system requirements from the scenario of coursework. As
business area. Fashion Belts is ambassador user is responsible for signing them off for the
 He/she must know high delegated to be an systems using DSDM, CIO will have to discuss with the managing
level view on processes ambassador user. director to do this task.
of how the business  CIO will be the most responsible personnel for design decisions
works and can elucidate and must have authority, knowledge and responsibility for making
which information is sure that the right system is implemented for Fashion Belts.
fundamental where,  CIO will also have to coordinate with developers to build the
when or for whom. prototypes and then will have to present these to Advisor Users.
 Involvement of CIO during developing system is very important
because he/she has to act as a communication channel between
Advisor Users and the developers.
 Advisor Users are the Supervisor  Will be responsible to clarify how belt specifications are
people who will use the identified.
delivered system.
 They can help the
Sales Staff  Give explanations on how order, customer and delivery
developers with
information is kept.
information on day-to-
day operations of a
specific business area. Accountant  Justify how payment process and sending final demand are

 They must participate in performed.

prototype demonstration
sessions and prototype Help Desk Staff  Will be in charge for customer complaints and report functions
testing to provide
feedbacks if Ambassador
User makes request.

11


4. Class Diagram

Assumptions for Class Diagram

Since it is a customer order processing system of belts, we assumed that classes for belt
specification, stock, customer, order, delivery and invoice will be surely included. According to the given
scenario, a belt specification can be exactly classified only if we know its size, belt design and colour. So,
we will need to record classes for size, design and colour. In addition, component class and style class
will also be required so that we can identify the components included in a belt design and can distinguish
which belt design comes with which style. Apart from these classes, complaint class will also be
considered for our class diagram because Fashion Belts wants to log customer complaints. To deal with
above classes, we will define some classes like department class and staff class which has there
generalized classes such as sales staff, accountant and help desk staff. Details of our assumptions will be
explained in appendix.
To summarize, attributes and operations of each class and relationships between classes can be
clearly seen because of our drawn class diagram. Consequently, this helps us in analyzing the current
system and increasing the possibilities of producing the right proposed system for Fashion Belts
Company.


12


Class Diagram for COPS of Fashion Belts
Style Size Stock OrderLine
- StyleNo: string - SizeNo: string
- BeltStyle: string - StockQtyEachBelt: int - Quantity: int
- LengthType: string - Price: double
- DesignerName: string - LengthInInch: string + AddStockItem() - SubTotal: double
- Status: boolean - Thickness: string + UpdateQty() - Remark: string
- Remark: string
+ AddSizeInfo() + DeleteStockItem() Associates with
+ AddBeltSpecification() 1 1
+ AddStyleInfo() + UpdateSizeInfo() + CheckQty(BeltSpecID)
+ UpdateStyleInfo() + DeleteSize() + NotifyUser(BeltSpecID) + UpdateQuantity(BeltSpecID)
+ DeleteStyle() + CheckValidSize(Inch) + RemoveBeltDesign()
0..1

Has
+ CustomMadeStyle() + CustomMadeSize()
1 Order Delivery
0..*
- OrderNo: string
BeltSpecification - DeliveryNo: string
Includes

* - OrderDate: Date
- DeliveryContact: string
- SpecificationNo: string 1..* 0..* - OrderStatus: string
- DeliveryStatus: string
- RetailPrice: double - OrderTotalPrice: double
* Contains
- WholesalePrice: double
Involves
- Remark: string
- ExpectedDate: Date
- ActualDate: Date
0..* - ReorderQty: int + AddNewOrder() 1..* Links to 1 - Address: string
BeltDesign * - Remark: string + UpdateOrderStatus() - Postcode: string
+ DeleteOrder() - Phone: string Invoice
+ AddNewBeltSpecification()
- BeltDesignNo: string + UpdatePrice() + CheckOutstanding - DeliveryCharges: double
- ApprovedDate: Date Payment(CustID) - InvoiceNo: string
+ DeleteBeltSpecification() - Remark: string
- Status: boolean Colour 1 0..* - IssueDate: Date
0..* + AddNewDelivery() - InvoiceStatus: boolean
- ApprovedBy: string - ColourNo: string + UpdateDeliveryInfo() - PaymentDueDate: Date

Orders
- Remark: string - ColourName: string * + UpdateDeliveryStatus() - FinalReceivedDate: Date
0.. + DeleteDelivery()
+ AddBeltDesingInfo() + AddColourInfo() - TotalAmount: double
1 s + CheckActualDeliveryDate(DID) - Discount: double
+ UpdateBeltDesingInfo() + UpdateColourInfo() ive
ce - NetAmount: double

Encounters Complaints
+ DeleteBeltDesign() + DeleteColour() Customer Re
+ CustomMadeDesign() 1 - FinalDemandStatus: boolean 0..*
- CustomerNo: string - FinalDemandDate: Date
0..* - CustomerName: string - OutstandingAmount: double
- Address: string - Remark: string
Comprises

BeltComponents Staff
- Postcode: double 0..*
1 Makes + AddNewInvoice()
- ComponentQty: int - StaffNo: string - TelNo: string
- FullName: string - CustomerContact: string + UpdatInvoiceInfo(InvoiceID)
- Remark: string + UpdateInvoiceStatus(InvoiceID)
- Position: string - Email: string 1
Com + CheckPaymentDueDate(InvoiceID)
+ AddBeltComponentInfo() - DOB: Date - Remark: string plain
ts + DeleteInvoice()
+ UpdateQty() -/ Age: int
1..* + DeleteBeltComponent() + AddNewCustomer() + CheckOutstandingPayment(CustID)
- Qualification: string 0..*
+ UpdatePersonalInfo() + CreateFinalDemand()
Component
Accepts Order

- Phone: string + DeleteCustomer()
- Email: string Complaint + CheckFinalDemandDate(InvoiceID)
- ComponentNo: string + MakeOrder() + CheckFinalDemandStatus(InvoiceID)
- Address: string + MakePayment(InvoiceID) - ComplaintNo: string
- ComponentType: string - Postcode: string - ComplaintDate: date
- Status: boolean + MakeComplaint(OrderID) Department
- Salary: double - CustomerSatisfy: boolean
- Remark: string - Remark: string 0..* - ComplaintPriority: string - DeptNo: string
+ AddStaffInfo() - Title: string Handles - DeptName: string
+ AddComponentInfo() - Location: string
+ UpdateStaffInfo() - Description: string 0..* 1..*
+ UpdateComponentInfo() - TotalStaff: int
+ DeleteComponent() + UpdatePosition() + AddNewComplaint()
+ DeleteStaff() - Remark: string
+ UpdateCustomerSatisfy()
+ DeleteComplaint() + AddNewDepartment()
0..* + CheckComplaint + UpdateDepartmentInfo()
1
Priority(ComplaintID) + DeleteDepartment()
rds
Sales Staff Accountant Help Desk Staff Reco + HandleComplaints()
1
Report
- DeptSolveDate: Date
1 - Solution: string
- Remark: string
+ AddNewReport()
+ UpdateReportInfo()
+ DeleteReport()
Generates Invoice and Issues Payment + CheckSolution(ComplaintID)

13


5. Use Case Diagram

Assumptions for Use Case
In our use case diagram for Fashion Belts, there are 11 main use cases, four primary actors and
two secondary actors.
As it is an order processing system for belts, we need to firstly record the data for belt
specification. According to scenario of coursework, we can infer that a supervisor of manufacture
department saves this data. So, supervisor can be regarded as a primary actor.
When an order is accepted, information of customer, order and delivery has to be kept to process
order. So, we considered a sale staff as a primary actor for all the use cases concerned with these data.
Moreover, we also assumed that this actor will be responsible for updating order fulfillment information
such as delivery status or order status, for example, whether a delivery or an order is completed or not,
etc.
After an order had been confirmed, we supposed that an invoice must be generated by an
accountant so that a customer can transfer money via bank to make payment. As an accountant will use
this system directly for issuing invoice, payment process and sending final demand letter, he/she can be
assumed as a primary actor. For “collect money” use case, we found out that this primary actor cannot use
the system if bank of Fashion Belts does not notify that money has been received from a customer. Since
bank only exists so that accountant can interact with the system, it can be supposed as a secondary actor.
Apart from these functions, we have learnt that Fashion Belts want to document customer
complaints together with responsible departments which are handling those complaints. So, we chose
help desk staff of customer information department to be a primary actor for logging the complaints data
into the database. After creating a daily report, this actor will have to pass it to respective departments.
Hence, responsible departments can be presumed as a secondary actor.
All in all, we could highlight the main functions of COPS from recording the belts information to
processing order, fulfillment stages and handling customers' complaints with the help of our drawn use
case diagram. Moreover, we could also observe that which processes are managed by which staff. For
example, we came to know accountant is concerned with payment issues and generating invoice or final
demand letter and bank is a secondary actor to assist accountant in accepting payment.


14


Use Case Diagram for COPS of Fashion Belts

Customer Order Processing System for Fashion Belts

Insert Belt
Specifications

Add Customer’s
Supervisor Details
<<Manufacture
Department>> <<extend>>
Sales Staff
<<Sales
Input Order Department>>
Information

Update Order Status
whether Confirm or
>
e s> Cancel
us
<<
Enter Delivery
Check Details
Outstanding
Payment

Issue Invoice Accountant
<<Account Department>>
<<
us
es>
>

Collect Payment

Create Final
Accountant Bank of Fashion Belts
Demand
<<Copy of Accountant <<CPU>>
Actor>> Secondary Actor
Update Order
Fulfilment Info

Record Customer
Complaints

Generate Daily
Report on
Complaints
Respective Head
Help Desk Staff of Department
<<Customer Information <<Department>>
Department>> Secondary Actor

15


6. Conclusion

Honestly, we made use of many analytical approaches to consider the needs of COPS for Fashion
Belts. By means of requirement catalogue, we realized which processes are functional requirements and
could also predict non-functional requirements for the proposed system. Furthermore, persons who will
sign off these requirements or use them and the priority level of each requirement could be pointed out
straightforwardly. Since we had prioritized the requirements, it will be beneficial for developers to discuss
with Ambassador User to leave out requirements which are not very important if development time is
behind schedule.
Although prototypes we proposed above can facilitate in ensuring user requirements, there can
be many drawbacks if we do not control prototyping activities. Since prototypes have to be demonstrated
to the users, users become notice their needs and keep changing their requirements. So, developers have
to modify the prototypes again and again and this will waste time. To prevent this, we will have to limit
the number of times for modification of prototypes and set the exact duration for prototype demonstration.
We all appreciate that active user involvement can lead to the successful implementation of a
system. Consequently, we believe that classifying classes of users who will take part in development will
aid us in analysis of COPS.
The last two techniques, class diagram and use case diagram, also guided us to be able to focus on
user requirements. Therefore, we could figure out the relationships between classes, for example,
customer, order, etc and data included in each class with the help of class diagram. Likewise, use case
diagram let us distinguish which processes are related to which staff of Fashion Belts.
To summarize, we could analyze the user requirements for COPS closely to perfect by using
many requirements analysis and gathering methods described above. Moreover, since our proposed
system can streamline the order processing, reduce costs for paper-based works, handle customers‟
complaints more and provide ability to search the required data without delay, customers‟ satisfaction can
be increased and company can also get many benefits. So, we do hope we deserve the opportunity to build
the efficient and accurate system for Fashion Belts.

16


References

Book References

Title : Business Information Systems 3rd Edition
Author : Paul Bocij, Dave Chaffey, Andrew Greasley & Simon Hickie
Publisher : CPI-Bath Press, UK
Published Year: 2006
ISBN : 0273688146
Referenced Pages: page 431-432

Title : DSDM Dynamic System Development Method 1st Edition
Author : Jennifer Stapleton
Publisher : Biddles Ltd, Guildford and King‟s Lynn
Published Year: 1997
ISBN : 0-201-17889-3
Referenced Pages: page 42-43, 65-69

Web References

Section 3
URL : http://www.scribd.com/doc/35861879/72/Categories-of-prototypes
Accessed Date : 16.9.2012
Accessed Time : 4:30 PM

17


Bibliography

Categories of Prototype
(n.d.). Retrieved 9 16, 2012, from http://www.scribd.com/doc/35861879/72/Categories-of-prototypes

Functional and Non-functional Requirements Catalogue
Paul Bocij, Dave Chaffey, Andrew Greasley & Simon Hickie. (2006). Business Information Systems ( 3rd
Edition ed.). (A. Greasley, Ed.) England, England, United Kingdom: CPI - Bath Press, UK.

Classes of Users and Categories of Prototype
Stapleton, J. (1997). DSDM Dynamic System Development Method (1st Edition ed.). Harlow, England,
United Kingdom: Biddles Ltd, Guildford and King's Lynn.

18


Appendices

Section 2 (Functional Requirements)


Update Order Status whether Confirm or Cancel

 Volume for  About 500 per day  500-600 per day
confirming orders

This will assist the sales manager to check which orders are confirmed.

- Order ID must be selected and order status must be changed from “Placed” to “Confirmed”
or “Canceled”.
- The system should check the outstanding payment. If the customer has the outstanding
payment, order should not be confirmed.
- Order must be confirmed or canceled after two days an order is placed.

Customer Class and Invoice Class to check outstanding payment

19


Accountant (Account Chief Financial Officer R5 Should
Department) (Account Department)

Check Outstanding Payment

 Response time  About 4 seconds per  4-7 seconds
customer
 Volume  Above 1000 per day  900-1200  About 500 orders have
to be confirmed per day
plus about 500 invoices
have to be checked for
outstanding payment

Since outstanding payment for each customer can be calculated, it is useful in sending final demand
letters to customers. Moreover, the company will not lose money because the system can check
whether a customer has outstanding money prior accepting order to be confirmed.

- Customer ID must be entered to calculate the outstanding payment.
- If there is outstanding payment, the system should automatically notify either sales staff to
cancel the order or accountant to generate the final demand letter.

Order Class, Invoice Class, Sales Staff Class and Accountant Class

20


Sales Staff Sales Manager R6 Should

Enter Delivery Details

 Performance  Within 3 seconds  3-5 seconds
 Volume  About 500 per day  500-600 per day

Delivery Status whether pending or delivered or cancel can be searched easily.

- Order No and Customer No must be chosen and then delivery contact info must be entered.
- Delivery Contact info must not be added if order is not confirmed.
- Delivery Information should be added as soon as order is confirmed.
- Expected Delivery Date should be automatically shown by adding five days to the date the
delivery information is issued

Customer Class and Order Class

21



Issue Invoice

 Response time  within 3 seconds  3-5 seconds
 Volume  about 500 per day  500-600 per day  This is because about
500 orders may be
confirmed per day to
issue invoice.

Payment information will be more reliable. This enable accountant to search for payment due date
for each order without difficulty.

- Order No, Customer No and payment information must be added to issue an invoice.
- Payment due date must be automatically calculated by adding three days to the issued
invoice date.
- If there is discount, discount amount must be subtracted from total amount and result must
be shown as net amount.
- Connecting directly with the printer is essential to generate invoice.

Order Class, Customer Class and Accountant Class

22



Collect Payment

No extraordinary non-
functional requirements

Collecting payment will be more convenient and the accountant can check the list of invoices which
have not been paid yet.

- When the bank of Fashion Belt receives money transferred by a customer, the accountant
must change the invoice status to „Paid‟ from „Unpaid‟.

Invoice Class and Customer Class

23


Accountant (Account Chief Financial Officer R9 Could

Create Final Demand

 Response time  Within 6 seconds  4-7 seconds  Outstanding payment
will also be checked.
 Volume  35 per day  25-35 per day
 Print final demand  10 per minute  8 per minute
form

This function reduces time to generate final demand letter since the accountant will not have to
manually search for the customers who have the outstanding payment.

- If there is a customer who has the outstanding payment, the system should notify the
accountant and automatically generate final demand letter which include final demand date.
- Printer should be connected directly to print out final demand letter at once.

Customer Class, Order Class and Invoice Class

24



Update Order Fulfilment Information

 No extraordinary non-
functional requirements

This will be helpful if the report on delivered orders is to be produced.

- Select order no to change the order status to „Completed‟ from „Progress‟.
- Choose delivery no to change the delivery status to „Delivered‟ from „Pending‟.

Order Class and Delivery Class

25


Help Desk Staff (Customer Head of Customer R11 Would
Information Department) Information
Department

Record Customer Complaints

 Response time  As soon as data is inserted  Within 3 seconds
 Volume  10 complaints per day

If customer complaints are recorded systematically, the respective department can not only know
the source of problems within a few minutes but also handle the complaints more easily.

- Customer no, order no and complaint information must be inputted.
- Complaint priority must be defined to let the respective departments know which
complaints are needed to solve immediately.

Customer Class, Order Class, Help Desk Staff and Department Class

26


Help Desk Staff (Customer Head of Customer R12 Would
Information Department) Information
Department

Generate Daily Report on Complaints

 Response time  immediately data is added  Within 3 seconds
 Volume  10 complaints per day
 Print complaint report  10 per minute

Management level can know which complaints are concerned with which departments.

- Complaint ID and department ID(s) which have to deal with that complaint must be filled.
- When a complaint has been solved, its solution must be recorded into the database.
- Linking directly to printer should be considered.

Department Class and Complaint Class

27


Section 3 (Categories of prototypes)

(2) Usability prototype

Usability prototype for Fashion Belts will be designed based on business prototype described
above. We will implement user friendly interface to ascertain that the computerized system for Fashion
Belts is easy to learn and use for end-users. During usability prototype session, we will let users operate
the prototypes themselves. By doing so, we can note down any inconveniences faced by users and then,
we can remove these user-unfriendly features in order to enhance the usability of the final delivered
system for Fashion Belts. So, we will demonstrate some user interfaces such as belt specification form,
customer registration form, order form, delivery form, invoice form and complaint form to rate the
usability level and to obtain the feedbacks of users.


Fig 3.1 Belt Specification Form

28


Fig 3.2 Customer Registration Form

Fig 3.3 Order Form

29


Fig 3.4 Delivery Form

Fig 3.5 Invoice Form

30


Fig 3.6 Complaint Form

(3) Performance and Capacity prototype
This sort of prototype is required to test non-functional requirements of COPS for Fashion Belts.
If we do not carry out performance testing, we cannot predict the limitation of system performance and
response time. Since the system will be accessed by staff of various departments from respective
workstations implemented on the company LAN, we should make sure that the system can fulfil the
desired performance requirements such as printing order or complaint report or final demand forms at a
rate of 10 per minute, etc when there are concurrent transactions or bottlenecks occur.

(4) Capability/Technique prototype
Before developing the system for Fashion Belts, this kind of prototype should be generated for
the sake of developers to compare the benefits of each technique, tool and approach and then to choose
the most suitable one. Firstly, we must think about programming language. During these days, there are
two popular programming languages: Java and VB.Net for developing desktop applications. After
analyzing the benefits of each language, we decided to use VB.Net because of its abundant useful built-in

31


functionalities and its efficient environment and tools for designing GUI. Then, we need to choose
database to save data for Fashion Belts. There are three well known DBMS in the market. They are
Microsoft Access, Microsoft SQL Server and Oracle. According to the comparisons we have made, we
have learnt that the cost of Microsoft Access is lower than any other two but it has some weakness in data
security. Although Oracle is better in some facilities than SQL, it needs more system requirements and
can cost a lot. Accordingly, we chose SQL server because of its reasonable cost and efficient
functionalities it provided. We will justify about all these facts in capability/technique prototype session.

To conclude, we planned to present these four categories prototype to the management in order to
broaden the users‟ understanding of the functionalities of the computerized system. With the help of
prototypes, users can give more feedbacks to the developers than using other data gathering techniques
and this can assist in delivering the right system.


32


Section 4 (Class Diagram)

While drawing class diagram, some data is not clearly mentioned in the coursework scenario. So,
some assumptions have to be made to demonstrate the complete picture of Customer Order Processing
System for Fashion Belts and we will make clear our assumptions for the relationships between classes,
some specially created attributes and complex operations.

Style BeltDesign  According to our analysis of sale order form provided by
- StyleNo: string
- BeltStyle: string
- BeltDesignNo: string coursework, we can infer that a belt design must have only
- ApprovedDate: Date
- DesignerName: string Includes
- Status: boolean one belt style. Consequently, we link Belt Design class to
- Status: boolean
1 0..* - ApprovedBy: string
- Remark: string - Remark: string
+ AddStyleInfo()
Style class with 1: M relationship. Moreover, since a Belt
+ UpdateStyleInfo() + AddBeltDesingInfo()
+ DeleteStyle() + UpdateBeltDesingInfo() Design may be made up of more than one Component
+ CustomMadeStyle() + DeleteBeltDesign()
+ CustomMadeDesign() and a component can be made into many belt designs, we
Comprises

0..*
BeltComponents can suppose that M:N relationship does exist between
- ComponentQty: int
- Remark: string 1..*
them. We show this idea by placing an associate class
+ AddBeltComponentInfo() named BeltComponents between them.
Component
+ UpdateQty()
+ DeleteBeltComponent() - ComponentNo: string  These four classes comprises of only attributes and
- ComponentType: string
- Status: boolean
- Remark: string
operations which are not complex except from
+ AddComponentInfo() CustomMadeDesign() in BeltDesign class and
+ UpdateComponentInfo()
+ DeleteComponent() CustomMadeStyle() operation in Style class which allow
customers to order custom made style and design.
Size
 Since a particular Belt Specification No can be known
- SizeNo: string
- LengthType: string
- LengthInInch: string by only combining three classes; Belt Design, Size and
- Thickness: string
+ AddSizeInfo() Colour, we made Belt Specification as an associate class
+ UpdateSizeInfo()
+ DeleteSize()
+ CheckValidSize(Inch) for these three classes.
+ CustomMadeSize() BeltSpecification
BeltDesign

- BeltDesignNo: string
* - SpecificationNo: string
- RetailPrice: double  In Size class, we defined some attributes which can tell
- WholesalePrice: double
- ApprovedDate: Date * Contains
- Status: boolean - ReorderQty: int
- Remark: string
LenghtType (Large, Medium, Small), LengthInInch and
- ApprovedBy: string
- Remark: string * + AddNewBeltSpecification()
Colour + UpdatePrice()
Thickness. Specially designed operations, for example,
+ AddBeltDesingInfo()
+ DeleteBeltSpecification()
+ UpdateBeltDesingInfo() - ColourNo: string
+ DeleteBeltDesign() - ColourName: string CheckValidSize(Inch) and CustomMadeSize() are also
+ CustomMadeDesign()
+ AddColourInfo()
+ UpdateColourInfo() taken into consideration.
+ DeleteColour()

 As prices of belt specifications are different based on
colour and size, RetailPrice and WholesalePrice for each
belt specification will be needed to record in
BeltSpecification class. ReorderQty attribute will be
explained in detail below.

33


BeltSpecification Stock  Stock table is used to hold available quantity of each belt
- SpecificationNo: string
- StockQty: int
- RetailPrice: double
- WholesalePrice: double + AddStockItem() specification. These two tables have 1: M relationship.
- ReorderQty: int 0..* Has 0..1 + UpdateQty()
+ DeleteStockItem()
- Remark: string
+ CheckQty(BeltSpecID) There may be no or many belt specifications in the stock.
+ AddNewBeltSpecification() + NotifyUser(BeltSpecID)
+ UpdatePrice()
But, a belt specification may contain none or at most one
time in the stock.
 If the quantity of an item in the stock is equal or less than
ReorderQty while the system automatically call
CheckQty(BeltSpecID), the system will notify users
whether they want to reorder this item to the factory.
OrderLine
 There is M:N relationship between Belt Specification and
- Quantity: int
- Price: double
- SubTotal: double
Order. Therefore, we put an associate class called
- Remark: string

+ AddBeltSpecification() OrderLine between them. An order must involve at least
+ UpdateQuantity(BeltSpecID)
+ RemoveBeltDesign()
one to many belt specifications whereas a belt

BeltSpecification Order
specification may be involved in none or many orders.
- SpecificationNo: string 1..* 0..* - OrderNo: string
- RetailPrice: double Involves - OrderDate: Date  CheckOutstandingPayment(CustID) will be used
- WholesalePrice: double - OrderStatus: string
- ReorderQty: int - OrderTotalPrice: double
- Remark: string - Remark: string whenever a new order is processed. Order Status attribute
+ AddNewOrder()
+ AddNewBeltSpecification()
is included to show “Placed”,“Confirmed”, “Canceled” or
+ UpdateOrderStatus()
+ UpdatePrice()
+ DeleteOrder()
+ CheckOutstanding
Payment(CustID)
“Finished”. Ordered item together with quantity, price and
subtotal are added to OrderLine and total money must be
recorded in Order class.
Order
- OrderNo: string
Delivery
 A customer may place order not at all or many times. So,
- OrderDate: Date 1..* Links to 1 - DeliveryNo: string
- DeliveryContact: string
- OrderStatus: string
- OrderTotalPrice: double
- DeliveryStatus: string
- ExpectedDate: Date
1: M relationship exists between Customer and Order.
- Remark: string
- ActualDate: Date
+ AddNewOrder()
0..* + UpdateOrderStatus()
- Address: string
- Postcode: string
Likewise, the relationship of Staff and Order and also
+ DeleteOrder() - Phone: string
+ CheckOutstanding
Payment(CustID)
- DeliveryCharges: double
- Remark: string
Customer and Delivery are same with above two classes.
+ AddNewDelivery()
Since a delivery can contain more than one order and an
0.

+ UpdateDeliveryInfo()
.*

+ UpdateDeliveryStatus()
+ DeleteDelivery()
Staff + CheckActualDeliveryDate(DID) order must be delivered only once, we guess that there can
O

0..*
rd

- StaffNo: string
er
s

- FullName: string
be 1:M relationship.
Receives

- Position: string
Accepts Order

- DOB: Date

 In Staff class, we describe Age attribute as derived
-/ Age: int
- Qualification: string 1 1
- Phone: string
Customer
- Email: string
- Address: string - CustomerNo: string
- CustomerName: string
attribute which can be calculated from DOB. We designed
- Postcode: string
- Salary: double - Address: string
- Remark: string - Postcode: double
- TelNo: string
Staff class by applying the concept of generalization.
+ AddStaffInfo()
- CustomerContact: string
+ UpdateStaffInfo()
+ UpdatePosition()
- Email: string
- Remark: string
Under this parent class, there are child classes like sale
+ DeleteStaff()
+ AddNewCustomer()

1
+ UpdatePersonalInfo()
+ DeleteCustomer()
staff, accountant, help desk staff, etc.
Sales Staff Help Desk Staff + MakeOrder()
 A customer can make order, payment and complaints. So,
Accountant
+ MakePayment(InvoiceID)
+ MakeComplaint(OrderID)

these three operations are shown in Customer class.

34


 UpdateDeliveryStatus() is called to change delivery status
like “Pending”, “Canceled” or “Finished”
Invoice
 Customer may make payment for none or many invoices
- InvoiceNo: string
- IssueDate: Date
- InvoiceStatus: boolean
- PaymentDueDate: Date
although an invoice must be belonged to one customer.
- FinalReceivedDate: Date
Order
- OrderNo: string
- TotalAmount: double
- Discount: double
Similarly, a staff may generate none or many invoices and
- OrderDate: Date 1 1
- NetAmount: double
- OrderTotalPrice: double
Associates with - FinalDemandStatus: boolean
- FinalDemandDate: Date receive the payment whereas an invoice and payment
- Remark: string - OutstandingAmount: double
+ AddNewOrder() - Remark: string
+ AddNewInvoice()
information must be dealt by one staff. So, we can see 1:
+ DeleteOrder()
+ UpdatInvoiceInfo(InvoiceID) 0..*
+ CheckOutstanding
+ UpdateInvoiceStatus(InvoiceID)
Payment(CustID)
+ CheckPaymentDueDate(InvoiceID) M relationship between these two pair of classes.
+ DeleteInvoice()

 We assumed that an invoice must be generated for each
+ CheckOutstandingPayment(CustID)
+ CreateFinalDemand()
0..* + CheckFinalDemandDate(InvoiceID)
es + CheckFinalDemandStatus(InvoiceID)
Ma k
order to make payment as soon as an order has been
1
Customer Staff
- CustomerNo: string - StaffNo: string
confirmed. Hence, we link order class and invoice class
- CustomerName: string - FullName: string Generates Invoice and Issues Payment
- Position: string
- Address: string
- Postcode: double - DOB: Date with 1:1 relationship. Since full payment for an invoice
- TelNo: string -/ Age: int
- CustomerContact: string - Qualification: string
- Email: string - Phone: string
- Email: string
must be transferred by bank only once, there will be 1:1
- Remark: string
- Address: string
+ AddNewCustomer()
- Postcode: string
- Salary: double
relationship between payment and invoice. However, we
+ DeleteCustomer()
- Remark: string
+ MakeOrder()
+ MakePayment(InvoiceID)
+ MakeComplaint(OrderID)
+ AddStaffInfo()
+ UpdateStaffInfo()
will not design payment as a separate class and it will be
+ UpdatePosition()
+ DeleteStaff()
combined into invoice class. Therefore, attributes and
Sales Staff Accountant Help Desk Staff operations which are for both invoice information and

1
payment information are taken into invoice class.
Similarly, attributes like outstanding payment, final
demand date, final demand status attribute to record “yes”
if there is outstanding payment or “no” or “paid” and
operations such as CheckOutstandingPayment(CustID),
CreateFinalDemand(),
CheckFinalDemandDate(InvoiceID) and
CheckFinalDemandStatus(InvoiceID) are also put into
Invoice class because final demand letter can be generated
only once and there can be only 1:1 relationship with
invoice class.

35


Order
Complaint  A customer may complaint not at all or many times for
- ComplaintNo: string
- OrderNo: string
- ComplaintDate: date
- OrderDate: Date
1 0..*
- CustomerSatisfy: boolean his/her order. Likewise, an order can be complained for
Encounters - ComplaintPriority: string
- OrderTotalPrice: double Complaints - Title: string
- Remark: string
- Description: string many times while a complaint can contain one order. A
+ AddNewOrder()
+ AddNewComplaint()
+ DeleteOrder()
+ UpdateCustomerSatisfy() staff may also issue none or many complaints. However,
+ DeleteComplaint()
+ CheckOutstanding
+ CheckComplaint
Payment(CustID) 0..*
Priority(ComplaintID) a complaint must be issued by a staff. Thus, we assumed
nts
lai 0..*
mp
Co there is 1: M relationships between these three pair of
1
Customer Staff
classes.
- CustomerNo: string
- CustomerName: string
- StaffNo: string
- FullName: string  For complaint class, we created such attributes as
- Address: string - Position: string
- DOB: Date
- Postcode: double
complaint date, customer satisfy to record whether a

Records
- TelNo: string -/ Age: int
- CustomerContact: string - Qualification: string
- Email: string
- Remark: string
- Phone: string
- Email: string
complaint has been satisfied or not, complaint priority that
- Address: string
+ AddNewCustomer()
- Postcode: string
- Salary: double
shows which complaints are important, complaint title and
+ DeleteCustomer()
- Remark: string
+ MakeOrder()
+ MakePayment(InvoiceID) + AddStaffInfo() its description.
+ MakeComplaint(OrderID) + UpdateStaffInfo()
+ UpdatePosition()
+ DeleteStaff()  Like other class, „Complaint Class‟ has operations to add
1
or delete complaints, update complaint status and check
Sales Staff Accountant Help Desk Staff
complaint priority.

Complaint  According to the fact described in coursework, sometimes
- ComplaintNo: string
- ComplaintDate: date
Department
more than one department will have to handle and solve
- CustomerSatisfy: boolean
- ComplaintPriority: string - DeptNo: string
- Title: string Handles - DeptName: string
the same customer complaint. Therefore, we considered
- Description: string - Location: string
0..* 1..* that there can be M:N relationship and take an associate
- TotalStaff: int
+ AddNewComplaint()
- Remark: string
+ UpdateCustomerSatisfy()
+ DeleteComplaint() + AddNewDepartment() class called „Report‟ into the class diagram.
+ CheckComplaint + UpdateDepartmentInfo()
Priority(ComplaintID) + DeleteDepartment()  HandleComplaint() operation can be used to check the
+ HandleComplaints()

Report complaints which are dealt with specific department.
- DeptSolveDate: Date
- Solution: string  In report class, CheckSolution(ComplaintID) can be
- Remark: string
+ AddNewReport() called to check the solution for each complaint.
+ UpdateReportInfo()
+ DeleteReport()
+ CheckSolution(ComplaintID)

36


Section 5 (Use Case)

Use Case Descriptions

Name: Insert Belt Specifications
Actor: Supervisor

Use Case begins when supervisor records new belt specifications.
1. Colour, size no and belt design no are chosen.
2. Belt Specification, for instance, price, reorderQty, etc are entered.
3. After validating, belt specifications information is added to the system.

Name: Add Customer’s Details
Actor: Sales Staff

Use Case begins when sales staff chooses “Customer Registration Form”.
1. Sales staff checks whether a customer has already registered or not.
2. Enters personal details of customer.
3. Validate data and save it into company database.

Name: Input Order Information
Actor: Sales Staff

Use Case begins when a new order is accepted.
1. Sales staff checks whether a customer is an existing customer or not.
2. Check the available quantity in the stock.
3. After Entering order date, order status, ordered belt specification no and required quantity to calculate
subtotal cost for each belt specification and total costs for all, sales staff submits order form.

37

Rapid Development Method Coursework by May Hnit Oo Khin

Rapid Development Method Coursework by May Hnit Oo Khin

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (18)

Similaire à Rapid Development Method Coursework by May Hnit Oo Khin

Similaire à Rapid Development Method Coursework by May Hnit Oo Khin (20)

Dernier

Dernier (20)

Rapid Development Method Coursework by May Hnit Oo Khin