4.

0 System Analysis

4.1 STUDY OF CURRENT SYSTEM:

Presently in AGCL, the system used for secondary sales registration is created using JSP. It
included the maintenance of the details of end customers, funnels, stock statements, purchase
orders.

This system did not include any facilities to maintain the details of the invoices that were
generated between the BP and Company. As well as generation and confirmation of the invoice
consisting of the materials ordered by the customer was done manually by the BP. The invoice
consisting of the materials ordered by the customer registered by the BP is then sent to the CM.
The CM, then analyzes the details of the customer for which this invoice was created and then
accepts or rejects the invoice.

Thus, the whole process of invoice registration was conducted manually.

4.2 PROBLEMS AND WEAKNESSES OF THE CURRENT SYSTEM:

 As the whole process of invoice registration was conducted manually, it resulted in a very
time-consuming process.
 The user interface of the current system is not user friendly. Thus, sometimes, the users
used to face certain problems regarding the GUI.
 The BPs and the CMs pursue their work at remote places, mostly in different states.
Hence, the delivery of the invoices from BP to the CM took lots of time.
 As the detail of the old transactions of the customers is on paper, it becomes a tedious job
for the CM to analyze those data and make a decision for the confirmation of the invoice.

4.3 REQUIREMENTS OF NEW SYSTEM:

Requirement analysis is a software engineering task that bridges the gap between system level
software allocation and software design. Requirements analysis enables the system engineer to
specify software function and performance, indicate software’s interface with other system
elements, and establish constraints that software must meet. Requirements analysis allows the
software engineer (often called analyst in this role) to refine the software allocation and build
models of the data, functional and behavioral domains that will be treated by software.
Requirements analysis provides the software designer with models that can be translated tin to

DDU(Faculty of Tech., Dept. of IT) 33

 4.0 System Analysis

data, architectural, interface and procedural design. Finally, the requirements specification
provides the developer and the customer with the means to assess quality once software is built.

4.3.1 USER REQUIREMENTS:

The user requirements for new proposed system are:

 Facilities for the BP to add the details of a new end customer, a funnel entry, stock
statements.
 The BP should be able to view the details of the invoices resulted from the deals between
the BP and Company.
 The BP should be allowed to register the invoices generated as a result of the deals
conducted between the BP and the end customer and wait for the CM confirmation.
 The CM should be allowed to view the pending acceptance and take desired decisions.
 Data Security & consistency is maintained.
 Detailed report regarding each of the criteria.
 Registration status of the invoices are updated on regular basis, allowing the BP to take
the related decision.
 Ease in Information Flow between different levels in the organization. All the required
details are just a click away.
 Statuses of all transactions are maintained from within the system.

4.3.2 SYSTEM REQUIREMENTS:

R1:Login

R1.1: BP login

Input: BP is requested to enter username & password.

Output: If the details entered are correct then the page is navigated to the next
page. But if the entered data is not correct then an error message is
displayed & the user is requested to enter the details again.

Description: By entering the correct details in the form the BP is

logged in.

Processing: When the user enters the data , it is checked in the database for

DDU(Faculty of Tech., Dept. of IT) 34

 4.0 System Analysis

validation.

R2:End customer details

R2.1: Addition of a customer

Input: The BP is supposed to enter the required details and click the
Save button.

Output: A message is displayed which says that the data is entered in the d/b.
if there is any missing value, an error message is displayed.

Description: Here the BP is allowed to add a new customer by entering

all its details.

R2.2: Customer search

Input: Select the criteria provided like name, sr.no, date of registration,
etc. and click the search button.

Output: Here, on the basis of the selected criteria details

are displayed.

Description: If the required criteria is selected then a list of customer details is

displayed and whichever customer is selected by the user from the
list ,the details of that customer is displayed.

R2.3: Modification of customer details

Input: Select the button provided on left side of table to modify customer details.

Output: The modifications are done in the d/b.

Description: Here, when BP clicks on the edit button a new window is opened to
modify data. BP then enters the new data and clicks on the button to
modify data.

DDU(Faculty of Tech., Dept. of IT) 35

 4.0 System Analysis

