Requirements document for biotech company

Requirements Document: Setting up a custom ERP System for a Biotech Company

BHATT, PRANAV – 82326PATEL, AXHAY 83061KHAN, MEHNAZ 83060

VENUGOPAL, KARTHIKEYAN 12200256BADIANI, DIMPLE 81049

SIVANANDI, KARTHIKEYAN12200010KUMAR, AVDESH 84201

INTERNATIONAL TECHNOLOGICAL UNIVERSITY

SEN 941 Software Engineering

Fall 2013

Document Version 1.0Last Update: December 16, 2013

1

Acknowledgements

We would like to thank Dr. Richard Riehle, who helped us understand in detail how togather and document software requirements to engineer technologyreliant products. Wewould also like to thank our family members who connected with us as end users enablingus to gather requirements and provide us with an understanding of how ERP systems andbiotech companies work. Without these two facets, our documentation would not havebeen complete. We would also like to thank the International Technological University’sstaff and faculty for helping us every step of the way enabling us to be better students andbecome more collaborative.

2

Work Statement

This project involves taking a small startup biotech company that primarily relies onpaperwork to conduct its business and providing it with an information technology solution.Our goal is to set up a basic and costeffective ERP system customized to theorganization’s needs by providing a system that enables the organization to take inpurchase orders and be able to generate invoices for delivered goods.

3

Revision History

Date Version Author Description

10/22/2013

0.1 Pranav Bhatt Document created

10/23/2013

0.2 Pranav Added Materials Management SystemRequirements documented and Use Casediagram added

11/3/2013

0.3 Dimple Added Sales order and vendor managementsystem Use Case diagram

11/5/2013

0.4 Mehnaz Added Concept definition, context descriptionand test plan

11/5/2013

0.5

11/1/2013

0.6 Pranav Added work statement, vision document, systemarchitecture; use cases and activity diagram formaterials management system

11/11/2013

0.7 Dimple Added activity diagram for sales order andvendor management system

11/12/2013

0.8 Pranav Added class diagram, updated use casediagram and activity diagram for materialsmanagement and waste management

11/27/2013

0.9 Avdhesh Added Use Case diagram of SOP , IssueTracking and Use cases Summary.

12/16/2013

1.0 Pranav Added screenshots of implemented work usingFileMaker Pro AdvancedTM

4

Table of Contents 11. Concept Definition

2. Context Description

3. Vision Document

4. Project Schedule

5. Stakeholders

6. System Architecture

7. Business Requirements7.1. Functional Requirements7.2. Non-Functional Requirements

8. System Design

8.1. System 1

8.2. System 2

9. Use Case

10. Activity Diagram

11. Sequence Diagram

12. Database Overview

13. Test Plan

14. Implemented Interface

5

1. Concept Definition

We intend to create a custom ERP for our customer, a start up biotech company that has

needs to digitize/automate its production and sales processes such that they can be easily

updated and managed. There are three modules included vendor and inventory

management, manufacturing process, and sales & distribution. The product is intended for

a startup company that is in the stages where it requires automation to manage its

business. The system architecture will be similar to other ERP systems where there is a

procure to pay systems for vendor management from whom products and services are

obtained as well as a sales and distribution system.

The company includes some functional requirements:

i) Sales Order and Vendor Management System: includes logon creation, customer ID

generation, customer registration, membership alteration, material management, order

placement, order status management, material purchase, material receival, material

delivery, delivery scheduling, order processing.

ii) Material Management System: includes production planning description, allowing user

to enter and view standard operating procedures, issue tracking, waste disposal system

description.

iii) Shipping and Invoicing System: includes product availability, time estimation of

6

purchased material, billing invoice, credit history, issue management of delivery good,

stock status update, customer payment confirmation receipt.

This project will be using a COTS analysis that will help determine the base ERP

technology to use for the customer’s requirements and testing will be planned on the basis

of Scenario driven testing approach.

2. Context Description

The project is to create a custom ERP for our customer, a start up biotech company that

has needs to digitize/automate its production and sales processes such that they can be

easily updated and managed. It is fully integrated, comprehensive business management

solution which boasts functionality across all departments and office locations. And

because the solution works from one central database,it really can give a complete unified

picture of all business.

It includes the entire modules that needs to automate from entire business from Accounting

and Finance, Purchase and Operations, Sales, Administrations, Inventory and

Distributions, Productions and Reporting.

Listed below are some of the core modules:

7

Inventory Management: handles inventory levels, item management, price lists,

special price agreements, transfers, and picking and packing of inventory for

shipment.

Material Management System: includes production planning description that

