Posted: February 26th, 2023
Stage 3 System Design Specification
1
Stage 1 – Preliminary Investigation Report
UMGC
I.
Introduction
Precision Electronics Parts, Inc. has identified a need to replace the current customer billing and payment system and re-engineer the associated processes. The purpose of this preliminary investigation report is to document the planning phase of the System Development Life Cycle (SDLC) for this project. The report will identify the problem or opportunity presented, analyze various feasibility aspects of implementing a system, and provide a recommendation for further action with estimated costs and schedule.
II.
Problem to be solved
The current customer billing and payment system at Precision Electronics Parts, Inc. needs to be updated and meet the organization’s needs. The system is causing delays in billing and payments, resulting in lost revenue and dissatisfied customers. The manual process for handling billing and payments is time-consuming and error-prone, leading to inefficiency and errors. The main problems with the current system are delays in billing and payments, resulting in lost revenue and dissatisfied customers; inefficiency, errors in the manual process, leading to incorrect billing and payments; and high operational costs.
III.
Findings
a.
Scope of Proposed System
The proposed system will automate the billing and payment process and integrate with the company’s existing inventory management system. The system will include automatic billing generation, electronic payment processing, and real-time billing and payment status reporting. The system will also include a customer self-service portal for viewing and paying bills. The system will cover all aspects of the billing and payment process and will be implemented across all departments within the organization.
b.
Constraints
Several constraints have been identified for the proposed system. These include:
· Limited budget for the implementation of the system
· Inadequate IT resources within the organization
· Limited time for implementation and testing of the system
· Less training resources available for employees
c.
Fact Finding
The fact-finding process revealed that the current manual billing and payment process is causing delays in billing and payments, resulting in lost revenue and dissatisfied customers. The process is also error-prone, leading to incorrect billing and payments. Additionally, the manual process is time-consuming and leads to high operational costs.
d.
Current Costs
The current cost of the manual billing and payment process includes labor costs associated with manual data entry and errors, as well as the cost of delays in billing and payments. The exact cost of the current system needs to be specified in the case study. Still, the organization is losing revenue and incurring additional costs due to the manual process inefficiencies.
IV.
Feasibility Analysis
a.
Technical Feasibility
The technical feasibility of the proposed system has been determined by assessing the availability of the necessary hardware and software resources to implement the proposed system. This includes evaluating the compatibility of the proposed system with the existing hardware and software infrastructure and the availability of the necessary technical skills within the organization. The proposed system is technically feasible, as the necessary resources and skills are available within the organization.
b.
Financial Feasibility
The financial feasibility of the proposed system has been determined by evaluating the costs and benefits of the proposed system. This includes a cost-benefit analysis of the proposed system, which estimates the costs of implementing it and compares them to the expected benefits (Mall, 2018). The costs include the expenses related to the development, implementation, and maintenance of the system, while the benefits include improvements in efficiency, accuracy, and customer satisfaction. The proposed system is financially feasible, as the benefits outweigh the costs.
c.
Organizational/Behavioral Feasibility
The organizational and behavioral feasibility of the proposed system has been determined by assessing the organization’s ability to implement and maintain the proposed system (Shylesh, 2017). This includes evaluating the organizational resources, such as personnel and budget, that will be required to implement the system and assess the organizational readiness and willingness to adopt the proposed system. The proposed system is organizationally and behaviorally feasible, as the necessary resources and support are available within the organization.
IV
. Recommendation
After conducting a thorough analysis of the current situation and the proposed system, it is suggested that Precision Electronics Parts, Inc. proceed with the implementation of the proposed system. The system’s benefits outweigh the costs, and the organization has the necessary resources to implement and maintain the system.
A comprehensive evaluation of the system requirements and a specific solution proposal is proposed to be developed in the next phase of the SDLC. This will comprise a more in-depth examination of the proposed system’s technical, economic, and operational feasibility, as well as the development of a project plan that includes a schedule and budget for implementation.
It is also advisable that the organization forms a project team to oversee the implementation of the proposed system. This team should include members from various departments within the organization, such as IT, finance, and operations. The project team will ensure that the proposed system is implemented on time, within budget, and to the satisfaction of all stakeholders.
Moreover, it is also suggested that the organization conducts thorough testing and training of the system before it is deployed to production. This will ensure that the system works as intended and that the employees are properly trained to use the system.
Finally, it is recommended that the organization establishes a plan for ongoing maintenance and support of the system. This will ensure that the system operates efficiently and effectively over the long term.
V.
Conclusion
The proposed system for automating the billing and payment process at Precision Electronics Parts, Inc. has been thoroughly evaluated for feasibility and potential benefits. The analysis results in support the recommendation to proceed with implementing the system. The proposed system will automate the billing and payment process and integrate with the company’s existing inventory management system, leading to increased efficiency, accuracy, and customer satisfaction, reduced operational costs, improved inventory management, and improved data analysis and reporting.
References
Shylesh, S. (2017). A study of software development life cycle process models. In
National Conference on Reinventing Opportunities in Management, IT, and Social Sciences (pp. 534-541).
Mall, R. (2018).
Fundamentals of software engineering. PHI Learning Pvt. Ltd..
Stage 3: System Design Specification
Before you begin this assignment, be sure you have read the Case Study and all assignments for this class, especially Stage 4: Final System Report. The feedback you received on your Stage 1 and Stage 2 assignments should be reviewed and used as you proceed with Stage 3.
Purpose of this Assignment
This assignment gives you the opportunity to apply a systematic approach to translate requirements into a high-level logical system design. This assignment specifically addresses the following course outcomes to enable you to:
· apply a systematic approach to translate requirements into an executable systems design
· effectively communicate with stakeholders to determine, manage, and document business requirements throughout the SDLC
Assignment
The results of your systems analysis and design work in this class will be documented in a Final System Report. The purpose of the Report is to inform management of your system proposal and gain approval to proceed with the project. The Report will be developed and submitted in stages, which will be compiled at the end of class into the Final System Report. Review the outline of the Final System Report in the Stage 4 Assignment description. Note that it contains the analysis of the problem(s) and requirements, and proposes what kind of a system solution is needed. It does not propose a specific solution, but it does recommend why and how the organization should acquire the solution.
Following the Requirements Specification (Stage 2 assignment), the next step is to develop the System Design Specification. The System Design Specification builds on the Requirements Specification to illustrate how the files/database(s) will be laid out, how the output (forms, reports, and/or screens) and input (forms and/or screens) should be designed. As you develop this assignment, you should refer to your Stage 2 Requirements Specification (and the feedback you received) and use the inputs and outputs you listed to create the input and output layouts and the file/database design.
All of the information you need to complete the projects in this class is not provided in the case study. In the discussion area of the classroom, there is a discussion titled ”
Case Study Interview Questions” where you can pose questions about the case study, as if you were interviewing the people in the case study organization. Any information that you need that is not included in the case study should be asked about in this discussion. Responses from the faculty member on behalf of the case study organization will be available for everyone in the class.
Use the case study and the Case Study Interview Questions discussion, along with your Stage 2 Requirements Specification (including the feedback received), and resources below, to create a System Design Specification in the format shown below. Include your corrected Stage 2 Requirements Specifications as the first part of this assignment. Approximate lengths for each section of the Systems Design Specification are provided as a guideline; be sure to provide all pertinent information. The sources of explanatory materials can be found in the Week
5
Content readings.
Requirements Specification
Include your Requirements Specification from Stage 2, with corrections from the feedback included. This will establish the context for your System Design Specification to follow.
System Design Specification
I.
Introduction
. Provide an appropriate introduction to this document. (one paragraph)
II. Output Layout. Begin with the three outputs listed in your Requirements Specification. For each of them, create a diagram or table illustrating what the output would look like. (use a short paragraph to introduce this section and each diagram, table or illustration should use about ½ of a page)
A. Output Layout #1.
B. Output Layout #2.
C. Output Layout #3.
III. Input Layout. Using the data elements listed in your Requirements Specification, create a diagram or table illustrating what the input screen would look like for each of the three sets of input. (use a short paragraph to introduce this section and each diagram, table or illustration should use about ½ of a page)
A. Input Layout #1.
B. Input Layout #2.
C. Input Layout #3.
IV.
File/database Design ERDs. For each of the three sets of outputs and inputs, create an Entity Relationship Diagram showing how the data elements are related to each other [see an explanation at
http://www.cs.uregina.ca/Links/class-info/215/erd/
, and use the formatting specified in the example]. Depending on the inputs and outputs identified, there may be some overlap of the data elements in the ERDs; a separate ERD should be developed for each pair of inputs/outputs. (use a short paragraph to introduce this section, and each ERD should be on one page)
A. File/database Design ERD #1.
B. File/database Design ERD #2.
C. File/database Design ERD #3.
Submitting Your Assignment
Submit your Requirements Specification and System Design Specification as one document via your Assignment Folder as Microsoft Word document, or a document that can be ready using MS Word, with your last name included in the filename. Use the Grading Rubric below to be sure you have covered all aspects of the assignment.
GRADING RUBRIC:
|
90- 100 % Far Above Standards |
80-89% Above Standards |
70-79% Meets Standards |
60-69% Below Standards |
< 60% Well Below Standards |
Possible Points |
||||||
| Introduction |
5 Points The corrected Requirements Specification is included along with a well-written introduction to the Systems Design Specification; demonstrates a sophisticated level of writing. |
4 Points The corrected Requirements Specification is included along with an appropriate introduction to the Systems Design Specification; demonstrates clear writing. |
3.5 Points The corrected Requirements Specification is included along with an introduction to the Systems Design Specification. |
3 Points The corrected Requirements Specification and/or the introduction to the Systems Design Specification may not be included or may not be complete. |
0-2 Points The corrected Requirements Specification and introduction to the Systems Design Specification are not included, or little effort is demonstrated. |
5 | |||||
|
Output Layouts |
27- 30 Points Three output layouts are clearly and logically presented; and very clearly relate to the output requirements previously defined. Demonstrate a sophisticated level of analysis. |
24-26 Points Three output layouts are clearly presented; and clearly relate to the output requirements previously defined. Demonstrate accurate analysis. |
21-23 Points Three output layouts are presented and relate to output requirements previously defined. |
18-20 Points Fewer than three output layouts may be provided, and/or they may not be appropriate to the previously defined output requirements. |
0-17 Points One or no output layouts are provided, may not relate to the previously defined output requirements, or little effort is demonstrated. |
30 | |||||
|
Input Layouts |
27-30 Points Three input layouts are clearly and logically presented; and very clearly relate to the input requirements previously defined. Demonstrate a sophisticated level of analysis. |
24-26 Points
Three input layouts are clearly presented; and clearly relate to the input requirements previously defined. Demonstrate accurate analysis. |
21-23 Points
Three input layouts are presented and relate to input requirements previously defined. |
18-20 Points Fewer than three input layouts may be provided, and/or they may not be appropriate to the previously defined input requirements. |
0-17 Points
One or no input layouts are provided, may not relate to the previously defined input requirements, or little effort is demonstrated. |
||||||
|
File/Database Design ERDs |
27-30 Points
Three Entity Relationship Diagrams are correctly constructed, logical, appropriate to the inputs/outputs, and demonstrate a sophisticated level of analysis. |
24-26 Points
Three Entity Relationship Diagrams are correctly constructed, logical, appropriate to the inputs/outputs, and demonstrate accurate analysis. |
21-23 Points
Three Entity Relationship Diagrams are adequately constructed, and appropriate to the inputs/outputs. |
18-20 Points
Three Entity Relationship Diagrams may not be included, and/or may not be appropriate to the inputs/outputs. |
0-17 Points
Fewer than three Entity Relationship Diagrams are not provided, are not appropriate to the inputs/ outputs or little effort is demonstrated. |
||||||
|
Format |
5 Points
Submission reflects effective organization and sophisticated writing; follows instructions provided; uses correct structure, grammar, and spelling; presented in a professional format; any references used are appropriately incorporated and cited using APA style. |
4 Points
Submission reflects effective organization and clear writing; follows instructions provided; uses correct structure, grammar, and spelling; presented in a professional format; any references used are appropriately incorporated and cited using APA style. |
3.5 Points
Submission is adequate, is somewhat organized, follows instructions provided; contains minimal grammar and/or spelling errors; and follows APA style for any references and citations. |
3 Points
Submission is not well organized, and/or does not follow instructions provided; and/or contains grammar and/or spelling errors; and/or does not follow APA style for any references and citations. May demonstrate inadequate level of writing. |
0-2 Points
Document is extremely poorly written and does not convey the information. |
||||||
| TOTAL Points Possible | 100 |
Stage 3: System Design Specification 4
2
Requirements Specification
UMGC
IFSM 461
Requirements Specification
Background:
The proposed system is an automated billing and payment system that will replace the manual process currently used at Precision Electronics Parts, Inc. The system will automate the billing and payment process and integrate with the company’s existing inventory management system. The system will include automatic billing generation, electronic payment processing, and real-time billing and payment status reporting. The system will also include a customer self-service portal for viewing and paying bills (Shylesh,2017).
I.
Functional Requirements.
a.
Output requirements.
i.
electronic payment confirmation: An electronic confirmation of payment that is sent to the customer upon completion of payment.
ii.
Billing/payment report: A report that will be generated monthly that provides a breakdown of all billing and payments that were processed in that month.
iii.
Payment status report: A report that will be generated on demand that provides the current payment status of a customer’s account.
b.
Input requirements.
i.
Customer data: This includes the customer’s name, address, phone number, and other contact information.
ii.
Payment information: This includes the payment amount, payment method, and payment date.
iii.
Invoice data: This includes the invoice number, invoice date, and invoice amount.
c.
Processing requirements.
i.
Generate invoice: This process will generate an invoice based on the customer’s purchase data.
ii.
Process payment: This process will process the payment information and update the customer’s account with the payment amount.
iii.
Send payment confirmation: This process will send an electronic payment confirmation to the customer upon completion of payment.
II.
Technical Requirements
a.
Security requirements: The system must be secure and protect the data from unauthorized access.
b.
System control requirements: The system must provide an audit trail of all transactions and must be able to be monitored and controlled.
c.
Performance requirements: The system should be able to process payments promptly and should be able to generate reports quickly.
d.
Business continuity requirements: The system should have backup and recovery processes in place to ensure that data is not lost in the event of a system failure.
III.
System Scope Diagrams
a.
Context Diagram: The diagram below shows the context of the system and the external entities that interact with the system.
Fig1. Context of the system and the external entities that interact with the system
Initial discussions with users about issues with the current system and the requirements for the new system are required as part of the process of developing the analytical framework by drawing and analyzing the context diagram. They are formally recorded alongside any identified system needs from prior research (Mall,2018).
b.
Use Case Diagram: The diagram below shows the actors and use cases of the system.
IV.
Data Flow Diagram
a. Data Flow Diagram: The diagram below shows the flow of data through the system.
Process Models
Structured English
If the customer account has an outstanding balance IF the payment method is a credit card
THEN process payment
THEN generate invoice
THEN process payment
ELSE IF payment method is electronic payment
References
Kramer, A. F. (2020). Physiological metrics of mental workload: A review of recent progress.
Multiple-task performance, 279-328.
Mall, R. (2018). Fundamentals of software engineering. PHI Learning Pvt. Ltd.
Roleda, M. Y., & Hurd, C. L. (2019). Seaweed nutrient physiology: application of concepts to aquaculture and bioremediation.
Phycologia,
58(5), 552-562.
Shylesh, S. (2017). A study of software development life cycle process models. In National Conference on Reinventing Opportunities in Management, IT, and Social Sciences (pp. 534-541).
image1
image2
Expert paper writers are just a few clicks away
Place an order in 3 easy steps. Takes less than 5 mins.