A feasibility report is an organized presentation in form of a document that describes the economic and operational benefits of carrying out a project to completion against incurred costs (Kuiper & Clippinger). Modeling and analysis displays the logical flow of information and sequence of activities.
The Pizza Shop case study
Actors: owner/manager, two cooks, one waitress, one delivery person, and accountancy person.
Table 1: the domain dictionary of The Pizza Shop
|The Pizza Shop |
Customer services: Domain Dictionary
Version 1.1- August 24, 2012
|Owner/manager||Oversees that the operations of the enterprise are working as planned|
|Two cooks||Prepare the pizzas in the kitchen|
|waitress||Serves the in-house customers as well packaging for the takeouts, and deliveries|
|Delivery person||Delivers the packaged goods to the doorstep of customers|
|Accountancy person (husband)||Keeps records of the three system, and tracks the earnings so as to ascertain which system is more profitable and therefore be enhanced |
Validate credit cards
Table 2: The use case summary of customer service
|The Pizza Shop |
Customer Service: Use Case Summary
Version 1.0- August 24, 2012
|sourcing||Arrange for supplies to reach the shop, and make payments.||Manager, delivery man|
|Makes the pizzas||Mix the ingredients and bake to come up with the pizzas.||The two cooks|
|Receives customers call||A customer calls to place an order to be delivered to his/her place. The receiver notes his details.||The waitress, the manager|
|Verify credit card details||Validates that the customer has the capacity to use credit card for payment||manager|
|delivery||Takes the product to the doorstep of customer||Delivery person|
|Serving an in-house customer||An in-house customer pays at the counter and shows the receipt to the waitress||Manager (also cashier), waitress|
|packaging||Properly wraps the products into papers||waitress|
|Develops information system||A system to validate credit cards and a record keeping system on accounts.||Accountancy person|
Table 3: The Pizza Shop accountancy use case summary
|The Pizza Shop |
Accountancy: Use Case Summary
Version 1.2, August 24, 2012
|Amount entry||enters the amount paid by customers |
|Enters amount paid to suppliers||manager|
Amount entered with receipts
|Verify the amounts entered and put |
the system to work out the balances
for payments and receipts side of
the cashbook. Checks the track records
of the deliveries, takeouts, and in-house
customers to ascertain their viability
|payroll||Looks at the working hours and rates. |
Prepares payroll and makes payments
The Pizza Shop accountancy case summary
The stakeholders include the accountancy person (husband), and the manager (owner). The accountancy person becomes stakeholder through producing the off-the-shelf accounting system. His production is considered an in-house development which lowers cost of acquiring such information systems software (Rosenberg & Stephens 2007).
For this, he will be constantly required to make modifications for the systems software. He will recommend re-use possibilities, and running tests for the system. His benefits extend to the part that he could change the utility class software into business class to be used with similar businesses.
The manager is the owner who provides the capital, conducts feasibility study, and makes sure that the business either breaks even or remains profitable (IBM n.d).
The actors include the cashier for data entry into the system, the manager for making payments to sourcing and payroll. The accountancy person ensures that the system meets expectation.
The manager and the accountancy person carry out an analysis to check the project’s feasibility. They run a break-even analysis. This is after they have assigned each of the actors including themselves wages. They come up with management requirements for the business to continue operating (Wang 2011).
Activity diagram for withdrawing cash in an ATM
The ATM cash withdraw starts with the system requesting the customer to insert a card. After inserting the card, a compulsory test on the card is run for a few seconds. If the card is validated, the system asks the customer to insert pin number, and choose language.
Followed by which activity he/she would like the machine to conduct such as check balance or withdraw cash. In this case, it is cash withdrawal. If the card does not meet validation requirements, the customer is told to take his/her card. When the requirements are met, the customer chooses amount to withdraw and takes the card, then cash (Sarknas 2006)
An activity diagram displays the logical flow of activities (Ashafi et al 2009). In this case, the system is the ATM machines which uses complex software that are hidden from the outside world to prevent customers from changing how the system functions. With the systems programming, the ATM machine is able to make accurate decisions about what the customer wants (Rosenberg & Stephens 2007).
Class diagram for the Pizza Shop Credit Card Validation
The attribute is what an object knows. In this case, the attributes of the customer are the ability to make wise decisions provided with choices, and reliable information (Jalloul 2004). He/she knows how the system expects him/her to behave. The waitress attributes are knowledge of what a majority of customer prefer to be treated and served.
The waitress is supposed to notify the cashier of purchase intentions and the preferred mode of payment. In case of issues, the cashier notifies the waitress who will proceed to notify the customer. If there is no agreement, the customer can go to the cashier directly for better understanding.
Operations are the activities carried out by the objects. Operations and attributes begin with small letters while the classes begin with capital letters. The operations are in circles within the box. The classes are waitress, cashier, and customer.
Classes are known from their ability to do the same operations for different business settings. For this characteristic, they are said to have the ability to be generalized. The three classes here are all business classes. Only the account tracking system may be classified under utility class because it has only been developed for this particular business.
Sequence Diagram for the Tenderfoot Generate Weekly Payroll
The sequence diagram indicates the interaction between the objects. The objects are placed at the top of the diagram. The arrows show the exchange and flow of information. This interaction includes the space and time. The timeline on a vertical scale moves downwards and the space line on a horizontal scale moves towards the right-hand side.
In the above sequence diagram, the messages that are exchanged include the working hours that each employee has worked as per the records (Satzinger et al. 2008). The clerk is the one who keeps the records and the department head has to obtain them from the clerk before working out the payroll. T
he list can be obtained daily or weekly. After the department head has calculated the number of hours, the list is forwarded to the payroll clerk who may place it as a poster for the employees to view. The employees who think that the working hours are not correctly entered contact the payroll clerk for verification.
When the verification period is over, the problem time is closed. This opens the solution time, whereby the payroll clerk notifies the department head of the necessary changes, if there is any. The solution space therefore is in between the department head and the payroll clerk (Shelly et al. 2009).
List of References
Ashafi, H 2009, COIT 11226 Systems Analysis and COIS20025 Systems Development Overview, Pearson Education, New York.
IBM n.d., Introduction to Business Modeling using the Unified Modeling, <https://www.ibm.com/ua-en>.
Jalloul, G 2004, UML by Example, Cambridge University Press, New York.
Kuiper, S. & Clippinger, D 2012, Contemporary Business Report Writing, Cengage Learning, Mason.
Rosenberg, D. & Stephens, M 2007, Use Case Driven Object Modeling with UML Theory and Practice, Apress, Berkeley.
Sarknas, P 2006, Pro.Asp.net 2.0 E-Commerce in C# 2005. Apress, Berkeley.
Satzinger, W. J., et al. 2008, Systems Analysis and Design in a Changing World. Springer, New York.
Shelly, G.B., et al. 2009, Systems Analysis and Design, Cengage Learning, Mason.
Wang, R 2011, Research Summary: Introducing the 43 Use Cases for Social Business (Social Enterprising), <https://www.forbes.com/>