define multi level bills of materials (BOMs) and create work orders.

Invoicing System: helps create price quotes, enter customer orders and manage

all invoices and accounts receivables.

3. Vision Document

Vision: We intend to create a custom ERP for our customer, a start up biotech company

that has needs to digitize/automate its production and sales processes such that they can

be easily updated and managed.

Product Overview: The first iteration of the ERP will customize three modules vendor

and inventory management, manufacturing process and sales and distribution. An update

will add enhanced features as well as add the accounting module to automate the process

even further. Which ERP to use as a base (e.g. Oracle or SAP) will be done via COTS

analysis following requirements engineering but before implementation.

8

User/Market Demographics: This product is intended for a startup company that is in the

stages where it requires automation to manage its business.

User Environment: A COTS analysis will help determine the base ERP technology to use

for the customer’s requirements.

Key User Needs: The customer requires management of its inventory, vendors, materials

processing to produce products, manage waste and track its disposal as well as sales and

distribution.

Product Position Statement:

For: Startup companies

Who: have the need to automate their business

That: enables end users to be able to more accurately conduct their business

Unlike: in their current state where paper management is cumbersome and error prone

Our Product: will help reduce errors, be environmentally responsible as well as make work

more efficient.

Assumptions and Dependencies: We will have to perform a COTS analysis to

determine which existing software can best accommodate product requirements and

ensure customization is seamlessly engineered.

9

Document Requirements: This document shall entail product requirements from a

business standpoint. It will have detailed use cases and functionality rendered via activity

diagrams

Licensing, Security, and installing new software: Our team must license the the ERP

from SAP or Oracle. and leverage their APIs to ensure data flow is seamless between the

abovementioned modules.

4. Project Schedule

W0: Project plan 24th September 2013

Hello Team,

Here is the layout of what we discussed in today's meeting headed by Pranav.

Please find below high level snapshot of what we are going to do in weeks to come which

might change as per demand considering we are operating in agile environment.

W1: Freeze requirements considering it as Version 1

W2: Create high level system flows(activity)/ Use cases

W3: Review and Complete feedback incorporation

W4: Documentation and checkpoint with respect to review

W5: Same as above

10

W6: Same as above

W7: Print documentation and submit

W8:

W.: Week 1.........8

Today, we discussed requirements in more detail with help of Pranav and came up with

notion of putting stuffs in our final Google docs(template embedded) only after approval

from our sub team members. You do have option of creating sub team Google docs for

version control of all the contents you update daily. Any other means/tool to avoid rework

and is mutually understood within the sub team should also work.

We do have new team member named S.Karthikeyan who will be our project mate and

was present in today's meet.

Below is the distribution of the tasks based on the requirements document sent by Pranav

and also attaching it again for reference.

Procurement and Inventory: Mehnaz and Dimple

Materials Processing: Pranav and Avdhesh

Sales and Distribution: V.Karthik, S.Karthik and Axhay

11

Lets rock team 7!

Best Regards,

Axhay Patel

W3: Process flow 15th October 2013

Hello Team,

Here is little bit about today's meet.

Venue: Auditorium

Row: 1

Timings: 5:05 pm 5:15 pm

Members:

Bhatt Pranav

Kumar Avdhesh

Badhiani Dimple

Mehnaz Sanaa

Venugopal Karthik

Patel Axhay

Purpose:

12

Better understanding of high level process flow.

Proceedings:

Process flow was explained by Pranav, punched into notepad of Karthikeyan Venugopal,

curiously participated by Sanaa and Dimple. intuitive thinking by Avdhesh followed by more

clarity from Axhay. Missed Karthik S. today.

Action items:

Every sub team needs to come up with the high level use cases for the their respective

pieces.

We will follow the similar approach of sharing with sub team about the progress and later

with whole team.

Any questions, comments, queries open with 24/7 online support with participation of

stupendous 7 with preference of resolution in Tuesdays project meet.

Cheers,

Axhay Patel

13

W4: Process flow continued 22nd October 2013

Hello Team,


Venue: Auditorium(Column 1 Row 5)

Timings: 5:20 pm to 5:27 pm

Attendees:

Bhatt, Pranav

Kumar, Avdhesh

Sanaa, Mehnaz

Venugopal, Karthik

S., Karthik

Patel, Axhay

Derived Purpose:

Better clarity on high level process flow. Thanks to curiosity from Mehnaz to bring up the

detailed process flow diagram shown by Pranav. Pranav may share SAP ERP link with the

14

whole team.

Proceedings:

It all started with high level plan on way to proceed. Mehnaz wanted to verify Procurement

