Information Systems Deliverable
There are two assignment deliverables. One is a formal written project and power point presentation. Attached the word document (Final Deliverable) for assignment instructions and also attached a zip file where it has all the related project documentation where the whole thing has to be incorporated into the final assignment in an organized manner.
There are two deliverables – One is written deliverable (final project documentation) and a power point presentation.
Final Deliverable –
This can be submitted in either or . It must be all in one document. This would be as if you were submitting for a formal project. It combines all previous written deliverables into one document. Works Cited, Table of contents and page numbers are required. You can format with appendixes or supplemental sections as you like.
Required Items:
1. System Request
2. Company overview
3. Feasibility Analysis
4. Gantt Chart
5. Requirements Definition Statement
6. Acquisition Strategy
7. Prototypes/Mockups
8. Hardware and Software Specifications
9. Architectural Design
10. Non-functional requirements
11. All your Implementation Deliverables
– Documentation Plan
– Testing Plan
– System Changeover Strategy
– Training Plan
– Support/Maintenance Plan
12. Works Cited
Notes from the Professor –
This is the final written deliverable. But essentially this covers everything we’ve gone over in the course. From the initial system request through all the different implementation deliverables, as well as your, your prototypes, mockups and those type of things. So, nothing new here. So, just make sure you have all these things in there that says at the top, make sure you have aside from the usual title page, you need a works cited page. You need a table of contents and those page numbers have to match. So just keep in mind you need all those things. This, kind of emulates a formal written deliverable you and hand be handing into either a potential customer or stakeholders for a project. And this is kind of common, especially where you’d present something smaller, but your written deliverable would have a vast much more information in it. There’s not a page length requirement because some air to liberals is going to be longer than others. There’s just the requirement that all of these sections must be present. And of course, it has to have the usual no grammar issues, no spelling mistakes.
Power Point Presentation Deliverable –
Separate Slide for each main topic
· Introduction
· Name and introduction/overview of project
· Company if you are focusing on one
· If not, what type of business or company does this system benefit or address?
· History of company
· If no company, history of problem
· Problem you are addressing – be thorough
· Why is it a problem? How does it affect the business specifically?
· Sales, branding/image/reputation, profits, employee retention, etc.
· Gantt Chart – overview, not specific
· Solution you are proposing
· How does it address the problem?
· How does it benefit the business
· Feasibility Analysis
· Requirements Definition Overview
· Implementation, Training, and Support Plans
· What System Changeover strategy do you propose and why?
· What Training do you propose?
· What Support and maintenance do you propose
· What Security issues do you need to address?
· Should you have any Backup and/or Recovery solutions in place?
· Documentation plan
· What will you use?
· How will it be available?
· Architecture Design – summarize and support
· Hardware/Software Specification
· Testing plan
· What testing do you propose and why?
· Acquisition Strategy – explain and back up – why?
· Interface Mockups/Prototypes
· Show and move on, do not need to give intimate details
· Conclusion
· Works cited if any (you do not present this page. Just have it available on the screen)
Gantt Chart_Copy.xlsx
Gantt Chart
Project Name Online Inventory
Development Project
Project Duration 86
Project Start Date 4-Jan-21
Project End Date 31-Mar-21
Start Date Duration End Date
Planning Phase
System Request 4-Jan 11 15-Jan-21
Feasibility Analysis 5-Jan 8 13-Jan-21
Gantt Chart 14-Jan 6 20-Jan-21
Requirements Definition 15-Jan 13 28-Jan-21
Data Flow Diagram 20-Jan 9 29-Jan-21
Use Cases 20-Jan 9 29-Jan-21
Acquisition Strategy 1-Feb 8 9-Feb-21
Entity-relationship Design 5-Feb 7 12-Feb-21
Protoypes/Mockups 15-Feb 4 19-Feb-21
Input/Output Design 17-Feb 5 22-Feb-21
Architecture Design 16-Feb 10 26-Feb-21
Hardware and Software Specification 22-Feb 10 4-Mar-21
Testing 4-Mar 19 23-Mar-21
Documentation 22-Mar 4 26-Mar-21
Migration and Conversion 24-Mar 7 31-Mar-21
Online Inventory Development Project
Start Date System Request Feasibility Analysis Gantt Chart Requirements Definition Data Flow Diagram Use Cases Acquisition Strategy Entity-relationship Design Protoypes/Mockups Input/Output Design Architecture Design Hardware and Software Specification Testing Documentation Migration and Conversion 44200 44201 44210 44211 44216 44216 44228 44232 44242 44244 44243 44249 44259 44277 44279 Duration System Request Feasibility Analysis Gantt Chart Requirements Definition Data Flow Diagram Use Cases Acquisition Strategy Entity-relationship Design Protoypes/Mockups Input/Output Design Architecture Design Hardware and Software Specification Testing Documentation Migration and Conversion 11 8 6 13 9 9 8 7 4 5 10 10 19 4 7
__MACOSX/._Gantt Chart_Copy.xlsx
Inventory Management System.pptx
Online Inventory Management System Proposal
By:
Srikanth, Bhonagiri Santosh Kumar
IS5803
Introduction
Technology forms an integral part of a business organization
It allows organization to conduct their activities in a flexible manner
Most of the organizations are making fair use of the online platform
Online presence plays a significant role in the current corporate world
Business organizations are taking advantage and turning to online entirely in their operations
This presentation is a system proposal for an online inventory system
Overview of the system
Name: Online Inventory management system
Organization: Davidson convenience store, Charlotte, North Carolina
Currently, the convenience store uses offline Inventory management system
The proposal is to implement online inventory management where the system will take the data from the online business activities regarding inventory and generate their associated reports
System goals for the business
Automation of the Inventory management
Reports on the Inventory performance
Inventory tracking
History of Convenience store, Charlotte, NC
Davidson store is one of the best firm in the Charlotte area
It was first established in 1994
The store sells a wide selection of items that you use daily (bread, milk, perishable foods, house/bathroom supplies, wide variety of good beer selection and great wines etc..)
The firm has a plan to open one or two stores in other parts of Charlotte area in the mere future
Problem facing the firm
The firm faces issues with its inventory management
It has an offline inventory system which fits the current business environment where the inventory operations happens manually
It requires the store employees to be physically in the organization’s premise
The issues affect fast inventory management
Sluggish inventory management affects the achievement of organizational goals
Not able to identify accurately the slow selling stock in the inventory
Solution
Development of online Inventory management system
The system allow Inventory personnel to attend the inventory remotely
The system will also allow them to make decisions remotely and give instructions to the employees on different tasks
The manager can also observe the performance of different inventories, audit the inventory and track the sales along with generating reports
Therefore, the system will enhance the management of inventory leading to maximization of profits
Feasibility Study
Operational Feasibility: The system will automate the Inventory management system, monitor inventory remotely and execute real time decisions
Economic Feasibility: The system will reduce the staff’s cost associated with Inventory management, will reduce the number of personnel needed for Inventory management activities, and reduce Inventory operation costs
Technical Feasibility: The organization has the technology necessary to implement the system within the estimated cost and will be profitable for the convenience store
Schedule Feasibility: The development of the Inventory management system won’t take a lot of time and the anticipated duration of the project is 3 months from start to finish
Gantt Chart
Project Schedule
Start Date System Request Feasibility Analysis Gantt Chart Requirements Definition Data Flow Diagram Use Cases Acquisition Strategy Entity-relationship Design Protoypes/Mockups Input/Output Design Architecture Design Hardware and Software Specification Testing Documentation Migration and Conversion 44200 44201 44210 44211 44216 44216 44228 44232 44242 44244 44243 44249 44259 44277 44279 Duration System Request Feasibility Analysis Gantt Chart Requirements Definition Data Flow Diagram Use Cases Acquisition Strategy Entity-relationship Design Protoypes/Mockups Input/Output Design Architecture Design Hardware and Software Specification Testing Documentation Migration and Conversion 11 8 6 13 9 9 8 7 4 5 10 10 19 4 7
__MACOSX/._Inventory Management System.pptx
Feasibility Analysis x
Feasibility Analysis
The feasibility analysis shows the suitability of the system, considering different operational factors. Subjecting project to feasibility test helps to find out if they are worth implementing. The feasibility test finds out if the system development is within a reasonable cost and developed within a reasonable time frame if it will be economical to the organization.
This paper is a feasibility test for the project of developing an online inventory management system. Some of the factors of consideration include the following.
Operational Feasibility
By using an unautomated online system can results in several issues, as highlighted in the scope statement. The system will thus provide solutions to the issues raised. First, the system will develop an inventory management system that automates the inventory management system. Second, the system will allow the management to monitor every inventory remotely and execute real-time decisions based on the information provided. Third, the inventory management will generate reports regarding each item’s performance and give projections of sales depending on the available information. In the perspective of the store, the online inventory management system can be considered as low risk project.
Economic Feasibility
The economic feasibility assesses the benefits of system implementation. Will the system benefit the organization in the long run? The system will be beneficial in many ways. First, the system will reduce the staff’s cost associated with inventory management since it an automated one; hence, inventory managers will only access the trends and make informed decisions. Second, though it might not go well with some staff, the system will reduce the number of personnel needed for inventory management activities, saving the management’s cost. Lastly, the cost of operating the inventory management greatly reduces since the system is integrated with an online platform. The inventory management system is economically feasible and easy to use for the users and low maintenance to the Davidson convenience store.
Technical Feasibility
The organization has the technology necessary to implement the system; it uses the same resources used by its online resources. Also, during development, the organization has all the resources that will be used. Some of the technical resources are not expensive and can pressure the organization’s financial resources. The proposed project online inventory management system is technically feasible and feasible within estimated cost and will be profitable to the Davidson convenience store. Tracking the stores inventory is an important feature in the Online Inventory Management system. The system allows the users to track the inventory by serial numbers, barcodes and other IDs. Without traceability the store risk by recalling items for any clarification and therefore loosing revenue. Purchase is another feature to any warehouse that relies on vendor for goods to purchase. This feature I will be building to the system that helps the users to manage and create purchase orders.
Schedule Feasibility
The development of the inventory management system won’t take a lot of time. Three months is enough to develop it and deploy it into the working environment. The project online inventory management system follows SDLC process. Firstly, the project starts with planning phase with System Request and Feasibility Analysis are focused. Secondly, the Analysis phase to document the requirements, analyze the current offline inventory process and accordingly work on future state requirements for online inventory process. Thirdly, the design phase which includes the prototypes, architecture designs and hardware/software specifications. Finally, the implementation phase to test the online inventory process and deploy into production environment. The risk will encounter in test process and have to plan, document, test all the test scenarios and make sure there will be no production issues when deployed in production environment. Production issues might arise in any software development, the issues should be rectified and fixed as soon as they are identified.
Additional comments
The requirements of the organization to implement the system push the organization. The organization shall benefit from the implementation significantly. It will lead to the enhancement of customer service leading to customer satisfaction. The process of inventory management system is to ensure their inventory is kept at optimal level. This system will track all the products information, audit the inventory and track the sales along with generating reports. The system also helps the business by identifying the slow selling stock, which helps to look for stock that has not been sold in the last 6 to 12 months.
__MACOSX/._Feasibility Analysis x
Non Functional Requirements Sheet.xlsx
Non Functional Requirements
Operational Requirements Definition Online Inventory Management System
Technical Special hardware, software, and network requirements imposed by business requirements System will use cloud for remote connection. The system will have real-time updates and minimize delays. The inventory manager can thus update database instantly
System Integration The extent to which the system will operate with other systems The sytem will be able to access database. However restriction will be placed on the type of data it accesses
Portability The extent to which the system will need to operate in other environments The system will be available to all devices provided that they have web browsers. The system is designed for access from different mobile devices (Android and iOS)
Maintainability Expected business changes to which the system should be able to adapt The system accomodates modifications to meet the requiremnts as well as to fit in its environment. It will be updated depending on the organization’s needs.
Accessbility How users can use the system The system will be accessed remotely. The system is accessible to users even outside the company. It is available at any location globally because of cloud service.
Performance How fast the system will return results The system must not lag, because the users using it don’t have down-time to wait for it to complete an action.The system should be very fast in processing users data and response time should be high. The system is developed using advanced technologies and has its servers stored in fast cloud servers. Accessibility will be fast and at any location
Supportability Inherent characteristics of a system that allow efficient and effective sustainment The application will work even on systems with minimum configurations
Packaging Defines how software sotware application is structured or packaged The system must incorporate license key authenitcation process. The packaging must come with manual that details the use of the system. The Inventory Management system contains installation disk and license key in the form of a file. User manual is also provided for the same
Performance Requirements Definition Online Inventory Management System
Speed Time within which the system must perform its function Transaction response not exceeding 5 seconds. However, speed will depend on the network connection when the system is accessed remotely.
Capacity Total and peak number of users and the volume of data expected 1000 maximum users can access the system simultaneously.
Availability and Reliability Extent to which the system will be available to the users and the permissible failure rate due to errors The system will be available 99.999%. Minimal down time will be experienced.
Interfacing How well the system looks and ease of use The system will offer a simple way of viewing the current inventory. The system will display the relationships between the various components in the system
Usability How hard it may be to use the system The system wil use a simple well-designed interface to provide easy navigation for new users, enhance their efficiency and memorability. The inventory management system uses graphic user interface that many people are conversant with and is easy to use
Integrity and Safety The extent to which the data stored in the system’s database can be free from integrity corruption and infortion be safe The system will ensure that only the right users have rights to access information and only administrators can change data, remove records or add new users. The system will ensure integrity as it will not allow data manipulation
Accuracy How accurate the system will be The system will minimize and eradicate the errors. It will improve on accuracy and ease all the processes. Records updating, searching and generation of inventory reports will be accurate from the new system
Security Requirements Definition Online Inventory Management System
System Value Estimates Estimated business value of the system and its data The loss of data will lead to approximately $5 million
Access Control Limitations on who can access what data The inventory management employee has access to change items in the database through instruction from the inventory manager. Data security is ensured through access controls. The various users and their access rights are well defined and cannot be violated.
Encryption and Authentication Defines what data will be encrypted where and whether authentication will be needed for user access Data encryption will occur in the users browsers. The system requires login after sometime of inactivity. Also, users must login successfully to access information otherwise the system locks. Any failed login will be reported to the security administrator.
Virus Control Controls to limit viruses Virus checks will be done everytime the data is uploaded to the system. The system is configured to be compatible with antivirus software thus protecting its information. The system has autobackup for database after three hours.
Disaster Recovery How the system will recover from problems The system will be able to recover from unstable problems and will backup data. Back up of data will ensure that the system will recover from any problems
Error Handling How best the system handles errors The system will be able to handle unexpected errors quickly and easily.
Cultural/Political Requirements Definition Online Inventory Management System
Multilingual The language(s) the system users will need The system will operate in English language since the system is only used locally.
Customization Specification of what aspects of the system can be changed by local users Local users can customize the view of the data in the database depending on the information they are looking for in the system. The system facilitates upgrade and update anytime need arises.
Making Unstated Norms Explicit Explicitly stating assumptions that differ from country to country All prices description will be in American dollar
Legal The laws and regulations that impose system requirements The customer information shall be kept for the organizational use only and customers must be made aware. The system is licensed and cannot be installed before an agreement is made.
__MACOSX/._Non Functional Requirements Sheet.xlsx
Architecture Design x
2
Architecture Design
Introduction
Development and implementation of an information system is an important process that needs more emphasis to achieve. Some of the most important aspects of the development, installation, and maintenance of an information system include the architecture and the requirements for the system. In the case of an online inventory management system for a convenience store, the system architecture is crucial in ensuring an easy to run system and maintenance. The design document will discuss the types of system architectures that will be applied in an online inventory management system and the benefits.
3-Tier Architecture
The system will use the 3-tier architecture. It is a software architecture that comprises three layers of logical computing. The architecture modularizes the user interface, business logic, and data storage layers thus making it easy for the development team to update one part of the application without interfering with the other parts. The 3-tier architecture is divided into presentation tier, application tier, and data tier protocols that help in communicating with the server. The presentation tier consists of the user interface. The user interface is graphical and can be accessed through a web application or a web browser and provides useful information to the end-user. The application tier consists of functional business logic that drives an application’s core capabilities while the data tier contains a data storage system (database) and data access layer.
With the different layers/tiers available in the architecture, it is easy for administrators and the development team to work on each modular independently. The use of 3-tier architecture in the system will provide fast and secure access to services from the server. Additional benefits of 3-tier architecture include the speed of development, performance, scalability, and availability. With the architecture allowing usage of devices like mobile devices, it allows easy access and processing of information even at remote locations.
Figure 1 3-Tier Architecture
In conclusion, using thin-client server architecture and 3-tier architecture will ensure fast and secure processing of data as well as less cost in the data processing. In the system, the two architectures are used since they are easy to access, easy to maintain and scale independently when the need arises.
__MACOSX/._Architecture Design x
Hardware and Software Specification x
Hardware and Software Specification
Introduction
Hardware and software specifications form part of the requirements when implementing any given system. Deployment of VM in 3-tier architecture will require stable hardware and software resources. In assessing both hardware and software specifications in 3-tier architecture, it is worth noting that this architecture is divided into 3 (presentation tier, business logic tier, and data management tier). The document aims to provide an overview of hardware and software specifications within the three-tier architecture environment.
Hardware Specifications
Agreeably, deployment of any system in three-tier architecture depends on hardware availability, which must be associated with some features such as RAM, hard disk capacity, and processor speed. In line with the 3-tier architecture, from the client part, access to system resources is based on the presentation layer, where access information requires hardware such as tablets, smartphones, and laptops. Laptop with Windows 10 Pro, 4GB RAM, and processor of corei5 are best suited to be hardware requirements from the client part. The server-side hardware requirements from the server include Centos 7 server with CPU type of Intel XEON, 32GB DDR4 RAM, 10TB data transfer, and 1TB SSID primary storage.
Software Specifications
In the deployment of this 3-tier architecture software, requirements will be based on both the client and the server. On the client-side, the software requirements include web browsers (Mozilla, Chrome, Opera, Internet Explorer, etc.). For the server-side, software requirements include Centos 7 server, Apache 2.4 (web server), PHP 7.2 for server-side scripting. The system will have a MySQL database management system installed for storage of data. Such software will be useful in the execution and deployment of applications within the Virtual Machine environment.
The software and hardware specifications ensure resilience and easy manageability of the system and ensure that processes run swiftly.
__MACOSX/._Hardware and Software Specification x
UI Prototype.zip
Sign Up page.JPG
__MACOSX/._Sign Up page.JPG
Sign In page.JPG
__MACOSX/._Sign In page.JPG
Search Page.JPG
__MACOSX/._Search Page.JPG
Report.JPG
__MACOSX/._Report.JPG
Privacy Policy.JPG
__MACOSX/._Privacy Policy.JPG
Home Page.JPG
__MACOSX/._Home Page.JPG
Fruits Vegetables.JPG
__MACOSX/._Fruits Vegetables.JPG
Dashboard.JPG
__MACOSX/._Dashboard.JPG
Dairy Page.JPG
__MACOSX/._Dairy Page.JPG
__MACOSX/._UI Prototype.zip
Gantt Chart.xlsx
Gantt Chart
Project Name Online Inventory
Development Project
Project Duration 86
Project Start Date 4-Jan-21
Project End Date 31-Mar-21
Task Start Date End Date 4-Jan-21 5-Jan-21 6-Jan-21 7-Jan-21 8-Jan-21 9-Jan-21 10-Jan-21 11-Jan-21 12-Jan-21 13-Jan-21 14-Jan-21 15-Jan-21 16-Jan-21 17-Jan-21 18-Jan-21 19-Jan-21 20-Jan-21 21-Jan-21 22-Jan-21 23-Jan-21 24-Jan-21 25-Jan-21 26-Jan-21 27-Jan-21 28-Jan-21 29-Jan-21 30-Jan-21 31-Jan-21 1-Feb-21 2-Feb-21 3-Feb-21 4-Feb-21 5-Feb-21 6-Feb-21 7-Feb-21 8-Feb-21 9-Feb-21 10-Feb-21 11-Feb-21 12-Feb-21 13-Feb-21 14-Feb-21 15-Feb-21 16-Feb-21 17-Feb-21 18-Feb-21 19-Feb-21 20-Feb-21 21-Feb-21 22-Feb-21 23-Feb-21 24-Feb-21 25-Feb-21 26-Feb-21 27-Feb-21 28-Feb-21 1-Mar-21 2-Mar-21 3-Mar-21 4-Mar-21 5-Mar-21 6-Mar-21 7-Mar-21 8-Mar-21 9-Mar-21 10-Mar-21 11-Mar-21 12-Mar-21 13-Mar-21 14-Mar-21 15-Mar-21 16-Mar-21 17-Mar-21 18-Mar-21 19-Mar-21 20-Mar-21 21-Mar-21 22-Mar-21 23-Mar-21 24-Mar-21 25-Mar-21 26-Mar-21 27-Mar-21 28-Mar-21 29-Mar-21 30-Mar-21 31-Mar-21
Planning
System Request 4-Jan-21 15-Jan-21 X X X X X X X X X X X X
Feasibility Analysis 5-Jan-21 13-Jan-21 X X X X X X X X X
Analysis Phase
Gantt Chart 14-Jan-21 20-Jan-21 X X X X X X X
Requirements Definition 15-Jan-21 28-Jan-21 X X X X X X X X X X X X X X
Data Flow Diagram 20-Jan-21 29-Jan-21 X X X X X X X X X X
Use Cases 20-Jan-21 29-Jan-21 X X X X X X X X X X
Design Phase
Acquisition Strategy 1-Feb-21 9-Feb-21 X X X X X X X X X
Entity-relationship Design 5-Feb-21 12-Feb-21 X X X X X X X X
Protoypes/Mockups 15-Feb-21 19-Feb-21 X X X X X
Input/Output Design 17-Feb-21 22-Feb-21 X X X X X X
Architecture Design 16-Feb-21 26-Feb-21 X X X X X X X X X X X
Hardware and Software Specification 22-Feb-21 4-Mar-21 X X X X X X X X X X X
Implementation Phase
Testing 4-Mar-21 23-Mar-21 X X X X X X X X X X X X X X X X X X X X
Documentation 22-Mar-21 26-Mar-21 X X X X X
Migration and Conversion 24-Mar-21 31-Mar-21 X X X X X X X X
__MACOSX/._Gantt Chart.xlsx
Alternative Matrix.xlsx
Sheet1
Criteria Weight option1 score weighted score option2 score weighted score option3 score weighted score
Technical Outsource Prepackaged In house
Efficiency 20 Efficient 5 25 Efficient 5 100 Very efficient 5 100
Technical Resources 10 More expensive 3 30 More expensive 2 20 Not expensive 5 50
Easy user management for tracking the products in inventory 15 Easy User Interface 5 75 Easy User Interface 5 75 Easy User Interface 5 75
Economic
Cost efficient in budget 25 Most expensive 3 75 Most expensive 3 75 Less expensive 5 125
Cost of maintenance 10 High maintenance 3 30 High maintenance 3 90 Low maintenance 5 50
Organizational
Suit organizational culture on the online automation process 10 Online automation process 5 50 Online automation process 5 50 Online automation process 5 50
Easy acceptance 10 User acceptance 5 50 User acceptance 5 50 User acceptance 5 50
100 1 through 5 335 460 500
__MACOSX/._Alternative Matrix.xlsx
Acquisition Strategy x
2
Acquisition Strategy
The alternative matrix enabled us to determine which of the three options – outsourcing, prepackaged, and in-house is the best and fits the current organizational situation. From the scores obtained, we can see that developing the system in-house is the best option. The in-house option scores 500. Technical, financial, and organizational factors were the main areas of consideration when deciding which is the best method to develop the online inventory system.
Technical – here, we considered the efficiency and update of the system. For efficiency, we prefer a system that will solve the organization’s issues comprehensively. The in-house development provides a comprehensive solution since the developers understand the system requirements exhaustively what is needed by the system. Also, the inventory management technical team can receive the required updates and work promptly. The other options will require to consult the vendors who will perform their techniques for the implementation of the update, hence consuming time. Loss of control, high development and maintenance costs are other factors for not opting to Outsourcing and Prepackaged solutions. In-house solution saves significant costs, has a significant advantage on response time when compared to other options.
Financial – the cost of developing the system varies significantly. Outsourcing or having the prepackaged system costs more than developing in-house. Developing a system in-house is less expensive since the firm purchases all resources required for the process. The technical resources which include development, system support is relatively low cost efficient and has control over the system with low development and maintenance costs.
Organizational – The system best fits with the organizational needs. The three options might fit the requirements, but the outsourced and prepackaged does not guarantee. Lack of control, communication issues and problems with crossing the budget even though the quality is good are the other factors which may impact the system support and maintenance. It cannot be accepted quickly and also may fail to match the organizational culture.
The benefits of using an in-house inventory management system includes greater cost savings, simplified inventory management and better product visibility. The main reason to opt for in-house is that the software is developed by a team of our choice which gives access to knowledgeable support rather than dealing with team with outsourcing team who might not understand the difficult situations. Finally, we have decided to go for in-house development because it fits the organizational technical and economical requirements.
__MACOSX/._Acquisition Strategy x
Requirements Definition Statement x
2
System Requirements
The organizational needs drive the Davidson Convenience Store online inventory system requirements. These requirements consist of those required during the development process and after the system deployment. These requirements are categorized into five categories: output, input, process, performance, and control.
Output
The system will output different information depending on what the Systems Analyst wants from the system. They will perform the duty locally regardless of their location, provided that they have an internet connection. The system’s information includes viewing each product’s performance in the inventory, the products’ suppliers, and the inventory shelf age. The system will allow the management to monitor every inventory remotely and execute real-time decisions based on the information provided. The system allows the users to track the inventory by serial numbers, barcodes and other IDs. The system will help the users to manage and create purchase orders. The information can be in a graphical display such as graphs and charts, and they are critical for making decisions.
Input
Our system is an online system that allows the organizational personnel to manage inventories locally. Some of the operations include monitoring and updating inventory. Therefore, the inputs of the system will comprise the inventory details. These details include suppliers’ details, date of purchase, expiry date, date of sale. The input of serial numbers, barcodes and other IDs can track the inventory. Through the analysis of this information, the organization can observe each product’s performance and organizational decisions. The inputs will also include details of the personnel and the system’s duties which the System Analyst can update. The system also helps the business by identifying the slow selling stock, which helps to look for stock that has not been sold in the last 6 to 12 months based on barcodes or item numbers.
Process
The system will also conduct some processes. The Systems Analyst will entirely manage the inventory processes in the system. The processes include monitoring the inventory and giving alerts on the expired inventory and those overstayed on the shelves. It can also calculate the selling price through the recorded buying prices, depending on the organization’s percentage for the profit. Also, the manager can order inventory depending on the stock performance. The system collects the data from each product, and it visually shows the analysis that will enable management to observe how they perform and use them to make management decisions. The Online Inventory Management system will allow the users to track goods across the business supply chain. It gives the system user, the information about the entire process from the order placement with the vendor to the customer delivery where the business can track the complete journey of the product.
Performance
The Online Inventory Management system is a useful tool to improve the business productivity and process efficiency. This automated software reduces human error. The system is entirely online, and thus it must always be operational; it must be operating seven days a week and 365 days – This is not possible but must operate 99.9999 % of the time. The downtime must be insignificant. This high availability time will ensure that the system is always available every time the users require it.
The system will support up to a maximum of 1000 users simultaneously. The performance will drop when the number is surpassed. This high number shows that the organization will always have many users who mostly are remote users consisting of the organization’s vendors and customers.
Lastly, response times should not exceed three seconds. The time is not guaranteed at low internet connection speed. The users who access the system remotely might experience these sluggish internet connections but those; however, the organization’s internet connection is always good, and the response time will not be affected significantly.
Control
The system must also ensure that there is safety of the resources. Thus, it is important to control who accesses the system. The logon security will be implemented; the users will need to supply their login details when they want to access the system. The design will maintain different levels of protection for users and system administrators. Also, the system will keep audit transactions and backup of all transactions.
The system will also beef up data security by implementing strong security strategies to protect the data from cybercriminals’ access. These measures include encryption of the data so that the criminal cannot decipher the content of different files to access them.
Conclusion
The system requirements are crucial for the process of developing the system. The developers need to understand they are developing through the stated requirements and develop as the specification. The common requirements discussed include input, output, process, performance, and control. The Online Inventory Management system will help to manage and maintain the business as it continues to develop and grow. The system helps the business to provide knowledge on how to shape the product offering. With the Online Inventory Management system, the business can prevent overstock by setting their products catalog. The system helps the business to identify what needs to change to develop the business based on the stock analysis and report metrics.
__MACOSX/._Requirements Definition Statement x
System Request x
System Request: Inventory Management System
Project Sponsor
Name(s): Davidson Convenience Store, Charlotte, NC
Title(s): Systems Analyst
Business Need – Why is this request being made:
Most of the organization are making fair use of the online platform. Online presence plays a significant role in the current corporate world. Since most clients have turned online, business organizations should take advantage and turn to online entirely in their operations. Currently, the convenience store uses offline inventory management system that requires users to transfer data from offline operations and enter into the system to manage their inventory. Therefore, with the online inventory management implementation, the system will take the data from the online business activities regarding inventory and generate their associated reports. Therefore, it will save time and allow the organization to perform other activities.
Business Requirements – What is needed explicitly from this system:
· Automation of the inventory management
· Reports on the inventory performance
· Inventory tracking
Business Value – how will this benefit the business:
The system will benefit the organization by managing their inventory. The information obtained from the system will help organization management make better and informed decisions regarding the inventory drawn from each inventory’s performance.
Special Issues or Constraints:
The issues with the system development include:
· Resources for development.
· The development will also require trained people to implement
· Time constrained for the entire development process
__MACOSX/._System Request x
DREXEL
ISCHOOL
Apartment Management
System Analysis & Design
INFO 620 Information Systems Analysis and Design
Spring Quarter 20
10
Nathan Vasserman
Fangwu Wei
David Fernandez
Andrew Messina
Final Report Submission
06/10/2010
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
2
INFO 620: Information Systems Analysis and Design, Spring Quarter 2010
Fangwu Wei, David Fernandez, Nathan Vasserman, Andrew Messina,
Project Category: Analysis & Design, Apartment Management System
Contents
Introduction …………………………………………………………………………………………………………………..
4
System Analysis ……………………………………………………………………………………………………………. 4
1. Title: …………………………………………………………………………………………………………………….. 4
2. The Problem Statement …………………………………………………………………………………………… 4
3. Requirements ………………………………………………………………………………………………………….
5
4. Examples of system input/output, etc. ……………………………………………………………………….
8
5. Knowledge Acquisition …………………………………………………………………………………………… 8
6. Software and/or hardware involved ………………………………………………………………………….. 8
7. Proposed Deliverables and work plans ……………………………………………………………………… 8
8. Known References (so far) ……………………………………………………………………………………….
9
Use Case Diagram
……………………………………………………………………………………………………….. 10
Use Case Descriptions …………………………………………………………………………………………………..
11
Apartment Unit Assumptions ……………………………………………………………………………………..
14
Detailed Use Case Descriptions …………………………………………………………………………………. 1
7
USE CASE # ……………………………………………………………………………………………………………….
25
USE CASE Name ……………………………………………………………………………………………………….. 25
ACTOR ……………………………………………………………………………………………………………………… 25
Goal (1 phrase) ……………………………………………………………………………………………………………. 25
Overview and scope …………………………………………………………………………………………………….. 25
Level ………………………………………………………………………………………………………………………….. 25
Preconditions ………………………………………………………………………………………………………………. 25
Postconditions in words(write in passive and past tense) ………………………………………………….. 25
Class Diagram
………………………………………………………………………………………………………….
28
Sequence Diagrams ………………………………………………………………………………………………………
29
Fangwu Wei, System Sequence Diagram (Record regular maintenance) …………………………. 29
Andrew Messina, Pay Rent
………………………………………………………………………………………..
34
Nathan Vasserman, Terminate Lease …………………………………………………………………………..
35
David Fernandez, System Sequence Diagram: Process Tenant Registration
…………………….. 36
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
3
State Diagrams for Apartment and Lease objects ……………………………………………………………..
38
Design Class Diagram
…………………………………………………………………………………………………..
39
Package Diagram ……………………………………………………………………………………………………..
40
Database schema ……………………………………………………………………………………………………… 40
Discussion on developing the diagrams. ………………………………………………………………………
41
Summary and Lessons Learned ……………………………………………………………………………………… 41
Appendix …………………………………………………………………………………………………………………….
42
Division of Work ……………………………………………………………………………………………………… 42
Lessons Learned ………………………………………………………………………………………………………. 42
David ………………………………………………………………………………………………………………….. 42
Andrew ……………………………………………………………………………………………………………….. 42
Nathan …………………………………………………………………………………………………………………
43
Fangwu ……………………………………………………………………………………………………………….. 43
Unanswered Questions ……………………………………………………………………………………………… 43
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
4
Introduction
For our project, we have decided to do comprehensive UML model of the
Apartment Management System. The requirements of the AMS require a tool be built
for a local building management company wishing to automate many of the interactions
between tenant, landlord and apartment management staff. In addition to just handling
rent money exchange, the system needs to keep track of the entire services apartment
owners offer to their tenants such as maintenance, basic inspection and transfer of
tenants.
The project proved to be a large undertaking as we spent a significant amount of
time delving into the details of what the maintenance an apartment building requires and
all of the rent laws in Pennsylvania. The amount of work required significant
breakdown by services. We had team members who worked on rent interactions,
inspection processes, maintenance and the unfortunate possibility that a tenant‟s lease
might be terminated, either by the tenants or the landlord‟s choice. The following
design document reflects all of those features and more.
For the group members that have never lived in an apartment, this project
proved to be quite the learning experience. We hope the following can accurately
portray a sample of what such a software suite would require and how it could be coded
to become a reality.
System Analysis
1. Title: Analysis and Design of an Apartment Management System
2. The Problem Statement
A small Apartment Rental company would like to create a management system,
common for every apartment blocks distributed by Philadelphia and towns around.
(a) Overall goals of the system
The overall goals of the system are to keep track of tenant maintenance requests,
tenant
record, document and contract management, to make easier to the tenant and controlling
the rental payment.
(b) Context and Importance of the system
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
5
It is critical that any apartment rental company to control the expenses of the apartment
management and tracking the rental payment for the tenants. Managers complain that
tenants often forget to pay the rent on time, and some of them are even difficult when it
comes to communicating or being localized. An on-line system which improves the
communication between property managers and tenants will serve as a reminder for
making on-line payments obligations and in case of delays, and to warn them about it,
instantly. Tenants complain that managers are slow in problem solving and sometimes
they are difficult to localize. An on line system to make request about maintenance
problems allows managers to be more effective to resolve the problem and the central
management to be able to plan expenses, to contract or hire some services at the best
price and put on disposition to very apartment manager the company which would help
with the problem.
(c) Scope of the project
IN-Scope:
AMS will include only tenants and their requests and obligation, rental payments,
apartment maintenance services as plumbers, windows, insects, etc., building
maintenance service such as gardening, roof, central heating, etc, and contract
management as new tenant contract, current tenant renewals. It also includes requests
and reports from the managers to the central administration and service contract from
the central administration to the managers.
OUT-Scope:
SAMS (Small Apartment Management System) will not include a central accounting
system.
3. Requirements
3.1 Functional Requirements (partial list)
The system will be password-protected. AMS will be a multi-user system where every
user must log in. AMS needs to perform the following functions:
Tenants to the manager system:
(1) Request a change of apartment.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
6
(2) Request a maintenance petition.
(3) Complaints.
(4) Pay the rent on-line.
Manager System to the tenants
(1) Add a new tenant and make and managing his/her contract.
(2) Warn and report any tenant about his/her rental payment.
(3) Report any interesting information (new services, taxes, etc)
(3) Manage the tenant maintenance request, and reporting about it.
Manager System to a manager:
(1) Report about any tenant maintenance tasks.
(2) Report about any periodical building maintenance.
(3) Pick up the manager request to the central administration.
Manager System to Central Administration:
(1) Report about the tenant rent payments.
(2) Report about the maintenance services.
(3) Request available services.
(4) Report and send tenant contract or documents.
3.2 Data requirements (Partial List)
For clients, keep track of client‟s name, address, business phone, home phone, cell
phone, outstanding balance, starting date, and business type. The business type is One
of S-corp, C-Corp, Partnership, LLC, LLP, SolePropreiter, Estate, Trust, Non-Profit,
Individual, Other.
For each billable item, SAMS will keep track of item#, date entered, description, initial
amount, status, and balance. Billable items are either monthly service charge or other
special service charge. For the latter case, the name and the fee of the service is
recorded.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
7
For each invoice, SAMS will need to keep track of invoice#, invoice date, total billing
amount from all the billable items which are not marked as Paid In Full.
For each payment, SAMS will keep track of payment#, payment date, description,
amount, payment type, check#, and bank name.
3.3 Business Rules and Logic (Partial List)
(1) The outstanding balance of a client will always reflect the summation of
balances of all the billable items.
(2) When a new billable item is created, initial amount and balance are zero. Later
when a payment is made, the initial amount remains the same, but balance must
be reduced by the amount of payment amount.
(3) The status of billable items must be properly changed its value. Initially, when
the item is created, the STATUS is Un-invoiced. When an invoice is sent out,
the STATUS becomes invoiced. When the item is paid in full, the STATUS
becomes Paid in-full. When the tenant is deceased or other circumstances arise,
the STATUS will become payment-in-
process.
(4) When the item is paid by only by partially, the STATUS becomes Paid-in-
Partial. The state changes need to be automatic. A billable item could also be
discounted or cancelled.
(5) The total billable amount is derived as the summation of current unpaid billable
items.
(6) SAMS will be used by multiple accountants, and thus some important activities must be
noted on who recorded or changed the record with the last update
date.
(7) When a request for a sublease is sent out, the system will then process the
request. With regard to the information the system will either approve or
decline the request.
3.4 Non-functional
requirements
Requirements on usability, reliability, performance, supportability, security,
recovery, interface, implementation, operation, and legal.
(1) The system will be a screen-based application.
(2) Menus should be organized in a hierarchical manner (usability)
(3) The system will be password-protected. (Security)
(4) SAMS will be backed up daily. (Back up)
3.5 Other Assumptions
(What are the assumptions of the system? What are HW and SW constraints? Are
there any implementation constraints?)
(1) We will assume SAMS will be used by a small accounting firm in a real-world setting.
(2) SAMS runs on a client/server environment, running Windows Server as OS.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
8
(3) The underlying DB system is Microsoft Access
(4) State specific rental laws will be based on Pennsylvania laws, should any discrepancies
arrive.
(5) Buildings affected will not be rent-controlled units.
4. Examples of system input/output, etc.
Examples of system input:
(1) A tenant pays rent by a personal check.
(2) A tenant wants to sublease an apartment before completing the contract.
(3) A tenant rents an apartment.
(4) A staff adds new tenant information.
Examples of system output:
(1) System prints tenant information including payment history by tenant requests.
(2) Payment reports comply with local tax codes.
(3) System keeps logs of rental unit history. Past and present tenants.
(4) System maintains information regarding regular unit inspections and compliance
with tenant; insuring units remain up to code.
5. Knowledge Acquisition
The problem is an Analysis and Design project. First we will develop our requirements
based on our common sense and the current knowledge. After that, we will consult with
an actual accounting office to validate our requirements.
6. Software and/or hardware involved
We will use Rational Rose for developing all the UML diagrams. Microsoft Access will
be used when the system needs to be prototyped to get the ideas for screen
developments. The application itself is PC-based running on XP.
7. Proposed Deliverables and work plans
We intend to turn in a complete set of UML diagrams along with supporting
documentation. We will also put together a report describing our experience with
analyzing the current process, what we were able to learn from our study, known pitfalls,
remaining questions after project, and any recommendations on how to improve the
current system.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
9
8. Known References (so far)
References at this point will be drawn from personal experiences and widely available
resources on laws and regulations regarding residential rental units. Most team members
have lived in an apartment building for at least a portion of their lives. Pennsylvania
state law has rules regarding the treatment and maintenance of a rental unit, and the
rights and responsibilities of a tenant. Codes can be found here for
http://www.rentlaw.com/pennsylvaniarentlaw.htm Pennsylvania laws. Laws differ from
state to state but for this project we will assume PA regulations.
http://www.rentlaw.com/pennsylvaniarentlaw.htm
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
10
PaymentSystem
Process credit card payment
Add inspector
Inspector
Send out notifications
Record pest control
Record emergency test
DocumentManage
rSystem
Store occupancy verification
Process lease termination
Process tenant’s apartament
change request
Process tenant registation
<
Schedule inspection
<
<
Enter inspection results
Manager
Record regular maintenance
<
<
Request lease termination
Request apartment change
Send on-line registration
<
Requests inspection
Submit feedback form
Request maintenance
Pay rent
<
Check payment status
Login
Staff
Renew lease
Run Credit Report
Manager
Send eviction notice
Send renewal notice
Staff
Edit apartment information
Schedule visit
Prospect
Tenant
Send rental application
Tenant
Tenant
Landlord
Check room availability
Use Case Diagram
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
11
Use Case Descriptions
Use Case Name: Schedule visit
Actor(s): Prospect Tenant
Purpose: Booking landlord time for visiting the
apartments.
Overview: Prospect tenant (after a visitor phone petition) chooses a date and time
available for visiting the apartments.
Use Case Name: Send rental application
Actor(s): Prospect Tenant
Purpose: Renting an apartment
Overview: Prospect tenant can rent an apartment sending the solicitation form and
required digital documents. Prospect tenant must provide a credit card to
pay the security deposit and prepaid rent.
Use Case Name: Check payment status
Actor(s): Landlord, Staff, Manager
Purpose: To clearly know the payment status of an apartment.
Overview: Landlord can check the payment status to know whether the tenant pays
the rent or the apartment payment is on time.
Use Case Name: Check room availability
Actor(s): Landlord, Tenant, Staff, Manager
Purpose: To check the apartment availability and basic information.
Overview: Landlord can check whether the apartment is available and view the basic
information related to the apartment.
Use Case Name: Request inspection
Actor(s): Tenant, Staff, Manager
Purpose: To submit a request to inspect the building.
Overview: Shows the process of requesting inspections. Tenant will submit the
request in order to be processed by the landlord.
Use Case Name: Request maintenance
Actor(s): Tenant, Staff, Manager
Purpose: To submit a request to fix accidental apartment problems.
Overview: Shows the process of requesting maintenance. Tenant will make an
appointment, set a schedule, and fill out a maintenance form for repairing
the accidental maintenance problems.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
12
Use Case Name: Submit feedback form
Actor(s): Tenant, Staff, Manager
Purpose: To provide a real-time feedback.
Overview: After the accidental maintenance, tenants will fill out a feedback form and
submit it. This form will help apartment managers improve their work.
Use Case Name: Request an apartment change
Actor(s): Tenant, Staff, Manager
Purpose: Requesting the landlord for moving from the present apartment to another
Overview: Tenant chooses a new apartment and the date to move and send the
solicitation to the landlord for studying
Use Case Name: Request lease termination
Actor(s): Tenant, Staff, Manager
Purpose: Requesting the landlord for moving out from the present apartment and
finishing the
lease.
Overview: Tenant report landlord the date to move out.
Use Case Name: Pay rent
Actor(s): Tenant, Staff, Manager
Purpose: Allows Customer to make payments online.
Overview: Customers use the AMS to pay the rent.
Use Case Name: Login
Actor(s): Tenant, Landlord, Staff, Manager
Purpose: To use different levels of security access to protect user‟s information.
Overview: Based on the different security levels of users, the system only provides
proper information to users.
Use Case Name: Edit apartment information
Actor(s): Staff, Manager
Purpose: To manage apartment information.
Overview: Staff or manager check/update apartment information, such as rental fee.
Use Case Name: Process tenant registration
Actor(s): Staff, Manager
Purpose: Renting an apartment for a new tenant
Overview: Landlord enters the entire tenant‟s data and the Document Manager
System is sent all the necessary data to generate the lease.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
13
Use Case Name: Process lease termination
Actor(s): Staff, Manager
Purpose: Releasing the apartment, calculating the amount the former tenant will get
or pay and making the Document Manager System know about the lease
termination.
Overview: Landlord enters any damage to the apartment and the apartment
conditions or required services to be in perfect conditions. The system
calculates the former tenant‟s final balance.
Use Case Name: Renew the lease
Actor(s): Automatic process
Purpose: Report to the tenant the lease renewal and any increase in the rent.
Overview: 70 days before the lease expires, the system report to the tenant, the lease
will be automatically renewed and the new rent.
Use Case Name: Send renewal notice
Actor(s): Staff, Manager
Purpose: To send an email to notify tenant that the lease is expiring.
Overview: Staff or manager sends an email to remind tenant to renew the apartment
lease.
Use Case Name: Run Credit Report
Actor(s): None, everyday process
Purpose: Keep tenants reported about the payment
status.
Overview: Runs a credit report on tenants to ensure that all tenants have settled their
debts and are able to pay rent, report about fines for lateness, etc.
Use Case Name: Process tenant‟s apartment change request
Actor(s): Staff, Manager
Purpose: Accepting a tenant‟s apartment change request
Overview: The landlord accepts the change petition, so a new lease must be signed.
Use Case Name: Record regular maintenance
Actor(s): Staff, Manager
Purpose: To make sure each tenant knows the maintenance schedule.
Overview: An email about regular seasonal/annual maintenance will be sent to all the
tenants in order to notify tenants in advance for the inconvenience, so they
can make a slight change for their schedule.
Use Case Name: Schedule inspection
Actor(s): Staff, Manager
Purpose: To program an external inspection of the building.
Overview: Landlord selects an external inspector and fixes the inspection date and
time. The inspection is notified to the tenants.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
14
Use Case Name: Enter inspection results
Actor(s): Staff, Manager
Purpose: To enter the inspection result in order to make them know to the tenants.
Overview: Landlord enters the inspection results to the system. Tenants can also pull
out the inspection results from the system.
Use Case Name: Store occupancy verification
Actor(s): Manager
Purpose: To verify rental applications entered by staff.
Overview: Allows the manager to verify rental occupation, cost and profits.
Use Case Name: Send eviction notice
Actor(s): Manager
Purpose: To send an email about eviction notice.
Overview: Manager checks the apartment and tenant status, and then sends an
eviction notice.
Use Case Name: Record pest control
Actor(s):
Purpose: To eliminate pest to make apartments cleaner.
Overview: Landlord will regularly (seasonal) eliminate pest, including mice,
cockroaches, and bugs.
This is an included use case. So, it does not have a responsible actor.
Use Case Name: Record emergency test
Actor(s):
Purpose: To test the facilities to make apartments safer.
Overview: Landlord will regularly test the fire alarm/sprinkler and make the facilities
usable.
This is an included use case. So, it does not have a responsible actor.
Apartment Unit Assumptions
Pennsylvania Landlord/Tennant laws can be found here:
http://www.rentlaw.com/pennsylvaniarentlaw.htm
Actors: Tenant, Landlord, Inspector, Superintendent
Assumptions:
1) Apartment inspections are done annually.
2) Inspections are performed by a 3rd party.
http://www.rentlaw.com/pennsylvaniarentlaw.htm
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
15
3) The 3rd party, known as the “inspector” report‟s findings in a report to the
superintendent and landlord.
4) Apartments must be found up to code and in good condition and livable. If an
inspection finds them to not be so, the landlord must discuss with the tenant
what can be done to improve them, and who is liable for repairs.
5) Tenants are notified at least 2 weeks in advance before an inspection is
scheduled.
6) A tenant must be present during the inspection.
7) Inspection fees are paid by the landlord.
8) The landlord will share the inspection results with the tenant after the inspection
is complete.
9) The superintendent is allowed to be present during the inspection to verify the
results.
10) A tenant may request an additional inspection up to once a year, if they feel
something is wrong with the property.
11) The system will send the inspection results to the landlord, the landlord may
send it to the tenant.
12) The inspector is chosen by the system, which finds the most available inspector
at the time of scheduling.
13) Inspections are scheduled within the system by the landlord, notifications are
sent out to all parties.
14) Inspection results are entered into the computer system by the superintendent.
15) If an apartment is not passed for inspection, the system will flag it, and it will be
investigated by the landlord.
16) Regular maintenance will be performed by the superintendent on an as needed
basis or by the request of the tenant with approval of the landlord.
17) Sprinkler tests and pest control will require notification to the tenant at least 2
weeks in advance.
18) Tenants are provided with AMS system feedback forms for their maintenance
jobs at their request. They are then submitted to the system for review.
19) Tenants will be provided with a single login for maintenance and payment
capabilities through the system.
Rules for Payment, Leases and new tenants
Actors: Tenant, Landlord, Payment System, Document Management System, Manager
Assumptions:
1) All payments are processed online through the payment system
2) Payment System accepts all major credit cards and debit cards.
3) Payment system is informed of credit reports, to determine if a tenant is a
potential credit risk.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
16
4) The managers may report to the system with information about credit reports,
risks and rental occupation.
5) Rent is due on the 1st of the month.
6) Before leases can be accepted or renewed, the landlord must manually view a
credit report.
7) Probable causes for lease termination, induced by the landlord, include: non-
payment of rent after 60 days, tenant requests termination, extensive destruction
to the property by the tenant, illegal activity going on inside an apartment,
housing of pets strictly forbidden by the lease. Other extenuating circumstances
are handled on a case-by-case basis with involvement of the tenant, landlord and
possibly the courts.
8) In the event of a non-consensual lease termination, the legal burden will be on
the landlord to begin the eviction process through the sheriff‟s office. The
landlord will flag the lease as an eviction in the AMS.
9) Old Tenant information is kept in the system archived for a period of 7 years,
then purged from the
database.
10) Apartment changes must be submitted into AMS with an extensive written
description of why a tenant or landlord is requesting the change. Changes must
be approved by both parties in the AMS.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
17
Detailed Use Case Descriptions
USE CASE # 1
USE CASE Name Record regular maintenance
ACTOR Staff, Manager
Goal (1 phrase) To make sure each tenant knows the maintenance schedule
Overview and scope An email about regular seasonal/annual maintenance will be sent to
all the tenants in order to notify tenants in advance for the
inconvenience, so they can make a slight change for their schedule.
Meanwhile, the related records will be stored in the system.
Level
Primary
Preconditions The staff is logged into the system.
The tenants‟ email list is
available.
Postconditions The information (name and date) of regular maintenance was
recorded and stored.
The notification email with the information of regular maintenance
was sent.
The notification email is forwarded to manager.
Trigger The staff has chosen “Regular Maintenance” option.
Included Use Cases Record
pest control.
Record emergency
test.
Extending Use Cases None
MAIN SUCCESSFUL
SCENARIO in numbered
sequence
Actor Action System Action
1. The staff selects the
“Record a new regular
maintenance”.
2. AMS displays a form to fill out the
emergency test information.
3. The staff enters the date
and type of testing device.
And then, the staff submits
all the data.
4. AMS confirms the data
entered.
5. INCLUDE Record emergency
test.
6. AMS displays a form to fill out the
pest control information.
7. The staff enters date, type
of pest, and type of pest
control. And then, the staff
submits all the data.
8. AMS confirms the data entered.
9. INCLUDE Record pest control.
10. AMS displays a complete
notification of regular maintenance
and also displays three buttons:
“Confirm”, “Back”, and “Cancel”.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
18
11. The staff confirms it. 12. The notification is stored to the
database.
13. AMS displays two options:
“Send this now” and “Send this
later”.
14. The staff selects “Send
this now”.
15. AMS displays the list of email
addresses.
16. The staff checks “Select
all current tenants”, and then
submits.
17. AMS sends the notification to
current tenants and manager.
18. AMS displays message “The
notification is sent.”
OTHER SUCCESSFUL
SCENARIOS
Step Branching Action
6a. Required data is not
entered.
AMS displays a message to enter the
required data.
10a. Required data is not
entered.
AMS displays a message to enter the
required data.
13a. The staff chooses
“Back”.
Go to step 5.
UNSUCCESSFUL
SCENARIOS
Conditions Actions
13b. The staff chooses
“Cancel”.
Abort the notification, display
cancellation message, and go to the
main screen.
16a. The staff chooses “Send
this later”.
Return to the main screen.
17a. Email bounces back
because of invalid email
address.
Ask to enter another address or
abort
Priority in scheduling Primary
Frequency 2 per month
Other non-functional
requirements
1. The notification is sent in 10 seconds.
2. Emergency test information and pest control information are
recorded in 5 seconds.
Business rules and data
logic
1. Emergency tests and pest control will require notification to the
tenant at least 2 weeks in advance.
2. Regular maintenance is performed by the apartment engineers.
Superordinates None
Developer Fangwu Wei
Creation date and last
modified date
Version 1, 05/08/2010
Version 2, 06/02/2010
Other Comments
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
19
USE CASE # 2
USE CASE Name Record emergency test
ACTOR
Goal (1 phrase) To test the facilities to make apartments safer
Overview and scope Apartment staff will regularly test the emergency devices (fire alarm
and sprinkler) and make the facilities usable.
Level Included
Preconditions Emergency test information (date and type of testing device) is
entered.
Postconditions Emergency test data was recorded.
Notification related to emergency test was generated.
Trigger A new notification was written or an old notification was modified.
Included Use Cases None
Extending Use Cases None
MAIN SUCCESSFUL
SCENARIO in numbered
sequence
Actor Action System Action
1. AMS fills out a notification
template by using the data entered.
2. AMS generates the notification of
pest control.
3. AMS stores the notification in the
database temporarily.
OTHER SUCCESSFUL
SCENARIOS
Step Branching Action
UNSUCCESSFUL
SCENARIOS
Conditions Actions
Priority in scheduling First
Frequency 2 per month
Other non-functional
requirements
The notification is generated within 2 seconds.
Business rules and data
logic
The notification builder is embedded to the system.
Superordinates Record regular maintenance
Developer Fangwu Wei
Creation date and last
modified date
Version 1, 05/08/2010
Version 2, 06/02/2010
Other Comments
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
20
USE CASE # 3
USE CASE Name Record pest control
ACTOR
Goal (1 phrase) To eliminate pest to make apartments cleaner
Overview and scope Apartment staff will regularly (seasonal) eliminate pest, including
mice, cockroaches, and bugs by using different methods of pest
control.
Level Included
Preconditions Pest control information (date, type of pest, and type of pest control)
is entered.
Postconditions Pest control data was recorded.
Notification related to pest control was generated.
Trigger A new notification was written or an old notification was modified.
Included Use Cases None
Extending Use Cases None
MAIN SUCCESSFUL
SCENARIO in numbered
sequence
Actor Action System Action
1. AMS fills out a notification
template by using the data entered.
2. AMS generates the notification of
pest control.
3. AMS stores the notification in the
database temporarily.
OTHER SUCCESSFUL
SCENARIOS
Step Branching Action
UNSUCCESSFUL
SCENARIOS
Conditions Actions
Priority in scheduling First
Frequency 2 per month
Other non-functional
requirements
The notification is generated within 2 seconds.
Business rules and data
logic
The notification builder is embedded to the system.
Superordinates Record regular maintenance
Developer Fangwu Wei
Creation date and last
modified date
Version 1, 05/08/2010
Version 2, 06/02/2010
Other Comments
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
21
USE CASE # 4
USE CASE Name Process Rental
Payment
ACTOR Tenant
Goal (1 phrase) Allows Customer to make payments online.
Overview and scope A customer makes a rental payment through the web AMS system. The
customer pays using a credit card. The system records relevant payment
and transaction data, process the payment, and changes the payment
status.
Level Primary
Preconditions The tenant logs into the AMS system. The customer then pays his
balance with a credit
card.
Postconditions in
words(write in passive
and past tense)
The payment status was changed to reflect the Tenants payment. The
payment information and transaction data was stored. A payment
confirmation email was sent to the tenant.
Trigger A tenant makes a rental payment using a credit card
Included Use Cases Process Credit Card Payment
Extending Use Cases None
MAIN SUCCESSFUL
SCENARIO in
numbered sequence
Reference “included use
cases” in this section
using INCLUDE
ius_name
Actor Action System Action
1. A tenant makes a full rental
payment via credit card.
2. The system processes the
transaction and verifies the credit
card.
3. INCLUDE Process Credit Card
Payment
4. The System, records relevant
transaction and payment data.
5. The tenant‟s payment status
is changed from INVOICED
to PAID-IN-FULL.
6 A Confirmation Email is sent to the
tenant
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
22
OTHER SUCCESSFUL
SCENARIOS (Specify
any successful variations
of the normal execution
path, including extension
points using
EXTEND eus_name)
Step Branching Action
1a. A tenant makes a partial
payment via credit card.
The payment is recorded as PAID-IN-
PARTIAL
An Invoice is sent to the customer
requesting the remaining amount
UNSUCCESSFUL
SCENARIOS
(erroneous situations)
Conditions Actions
3a. Credit Card Has
Insufficient Funds
Abort the transaction
6a. Email address is invalid Send confirmation email to Staff
Priority in scheduling Primary
Frequency Monthly
Other non-functional
requirements
1. The system will be a screen-based application.
2. Payment and transaction Information will be backed up daily
3. Menus should be organized in a hierarchical manner
Business rules and data
logic
1. Use of a Credit Card is required for online payment
2 The status of billable items must be properly changed following
the transaction
3 The rental payment amount is generated before the customer
makes payment.
Superordinates None
Developer Andrew Messina
Creation date and last
modified date
Created 4-30-10
Modified 5-2-10
Other Comments
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
23
USE CASE # 5
USE CASE Name Process Lease Termination
ACTOR
Staff, Document Management System
Goal (1 phrase) To terminate a tenant‟s lease
Overview and scope A staff member will initiate the ending of a tenant‟s lease, either
through cause of their eviction or decision to move out. Lease
terminations, specifically evictions, must be justified for reasons such
as non-payment of rent or breaking apartment rules.
Level Primary
Preconditions Tenant must have requested to end their lease or landlord must have
documented proof for reason for eviction.
Tenant must be otherwise be the primary lessee for the unit.
Postconditions in
words(write in passive
and past tense)
Tenant was removed from apartment, the unit shows
as vacant.
Trigger Staff requested by landlord or tenant to terminate a lease.
Included Use Cases
Extending Use Cases
MAIN SUCCESSFUL
SCENARIO in
numbered sequence
Reference “included use
cases” in this section
using INCLUDE
ius_name
Actor Action System Action
1. Staff, being asked by
landlord to terminate lease,
begins termination process.
2. Document management system
retrieves current lease information
3. Staff inputs reasons for
termination of lease.
4. System confirms they are valid and
lawful reasons for termination of a
lease.
5. Staff confirms 6. Lease is terminated, unit is labeled
as vacant.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
24
OTHER SUCCESSFUL
SCENARIOS (Specify
any successful variations
of the normal execution
path, including extension
points using
EXTEND eus_name)
Step Branching Action
1a. Staff, being asked by
tenant to terminate lease,
begins termination process.
2a. Document management system
retrieves current lease information
3a. Staff inputs reasons for
termination of lease.
4a. System confirms that tenant is in
good standing, and meets all
qualifications to terminate a lease.
UNSUCCESSFUL
SCENARIOS
(erroneous situations)
Conditions Actions
4. Document Management
System does not have
documented proof that will
allow a lease termination.
System requests more evidence, to
allow a lawful eviction of tenant.
Action Aborted.
4a. Tenant is not able to
terminate lease due to various
reasons such as back-rent
owed or legal contract in
place.
System requests tenant become good-
standing.
Action Aborted.
Priority in scheduling First
Frequency Once, at end of a tenants lease, before leaving the unit.
Other non-functional
requirements
Must be able to provide legal records, incase its needed in court in case
of evictions.
Must hold records in case of tenants return or request for references.
Business rules and data
logic
Tenant must be listed as primary lessee in document management
system.
Superordinates
Developer Nathan Vasserman
Creation date and last
modified date
1.0
Other Comments
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
25
USE CASE #
USE CASE Name
Process Tenant Registration
ACTOR
Staff, Document Management System
Goal (1 phrase)
To register a new tenant‟s lease
Overview and scope
A staff member or a Tenant will complete a registration process to
register a new Tenant who will be rented an apartment
Level
Primary
Preconditions
Staff must be logged on.
Postconditions in
words(write in passive
and past tense)
The system was registered a new Tenant.
All the tenant data was recorded in the System.
The tenant„s amount to pay was successfully calculated.
All the payment process was completed and its data recorded.
A new contract was generated.
The tenant‟s apartment was set as not available.
Trigger Staff selects rent a new
apartment option.
Included Use Cases “Process credit card payment”
Extending Use Cases
MAIN SUCCESSFUL
SCENARIO in
numbered sequence
Reference “included use
cases” in this section
using INCLUDE
ius_name
Actor Action System Action
1. Staff selects rent a new
apartment option.
2. The System shows all the available
apartments.
3. User selects an apartment,
and the date to enter to live.
4. System displays a tenant data form.
5. User enters his first and last
name, SSN, email, contact
phone, contact address.
6. System checks the form data.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
26
7. System gets the apartment rental
cost, security deposit and calculates
the prepaid rent.
8. System shows a form with all the 7.
Step concepts and the payment way
option (if a logged user as staff, if not,
credit card is the only option).
9. Staff selects credit card
option and enters the Credit
Card Type, CCName,
CCNumber and CCExpiration
date.
10. System performs “Process credit
card payment” use case.
11. System records the user data and
payment process data.
12. System sends tenant data to
Document Manager System
13. System records reports to the user
the operation was successful, and
shows the contract ready to be printed
two copies with instructions to send
one back by mail, fax or in person.
OTHER SUCCESSFUL
SCENARIOS (Specify
any successful variations
of the normal execution
path, including extension
points using
EXTEND eus_name)
Step Branching Action
10a.CCSystem doesn‟t process
the payment because of a
problem with the credit card.
10a. The step 9 is repeated again until
the payment is process. The use case
continues in step 11.
8a. Staff selects check pay
options and enters the check
number and check amount.
4a. The use case continues in step 11.
12a Document Manager
System is not available
The use case finishes.
UNSUCCESSFUL
SCENARIOS
(erroneous situations)
Conditions Actions
2. There are no apartments
available.
System shows a message and use case
finishes.
3a, 5a, 9a. Staff cancels the
process.
Use case finishes.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
27
Priority in scheduling First
Frequency Less than the amount of apartments per year.
Other non-functional
requirements
Connection must be secure.
The contract must be shown in less than 10 seconds.
User can cancel the process in every moment. Every user interface is
displayed in less than 5 seconds.
Business rules and data
logic
The staff prints the two copies of the contract.
Tenant must sign both.
Tenant must show a valid and official ID card to staff.
Superordinates
Developer David Fernandez
Creation date and last
modified date
5/10/2010
Other Comments
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
28
Class Diagram
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
29
Sequence Diagrams
Fangwu Wei, System Sequence Diagram
(Record regular maintenance)
: Staff : Staff
AMS : AMSAMS : AMS
1: Select new regular maintenance()
2: Display emergency test form( )
3: Enter emergency test data(testing date, type of test)
4: End emergency test data()
5: Display pest control form()
6: Enter pest control data(date of pest control, type of pest, type of pest control)
7: End pest control data()
8: Display regular maintenance notification()
9: Confirm notification()
10: Display send-out option(now, later)
11: Select send notification now()
12: Display email address list()
13: Select email address(current tenant, staff)
14: Send notification email(emergency test data, pest control data)
15: Display finish message(“Notification was sent successfully.”)
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
30
: Staff : Staff : RegularMaintenanceInterface : RegularMaintenanceInterface
:
RegularMaintenanceHandler
:
RegularMaintenanceHandler : RegularMaintenance : RegularMaintenance : NotificationBO : NotificationBO
: EmergencyTestFormBO : EmergencyTestFormBO
: EmergencyTestHandler : EmergencyTestHandler
: PestControlFormBO : PestControlFormBO
: PestControlHandler : PestControlHandler
1: selectNewRegularMaintenance()
2: create()
3: create()
4: displayEmergencyTestForm()
5: enterEmergencyTestData(testing date, type of test)
6: endEmergencyTestData()
7: create(testing date, type of test)
8: setTestingDate()
9: setTypeOfTest()
10: displayPestControlForm()
11: enterPestControlData(date of pest control, type of pest, type of pest control)
12: endPestControlData()
15: setTypeOfPest()
16: setTypeOfPestControl()
14: setDateOfPestControl()
17: displayRegularMaintenanceNotification()
13: create(date of pest control, type of pest, type of pest control)
SQD 1 (Record regular maintenance)
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
31
: Staff : Staff :
RegularMaintenanceHandler
:
RegularMaintenanceHandler : NotificationBO : NotificationBO
: DBHandler : DBHandler
: Send-outOptionBO : Send-outOptionBO
: EmailAddrListBO : EmailAddrListBO
: EmailAddrListHandler : EmailAddrListHandler : Tenant : Tenant
: FinishMessageBO : FinishMessageBO
1: confirmNotification()
2: saveNotificationToDB()
3: create()
5: selectToSendNotificationNow()
6: create()
10: selectCurrentTenantEmailAddr()
11: displayFinishMessage()
7: create()
8: getTenantEmailAddr()
9: displayEmailAddrList()
4: displaySendOutOption()
SQD 2 (Record regular maintenance)
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
32
Process Emergency Test (included use case)
: EmergencyTestHandler : EmergencyTestHandler
: NotificationTemplate : NotificationTemplate
: DBHandler : DBHandler
1: create()
2: filloutData(testing date, type of test)
3: saveEmergencyTestNotificationToDB()
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
33
Process Pest Control (included use case)
: PestControlHandler : PestControlHandler
: NotificationTemplate : NotificationTemplate
: DBHandler : DBHandler
1: create()
2: filloutData(date of pest control, type of pest, type of pest control)
3: savePestControlNotificationToDB()
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
34
AMS Tenant : AMS
tenant
AMS Tenant : AMS
tenant
Web Server : Web serverWeb Server : Web server
CC Verification : CC
Company
CC Verification : CC
Company
CC Verification Handler : CC
Company
CC Verification Handler : CC
Company
Payment Form : PaymentPayment Form : Payment
Payment Handler :
Payment Form
Payment Handler :
Payment Form
Database Handler :
Database
Database Handler :
Database
1: Login
4: Verify Credit Card
7: Display Current Lease
2: Submit Balance
3: Enter Credit Card Data
6: Process payment
5: Send Verification
8: Transaction Sucessfull
9: Send Payment Confirmation
10: Create Reciept
11: Send Confirmation Email
14: Store Customer Data
12: Submit Transaction ID
13: Request Payment Information
Andrew Messina, Pay Rent
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
35
: Staff : Staff Tenant Info : Tenant InfoTenant Info : Tenant Info Database Handler :
Database Handler
Database Handler :
Database Handler
Termination Form : Termination FormTermination Form : Termination Form
Termination Handler :
Termination Handler
Termination Handler :
Termination Handler
Apartment : ApartmentApartment : Apartment Tenant : TenantTenant : Tenant
1: Enter Tenant Info
2: Verify Tenant Info
4: Retrieve Current Lease
5: Reason for Lease Termination
6: Very Legitment Termination
3: Display Current Lease
7: Display Confirmation for Termination Reason
8: Enter Termination Date
9: Update Vacancy Date
11: Enter New Tenant
12: Update New Tenant
10: Update Old Tenant
13: Verify All Information
14: Display Confirmation
15: Attach Termination Documents
16: Confirm Termination Documents
17: Update apartment/tenant info to database
18: Display Termination Confirmation
Nathan Vasserman, Terminate Lease
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
36
David Fernandez, System Sequence Diagram: Process Tenant Registration
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
37
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
38
State Diagrams for Apartment and Lease objects
Apartment and Lease are the most relevant classes of Domain class diagram.
Apartment
Lease
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
39
Design Class Diagram
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
40
Package Diagram
MaintenanceUI package contains all screen and controllers classes used in the record regular maintenance sequence diagram.
PaymentUI package contains all screen and controller classes used in Pay Rent sequence diagram.
LeaseUI package contains all screen and controller classes used in Terminate lease and Process tenant registration sequence
diagrams.
Database package contains all the controllers in the all sequence diagrams which interact with the database.
User profile package contains the classes: Tenant, Employee, Staff, Manager, and Landlord.
Lease package contains: Lease, Rent, Payment, CreditCard_Payment, Check_Payment, Cash_Payment, ApartmentChange,
Termination, SecurityRefund and Renewal.
Apartment package contains: Apartment, Building, Inspection, Maintenance, AccidentalMaintenance and RegularMaintenance.
Database schema
Database schema
Landlord (landlordID, password)
Employee (employeeID, password, firstname, lastname, phone, email)
Staff (employeeID*)
Manager (employeeID*)
Tenant (tenantID*, password, SSN, firstname, lastname, email, phone, currentAddress, cityStateZip, password)
Lease (leaseID, startDate, endDate, balance, securityDeposit, rentalDate, tenatId*, apartmentNumber*, terminationID*,
apartmentChangeID*)
Building (buildingName, address, cityStateZip, landlordID*)
Apartment (apartmentNumber, size, aptType, rentalFee, buildingName*)
ApartmentChange(apartmentNumber, changeDate, newAptNumber, apartmentNumber*)
Renewal (renewalID, renewalDate, renewalPeriod, leaseID*)
Termination(terminationID, leavingDate, leavingReason ,)
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
41
Security_Refund(SRID, refundAmount, date, refundReason, terminationID*, employeeID*)
Rent (rentID, rentalFee, lateFee, date, dateToPay, leaseID*, payID*)
Payment (payID, payDate, payAmount, payMethod, rentID*)
Cash_Payment (payID*)
Check_Payment(payID*, bankName, checkNumber)
CreditCard_Payment(payID*, holderName, expDate, ccType, ccNumber)
Inspection (apartmentNumber*, inspectionID, inspectionDate, inspectionResult)
Maintenance (apartmentNumber*, maintenanceID, maintenanceDate, templateName*)
AccidentalMaintenance ((apartmentNumber*, maintenanceID)*, problem, feedbackDate, maintenanceRating)
RegularMaintenance ((apartmentNumber*, maintenanceID)*, pestType, pestControlType, emergencyType, pestControlDate,
emergencyTestDate)
NotificationTemplate (templateName, description, subject, emailAddress)
Discussion on developing the diagrams.
Our class diagram was developed with all four group members communicating via Skype. There was much debate over
the existence of certain classes. One of the biggest discussions within the group was regarding how lease terminations should be
handled. We came to the consensus to form a termination class with relationships to a security deposit refund, the lease class and
branching options for renewal. Maintenance was ultimately decided to be split into 2 generalizations because of the nature of
different types of maintenance and its relation to each apartment unit. We also debated between what constitutes an “employee”
of the building staff. This was decided to be a single class that could encapsulate a repairman, clerical staff or assistant property
manager. The handling of the employee class is on the administrative side of the building. Landlord was a separate class
altogether, even though his involvement with the apartment management system is minimal.
Our use case diagram was a similar approach as well. Since the use case descriptions and sequence diagrams were an
individual effort, we had to each choose our own use cases, and incorporate them into a much large diagram that would involve
several use cases we knew would not be addressed as in-depth as others. Our use case diagram ending up involving many more
actors then our class diagram would appear to show. In this instance we had to separate out many of the roles that the apartment
staff would manage, in addition to 3
rd
party inspectors, landlords, managers and the payment management systems. Most of the
use case diagram centers around the steps involved in simply paying rent and keeping the apartment database and their tenants up
to date. The group collaborative effort allowed us to share many of our experiences, especially those of us with first hand
experience living in an apartment building compared to those who haven‟t.
Summary and
Lessons Learned
After the completion of this project, we felt we have learned a significant amount about the work and processes that go
into handling apartment management. There are many different players in the process, many of whom we‟ve never actively
thought about. This includes not only the Landlord and Tenant, but also apartment staff, supervisors, employees and where they
all fit in to managing an apartment unit. Our class diagram design involved a lot of collaborative thinking to figure out where
they players fit and what roles do they accomplish.
The job of creating a design document for the system taught us much in how UML is structured. There are a lot of aspects
of it that are still confusing such as some of the different objects in a sequence diagram. Thinking about the sequence diagram
and the class diagram, I would say these were our biggest challenges. Some of the aspects of the system, such as paying rent, are
very complicated and required a lot of critical thinking on our parts to be able to identify all the different scenarios and sequence
steps for proper identification. The project in general definitely did a lot to expand our skills in UML and modeling and
hopefully we will be able to use these skills in the future.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
42
Appendix
Division of Work
Problem Statement: Group Effort
Class Diagram: Group Effort
David: Process Tenant Registration use case description and sequence Diagram, Database Schema
Andrew: Process payment/rent use case description and sequence Diagram
Nathan: Terminate Lease use case description and sequence Diagram
Fangwu: Notify for regular maintenance use case description and sequence Diagram
Document Compilation: Nathan,
Fangwu
Lessons Learned
David
This Project has consolidated my knowledge in two areas: Object Oriented Analysis and Design applying UML and team
working.
In OOA/D, we have got to implement INFO620 lectures knowledge in OOA/D into a medium-large complex project as AMS.
Under “if I do it, I understand it” philosophy, I understood much better the OOA/D process applying UML, translating these
concept into AMS project by UML diagrams: use cases, class diagram, sequence diagram, design class diagrams and database
schema.
I have learned how to develop use cases from the domain problem, identifying actors and their goals, how to do a detail
description of use cases developing one of the most complex one: defining pre-conditions and post conditions for “Process tenant
registration”, defining the logical steps in the main scenario, some alternative (un)successful scenarios, and including non
functional requirements and business rules.
I have learned to design the static vision of the system developing the domain class diagram, the dynamic vision developing the
sequence diagram for “Process tenant registration”, and to join both visions into the design class diagram.
I have learned how to apply the concepts to identify a good candidate class to AMS ones, its attributes, and its associations which
has ever been the most difficult part for me.
I have learned how to identify and how to use controller classes and how to develop a sequence diagram from the use case
description. I have started to distinguish between domain classes (class diagram), which support the business logic for AMS
(Apartment, Lease, Termination, Rental, etc) from the architecture and design classes which organizes the system structure
(DatabaseController, TenantDataController, …), making independent domain classes from system interfaces as user, database,
other system.
I have learned how to check the consistency between diagrams: all the classes in class diagram must participate at least in one
use case. In all interactions in sequence diagrams between domain objects, whose classes must exist in the class diagram, must
have an association in the class diagram (unless it was too obvious) and all the messages between domain classes must be
transform into class operations.
Working in groups has taught me the difficulty to coordinate and meet in a 4 member group, but how rich are the diagram when
pick up all the ideas of every member. I could not develop a use case diagram with so many use cases by myself. Putting together
the best ideas of every team member has allowed identifying 30 use cases!!!
Other positive experience has been to develop the class diagram. We did it altogether. Although it took us a lot of time, the result
is a class diagram which met the use cases with only a little corrections from the professor. I could not have developed the class
diagram without correction from the professor.
I still have a lot of thing to learn in this area of OOA/D. For example, to identify and apply design patterns. With the exception of
View-Model-Controller pattern, I have not applied any pattern in AMS project.
I have no very clear how to go further than design class and package diagram. It is not very clear how to develop component and
deploy diagrams.
Andrew
Coming into this class, I had a decent knowledge of UNL and diagrams. In my previous MIS classes I learned about all the
diagrams we learned in this class. I also used Rational Rose, so I was somewhat prepared for this class. I still found this class
extremely difficult, even though I had prior knowledge. I am a very messy person, so developing diagrams is very hard for me.
Although the class was challenging, I still feel that I learned a lot about UML and the relevant diagrams. I feel that I will
confidently be able to apply this knowledge and the diagrams I have learned in the future. This project also pushed me to spend
a lot of time developing a sequence and class diagram, which are my two least favorite. I am glad I received a better
understanding of both diagrams though this class.
Fangwu Wei, Andrew Messina, David Fernandez Galende, Nathan Vasserman
Group Project Submission 6/10/2010
43
Nathan
I felt I learned a lot the planning and preparation that goes into software design. Since my division was in the terminate lease
segment, there was a significant amount of research that needed to be done into rental laws in Pennsylvania. Making sure all
those laws were compliant with our Apartment Management System. As of writing this, I do not know what kind of grade I will
receive on my sequence diagram, but I am hoping it is acceptable as I put it in a significant amount of time and effort into it.
Going through the logical steps of software design sequences was a bit daunting for me and I think I learned a lot about it.
Fangwu
Learned how to create UML diagrams, including use case diagram, class diagram, and sequence diagram.
Learned how to identify the use case, class, object, and then draw the diagrams based on rules, notation, and heuristic
evaluation steps.
Learned how to analyze and design a system in a real world, and develop it further based on the UML diagrams, database,
and architecture.
Unanswered Questions
1. How to identify the control object and association between control object and boundary object/entity object? I felt better after I
read the paper, “Developing Sequence Diagrams in UML”, but I was not so clear about control object. I didn‟t create a control
object before in my java program because of my basic java programming skills. I guess to practice programming and UML
diagrams both would be better for me, which helps me be object-sensitive.
2. I learned the relational database last week. I used the ER Diagram and Data Flow Diagram (DFD) in my passed projects. Are
those diagrams necessary in an OOA/D? If we need them, which step we need to use them?