Stage 2: Requirements 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 assignment should be reviewed and used as you proceed with Stage 2.
Purpose of this Assignment
This assignment gives you the opportunity to specify clear and concise requirements, including the use of data and process models, for a system that enables a productive change in a way the business is conducted. 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
· perform modeling to assist with analysis and decision making
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 Preliminary Investigation Report (Stage 1 assignment), the next step is to identify the requirements for a system, documenting them in the Requirements Specification document. The purpose of the Requirements Specification is to clearly define what the proposed system will do in non-technical user-oriented language. It should identify what data is entered into the system, what output is required, what processes the system should perform, what protections and controls are needed, what performance is expected, and what the business continuity needs are. In order to clearly express the requirements, data and process models are used to communicate how the system should work.
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 information provided in the case study and the Case Study Interview Questions discussion to create a checklist of functional and technical requirements and the data and process models listed below. Using the format
and resources below,
list three requirements for
each
of the areas shown in I and II. Then, create two diagrams to illustrate the scope of the system: the
context diagram and the
use case diagram. Then, create the
data flow diagram to illustrate the flow of the inputs and outputs listed as functional requirements in section I. You should then select a
process or process step (from those listed in section I.b – processing requirements)
that has some decision associated with it to create the three process models listed below. The same process/process step will be used for all three of the process models; they are just different ways to represent the process and the decision involved. Approximate lengths for each section are provided as a guideline; be sure to provide all pertinent information. References in brackets are to the two e-textbooks (by authors Jawahar and Conger) used in this class and the page on which the explanatory information begins.
Use the examples listed in the brackets to develop your diagrams. [Note: Every diagram/model needs to be customized for the course scenario. Simply copying the example diagram(s) with little or no customization will result in a zero for that diagram.] There are several different methodologies using different symbols, but your diagrams will be graded for compliance with the examples listed. You are required to use the symbols and diagramming methods illustrated in the examples, and follow any rules for the diagram in the sources listed with each diagram.
Requirements Specification
Background: First, provide a brief description of your proposed system to establish the context for the Requirements Specification.
I.
Functional Requirements
. The input-processing-output requirements must relate to each other. Start with three outputs you expect from the system, then determine what inputs are needed to create each of those outputs, and finally specify what processing needs to occur for each input to create the output. At least one of your processing requirements must have a decision associated with it so it can be used for the
Process Models
below. You should have a complete statement for each requirement, and each requirement should be numbered within the category. (introductory paragraph and list of 9 inter-related requirement statements) [Jawahar, p. 95 and the Week 3 Content, including reading on IEEE Software Requirements Specifications] [another source of ideas and concepts is:
http://www.slideshare.net/ALATechSource/sample-project-requirements-document-library-blog
]
a. Output requirements. List three different reports, results of a calculation, or other outputs.
i. Output #1
ii. Output #2
iii. Output #3
b. Input requirements.
i. List the main data elements required to create output #1
ii. List the main data elements required to create output #2
iii. List the main data elements required to create output #3
c. Processing requirements (at least one must have a decision associated with it)
i. Processing required to create Output #1
ii. Processing required to create Output #2
iii. Processing required to create Output #3
II.
Technical Requirements
(introductory paragraph and 3 requirement statements listed for each area below) [Jawahar, p. 95]
a. Security requirements
b. System control requirements
c. Performance requirements
d. Business continuity requirements (backup, restart, recovery)
III.
System Scope Diagrams
(introductory/explanatory paragraph and 2 diagrams) [a good explanation and example is at
]
a. Context Diagram [explanation in Conger, p.228; use example in Conger, p.229. Figure 7.2]
b. Use Case Diagram [use example in weblink above]
IV.
Data Flow Diagram
(introductory/explanatory paragraph and diagram) [Week 4 Content module and weblinks]
a. Data Flow Diagram [explanation in Conger, p.228; use example in Conger, p.230, Figure 7.3; use the tips located in the assignment folder (DFD_Tips )]
V. Process Models (introductory/explanatory paragraph and 3 items below) [Week 4 Systems Analysis Course Module]
a. Structured English [use example in Systems Analysis Course Module, Process Description Tools]
b. Decision Table [use example in Systems Analysis Course Module, Process Description Tools]
c. Decision Tree [use example in Systems Analysis Course Module, Process Description Tools]
Submitting Your Assignment
Submit your 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- 10 0% Far Above Standards |
80-89% Above Standards |
70-79% Meets Standards |
60-69% Below Standards |
< 60% Well Below Standards |
Possible Points |
||||||
| Functional Requirements |
16- 18 Points Three requirements for input, output and processing are clearly stated and correctly inter-related; are logically derived from the Case Study, and demonstrate a sophisticated level of writing. |
14-15 Points Three requirements for input, output and processing are clearly stated and correctly inter-related; are logically derived from the Case Study, and demonstrate a clear understanding of the course concepts. |
12 -13 Points Three requirements for input, output and processing are stated and are inter-related; and are derived from the Case Study. |
10-11 Points May present fewer than three requirements for input, output and processing, or they may not be inter-related; and/or may not be derived from the Case Study. |
0-9 Points Functional requirements are not included, or demonstrate little effort. |
18 | |||||
| Technical Requirements |
11-12 Points Three requirements each for security, system control, performance, and business continuity are clearly stated and are logically derived from the Case Study, and demonstrate a sophisticated level of writing. |
9-10 Points Three requirements each for security, system control, performance, and business continuity are clearly stated and are logically derived from the Case Study, and demonstrate effective writing. |
8 Points Three requirements each for security, system control, performance, and business continuity are provided and are appropriate to the Case Study. |
7 Points Fewer than three requirements each for security, control, performance and business continuity may be provided, and/or they may not be appropriate to the Case Study. |
0- 6 Points Functional requirements are not provided, or little effort is demonstrated. |
12 | |||||
| System Scope Diagrams |
9-10 Points
Context diagram and Use Case diagram are correctly constructed, logical, appropriate to the Case Study and demonstrate a sophisticated level of analysis. |
8 Points
Context diagram and Use Case diagram are correctly constructed, logical, appropriate to the Case Study and demonstrate accurate analysis. |
7 Points
Context diagram and Use Case diagram are provided, and are appropriate to the Case Study. |
6 Points
Both Context and Use Case diagrams may not be provided, and/or may not be appropriate to the Case Study. |
0-5 Points Both Context and Use Case diagrams are not provided, or little effort is demonstrated. |
10 | |||||
| Data Flow Diagram |
9-10 Points
Data Flow Diagram is correctly constructed, logical, appropriate to the Case Study and demonstrate a sophisticated level of analysis. |
8 Points
Data Flow Diagram is correctly constructed, logical, appropriate to the Case Study and demonstrate accurate analysis. |
7 Points
Data Flow Diagram is provided, and are appropriate to the Case Study. |
6 Points
Data Flow Diagram may not be correctly contructed, and/or may not be appropriate to the Case Study. |
0-5 Points
Data Flow Diagram is not provided, or little effort is demonstrated. |
||||||
| Process Models |
36- 40 Points All three process models – structured English, decision table, and decision tree – are correctly constructed, logical, appropriate to the Case Study and demonstrate a sophisticated level of analysis. All three models describe the same decision process. |
32-35 Points All three process models – structured English, decision table, and decision tree – are correctly constructed, logical, appropriate to the Case Study and demonstrate accurate analysis. All three models describe the same decision process. |
28-31 Points All three process models – structured English, decision table, and decision tree – are provided, and are appropriate to the Case Study. All three models describe the same decision process. |
24-27 Points All three process models may not be provided, may not describe the same decision process, and/or may not be appropriate to the Case Study. |
0-23 Points The three process models are not provided, or little effort is demonstrated. |
40 | |||||
|
Format |
9-10 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. |
8 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. |
7 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. |
6 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-5 Points
Document is extremely poorly written and does not convey the information. |
||||||
| TOTAL Points Possible |
100 |
Stage 2: Requirements Specification 5
Data Flow Diagram (DFD) Tips
Processes: Verbs
Dataflows: Nouns
Data Store
s: Nouns
External Entities: Nouns
1) Process’s input & output are different
2) Each data store should have at least
one data flow in and one data flow out
3) Each process should have at least one
data flow in and one data flow out
4) All inputs and outputs should be
labeled
5) Processes should have an identifier
(Ex., 1.0, 2.0, etc.)
Process
Process
Process-to-Process
Process Process
Process-to-Process
Process-to-External
Entity
Process
External
Entity
Process-to-External Entity
Process
External
Entity
Data Store
Process-to-Data Store
Process Data Store
Process-to-Data Store
Process
External Entity-to-External Entity
External
Entity
External
Entity
External Entity-to-External Entity
External
Entity
External
Entity
Data Store
Data Store-to-Data Store
Data StoreData Store
Data Store-to-Data Store
Data Store
External Entity-to-Data Store
External Entity-to-Data Store
External
Entity
Data Store
External
Entity
Data Store
External
Entity
Data Store
External Entity-to-Data Store
External
Entity
Data StoreProcess Process
Process-to-Process
Process-to-External Entity
Process
External
Entity
Data Store
Process-to-Data Store
Process
External Entity-to-External Entity
External
Entity
External
Entity
Data Store
Data Store-to-Data Store
Data Store
External Entity-to-Data Store
External
Entity
Data Store
- DFD_Rules.vsdx
Top Process
PEP Case Study 1
IFSM 461: Systems Analysis and Design
Precision Electronic Parts, Inc.
Case Study
Introduction
This case study will be used for a series of staged assignments. It should be thoroughly read and
understood prior to working on any of the assignments.
Setting
Precision Electronic Parts (PEP), Inc., is a small private business that has retained you to assist in the
development of a new billing and payment system and associated processes.
Background
PEP is a small, private specialized electronics company in Kansas. For the past 20 years, it has
manufactured a wide range of precision electronic components and replacement parts for medical
equipment used in hospitals, doctor’s offices, and pharmacies. Last year, the company began building
and delivering custom low voltage motors that reduced electricity costs and made older medical
equipment more environmentally friendly. More recently, PEP has added a new line of more efficient
low voltage motors that can be used in precision equipment outside the healthcare industry.
As a result, PEP is experiencing significant increases in orders for the motors. The manufacturing facility
has been expanded, and the sales and marketing teams have been enlarged. All of this is straining the
Ordering & Shipping Department and the Inventory Management Department, which have received no
increase in personnel. They are meeting the challenge, but the Executive Leadership Team (the CEO,
COO, CFO, and CIO) know that they are only treading water. The Finance Department, however, is
getting further and further behind in their invoice, billing and payment processes. The Business
Administration Department has stepped up to the task, but is at the breaking point.
IT Steering Committee
The IT Steering Committee (ITSC) at PEP is comprised of the Executive Leadership Team, the Senior Vice
President and Vice President.
• Carolyn West is the Chief Executive Officer (CEO). She has been at the company for 11 years. Carolyn
has a background working for and managing electronics companies. Like most CEOs, Carolyn is focused
on the strategic and long-term business health of PEP. She chairs the IT Steering Committee. Carolyn
and the committee members jointly make decisions about IT systems and major organizational business
process changes.
• Tim Uduak, Jr. is the Chief Operating Officer (COO) and the son of founding partner Tim Uduak, Sr. Tim
has been around the company since its inception in one capacity or another, except for four years of
college and a 3-year break to startup his own company. When his startup failed, Tim came back to PEP
as the SVP, Engineering & Manufacturing Operations. Last year, he was promoted to COO. While Tim has
PEP Case Study 2
a strategic focus and is not technology averse, he prefers to solve business challenges with processes
rather than information technology.
• Karl Manley is the Chief Financial Officer (CFO). He has been with the company for 9 years. Karl has a
background in accounting and finance, and is a certified public accountant (CPA). He tends to focus on
the company’s financial health to the exclusion of all other business concerns. While Karl is technology
fluent, he resists new IT purchases unless there is a clear and direct connection made between the
technology investment and improving the company’s financial profile. The Director, Accounts Receivable
(Mary Winston) and the Director, Accounts Payable (Amy Dole) report to the CFO, and together are
responsible for the financial operations of the business.
• Mark Temple is the Chief Information Officer (CIO) and head of the IT Department. He provides all IT
services to PEP. Prior to being hired as the CIO, Mark was an IT manager at a large multi-national
corporation responsible for providing IT services to their offices from the headquarters in Lincoln,
Nebraska. While in that position, Mark participated in very structured IT processes, and developed an
appreciation for working with the operational and management divisions to ensure success of IT
projects. When he arrived at PEP, he advised the CEO, COO and CFO that an IT Steering Committee
could help ensure they pursued the most beneficial IT projects. He is your primary point of contact for
dealing with PEP in analyzing their processes and systems.
• Susan Black is the Senior Vice President (SVP), Engineering & Manufacturing Operations and is Tim’s
replacement. Susan has worked for the company for 13 years. She started as a Senior Engineer, and
after six years was promoted to Director, Engineering, where she spearheaded the successful research
and development of the low voltage motors. Susan is a champion of information technology as long as it
is clearly focused on the core business.
• Jason Udo is the Vice President (VP), Business Administration. He oversees all departments, except
Engineering & Manufacturing, Finance, and IT. His responsibilities include key support functions such as
Sales, Marketing, Ordering & Shipping, Inventory, and Human Resources.
The ITSC has adopted the IT governance processes recommended by the CIO. They review proposals for
IT investments and determine where to invest their limited funds. Each of the members has particular
areas of interest, but all of them are focused on reducing the overall cost of running the business,
increasing sales, and managing the cost of IT for the company. The ITSC has established a series of
checkpoints at which they make go/no-go decisions on IT projects. At these decision points the
following documents are reviewed by the ITSC:
Preliminary Investigation Report – describes the problem/opportunity, identifies benefits of
a new system, and reports on various aspects of feasibility of the proposed project.
Requirements Specification – documents the requirements to be fulfilled by the proposed
system.
Systems Design Specification – translates the requirements into a logical design for the
proposed system.
Final System Report – compiles previous documents and lays out the way ahead if the
project is approved and funded.
PEP Case Study 3
As each report is approved, work on the following step begins. This controls the amount of time and
effort put into a request for a system. For example, if the Preliminary Investigation Report is not
accepted by the ITSC, no further work is performed on the system proposal.
Your Task
You are an independent Business and IT Systems Analyst, specializing in developing IT solutions for small
business needs. You have been contracted by the CIO to prepare the documentation required for the
ITSC as they consider replacing the information systems associated with operations, business
administration, and finance. Due to the backlog in the billing and payment processes, the ITSC wants to
start by replacing the current customer billing and payment system and processes. However, the ITSC
requires assurance that a new billing and payment system and processes can be interfaced with other
new IT systems and updated business processes as needed. While there is currently no money in the
budget allocated to replacing or upgrading these systems, the executives are committed to moving the
company forward and improving PEP’s ability to manage its growing business efficiently and effectively.
Your Activities
After interviewing each member of the ITSC, you have collected the following information regarding the
invoice, billing and payment processes and needs:
• Customer billing is handled by the Invoicing Department, which reports to the VP, Business
Administration.
• Customer payments are handled by the Accounts Receivable Department, which reports to
the
CFO.
• Customer billing and payments are managed and recorded in an in-house developed Microsoft
Access based solution. The solution was developed by the IT Department and is housed on a
server controlled and managed by the IT Department. The solution is updated on request from
the Invoicing and Accounts Receivable Departments.
• The Sales Department works with Invoicing to establish new customer accounts and update
and close existing accounts as needed.
• The Ordering & Shipping Department sends a monthly report to Invoicing where the products
ordered and shipped and their codes are entered into the invoicing module. Pricing is computed
based on the product codes and quantities entered.
• Invoicing is responsible for adding, updating, and maintaining the product codes and pricing
used by the invoicing database on the 15th of each calendar month. The monthly report
containing the updates is provided by the Marketing Department.
• Invoicing generates and mails customer bills on the last business day of each calendar month.
• Customer payments (lump sum) are due by the 10th of each calendar. Customers send the
payments to Accounts Receivable. Accounts Receivable is responsible for updating customer
account records when the payments are received.
• Invoicing is responsible for identifying accounts that are 30 days, 60 days or more overdue.
These reports are sent to Accounts Receivable and Sales. Accounts Receivable handles all
collections.
• There is a 2% fee added to all invoices that are 30 days or more overdue.
PEP Case Study 4
• Accounts Receivable notifies the Sales Department to assist with customers who are 60 days
or more delinquent. Ordering & Shipping is also notified so that no further shipments are made
until the outstanding invoice is paid in full. These situations are rare.
• Installation services are offered as a fixed price fee for small businesses (doctor’s offices,
individually owned pharmacies, etc.). Larger installations (hospitals, chain pharmacies,
pharmaceutical manufacturers, etc.) are billed on a pre-defined hourly rate.
• Volume discounts are not currently offered, but Marketing is planning to offer this discount
within the next six (6) months because the low voltage motors are increasingly being ordered in
quantities of five (5) or more. The following volume discounts will be offered:
o 5 or more: 2%
o 10 or more: 5%
o 25 or more: 10%
• Electronic invoicing via email is not currently offered, but Marketing and Invoicing plan to offer
this feature within the next six (6) months.
• Electronic payment to a lockbox account is not currently offered, but Marketing and Accounts
Receiving plan to offer this feature within the next six (6) months.
• The customer account data elements currently include:
o Customer Organization Name
o Customer Street Address
o Customer City
o Customer State
o Customer Zip Code + 4
o Primary Contact First Name
o Primary Contact Last Name
o Primary Contact Phone Number
o Primary Contact Email Address
o Secondary Contact First Name
o Secondary Contact Last Name
o Secondary Contact Phone Number
o Secondary Contact Email Address
o Products Ordered
o Product Ordered Date
o Products Shipped
o Product Ship Date
o Quantity
o Product Pricing
o Calculated Price (Calculated Field)
o Amount Due (Calculated Field)
o Amount Paid
o Date Paid
o Amount 30 Days Overdue (Calculated Field)
o Amount 60 Days Overdue (Calculated Field)
o Amount Greater Than 60 Days Overdue (Calculated Field)
o 2% Overdue Amount (Calculated Field)
• The customer account data elements required for near-term plans include:
PEP Case Study 5
o Quantity Discount (Calculated Field)
o Electronic Invoicing (Check Box)
o Electronic Payment (Check Box)
• Paper invoices currently contain the following data elements:
o Unique Serialized Invoice Number (System Generated?)
o Customer Organization Name
o Customer Street Address
o Customer City
o Customer State
o Customer Zip Code + 4
o Products Ordered
o Product Ordered Date
o Products Shipped
o Product Ship Date
o Quantity
o Product Pricing
o Calculated Price (Calculated Field)
o Amount Due (Calculated Field)
o Amount 30 Days Overdue (Calculated Field)
o Amount 60 Days Overdue (Calculated Field)
o Amount Greater Than 60 Days Overdue (Calculated Field)
o 2% Overdue Amount (Calculated Field)
• Paper invoice data points required for near-term plans include:
o Volume Discount (Calculated Field)
o Electronic Invoicing (Yes or No)
o Electronic Payment (Yes or No)
• When electronic invoices are offered, the same current and near-term data elements as
shown above will be included.
You have also documented the following additional considerations:
• All customer, invoicing, and payment data must be secured, but accessible to those
departments and personnel who have a need to know.
• PEP requires the ability to generate a receipt automatically at the time payments are
recorded. The receipt will be sent electronically to the organization’s primary contact email
address. The receipt must contain:
o Unique Serialized Invoice Number
o Customer Organization Name
o Customer Street Address
o Customer City
o Customer State
o Customer Zip Code + 4
o Amount Paid
o Date Paid
PEP Case Study 6
o Amount Outstanding
• The following company entities need to be able to generate their own reports as needed:
o COO
o CFO
o Director, Accounts Receivable
o Accounts Receivable Managers & Staff
o Director, Accounts Payable
o SVP, Engineering & Manufacturing Operations
o VP, Business Administration
o Invoicing Managers & Staff
o Sales Managers & Staff
o Marketing Managers & Staff
o Ordering & Shipping Managers & Staff
Your Deliverables
Your first task is to develop the Preliminary Investigation Report (PIR), which will examine the
problems/opportunities, identify benefits of a new system, and report on various aspects of feasibility of
such a project. You will draw upon the background and other information provided above to develop
the PIR. If that Report is accepted by the ITSC, you will analyze and organize the requirements you have
collected into a Requirements Specification. After receiving approval of the Requirements Specification,
you will develop the Systems Design Specification, which will translate the requirements into a logical
design of the proposed system. With a further decision to proceed, you will then develop the Final
System Report, which will combine your previously developed documents and lay out the way ahead if
the project is approved and funded.
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 2: Requirements 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 assignment should be reviewed and used as you proceed with Stage 2.
Purpose of this Assignment
This assignment gives you the opportunity to specify clear and concise requirements, including the use of data and process models, for a system that enables a productive change in a way the business is conducted. 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
· perform modeling to assist with analysis and decision making
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 Preliminary Investigation Report (Stage 1 assignment), the next step is to identify the requirements for a system, documenting them in the Requirements Specification document. The purpose of the Requirements Specification is to clearly define what the proposed system will do in non-technical user-oriented language. It should identify what data is entered into the system, what output is required, what processes the system should perform, what protections and controls are needed, what performance is expected, and what the business continuity needs are. In order to clearly express the requirements, data and process models are used to communicate how the system should work.
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 information provided in the case study and the Case Study Interview Questions discussion to create a checklist of functional and technical requirements and the data and process models listed below. Using the format
and resources below,
list three requirements for
each
of the areas shown in I and II. Then, create two diagrams to illustrate the scope of the system: the
context diagram and the
use case diagram. Then, create the
data flow diagram to illustrate the flow of the inputs and outputs listed as functional requirements in section I. You should then select a
process or process step (from those listed in section I.b – processing requirements)
that has some decision associated with it to create the three process models listed below. The same process/process step will be used for all three of the process models; they are just different ways to represent the process and the decision involved. Approximate lengths for each section are provided as a guideline; be sure to provide all pertinent information. References in brackets are to the two e-textbooks (by authors Jawahar and Conger) used in this class and the page on which the explanatory information begins.
Use the examples listed in the brackets to develop your diagrams. [Note: Every diagram/model needs to be customized for the course scenario. Simply copying the example diagram(s) with little or no customization will result in a zero for that diagram.] There are several different methodologies using different symbols, but your diagrams will be graded for compliance with the examples listed. You are required to use the symbols and diagramming methods illustrated in the examples, and follow any rules for the diagram in the sources listed with each diagram.
Requirements Specification
Background: First, provide a brief description of your proposed system to establish the context for the Requirements Specification.
I.
Functional Requirements
. The input-processing-output requirements must relate to each other. Start with three outputs you expect from the system, then determine what inputs are needed to create each of those outputs, and finally specify what processing needs to occur for each input to create the output. At least one of your processing requirements must have a decision associated with it so it can be used for the
Process Models
below. You should have a complete statement for each requirement, and each requirement should be numbered within the category. (introductory paragraph and list of 9 inter-related requirement statements) [Jawahar, p. 95 and the Week 3 Content, including reading on IEEE Software Requirements Specifications] [another source of ideas and concepts is:
http://www.slideshare.net/ALATechSource/sample-project-requirements-document-library-blog
]
a. Output requirements. List three different reports, results of a calculation, or other outputs.
i. Output #1
ii. Output #2
iii. Output #3
b. Input requirements.
i. List the main data elements required to create output #1
ii. List the main data elements required to create output #2
iii. List the main data elements required to create output #3
c. Processing requirements (at least one must have a decision associated with it)
i. Processing required to create Output #1
ii. Processing required to create Output #2
iii. Processing required to create Output #3
II.
Technical Requirements
(introductory paragraph and 3 requirement statements listed for each area below) [Jawahar, p. 95]
a. Security requirements
b. System control requirements
c. Performance requirements
d. Business continuity requirements (backup, restart, recovery)
III.
System Scope Diagrams
(introductory/explanatory paragraph and 2 diagrams) [a good explanation and example is at
]
a. Context Diagram [explanation in Conger, p.228; use example in Conger, p.229. Figure 7.2]
b. Use Case Diagram [use example in weblink above]
IV.
Data Flow Diagram
(introductory/explanatory paragraph and diagram) [Week 4 Content module and weblinks]
a. Data Flow Diagram [explanation in Conger, p.228; use example in Conger, p.230, Figure 7.3; use the tips located in the assignment folder (DFD_Tips )]
V. Process Models (introductory/explanatory paragraph and 3 items below) [Week 4 Systems Analysis Course Module]
a. Structured English [use example in Systems Analysis Course Module, Process Description Tools]
b. Decision Table [use example in Systems Analysis Course Module, Process Description Tools]
c. Decision Tree [use example in Systems Analysis Course Module, Process Description Tools]
Submitting Your Assignment
Submit your 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- 10 0% Far Above Standards |
80-89% Above Standards |
70-79% Meets Standards |
60-69% Below Standards |
< 60% Well Below Standards |
Possible Points |
||||||
| Functional Requirements |
16- 18 Points Three requirements for input, output and processing are clearly stated and correctly inter-related; are logically derived from the Case Study, and demonstrate a sophisticated level of writing. |
14-15 Points Three requirements for input, output and processing are clearly stated and correctly inter-related; are logically derived from the Case Study, and demonstrate a clear understanding of the course concepts. |
12 -13 Points Three requirements for input, output and processing are stated and are inter-related; and are derived from the Case Study. |
10-11 Points May present fewer than three requirements for input, output and processing, or they may not be inter-related; and/or may not be derived from the Case Study. |
0-9 Points Functional requirements are not included, or demonstrate little effort. |
18 | |||||
| Technical Requirements |
11-12 Points Three requirements each for security, system control, performance, and business continuity are clearly stated and are logically derived from the Case Study, and demonstrate a sophisticated level of writing. |
9-10 Points Three requirements each for security, system control, performance, and business continuity are clearly stated and are logically derived from the Case Study, and demonstrate effective writing. |
8 Points Three requirements each for security, system control, performance, and business continuity are provided and are appropriate to the Case Study. |
7 Points Fewer than three requirements each for security, control, performance and business continuity may be provided, and/or they may not be appropriate to the Case Study. |
0- 6 Points Functional requirements are not provided, or little effort is demonstrated. |
12 | |||||
| System Scope Diagrams |
9-10 Points
Context diagram and Use Case diagram are correctly constructed, logical, appropriate to the Case Study and demonstrate a sophisticated level of analysis. |
8 Points
Context diagram and Use Case diagram are correctly constructed, logical, appropriate to the Case Study and demonstrate accurate analysis. |
7 Points
Context diagram and Use Case diagram are provided, and are appropriate to the Case Study. |
6 Points
Both Context and Use Case diagrams may not be provided, and/or may not be appropriate to the Case Study. |
0-5 Points Both Context and Use Case diagrams are not provided, or little effort is demonstrated. |
10 | |||||
| Data Flow Diagram |
9-10 Points
Data Flow Diagram is correctly constructed, logical, appropriate to the Case Study and demonstrate a sophisticated level of analysis. |
8 Points
Data Flow Diagram is correctly constructed, logical, appropriate to the Case Study and demonstrate accurate analysis. |
7 Points
Data Flow Diagram is provided, and are appropriate to the Case Study. |
6 Points
Data Flow Diagram may not be correctly contructed, and/or may not be appropriate to the Case Study. |
0-5 Points
Data Flow Diagram is not provided, or little effort is demonstrated. |
||||||
| Process Models |
36- 40 Points All three process models – structured English, decision table, and decision tree – are correctly constructed, logical, appropriate to the Case Study and demonstrate a sophisticated level of analysis. All three models describe the same decision process. |
32-35 Points All three process models – structured English, decision table, and decision tree – are correctly constructed, logical, appropriate to the Case Study and demonstrate accurate analysis. All three models describe the same decision process. |
28-31 Points All three process models – structured English, decision table, and decision tree – are provided, and are appropriate to the Case Study. All three models describe the same decision process. |
24-27 Points All three process models may not be provided, may not describe the same decision process, and/or may not be appropriate to the Case Study. |
0-23 Points The three process models are not provided, or little effort is demonstrated. |
40 | |||||
|
Format |
9-10 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. |
8 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. |
7 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. |
6 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-5 Points
Document is extremely poorly written and does not convey the information. |
||||||
| TOTAL Points Possible |
100 |
Stage 2: Requirements Specification 5
Data Flow Diagram (DFD) Tips
Processes: Verbs
Dataflows: Nouns
Data Store
s: Nouns
External Entities: Nouns
1) Process’s input & output are different
2) Each data store should have at least
one data flow in and one data flow out
3) Each process should have at least one
data flow in and one data flow out
4) All inputs and outputs should be
labeled
5) Processes should have an identifier
(Ex., 1.0, 2.0, etc.)
Process
Process
Process-to-Process
Process Process
Process-to-Process
Process-to-External
Entity
Process
External
Entity
Process-to-External Entity
Process
External
Entity
Data Store
Process-to-Data Store
Process Data Store
Process-to-Data Store
Process
External Entity-to-External Entity
External
Entity
External
Entity
External Entity-to-External Entity
External
Entity
External
Entity
Data Store
Data Store-to-Data Store
Data StoreData Store
Data Store-to-Data Store
Data Store
External Entity-to-Data Store
External Entity-to-Data Store
External
Entity
Data Store
External
Entity
Data Store
External
Entity
Data Store
External Entity-to-Data Store
External
Entity
Data StoreProcess Process
Process-to-Process
Process-to-External Entity
Process
External
Entity
Data Store
Process-to-Data Store
Process
External Entity-to-External Entity
External
Entity
External
Entity
Data Store
Data Store-to-Data Store
Data Store
External Entity-to-Data Store
External
Entity
Data Store
- DFD_Rules.vsdx
Top Process
PEP Case Study 1
IFSM 461: Systems Analysis and Design
Precision Electronic Parts, Inc.
Case Study
Introduction
This case study will be used for a series of staged assignments. It should be thoroughly read and
understood prior to working on any of the assignments.
Setting
Precision Electronic Parts (PEP), Inc., is a small private business that has retained you to assist in the
development of a new billing and payment system and associated processes.
Background
PEP is a small, private specialized electronics company in Kansas. For the past 20 years, it has
manufactured a wide range of precision electronic components and replacement parts for medical
equipment used in hospitals, doctor’s offices, and pharmacies. Last year, the company began building
and delivering custom low voltage motors that reduced electricity costs and made older medical
equipment more environmentally friendly. More recently, PEP has added a new line of more efficient
low voltage motors that can be used in precision equipment outside the healthcare industry.
As a result, PEP is experiencing significant increases in orders for the motors. The manufacturing facility
has been expanded, and the sales and marketing teams have been enlarged. All of this is straining the
Ordering & Shipping Department and the Inventory Management Department, which have received no
increase in personnel. They are meeting the challenge, but the Executive Leadership Team (the CEO,
COO, CFO, and CIO) know that they are only treading water. The Finance Department, however, is
getting further and further behind in their invoice, billing and payment processes. The Business
Administration Department has stepped up to the task, but is at the breaking point.
IT Steering Committee
The IT Steering Committee (ITSC) at PEP is comprised of the Executive Leadership Team, the Senior Vice
President and Vice President.
• Carolyn West is the Chief Executive Officer (CEO). She has been at the company for 11 years. Carolyn
has a background working for and managing electronics companies. Like most CEOs, Carolyn is focused
on the strategic and long-term business health of PEP. She chairs the IT Steering Committee. Carolyn
and the committee members jointly make decisions about IT systems and major organizational business
process changes.
• Tim Uduak, Jr. is the Chief Operating Officer (COO) and the son of founding partner Tim Uduak, Sr. Tim
has been around the company since its inception in one capacity or another, except for four years of
college and a 3-year break to startup his own company. When his startup failed, Tim came back to PEP
as the SVP, Engineering & Manufacturing Operations. Last year, he was promoted to COO. While Tim has
PEP Case Study 2
a strategic focus and is not technology averse, he prefers to solve business challenges with processes
rather than information technology.
• Karl Manley is the Chief Financial Officer (CFO). He has been with the company for 9 years. Karl has a
background in accounting and finance, and is a certified public accountant (CPA). He tends to focus on
the company’s financial health to the exclusion of all other business concerns. While Karl is technology
fluent, he resists new IT purchases unless there is a clear and direct connection made between the
technology investment and improving the company’s financial profile. The Director, Accounts Receivable
(Mary Winston) and the Director, Accounts Payable (Amy Dole) report to the CFO, and together are
responsible for the financial operations of the business.
• Mark Temple is the Chief Information Officer (CIO) and head of the IT Department. He provides all IT
services to PEP. Prior to being hired as the CIO, Mark was an IT manager at a large multi-national
corporation responsible for providing IT services to their offices from the headquarters in Lincoln,
Nebraska. While in that position, Mark participated in very structured IT processes, and developed an
appreciation for working with the operational and management divisions to ensure success of IT
projects. When he arrived at PEP, he advised the CEO, COO and CFO that an IT Steering Committee
could help ensure they pursued the most beneficial IT projects. He is your primary point of contact for
dealing with PEP in analyzing their processes and systems.
• Susan Black is the Senior Vice President (SVP), Engineering & Manufacturing Operations and is Tim’s
replacement. Susan has worked for the company for 13 years. She started as a Senior Engineer, and
after six years was promoted to Director, Engineering, where she spearheaded the successful research
and development of the low voltage motors. Susan is a champion of information technology as long as it
is clearly focused on the core business.
• Jason Udo is the Vice President (VP), Business Administration. He oversees all departments, except
Engineering & Manufacturing, Finance, and IT. His responsibilities include key support functions such as
Sales, Marketing, Ordering & Shipping, Inventory, and Human Resources.
The ITSC has adopted the IT governance processes recommended by the CIO. They review proposals for
IT investments and determine where to invest their limited funds. Each of the members has particular
areas of interest, but all of them are focused on reducing the overall cost of running the business,
increasing sales, and managing the cost of IT for the company. The ITSC has established a series of
checkpoints at which they make go/no-go decisions on IT projects. At these decision points the
following documents are reviewed by the ITSC:
Preliminary Investigation Report – describes the problem/opportunity, identifies benefits of
a new system, and reports on various aspects of feasibility of the proposed project.
Requirements Specification – documents the requirements to be fulfilled by the proposed
system.
Systems Design Specification – translates the requirements into a logical design for the
proposed system.
Final System Report – compiles previous documents and lays out the way ahead if the
project is approved and funded.
PEP Case Study 3
As each report is approved, work on the following step begins. This controls the amount of time and
effort put into a request for a system. For example, if the Preliminary Investigation Report is not
accepted by the ITSC, no further work is performed on the system proposal.
Your Task
You are an independent Business and IT Systems Analyst, specializing in developing IT solutions for small
business needs. You have been contracted by the CIO to prepare the documentation required for the
ITSC as they consider replacing the information systems associated with operations, business
administration, and finance. Due to the backlog in the billing and payment processes, the ITSC wants to
start by replacing the current customer billing and payment system and processes. However, the ITSC
requires assurance that a new billing and payment system and processes can be interfaced with other
new IT systems and updated business processes as needed. While there is currently no money in the
budget allocated to replacing or upgrading these systems, the executives are committed to moving the
company forward and improving PEP’s ability to manage its growing business efficiently and effectively.
Your Activities
After interviewing each member of the ITSC, you have collected the following information regarding the
invoice, billing and payment processes and needs:
• Customer billing is handled by the Invoicing Department, which reports to the VP, Business
Administration.
• Customer payments are handled by the Accounts Receivable Department, which reports to
the
CFO.
• Customer billing and payments are managed and recorded in an in-house developed Microsoft
Access based solution. The solution was developed by the IT Department and is housed on a
server controlled and managed by the IT Department. The solution is updated on request from
the Invoicing and Accounts Receivable Departments.
• The Sales Department works with Invoicing to establish new customer accounts and update
and close existing accounts as needed.
• The Ordering & Shipping Department sends a monthly report to Invoicing where the products
ordered and shipped and their codes are entered into the invoicing module. Pricing is computed
based on the product codes and quantities entered.
• Invoicing is responsible for adding, updating, and maintaining the product codes and pricing
used by the invoicing database on the 15th of each calendar month. The monthly report
containing the updates is provided by the Marketing Department.
• Invoicing generates and mails customer bills on the last business day of each calendar month.
• Customer payments (lump sum) are due by the 10th of each calendar. Customers send the
payments to Accounts Receivable. Accounts Receivable is responsible for updating customer
account records when the payments are received.
• Invoicing is responsible for identifying accounts that are 30 days, 60 days or more overdue.
These reports are sent to Accounts Receivable and Sales. Accounts Receivable handles all
collections.
• There is a 2% fee added to all invoices that are 30 days or more overdue.
PEP Case Study 4
• Accounts Receivable notifies the Sales Department to assist with customers who are 60 days
or more delinquent. Ordering & Shipping is also notified so that no further shipments are made
until the outstanding invoice is paid in full. These situations are rare.
• Installation services are offered as a fixed price fee for small businesses (doctor’s offices,
individually owned pharmacies, etc.). Larger installations (hospitals, chain pharmacies,
pharmaceutical manufacturers, etc.) are billed on a pre-defined hourly rate.
• Volume discounts are not currently offered, but Marketing is planning to offer this discount
within the next six (6) months because the low voltage motors are increasingly being ordered in
quantities of five (5) or more. The following volume discounts will be offered:
o 5 or more: 2%
o 10 or more: 5%
o 25 or more: 10%
• Electronic invoicing via email is not currently offered, but Marketing and Invoicing plan to offer
this feature within the next six (6) months.
• Electronic payment to a lockbox account is not currently offered, but Marketing and Accounts
Receiving plan to offer this feature within the next six (6) months.
• The customer account data elements currently include:
o Customer Organization Name
o Customer Street Address
o Customer City
o Customer State
o Customer Zip Code + 4
o Primary Contact First Name
o Primary Contact Last Name
o Primary Contact Phone Number
o Primary Contact Email Address
o Secondary Contact First Name
o Secondary Contact Last Name
o Secondary Contact Phone Number
o Secondary Contact Email Address
o Products Ordered
o Product Ordered Date
o Products Shipped
o Product Ship Date
o Quantity
o Product Pricing
o Calculated Price (Calculated Field)
o Amount Due (Calculated Field)
o Amount Paid
o Date Paid
o Amount 30 Days Overdue (Calculated Field)
o Amount 60 Days Overdue (Calculated Field)
o Amount Greater Than 60 Days Overdue (Calculated Field)
o 2% Overdue Amount (Calculated Field)
• The customer account data elements required for near-term plans include:
PEP Case Study 5
o Quantity Discount (Calculated Field)
o Electronic Invoicing (Check Box)
o Electronic Payment (Check Box)
• Paper invoices currently contain the following data elements:
o Unique Serialized Invoice Number (System Generated?)
o Customer Organization Name
o Customer Street Address
o Customer City
o Customer State
o Customer Zip Code + 4
o Products Ordered
o Product Ordered Date
o Products Shipped
o Product Ship Date
o Quantity
o Product Pricing
o Calculated Price (Calculated Field)
o Amount Due (Calculated Field)
o Amount 30 Days Overdue (Calculated Field)
o Amount 60 Days Overdue (Calculated Field)
o Amount Greater Than 60 Days Overdue (Calculated Field)
o 2% Overdue Amount (Calculated Field)
• Paper invoice data points required for near-term plans include:
o Volume Discount (Calculated Field)
o Electronic Invoicing (Yes or No)
o Electronic Payment (Yes or No)
• When electronic invoices are offered, the same current and near-term data elements as
shown above will be included.
You have also documented the following additional considerations:
• All customer, invoicing, and payment data must be secured, but accessible to those
departments and personnel who have a need to know.
• PEP requires the ability to generate a receipt automatically at the time payments are
recorded. The receipt will be sent electronically to the organization’s primary contact email
address. The receipt must contain:
o Unique Serialized Invoice Number
o Customer Organization Name
o Customer Street Address
o Customer City
o Customer State
o Customer Zip Code + 4
o Amount Paid
o Date Paid
PEP Case Study 6
o Amount Outstanding
• The following company entities need to be able to generate their own reports as needed:
o COO
o CFO
o Director, Accounts Receivable
o Accounts Receivable Managers & Staff
o Director, Accounts Payable
o SVP, Engineering & Manufacturing Operations
o VP, Business Administration
o Invoicing Managers & Staff
o Sales Managers & Staff
o Marketing Managers & Staff
o Ordering & Shipping Managers & Staff
Your Deliverables
Your first task is to develop the Preliminary Investigation Report (PIR), which will examine the
problems/opportunities, identify benefits of a new system, and report on various aspects of feasibility of
such a project. You will draw upon the background and other information provided above to develop
the PIR. If that Report is accepted by the ITSC, you will analyze and organize the requirements you have
collected into a Requirements Specification. After receiving approval of the Requirements Specification,
you will develop the Systems Design Specification, which will translate the requirements into a logical
design of the proposed system. With a further decision to proceed, you will then develop the Final
System Report, which will combine your previously developed documents and lay out the way ahead if
the project is approved and funded.
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..
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