and Inventory requirements with the team. Pranav suggested to make some changes and

make it look more automated as our sole purpose is to automate the manual process by

giving credit to system. Things are to be looked from systems perspective rather than

personal perspective. Cogently anticipated by Avdhesh, Karthik V/S, Mehnaz and Axhay.

Karthik S. and Karthik V.went through use cases and checked with Axhay in case of next

steps for Sales and Distribution sub team. Details continued in Action items below. Missed

Dimple today.

Action items:

Below is the step wise plan:

Procurement and Inventory team: Mehnaz and Dimple

Mehnaz and Dimple can coordinate the efforts for their part.

1) Refine requirements from Mehnaz to make it appear more automated. Can share it with

the whole team once done with it.

2) Come up with high level use case diagram (Mehnaz/Dimple).

3) Use cases description (Mehnaz/Dimple).

15

Material processing: Pranav and Avdhesh

1) Use case description.

2) Pranav can share SAP ERP link with whole team.

3) Pranav to share the name and link for tool used to create UML diagrams.

Sales and distribution: Karthik V/S, Axhay

1) Axhay/Karthik S. come up with use case description.

2) Karthik V. can be help with activity diagram once use case description finalized later in

project.

Here is link to what Axhay used for free trial 30 day period to create UML diagrams:

http://www.visualparadigm.com/download/vpuml.jsp?edition=pe

Mac users can go to other operating system link and check their compatibility before

installing on their respective OS.

Project pipeline:

Activity diagram after Use case (Diagram and Description).

Class diagram after Activity diagram. To be added as Prof. wants to see this in our

project.

Would be great if use case can be closed. Next week midterm will also have use cases.

16

http://www.google.com/url?q=http%3A%2F%2Fwww.visual-paradigm.com%2Fdownload%2Fvpuml.jsp%3Fedition%3Dpe&sa=D&sntz=1&usg=AFQjCNEMxdAL7p7gzq1JGX-GpqE_ym5dnA



Please let us know in case anything missed.

Cheers,

Axhay Patel

W5: Project layout 29th October 2013

Hello Team,


Venue: Room 102(Column 2 Row 6) starting from right facing class.


Attendees:

Bhatt, Pranav

Badiani, Dimple

17

Sanaa, Mehnaz

Venugopal, Karthik

S., Karthik

Patel, Axhay

Proceedings:

1) Project layout shown to Prof. Richard. He went through all team members to understand

them better.

2) Pranav showed the requirements document to whole team.

3) Some team members had question on document shareability. Karthik V. cleared

confusion.

4) Task distribution for whole team reflected in the requirements document.

5) Axhay’s question on organization chart clarified by Pranav.

6) Sequence diagram to be developed only by sales and distribution team.

Missed Avdhesh today.

Action items:

Please refer the resource oriented task allocation in the requirements document:

18

Just detailing to keep track of progress here as well:

1) Concept definition: Dimple/Mehnaz

2) Context description: Dimple/Mehnaz

3) Vision Document: Pranav

4) Project schedule: Axhay

5) Stakeholders: Pranav

6) System architecture: Pranav

7) Business requirements:

Functional:

Procurement and Inventory: Dimple/Mehnaz

Material Management: Done

Shipping and Invoicing system: Embedded by Axhay

Non functional: Dimple/Mehnaz (It might not be applicable to every sub team).

8) System design: Done

9) Use cases and description:

Procure to Pay/Vendor Management system Dimple/Mehnaz

Material Management/Logistics/Inventory System Pranav/Avdhesh

Shipping/Invoicing System:

Use case diagram: Embedded by Axhay

Use case description: Karthik S./Axhay

10) Activity diagram: Everyone

19

10.1 Production Planning: ????

10.2 Allowing users to enter and view standard operating procedures: ????

10.3 Issue tracking: Avdhesh

10.4 Waste Disposal system: ????

11) Sequence diagram: Karthik/Karthik/Axhay

12) Database overview: Pranav

13) Test plan: Dimple/Mehnaz

Pranav might want to add class diagram at some point as Prof. Richard need concept of

generalization which can be better explained in class diagram.

Here is link to what Axhay used for free trial 30 day period to create UML diagrams:

http://www.visualparadigm.com/download/vpuml.jsp?edition=pe

Mac users can go to other operating system link and check their compatibility before

installing on their respective OS.

Project pipeline:

Activity diagram after Use case (Diagram and Description).

Class diagram after Activity diagram. To be added as Prof. wants to see this in our

project.

Sequence diagram at later stage.

20