Processing: During the insertion process, a BAPI(ABAP Function Module) is called

through RFC which inserts all the data entered by the BP into the oracle d/b.
During the search process, according to the criteria selected the required data
is fetched from the Oracle database through RFC(Remote Function Call) or
it can be modify.

R3: Invoice

R3.1: Invoice search

Input: Select the criteria provided like invoice date, purchase date, P.O. number
and click the search button.

Output: Here, on the basis of the selected criteria details are displayed

Description: If the required criteria is provided then a list of invoice details is

displayed and whichever invoice no. is selected by the Business Partner
from the list , the details of that invoice is displayed..

R3.2: Invoice product selection

Input: Select the customer name who requires the products. Select the products
Required by that customer from the list provided .

Output: If the required criteria is provided then the list of the selected products
along with customer name and other details is displayed on the next screen.

Description: Here, the selected products for a particular customer are listed out
for registration purpose.

R3.3: Creation of registration number

Input: Click the confirmation button provided on the screen which includes the
list of the products required by the end customer.

DDU(Faculty of Tech., Dept. of IT) 36

 4.0 System Analysis

Output: When the confirmation button is clicked, a registration number is

created.

Description: Here, a unique registration number is created for the customer

request of products.

Processing: According to the criteria selected the required data is fetched from the
Oracle Database through RFC(Remote Function Call) and when the
confirmation button is clicked, a registration number is created. .

R4: Registration Acceptance/Rejection

R4.1: Pending registration

Input: Select the criteria provided like date of registration and click the search
button.
.
Output: When the Search button is clicked, a pending acceptance details is
displayed.

Description: When the Search button is clicked, a pending acceptance details is

displayed.

R4.2: Acceptance/Rejection by the Channel Manager

Input: Click on the link provided for the customer against each registration
number.

Output: A view consisting of the material description of the selected invoice is

displayed.

Description: When the Accept button is clicked, an acceptance message is

displayed. If Reject button is clicked, the status for that particular
invoice is updated in the database.

R4.3: Registration history

Input: Select the criteria provided like date of registration and click the search
button.
.

DDU(Faculty of Tech., Dept. of IT) 37

 4.0 System Analysis

Output: When the Search button is clicked, a registration history is displayed.

Description: When the Search button is clicked, a registration history of all

confirmed registration is displayed.

Processing: According to the criteria selected the required data is fetched from the
Oracle Database through RFC(Remote Function Call).

R5: Channel Partner Funnel Info:

R5.1: Creating a funnel entry

Input: The BP is supposed to enter the required details and click the
Save button.

Output: A message is displayed which says that the data is entered in the d/b.
if there is any missing value, an eror message is displayed.

Description: Here the BP is allowed to add a new Funnel entry by entering

all its details.

R5.2: Searching a funnel entry

Input: Select the criteria provided like Funnel id , city, dates, etc. and click the
search button.

Output: Here, on the basis of the selected criteria details

are displayed.

Description: If the required criteria is selected then a list of funnel details is

displayed and whichever funnel id is selected by the user from the
list ,the details of that funnel is displayed for editing. From here BP can also
download the data to Excel Sheet and saves the Excel Sheet.

R5.3: Modification of Funnel details

Input: Select the link provided on left side of table to modify funnel details.
then he can modify the data.

DDU(Faculty of Tech., Dept. of IT) 38

 4.0 System Analysis

Output: The modifications are done in the d/b.

Description: Here, Here, when BP clicks on the edit button, a new window is
opened to modify the data. BP then enters the new data and clicks
on the button to modify data.

Processing: During this process, a BAPI(ABAP Function Module) is called through

RFC which inserts or updates all the data entered by the BP into the oracle d/b.

R6: Stock Statement :

R6.1: Creating a stock entry

Input: The BP is supposed to enter the required details and click the
Save button.

Output: A message is displayed which says that the data is entered in the d/b.
if there is any missing value, an eror message is displayed.

Description: Here the BP is allowed to add a new stock entry by entering

all its details.

R6.2: Searching a stock entry

