Stage 4
1
PEP Inc. Requirement Specification
Ayomide Ajayi
University of Maryland Global Campus
IFSM 461
Matthew Kennedy
11/16/2021
PEP Inc. Requirement Specification
After the problem analysis conducted in Precision Electronics Part, Inc. on the increased challenges in billing and payments caused by increased organization operations, the company has proposed for development of a new system that will provide solutions to these problems. The system will help the PEP, Inc. to conduct its billing and payment processes in a more efficient and convenient way. As a system Business and IT analyst I have come up with requirement specifications and designs that will aid in the development of the new system. First of all, we look at the system requirements and outputs of the proposed system.
1. Functional requirements
A. Output requirements
· Billing customers
· Paying customers
· Customer Invoicing
B. Input requirements
· Customer credits and debits
· Customer invoices
· Customer transactions and supplies
C. Processing requirements
· Billing
· Payments
· Invoicing
2. Technical Requirements
A. Security Requirements
· Sales department and invoicing establish, update, and close customer accounts as needed
· The system must secure all customer, invoicing, and payment data
· All customer, invoicing, and payment data made available to only authorized members
B. System Control Requirements
· 2% added to all invoices overdue for 30days or more
· Identiftying all accounts that are 30days and 60 days overdue
· Customer payments are due by the 1oth of each calender
C. Performance Requirements
· Invoicing managers generates and mails customer bills
· Invoicing managers adds, updates, maintains the product codes and pricing used in invoicing
· Sales departments with invoicing establishes new customers
D. Business Continuity Requirements
· Electronic invoicing via email in the next six months
· Volume discounts in the next six months
· Electronic payments in the next six months
Content Diagram and Use Case Diagram
Content and Use Case Diagrams are pictorial representation of all activities that are carried out in a proposed system to be developed in an organization. These diagrams are meant to describe/represent all user transactions with a system and vice versa with all activities indicated in an arrow representation pointing from the source of the action (Software, 2019). The following two diagrams show a context diagram and Use Case diagrams respectively.
Fig 1.1: Content Diagram
Fig 1.2: Use Case Diagram
A Data Flow Diagram
A data-flow diagram is a way of representing a flow of data through a process or a system. The DFD also provides information about the outputs and inputs of each entity and the process itself. The following is a Data Flow Diagram representing the flow of data of the PEP, Inc. Billing and Payment system
Fig 1.3: Data Flow Diagram
Start
No
Accounts
Check
Stop
Volume discounts
Electronic Payments
Electronic Invoicing and mailing
Sent reports
Option
Yes
Payments
Valid
Billing and Invoicing
Establish new customers Accs.
Process Models
A software process model is an abstraction of the software development process. The models specify the stages and order of a process. In other words, it is the representation of the order of activities of the process and the sequence in which they are performed during the project development. The following diagram is a process diagram of waterfall process model
Requirement Analysis
System design
Implementation
Deployment and Maintenance
Testing
A. Structured English
Structured English is the use of the English language with the syntax of structured programming to communicate the design of a computer program to non-technical users by breaking it down into logical steps using straightforward English words.
IF requirement analysis is complete THEN
Continue to system design phase
ELSE
Repeat requirement analysis phase
IF System Design Phase is complete THEN
Proceed to Implementation phase
ELSE
Repeat Design Phase
IF Implementation Phase is Complete THEN
Proceed to testing phase
ELSE
Repeat Implementation phase
IF Testing Phase is complete THEN
Proceed to deployment and maintenance phase
ELSE
Repeat testing phase
ENDIF
ENDIF
ENDIF
ENDIF
EXIT
B. Decision table
A decision table is the tabular representation of several input values, cases, rules, and test conditions. The Decision table is a highly effective tool utilized for both requirements management and complex software testing. Through this table, we can check and verify all possible combinations of testing conditions.
|
Process Conditions |
True/Yes |
False/No |
|
Requirement analysis is complete |
1/yes |
__ |
|
System Design complete |
1/yes |
__ |
|
Implementation phase complete |
1/yes |
__ |
|
Testing phase complete |
1/yes |
__ |
|
Deployment and maintenance |
1/yes |
|
C. Decision Tree
A decision tree is a very specific type of probability tree that enables you to make a decision about some kind of process
Project Development
Implementation
Testing
Requirement Analysis
Testing
Implementation
Deployment and Maintenance
System Design
References
Software, J. (2019). Defining Project Scope | Context and Use Case Diagrams. Jama Software. https://www.jamasoftware.com/blog/defining-project-scope-context-use-case-diagrams/
Krüger, N. (2018). How to Write a Software Requirements Specification (SRS Document). Perforce Software. Retrieved November 14, 2021, from https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-document#:~:text=A%20software%20requirements%20specification%20is