http://www.google.com/url?q=http%3A%2F%2Fwww.visual-paradigm.com%2Fdownload%2Fvpuml.jsp%3Fedition%3Dpe&sa=D&sntz=1&usg=AFQjCNEMxdAL7p7gzq1JGX-GpqE_ym5dnA




Cheers,

Axhay Patel

W6: Project tasks review (5th November 2013)

Hello Team,

Wishing you all Happy Diwali to enlighten everyones life with victory of lightness(goodness)

over darkness(ignorance).

Here is little bit summary about today's no meet.

Action items:

Very happy to strike out many of the items already worked up on.

Summary of pending items from requirements document:

21


5) Stakeholders: Avdhesh

7) Non functional: Dimple/Mehnaz (It might not be applicable to every sub team).

9) Use case description:

Procure to Pay/Vendor Management system Dimple/Mehnaz

10) Activity diagram: Everyone


12) Database overview: Pranav


Project pipeline:

Mehnaz has test plan with her now to give justice to that section from only one project

folder lying in the library.

For 10 and 12(generalization in demand), Pranav can give more insight apart from

Activity diagram.

Is there anyone in our group who has the reference project? We might need that to get

context description.

Activity diagram for Procure to Pay, Sales and Distribution system.

Sequence diagram for Sales and Distribution team.


22



Cheers,

Axhay Patel

W7: Project design phase (12th November 2013)

Hello Team,

Happy 111213 usually coming once in a lifetime.

Here is little bit summary about today's meet.

Venue: Room 102(Column 2 Row 6) starting from right facing class.


Attendees:

Bhatt, Pranav

Badiani, Dimple

23

Sanaa, Mehnaz

Venugopal, Karthik

S., Karthik

Patel, Axhay

Action items:

Thanks to Pranav to create the class diagram to give justice to Professors interest. Really

appreciate that attitude to get things done. Came to know another tool that can be used for

creating UML diagrams and pretty handy to use.

http://creately.com/

Very useful tool with no download required and it allows to draw flowcharts and UML

diagrams online. If you sign up which is for free for their trial version, you can even export

and save your work. I really loved it.

There are some changes in summary of pending items from requirements document:


7) Non functional: Dimple/Mehnaz (It might not be applicable to every sub team).

9) Use case description: to be modified for D/M and K/A/K team. Prof suggested to have

24

http://www.google.com/url?q=http%3A%2F%2Fcreately.com%2F&sa=D&sntz=1&usg=AFQjCNGqnA2wIawh4xSwMrGrnXi9jxtNpw

use case description first and then the use case diagram. That sequence needs to be

changed by every team.

10) Activity diagram: D/M , K/A/K



Project pipeline:

D/M team to modify the use case(No verbs as Prof don't want to see any verbs in use

cases) and use case description.

K/A/K team to modify the use case description.

Activity diagram for Procure to Pay, Sales and Distribution system.

Sequence diagram for Sales and Distribution team.




Cheers,

Axhay Patel

25

W8: Project design continued (19th November 2013)

Hello Team,

Here is little bit summary about today's scheduled meet.

Action items:

There are some changes in summary of pending items from requirements document:

9) Use case description: (D/M and P/A team)Sequence of use case description followed

by use case diagram needs to be followed by every team as per suggestion from Prof.

Richard.

10) Activity diagram: Dimple/Mehnaz


Project pipeline:

Pranav to upload the Avdhesh creation of activity and use case diagram in final

document.

Activity diagram for Procure to Pay Inventory system.

Sequence diagram (any volunteers want to sequentialize their approach are more than

welcome to be of service as it relates to all sub team in our project?).

26




Cheers,

Axhay Patel

5. Stakeholders

Person Domain Responsibility

XXX Product Management Review/Approve

XXX System Architecture

Design

Review/Approve

XXX Engineering Manager Review/Approve

XXX Developers Review/Approve

XXX Marketing Lead Review/Approve

27

XXX Legal Review/Approve

XXX QA Review/Approve

XXX QA Manager Review/Approve

XXX Support Team Review/Approve

6. System Architecture

The system architecture will be similar to other ERP systems where there is a procure to

pay systems for vendor management from whom products and services are obtained as

well as a sales and distribution system. Accounting system that manages accounts

payable/receivables/ledger entries, etc. will be a future enhancement.

Sales and Distribution architecture for the biotech company

28

7. Business Requirements

7.1. Functional Requirements

7.1.1 Sales Order and Vendor Management System

1. The Computed System creates a Login for the new customer.

2. The Computed System generates a new customer ID if the customer does not have the

ID.

3. The Computed System registers the new customer ID.

4. The Computed System checks and updates current membership of the existing

customer.

