Stage 4

profileAuztina
Stage2_AyomideAjayiResubmission1.docx

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