Input: Select the criteria provided like month , year, product, etc. and click the
search button.

Output: Here, on the basis of the selected criteria details

are displayed.

Description: If the required criteria is selected then a list of stock details is

displayed and whichever srno. is selected by the user from the
list ,the details of that stock is displayed for editing.

R6.3: Modification of stock details

Input: Select the link provided on month/year of table to modify stock details.
then he can modify the data.

Output: The modifications are done in the d/b.

DDU(Faculty of Tech., Dept. of IT) 39

 4.0 System Analysis

Description: Here, the BP can modify any details of the stock.

Processing: During this process, a BAPI(ABAP Function Module) is called through

RFC which inserts or updates all the data entered by the BP into the oracle d/b.

R7: Reports:

R7.1: Display Factsheet details

Input: The BP is supposed to select the link provided in the custom navigation.

Output: The factsheet details are displayed.

Description: Here the BP is allowed to view the factsheet details like the
Quarterly Targets, Revenue realized, etc.

R7.2: Display purchase order details

Input: The BP is supposed to select the link provided in the custom navigation then
clicks on the search button.

Output: The purchase order details are displayed.

Description: Here the BP is allowed to view the purchase details and he/she can
also download the PDF file which is on purchase order.

R7.3: Display registration history

Input: The BP is supposed to select the link provided in the custom navigation then
clicks on the search button.

Output: The registration history are displayed.

Description: Here the BP is allowed to view the registration history like which invoices
are accepted or rejected, what are the reasons to reject invoices.

Processing: During this process, a BAPI(ABAP Function Module) is called through

RFC which displays all the data required by BP from the oracle d/b.

DDU(Faculty of Tech., Dept. of IT) 40

 4.0 System Analysis

4.4 REQUIREMENT VALIDATION:

Requirement validation is concerned with showing that the requirements actually define the
system that customer wants. If this validation is inadequate, errors in the requirements will be
propagated to the system design and implementation.

Requirements are checked to discover if they are complete, consistent and in accordance with
what company officials and other users want from the projected system.

The system includes following aspects to meet the requirements given by the organization:

 The system includes the login module based on rights of user to access the data.
 The system includes the end customer module, funnel module, stock statement module to
maintain the details of the customer, funnel and stock statement respectively.
 It also includes facilities for the BP to generate and confirm an invoice.
 It also includes facilities for the CM to confirm the registration.
 The report module meets the requirement of generation of different reports.

4.5 FEATURES OF NEW SYSTEM:

 Windows based user friendly software.

 Well designed screens, logically arranged functions.
 It is based on 3 -Tier client server architecture.
 Multi-user and unlimited user access.
 Integrity and consistency is maintained even when concurrent data storage and retrieval
are done.
 Generations of different types of Reports.

DDU(Faculty of Tech., Dept. of IT) 41

 4.0 System Analysis

4.5 USECASE DIAGRAM:

A use case diagram is a type of behavioral diagram defined by the Unified Modeling
Language (UML) created from a Use-case analysis. Its purpose is to present a graphical
overview of the functionality provided by a system in terms of actors, their goals—
represented as use cases—and any dependencies between those use cases.

Use case diagrams depict:

 Use cases. A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.
 Actors. An actor is a person, organization, or external system that plays a role in
one or more interactions with your system. Actors are drawn as stick figures.
 Associations. Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is involved with
an interaction described by a use case. Associations are modeled as lines
connecting use cases and actors to one another, with an optional arrowhead on
one end of the line. The arrowhead is often used to indicating the direction of the
initial invocation of the relationship or to indicate the primary actor within the use
case. The arrowheads are typically confused with data flow and as a result I avoid
their use.
 System boundary boxes (optional). You can draw a rectangle around the use
cases, called the system boundary box, to indicates the scope of your system.
Anything within the box represents functionality that is in scope and anything
outside the box is not. System boundary boxes are rarely used, although on
occasion I have used them to identify which use cases will be delivered in each
major release of a system.
 Packages (optional). Packages are UML constructs that enable you to organize