5. The Computed System receives the PO from the Customer.

6. The Computed System checks the customer records and enter products as requested

by the customers.

29

7. The Computed System should check automatically if any services or stocks are

available.

8. The Computed System sends the confirmation and places the order if extra materials

are required.

9. The Computed System generates the sales order and monitors the status of the placed

order.

10. The Computed System should allow users to generate delivery, Postgoods issue and

invoicing documents.

11. The Inventory System checks the product requirements and orders the materials as

needed.

12. The Inventory System receives the Ordered materials.

13. The Inventory System Delivers the materials for which the order has been placed to the

concerned customer.

14. The Inventory System should be linked to accounting system and procure to pay system

to manage endtoend flow (future enhancement).

15. The inventory System should allow users to manage schedule lines to split order for

delivery.

16. The Process System schedules a delivery for the completed order

17. The final order is processed by the system.

18. Any errors in the system/blocks should be notified to the end user.

30

7.1.2 Materials Management System/Logistics View

1. The system will require a separate or joined DB with link to records from Procurement

and Inventory systems

2. Anytime raw materials are used, the P&I DB records will be updated

3. The system will require users to enter information required to update the following

parameters: input material, variables used for mixing raw materials (time, temperature and

mixing recipe template used), output volume/weight, state of the final product (solid/liquid),

product humidity %, yield %, final product weight and QA test results

4. Waste production and disposal inventorying of yield/weight and packaging

5. Tracking of waste disposal shipping to respective locations

6. System shall raise flags/notifications when there are unexpected results being yielded

after materials processing or any errors in the process

7. System shall raise flags/notifications when there are unexpected results being yielded in

waste disposal or any errors in the process

7.1.3 Shipping and Invoicing System

1. The system shall allow input of purchase order number data from partners/end clients

such as volume/weight of product required, name of product required, quantity/size of

product packaging requested, etc.

2. The system should have the availability status display options. Available quantities are

31

determined from receipt elements and stock elements.

3. The system should check for availability of product based on product allocation to

facilitate the distribution of products for certain customers or groups.

4. The system should perform check on required material availability date against

customers requested delivery date.

5. The system should include the time needed to order or produce requested material.

6. The system should have record of sales in particular location for particular product

category.

7. The system should check for the route from shipping point to ship to party location

8. On input of final data after processing materials, the system shall generate an invoice

for billing to the end client

9. The system should check the credit history of the end client to expect on time payment

of distributed goods.

10. If end client credit is an issue, the system shall have the logic to hold off on shipping

until the reimbursement comes through; this will require defining logic that is dynamic

based on trend vs. having admin manually enter variables.

11. Any reimbursement received from the client shall be tallied against the records.

12. Pick the materials on delivery notes as per customer requirement.

13. Post if there is any issues with the goods.

14. Update goods stock status .

15. Display both customer invoice and billing document.

16. After generating the invoice for the customers required items, Post receipt copy for

32

customer payment.

7.2. NonFunctional Requirements

Non Functional requirements are as critical as functional requirements.

These are the key to ensure:

the applications meets performance requirements.

is stable.

7.2.1 Security:

The system detects and reports unauthorized data access, and includes Login

Requirements, Password Requirements, Inactivity Timeouts.

7.2.2 Availability Management:

The system identify cost of business downtime, adverse publicity, business

termination, future business or funding losses, loss of morale.

7.2.3 Service Level Management:

The system establish/functions, operationalize and implements the services.

7.2.4 Generalizing:

The system includes requirements gathering, planning, designing and monitoring.

33

7.2.5 Capacity Management:

The system includes service improvements, proactive changes, etc.

7.2.6 IT Service Continuity Management:

The system process change management, testing, risk analysis, strategy, etc.

7.2.7 Measurable:

Requirements are measured by response time, availability time, etc. Some are

directly measured whereas some by simulation.

7.2.8 Development Process:

Particular approaches to testing is done by separate groups,

7.2.9 Reusability:

Certain percentage of the system are designed generically to support reusability.

7.2.10 Throughput:

The number of transactions per minute or number of computations per minute are

measured.

7.2.11 Cost and delivery dates:

34

May not be negotiable (once the projects starts).

8. System Design

The ERP system shall have a Sales and Distribution module to begin with a Procure to

pay/vendor management system. Accounting will still be handled using existing methods.

Future system enhancements will add the it as an additional module to provide a more

seamless automation.

Sales View of the Enterprise Structure

Logistics View of the Enterprise Structure

35

9. Use Cases

9.1. Sales order and Vendor Management System

Logon Creation:

This use case will create a new login for the customer. it will also check if the login name

already exists and if not the system creates a logon and generates the customer ID.

Membership Alteration:

This use case will check the membership status of the existing customers. If the

membership is expired then it will be updated automatically by the system, and if it is active

no changes will be made. For this use case it is necessary that customer records are

already entered in the database.

Material Management:

This use case is for the management of the materials and confirmation of the order.

Actor Description

Preconditions Customer records must be updated correctly

Database should have details about each

37

customer’s order including materials,

requirements and product details

Postconditions Detailed list of materials required according to

the customer’s needs is generated

Basic Path Computed

System

1. System launches the database and checks for

the customer records

2. System generates the order details of a

specified customer from the database

3. It displays the the customer records

4. The system gets the order details and checks

if any materials required for processing the order

5.If required it will check the availability of

products and create requirements

6. System sends the confirmation and places the

order of extra materials

7. After availability check is performed order is

scheduled accordingly

38

Order Status Management:

In this use case the system generates the sales order and monitors the status of the placed

order. At the end system returns the status of a specific order as required.

Material Receival:

Actor Description

Preconditions Inventory system has access to customer

records

Postconditions System generates a confirmation of the order

placed and receival of the materials

Inventory

Check

System

1. The inventory system has access to the

customer records and obtains information of a

specific order

2. System checks the product requirements and

generates and purchases the required materials

3. Ordered materials are received by the system

4. System delivers the materials for which the

39

order has been already placed to the concerned

customer

Delivery Scheduling:

In this use case the process system has to have access to the order details and check the

order is complete and ready to be delivered. The system schedules a delivery of the

completed order and the delivery date and time of the order is generated by the system.

9.2. Materials Management/Logistics/Inventory System

9.2.1 Production planning

Description: This use case will explore how end users will perform production planning.

40

Production planning requires checking available materials/services, what needs to be

ordered will be sent to P2P system for purchase. Production planning will also involve

doing detailed material planning and resource planning. It will generate a production

planning document/work order document.

Actor Description

Preconditions There should be sales order in the system

without error.

Master data in the database should have

information about materials, inventory, service

contracts, resources

Post Conditions A work order/production document is

generated after planning is completed

41

Basic Path User 1. User launches the materials management

module within the software application

2. User selects the option to create a production

plan

3. Within the planning screen, user should be

able to select from a list of available products to

create a production plan. A future enhancement

will allow creating new templates for production

planning

4. Once a product is selected to be produced,

the subsequent screen will show users the

available materials and services for the duration

when production is intended.

5. User will then be required to assign available

resources to carry out the production

6. Once an assignment is made, the user will have

to generate the work order/production plan

document.

7. System will check if there are any errors such

as lack of materials, services, etc.; if there are

42

errors, an error log is created requesting user to

fix the errors, else go to next step

8. If no errors are generated, system will generate

the document and transmit it to necessary

personnel and send a copy of the document to the

production manager and update the document

queue in the system

9.2.2 Allowing users to enter and view standard operating procedures

This use case will explore how end users can either view existing SOPs or create a new

SOP based on selecting product from Production planning order. For this, users must first

go in to the materials management module and select a task to view or create SOPs

43

9.2.3 SOP Summary

Actor Description

Preconditions Material Should be checked properly in QA

There should not be any defective material

from QA.

Production dept should receive MRN (Material

receiving note) from QA

44

Postconditions Product should be matched with the customer

requirement .

Product should be ready within the time limit.

Product should be checked by the QA and should

be ready for dispatch by the Sales and Export

department

Basic Path 1. User Login into the Operating Process system.

2. User can see QC status of all material released

from the QC department with detail status

comments .

3. If the Status of Material is Ok then system allow

user to send the Material information to Production

department through mail for production planning

approval.

4. Production Manager can approve or disapprove

product production based on the material

information.

5. If Manager approve, Approval information should be

send to Production Planning manager for Product

preparation .

6. System should allow tracking of product

preparation stages . Once final product is ready

and Status of Product is Finished Product.System

45

will send auto mail to QC to schedule Product

Checking .

7. QC after checking update status of Product to

Ready to Dispatch if Product is defectless .

8. When Status is Ready to Dispatch Sales and

Export department get mail and generate Dispatch

Invoice.

9.2.4 Issue tracking

This use case will explore how the system will generate flags by checking the backend for

any critical production issues such as lack of materials, resources, services, contracts, or

lack of a SOP for the work order.

46

9.2.5 Issue tracking Summary

Actor Description

Preconditions Issues has to be defined and entered into the

system.

Issues has to be valid and should have business

case details.

If issue is reported through email or telephonic has