model elements (such as use cases) into groups. Packages are depicted as file
folders and can be used on any of the UML diagrams, including both use case
diagrams and class diagrams. I use packages only when my diagrams become
unwieldy, which generally implies they cannot be printed on a single page, to
organize a large diagram into smaller ones.

DDU(Faculty of Tech., Dept. of IT)

42
 4.0 System Analysis

Fig 4.5.1 Use Case Diagram

DDU(Faculty of Tech., Dept. of IT)

43
 4.0 System Analysis

 USE-CASE SCENARIO:

U1:Login
Using this use-case, Business Partner or Channel Manager can login by entering
the username & password .

Actor: Business Partner/ Channel Manager

Pre-condition: Business Partner/ Channel Manager should have their username

and password.

Scenario 1: Mainline Sequence

1. Business Partner: Enter the user name & password.
2. System : System verifies the password with the database.
3. Channel Manager: Enter the username & pswd.
4. System: System verifies the pswd.

Scenario 2: At step 2 & 3 of the mainline sequence

1. System: If the data entered is right , then the Business Partner or the
Channel Manager gets successfully logged in .

Scenario 3: At step 2 & 3 of the mainline sequence

1. System: If the data entered is incorrect, then the system displays a
msg to try again.

Post-condition: Allowed to login or asked for the valid username and password
again.

U2: Customer Registration

Using this usecase, the Business Partner can add the details of a new customer.

Actor: Business Partner

Pre-condition: Business Partner should have the details of the customer.

Scenario 1: Mainline Sequence

1. Business Partner: BP selects link to create customer and enters all
the details of the new customer.
2. System : Adds all the details in the database.

DDU(Faculty of Tech., Dept. of IT)

44
 4.0 System Analysis

Scenario 2: At step 2
1. System: If any detail has not been entered, the system displays the msg. to
enter the incomplete details.

Scenario 3: At step 1 of Scenario 1

1. Business Partner: BP selects link to search customer and enters the
customer name and searches for it by selecting the search option & then
clicks the link to modify.
2. System: It opens the details of the required customer.
3. Business Partner: Enters the new values.
4. System: It modifies the database.

Post-condition: A message about the successful registration of the customer is

displayed or modification of customer details message is
displayed.

U3: Invoice Search

Using this usecase, the Business Partner can search invoices by providing the
invoices dates or by purchase dates or by P O number.

Actor: Business Partner

Pre-condition: Business Partner should have invoices dates or by purchase dates

or by P O number.

Scenario 1: Mainline Sequence

1. Business Partner: The Business Partner enters the invoices dates or by
purchase dates or by P O number.
2. System: Searches the database according to the criteria provided and
displays the list of invoices.

Scenario 2: At step 2
1. Business Partner: The Business Partner clicks the link provided on the
invoice no. that he requires.
2. System: It displays the details of that particular invoice.
3. Business Partner: selects the materials required by the end
customer.
4. System : System display another view which contains the list of
selected materials selected by BP.
5. Business Partner: Clicks on the confirmation button to generate registration no.
6. System: System creates a registration no. and stores it in database.

Post-condition: Invoice details and registration no. is created.

DDU(Faculty of Tech., Dept. of IT)

45
 4.0 System Analysis

U4: Funnel Info

Using this usecase, the Business Partner can create a new funnel entry.

Actor: Business Partner

Pre-condition: Business Partner should have the details of the funnel.

Scenario 1: Mainline Sequence

1. Business Partner: BP selects link to create funnel entry and enters all the
details of the new funnel
2. System : Adds all the details in the database.

Scenario 2: At step 2
1. System: If any detail has not been entered, the system displays the msg. to
enter the incomplete details.

Scenario 3: At step 1 of Scenario 1

1. Business Partner: BP selects link to search funnel entry and searches for
it by selecting the search option & then clicks the link to modify.
2. System: It opens the reqd. funnel entry .
3. Business Partner: Enters the new values.
4. System: It modifies the database.

Post-condition: A message about the successful registration of the funnel entry is

displayed or modification of funnel entry message is
displayed.

• U5: Stock Statement

Using this usecase, the Business Partner can create a new stock entry.