47

be entered in issue tracking excel sheet or in

system

Users should have proper access to log issue in

system

.System should ask basic information and give

options to select correct option.

Postconditions Issues should be assigned to correct group admin

for timely resolution.

Issue communication should be tracked down in

system properly for tracking issue resolution

approach.

Issue should be escalated based on time length

Assign Issue to correct group if know else system

assign to default group..

Admin should have access to all Issues.

Basic Path 9. User Login into Issue tracking System.

10. Provide details of Issue .

11. Select proper Issue category.

12. Provide Contact Information and availability.

13. User assign Issue to correct group if know else

system assign to default group.

14. Admin view all the logged issue and filter based on

48

Issue category .

15. Assign to right helpdesk support group based on

category.

16. Admin track progress of each log on Tracking

screen.

17. Based on time length escalate issue to upper

support group .

18. Admin email tracking report to managers to take

correct measured steps.

19. Support user change Issue status according to

Issue progress.

20. Support user assign resolved status once issues is

resolved.

21. Admin closed all resolved issues .

22. System send communication mail to user , admin,

and Manager when issue is closed .

Alternate Path 1 User 1. User can email or through phone can report issues.

2. Support team log all reported issues in excel sheet.

3. Admin import issues from excel sheet into tracking

system.

4. Admin assign issue to proper groups.

5. Admin view all the logged issue and filter based on

49

Issue category .

6. Assign to right helpdesk support group based on

category.

7. Admin track progress of each log on Tracking

screen.

8. Based on time length escalate issue to upper

support group .

9. Admin email tracking report to managers to take

correct measured steps.

10. Support user change Issue status according to

Issue progress.

11. Support user assign resolved status once issues is

resolved.

12. Admin closed all resolved issues .

13. System send communication mail to user , admin,

and Manager when issue is closed .

9.2.4 Waste disposal system

Description: This use case will explore how materials generated as waste will need to be

recorded and cataloged in the system and subsequently shipped off to respective waste

facility based on rules of the plant per government regulations.

50

Actor Description

Preconditions An authenticated user needs to be logged in to

the system in order to monitor or manage the

waste disposal system

Postcondition End user has successfully either monitored or

managed the waste disposal from a

production cycle

Basic Path User 1. User launches the materials management


2. User selects the option for waste disposal

3. On the waste disposal screen, user should be

able to monitor/track existing waste disposal or

create/manage new waste products for disposal

4. If user selected to create/manage new waste

for disposal, user will be asked to enter

production planning document reference number;

else go to step 9 of this flow fomonitoring/tracking

existing disposal

51

5. Once user enters production planning

document reference number, system will

autopopulate waste generated based on master

data and calculations based on production plan.

User will be able to edit the waste material entries

as well as quantity generated; each waste

material will be categorized for disposal based on

government regulations input in the master data.

6. System will check if there are any errors occur

such as lack of assignment to a waste product.; if

there are errors, an error log is created requesting

user to fix the errors, else go to next step

7. Once user is satisfied with content on the

screen, user will be asked to ensure waste is

being disposed off with regards to government

regulations (a confirm screen is shown) for new

items, for existing items, system will autoassign

based on history of disposal + master data


the disposal tracking document and transmit it to

necessary personnel and send a copy of the

52

document to the waste management mailbox and

the waste disposal facility as well as update the

internal document queue in the system

9. In order to track a waste disposal, user must

enter the disposal tracking document reference

number which will show the end user necessary

information such linking all the way back to

purchase order and current status whether

material has been sent for disposal or not

10. Once a waste disposal facility receives waste

product, their system will generate a receipt that

will be confirmed within our ERP system therefore

completing the queue for Materials Management

module.

53

9.3. Shipping/Invoicing System

9.3.1 Billing Invoice

Description: This use case will explore how sales and distribution system will generate

54

the billing invoice for the end client or user.

Actor Description

Preconditions There should be proper insertion of required

fields needed to generate the billing invoice

Master data in the database should have

information about users billing data.

Postconditions A billing invoice report document is generated

after successful verification of master data

Basic Path System, end

client

1. User selects the option to view the billing

invoice

2. Within the billing invoice screen, user enters

all the mandatory fields.

3. User is given the option to enter only home

address incase his home and shipping address is

the same.

4. User can then save or edit changes of

information he provided.

55

5. Once user confirms, system checks for any

errors in missing entry or improper home/shipping

address.

6. System will check if there are any errors such

as invalid pin, missing country code, improper

billing information etc.; if there are errors, an error

log is created requesting user to fix the errors,

else go to next step.


the document and transmit it to necessary

personnel and send a copy of the document to the

billing manager and update the document queue

in the system

9.3.2 Product Availability

Description: This use case will explore how sales and distribution system will check

product availability based on interaction with the procurement and inventory system.

Product availability requires checking available materials/services form the inventory.

9.3.3 Time estimation of purchased material

This use case will explore how the system keeps track of time needed to purchase the

56

material from the time it has been requested by the end client.

9.3.4 Credit History

This use case will calculate the credit history of the end client depending on the buying

behavior of the end client, their financial status, physical location etc. System stores the

credit history of the end client in credit history report for future business.

9.3.5 Issue management of delivered goods

Description: This use case will explore how materials not delivered on time are managed

taking in to account their source/destination address, date and time of delivery etc.

Actor Description

Preconditions An user is in the issue management screen of

the system in order to monitor and claim the

issue

Postconditions End user has successfully either claimed or

managed the issue related to product delivery

Basic Path User, Sales

system

1. User launches the sales and distribution


57

2. User selects the option for delivery issue

management.

3. User has the option to either claim or forgo

the issue related to delivery

4. If user selected to claim for the issue, user will

be forwarded to dispute screen else go to no

action taken.

5. Once user enters in claims window, user

enters the information related to claims

6. System checks estimated time and date of

product delivery. System also checks for source

and target location of product delivery.

7. User is notified about system resolution.

8. If user is satisfied, system will generate the

issue delivery report and send a copy of the

document to the issue management mailbox as

well as update the internal document queue in the

system.

58

10. Activity Diagram

10.1.1 Sales Order and Vendor Management System

60

10.2.1 Production planning and Waste Management

61

10.3.1 Sales and Distribution Planning

62

11. Sequence Diagram

12.Database Overview (Class Diagram)

63

13. Test Plan

This project will be using a COTS analysis that will help determine the base ERP technology to use for the customer’s requirements and testing will be planned on the basis of Scenario driven testing approach.

Objective:To deliver a bug free product.

Scope:Component Test, Configuration test , Application test , Application – Integration Gate, Integration testing, Integration User Acceptance Test Gate , User Acceptance Test

Test Strategy:During the Scenario driven testing approach, scenarios are identified that represent one or more transactions or processes that an end user will perform.

64

These scenarios are first solicited from the key users and then reviewed and augmented by implementation team members, to ensure that an adequate level of process testing is included.

Scenarios fall into two categories: standard and exception processing.Standard scenarios test the most common business processes that execute the vast majority of the time. Exception scenarios test those processes that execute infrequently, usually as a result of an error oruncommon variables that are introduced into the process.

In an ideal test strategy all scenarios would be equally tested and validated.

In practice the extent to which exception scenarios are validated depends on a number of implementation specific factors including: time to execute, criticality of process, frequency of the exception, stability of overall solution, etc.

The development team executes the Component test to ensure that the object they have coded supports the functional design and the test scenarios are included in that design.

The test team checks that test execution can begin as soon as possible and that the standard, configured product supports the processes. The test team executes the configuration test by utilizing business process based scenarios.

The scenarios that require extensions are tested in alignment with their unit test completion. The test team executes the Application test by utilizing business process based scenarios.

Between the end of the Application test and the start of Integration test a quality threshold gate is established. The exact quality metrics are dependent on the specific implementation, but should be established in the early stages of the project when the Test Approach is outlined. This is a fundamental checkpoint to ensure a suitable level of quality and stability exists within the ERP application “walls” before engaging legacy systems and outside vendors in the integration test.

Integration testing establishes connectivity to test environments for all legacy and vendor applications. Legacy and vendor resources allocates to execute tests as well as triage and resolve defects.

Between the end of Integration test and the start of User Acceptance Test (UAT) a quality threshold gate is established. No defects should be outstanding that impact the ability to successfully execute a process or do not have an acceptable workaround.

65

The User Acceptance Test raise the confidence level of the user based in the quality of the solution, so that they are able to signoff on the ERP solution moving into production.

Bugs found during the testing will be documented.

14. Implemented Interface

The following interface was built using FileMaker Pro Advanced a database tool used to help manage small business databases.

14.1 Screenshot of database relationships via class diagram

14.2 Screenshot of Customer Records listing Purchase Orders and Invoices (Paid/Unpaid)

66

14.3 Screenshot of a sample Purchase Order

67

14.4 Screenshot of Product Details record in the database

14.5 Screenshot of Invoice details

68

14.6 Screenshot of Invoice Print

69

Requirements document for biotech company

Presentations & Public Speaking

Transcript of Requirements document for biotech company