Actor: Business Partner

Pre-condition: Business Partner should have the details of the stock.

Scenario 1: Mainline Sequence

1. Business Partner: BP selects link to create stock entry and enters all the
details of the new stock
2. System : Adds all the details in the database.

Scenario 2: At step 2
1. System: If any detail has not been entered, the system displays the msg. to
enter the incomplete details.

DDU(Faculty of Tech., Dept. of IT)

46
 4.0 System Analysis

Scenario 3: At step 1 of Scenario 1

1. Business Partner: BP selects link to search stock entry and searches for
it by selecting the search option & then clicks the link to modify.
2. System: It opens the reqd. stock entry .
3. Business Partner: Enters the new values.
4. System: It modifies the database.

Post-condition: A message about the successful registration of the stock entry is

displayed or modification of stock entry message is
displayed.

U6: Purchase Order

Using this usecase, the Business Partner can view purchase order information.

Actor: Business Partner

Pre-condition: Business Partner should have the details of the purchase order.

Scenario 1: Mainline Sequence

1. Business Partner: BP selects link to view purchase order and searches for
it by selecting the search option
2. System : Display list of purchase order.
Post-condition: purchase order information.

• U7: Registration Acceptance/Rejection

Using this use-case, Channel Manager can accept or reject the registration.

Actor: Channel Manager

Pre-condition: Channel Manager should have registration details.

Scenario 1: Mainline Sequence

1. Channel Manager: Checks the past records and accept or reject the
registration.
2. System: System modifies the database.

Post-condition: If the Channel manager accepts registration then it is appended to

the registration history else to the pending acceptance history.

DDU(Faculty of Tech., Dept. of IT)

47
 4.0 System Analysis

4.6 SEQUENCE DIAGRAM:

The sequence diagram shows, as parallel vertical lines, different processes or objects that
live simultaneously, and, as horizontal arrows, the messages exchanged between them, in
the order in which they occur. This allows the specification of simple runtime scenarios
in a graphical manner.

 ANALYSIS LEVEL SEQUENCE DIAGRAM:

Analysis-level sequence diagram: sequence diagram which focuses on processing from

an actor's point-of-view. List objects and primary messages, but do not list
creation/deletion messages unless they are critical to the high-level view of the system.
Each diagram should start with an actor and correspond to a specific scenario in the use
case model. There need not be a strict one-to-one correspondence between messages in
the diagram and operations in the class diagram, and some messages might be expressed
as pseudo-code.

The sequence diagrams are associated with specific scenarios in an obvious way. The
best way to do this is add a text box (a note) which either names the scenario or contains
the text of the scenario itself.

DDU(Faculty of Tech., Dept. of IT)

48
 4.0 System Analysis

Fig 4.6.1 Analysis level Sequence Diagram for Login

DDU(Faculty of Tech., Dept. of IT)

49
 4.0 System Analysis

Fig 4.6.2 Analysis level Sequence Diagram for End Customer

DDU(Faculty of Tech., Dept. of IT)

50
 4.0 System Analysis

Fig 4.6.3 Analysis level Sequence Diagram for Invoice Search

DDU(Faculty of Tech., Dept. of IT)

51
 4.0 System Analysis

Fig 4.6.4 Analysis level Sequence Diagram for Funnel

DDU(Faculty of Tech., Dept. of IT)

52
 4.0 System Analysis

Fig 4.6.5 Analysis level Sequence Diagram for Stock

DDU(Faculty of Tech., Dept. of IT)

53
 4.0 System Analysis

Fig 4.6.6 Analysis Sequence Diagram for Purchase order

DDU(Faculty of Tech., Dept. of IT)

54
 4.0 System Analysis

Fig 4.6.7 Analysis level Sequence Diagram for Reg. Accept/Reject

DDU(Faculty of Tech., Dept. of IT)

55
 4.0 System Analysis

4.7 COMPONENT DIAGRAM:

User:Application

Event Handler

Database

SAP(Oracle)

Web Apllication Server

Fig 4.7.1 Component Diagram

DDU(Faculty of Tech., Dept. of IT)

56