,

c

ARMY RESEARCH LABORATORY

BuyIt Prototype

Software Requirements Analysis:

A C-BASS Component

by Brian R. Schallhom, Wade S. Jemigan,

and Dana L. Ulery

,

Approved for public release; distribution is unliited.
The findings in this report are not to be construed as an official

Department of the Army position unless so designated by other

authorized documents.

Citation of manufacturer’s or trade names does not constitute an

official endorsement or approval of the use thereof.

Destroy this report when it is no longer needed. Do not return

it to the originator.
Abstract

This document contains the software requirements analysis for a prototype of BuyIt. As a

component of the Corporate Business Application Software System (C-BASS), this application

automates small purchase requests (under $2,500). The document follows the process of

structured analysis, or step-wise refinement of requirements, as applied to the development of

BuyIt. The “environmental model” includes a high-level system description, followed by a

context diagram and a list of events to which the system must respond. The “behavioral model”

includes a data flow diagram (DFD) for each of the seven BuyIt subsystems. From this

representation, the basic functional specifications are derived and represented in structured

English (or program design language). The final segment of the document includes a data

dictionary.
Table of Contents

1.

1.1

1.2

1.3

2. Structured Analysis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.

3.1 Required Functionality ........................................................................................ .3

3.2 Context Diagram ................................................................................................. 3

3.3 Event List ............................................................................................................ 4

4. System Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.

5.1 BuyIt Subsystems ................................................................................................ 11

5.2 Subsystems Data Flow Diagrams........................................................................ 12

5.3 Processing Narration ........................................................................................... 17

6.

7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

BuyIt Prototype.................................................................................................... 1

Development Plan and Project Schedule ............................................................ 1

Contents of This Report ...................................................................................... 1

System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Functional Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Distribution List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Report Documentation Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

. . .

111
c

INTENTONAUY LEFTBLANK.

iv
List of Figures

Figure

1. Context Diagram for BuyIt ........................................................................................

2. Major Subsystems of BuyIt .......................................................................................

3. Prepare Purchase Request Process ............................................................................

4. Approve Funds Process.............................................................................................

5. Approvals Process .....................................................................................................

6. Edit Purchase Request Process..................................................................................

7. Prepare Purchase Order Process ................................................................................

8. Receive Shipment Process ........................................................................................

9. Inquires Process.........................................................................................................

List of Tables

w

5

12

13

14

14

15

15

16

16

Table &

1. High-Level Requirements for the BuyIt Prototype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

V
bJTEiNTIONALLY LJFTBLANK.

vi
1. Introduction

BuyIt is a component of the Corporate Business Application Software System (C-BASS)

family of applications, an integrated set of Lotus Notes and Web-based software to support

U.S. Army Research Laboratory (ARL) electronic workflow and task automation. The

motivating force behind this project has been ARL downsizing and findings put forth in the

Business Process Reengineering (BPR) report on the small purchase process. The BPR “To-Be

Model: Small Purchase” [l] identifies potential process improvements-some of which require

computer automation-that would increase productivity of purchasing operations at ARL.

Development of a full-production BuyIt will proceed in phases, using an incremental, evolutionary

approach.

1.1 BuyIt Prototype. The purpose of the BuyIt prototype project is to model a secure

client/server system that provides for the processing of small purchase requests. This proof-ofprinciple prototype will alleviate some of the risks involved in implementing new technologies

used to build the ARL Intranet. The project will also refine requirements described in the AIU

Business Process Reengineering (BPR) ‘To-Be Model” [ 11.

1.2 Development Plan and Project Schedule. The “BuyIt Software Development Plan” [2]

states a definition of the problem; gives an overview of technical, management, and reliability

issues; and provides a detailed project schedule. The report enclosed herein covers the work

accomplished to solidify user requirements (drawn from existing high-level design documents) and

the analytical expansions used to derive a data flow model, a pseudocode representation of

processing, and a data dictionary. As stated in the project schedule, the analysis represents a

lo-working-day effort and was completed within the stated timeframe of 13 January 1997 to

27 January 1997.

1.3 Contents of This Report. This document presents the results of a structured system

analysis used to derive the software requirements for BuyIt, starting with the baseline given in the

BPR “To-Be Model: Small Purchase” [ 11. The body of the report contains five sections.

1
Structured Analysis Overview - briefly explains

software functional specifications.

System Overview - delineates the basic BuyIt

requirements.

the methodology used to extract the

concept and outlines the high-level

Requirements - breaks the generic statements into low-level, derived requirements and

describes each in detail.

Functional Specifications - discusses the products of the structured analysis (i.e., the data

flow diagrams and structured English narrative) for each subsystem of BuyIt.

Data Dictionary - lists each of the BuyIt data elements, giving a full description and type for

.

the data model.

2. Structured Analysis Overview

Modern software engineering utilizes structured analysis [3] as a powerful methodology for

developing system specifications. Through a series of step-wise refinements, detailed delineations

of the system’s components and their behavior are extracted fi-om high-level descriptions of

system features and functions. In other words, primary system elements are broken down into

progressively more detailed levels of processes, and the data paths between these processes are

defined. Three modeling tools facilitate this decomposition: (1) data flow diagrams (DPDs), (2)

structured English process narratives (pseudocode or program design language [PDL]), and (3) a

data dictionary. Accuracy and precision in progressively expanding design definitions are critical

to successful system development.

The results of this analytical approach are systematic elaborations of product requirements,

typically expressed as two separate models:

l An environmental model that defines the system’s interfaces to the outside world. (See

section 3, “System Overview.“)

2
l A behavioral model that defines the internal behavior the system must exhibit in order to

deal with the environment. (See section 4, “System Requirements,” and section 5,

“Functional Specifications.“)

3. System Overview

The environmental model typically consists of three components: (1) a concise statement of

the system’s purpose or required functionality, (2) a context diagram, and (3) an events list. The

context diagram is the highest level DFD. It shows the system as a single process, including user

interaction and communication with external systems, as well as data flow input and output. The

events list creates an index of outside stimuli to which the system responds.

3.1 Required Functionality. As a system, the BuyIt prototype provides a secure,

automated means for the preparation, routing, approval, tracking, and reporting of small purchase

requests. Table 1 lists the high-level requirements for the BuyIt prototype and a general

description of what each requirement involves.

3.2 Context Diagram. Figure 1 shows the context diagram for the prototype. Each square

in the diagram represents an external entity (e.g. users, functional areas, and legacy systems) with

which BuyIt communicates. The arrows indicate the data that flow into and out of BuyIt. A few

elements on the DFD need additional explanation. First, the external entity “User” represents all

users of the system, and the data flow associated with this box is limited to display of information.

Second, all the other external entities (e.g., “Requester” and “Supervisor”), and their

corresponding data flow, show the specific information that is passed to BuyIt either by that user

or by the system. Lastly, the data store EMPLOYEE contains user information such as name,

phone number, address, office symbol, etc.
Table 1. High-Level Requirements for the BuyIt Prototype

Requirement

Security

Purchase request preparation

Automated request routing

Electronic approval

Receive/Accept order

Request tracking

Legacy system interface

Reporting

General Description

Provide security measures to prevent unauthorized access to

the system and its data and keep authorized users from

performing tasks not allowed in their roles.

Provide a means for the requesters and functional users to

input/edit relevant information pertaining to a purchase

request.

Automate the process of routing purchase requests to the

various functional areas.

Provide a means for approving officials and functional users to

electronically approve or reject a purchase request.

Provide a means for Receiving to notify requesters of shipment

arrival and for the purchaser to accept or decline the order.

Allow users to track the status of active purchase requests

currently in the system.

Implement automated interfaces to SOMARDS and

SAACONS legacy systems.

Provide users and management with a means for reporting

cycle times and costs.

3.3 Event List. The following list contains events to which the system must respond.

. Requester initiates new purchase request.

. Requester prepares request.

. Requester corrects rejected request.

. Requester, supervisor, or budget analyst completes fund source.

. Requester or supervisor cancels request.

. Budget analyst certifies fund source.

. SOMARDS certifies and commits funds.

. Special approving official(s) approves request item(s).

. Property book officer attaches item tags.

. Property book officer approves request.

. Contracting officer assigns buyer to request.

. SAACONS downloads purchase order information.

. Supervisor approves actual costs.

. Receiving marks shipment as received.

4
r

Requester

us&d

items

vendon

date-required

cancel_order

acceptance

corwctions

priority_co%

status_inquiry

report-type

inbox-inquiry

display-order

L

Receiving

Buyer

/

EMPLOYEE Supervisor

-Titem-tags

buyer-approval

user_info

i

Buylt

award

r

-

fund-source

superfkory_approval

actuaf_oost_approva

canc=el_order

fund_sourc=e_approva

-Q

funds

reconcile

Special

Approving

Offiiials

Propew cBool(

Offcer

buyer-assignment

Figure 1. Context Diagram for BuyIt.

5
l Receiving checks off tagged items.

l Requester accepts shipment.

l User submit status inquiry.

l User request report.

4. System Requirements

Antecedent studies and legacy systems also contribute to BuyIt’s requirements. The

“Automation Requirements” [4] and the “To-Be Model: Small Purchase” [l] were produced

during the BPR development effort. However, for some areas, these documents lack detail, and

necessary elements had to be derived. Additionally, the limited scope of a prototype necessitated

leaving out some of the more complicated or vague automation requirements of the “To-Be

Model” (e.g., a pull-down product selection) or areas where the requirement already exists in a

Department of Defense (DOD) standard system (e.g., functionalities handled by SAACONS).

“BuyIt: Software Development Plan’ [2] more fully addresses the constraints on the prototype

and the requirements of legacy systems.

El Security

El1 Prevent unauthorized access

Description -- Prevent unauthorized access to the system and its data.

Source -- Derived, due to the nature of the system

Intetiaces to major functions and external entities:

User.

El2 Enforce role restrictions

Description -- Prevent users from performing tasks or accessing/editing

data that are out of the scope of their role.

Source -- BPR “To-Be Model” document, Automation Requirements

section, requirement A12.

Interfaces to major functions and external entities:

6
User.

Approvals.

Edits.

E2

Employee address book (for roles).

Purchase request preparation

E21 Create new purchase request

Description -- Allow the requester to create a new purchase request with

preliminary user information filled-in

Source -- BPR “To-Be Model” document, “Automation Requirements”

section, requirements Al 11 and Al 14.

Inter$aces to major functions and external entities:

User.

security.

E22 Select items

Employee address book (for user info).

Description -- Provide a means for the requester to enter item descriptions,

specifications, quantities, and estimated costs.

Source -- BPR “To-Be Model” document, Automation Requirements

section, requirement Al 12.

InterSaces to major functions and external entities:

User.

Security.

E23 Complete purchase request

Description -- Provide a means for the requester and/or approving

supervisor to complete the purchase request.

Source -- BPR ‘To-Be Model” document, “Automation Requirements”

section, requirements Al 14.

Interj5aces to major functions and external entitik:

User.

Security.

7
E24 Item tag input

Description -- Provide a means for the Property Book Officer to enter item

tags.

Source -- BPR ‘To-Be Model” document, “Automation Requirements”

section, requirements Al 13.

Integ?aces to major functions and externul entities:

User.

Security.

E25 Edit purchase request

Description -- Provide a means for users to edit certain request details as

needed.

Source -- Derived, due to the need for making corrections to rejected

purchase request.

E3

Inte$aces to major functions and external entities:

User.

Security.

Automated routing

Description -- Automate the process of routing purchase requests to the

various functional areas and approving officials.

Source -- BPR “To-Be Model” document, “Automation Requirements”

section, requirements A12.

Interfaces to major functions and external entities:

security.

Employee address book (for default routing).

Ex Electronic approval

Description -- Provide a means for approving officials and functional users

to approve or reject a purchase request.

Source -- BPR “To-Be Model” document, “Automation Requirements”

section, requirements A12.

Interfaces to major functions and externul entities:

8
User.

E5

Security.

Receive/Accept order

E51 Receive shipment

Description -- Provide a means

shipment arrival.

Source -- BPR “To-Be Model”

section, requirements A12. .

for Receiving to notify purchasers of

document, “Automation Requirements”

Inter$aces to major functions and external entities:

User.

Security.

E52

E53 Tag item

Description -- Provide a means for Receiving to attach item tags to received

items.

Source -- BPR “To-Be Model” document, “Automation Requirements”

section, requirements A3.

Inteeaces to major functions and extend entities:

User.

Security.

E6

E54 Accept shipment

Description -- Provide a means for the requester to accept or decline the

order or items.

Source -- BPR “To-Be Model” document, “Automation Requirements”

section, requirements A3 1.

Inteflaces to major functions and external entities:

User.

Security.

Request tracking

Description -- Allow users to track the status of active purchase requests

currently in the system

9
E7

E8

E9

Source -- User requested.

Inter$aces to major functions and external entities:

User.

Legacy system interfaces

E71 Budget legacy system interface

Description -- Provide an electronic interface to the legacy financial system

(SOMARDS) that automates the certification and commitment of funds.

Source -- BPR, “To-Be Model” section, process model diagram A12,

process A122.

E72

E73 Procurement legacy system interface

Description -- Provide an electronic interface to the legacy procurement

system (SAACONS) that automates the uploading of request information to

that system and the download of purchase order data.

Source -- Derived. SAACONS is the primary tool the buyers use during the

procurement process; therefore, there is a definite need for interfacing with

this legacy system in order to eliminate the need for double entry into both

BuyIt and SAACONS.

Reporting

Description -- Provide users and management with a means for reporting

cycle times and costs.

Source -- BPR “Reports Specifications” document.

Inteeaces to major functions and external entities:

User.

Security.

Navigation

Description -- Provide users with a means for navigating to the various

functional areas within the system

Source -- Derived from the requirements previously listed.

Interfaces to major functions and external entities:

User.

10
5. Functional Specifications

The behavioral model expands the analytical results from the environmental model to more

fully define how the system performs prescribed tasks. Typical representations in this model are

(1) concise flowcharts showing how information is transformed as it moves through the system

and subsystems, (2) a set of structured English statements that form a processing narration based

on data types, control structures, and transformations, and (3) a data dictionary defining each data

item.

5.1 BuyIt Subsystems. The nine functionalities listed in the previous section identify the

major components of BuyIt: (1) security, (2) request preparation, (3) automated routing, (4)

electronic approval, (5) status tracking, (6) receive/accept notification, (7) legacy system

interfaces, (8) report generation, and (9) navigation. These categories consolidate into seven

subsystems.

Figure 2 shows the major functional subsystems of BuyIt, as represented by a DFD. Each of

the seven bubbles in the diagram represents a major subsystem or process of BuyIt, with the

arrows showing the data flowing into and out of the processes.

The data store ACTIVE-located in the center of the diagram--holds all the active purchase

requests, each waiting for the appropriate users to perform their functions on them The

CLOSED and CANCELED data stores contain purchase requests that have been closed out or

canceled, respectively. The small squares along the outer edges of this DFD are interfaces to the

outside world.

No process bubble for security appears at this level because the application environment (i.e.,

Lotus Notes) handles unauthorized user security. Additionally, enforcement of role restrictions is

handled within each subsystem, as detailed in the following section.

11
Figure 2. Major Subsystems of BuyIt.

5.2 Subsystems Data Flow Diagrams. System objects and operations can be coherently

represented as data flow diagrams (DFDs). A DFD can be used to capture system concepts and

components at any level of abstraction. Each of the following seven DFDs (Figures 3 through 9)

provides more detail for the information flow and functionality of each of the identified BuyIt

subsystems.

Figure 3 represents the DFD for the Prepare Purchase Request subsystem The major inputs

to this process (and its basic functions) are the requester information (derived from the

user-supplied userid and the EMPLOYEE data store), item details, vendor information (if known

12
Figure 3. Prepare Purchase Request Process.

at this time), and the date by which the items are required. The fund source completes the

information for the request, and the supervisory approval puts the request into the procurement

cycle.

Figure 4 shows the DFD for the Approve Funds subsystem This subsystem, besides having

interfaces to users for approvals, also has connections to the SOMARDS legacy system The

Build Block process is executed at the start of the day and creates the transaction block that will

be used by BuyIt for the remainder of the day. As certified purchase requests are created during

the course of the day, the Certify Funds process queries SOMARDS and grabs the returning

message. Depending on the results of this query, the request is either certified or rejected (with

explanation). At the end of the day, the Reconcile process is executed to balance the transaction

block.

The Approvals process is shown in Figure 5. At this point, the various approving officials

attach their approval or rejection to the request. The property book officer also attaches item tags

to the individual items in order to flag them during receipt of the shipment.

13
El

relum_mesage

0

fund_source_approval

c

completed_pr ceriifiablegr

rejected_pr

‘,I x _L,___~=

actual-cast ----a**

Figure 4. Approve Funds Process.

Figure 5. Approvals Process.

14
Figure 6 diagrams the Edit Purchase Request process. The rejected purchase request is

displayed for the requester, who then enters the corrections. What fields within the request the

user can edit depends on where the rejection came from and how far along in the approval process

the request traveled.

Figure 6. Edit Purchase Request Process.

The Prepare Purchase Order process is diagramed in Figure 7. The first step of the process is

assigning a buyer. This triggers the upload of the purchase request information to SAACONS.

The buyer then proceeds to work within SAACONS. The second part of the SAACONS

interface is the downloading of information (actual costs, selected vendor, delivery date). The

request is then forwarded to Receiving in order to alert that office of the pending shipment.

Figure 7. Prepare Purchase Order Process.

15
Figure 8 represents the Receive Shipment process. Once the shipment has been delivered to

the warehouse, Receiving marks the request as received and checks off any tagged items once

each has been properly accounted for. At this point, the system notifies the requester of receipt

and allows the user to accept or return items once they have been delivered.

13receipt ttem_tags

Q ordered_pr cbsdgr co

Figure 8. Receive Shipment Process.

The Inquires process is diagramed in Figure 9. The processes shown in this figure are used to

display to the user (1) pending actions (inbox), (2) purchase request details, (3) the status of

requests, and (4) reports.

Figure 9. Inquires Process.

16
5.3 Processing Narration. Having captured the flow of information and identified data

objects, each transformation can be further expanded by using the stylized notation of structured

English. Basic procedural constructs are combined with English phrases to give concise

descriptions for each major operation listed in the prescribed tasks analysis given in section 4.

El Security

El1 Login

Znput -- userid, passwd

Process:

REPEAT

GET from user the userid, passwd

UNTIL VALID userid, passwd

ALLOW login

Output -- N/A

El2 Role

Input -- role, action

Process

GET from EMPLOYEE the role using requesteruserid

IF VALID action for role THEN

EXECUTB action

ELSE

NULL

ENDIF

E2

Output -- action-results

Prepare purchase request for ordering

E21 Create new purchase request

Input -- pr, requester_userid, user-info

Process 1 .l

17
GET from EMPLOYEE the user-info using

requesteruserid

SET in pr the requester_userid

SET in pr the user-info using user-info

Output -- bla.nl_pr

E22 Fill in purchase request

Input -- blank_pr, priority-code, items, vendors, date-required

Process 1.2

GET from user the prior&code

SET in pr the priority_code

DO WHILE there is another item to add

GET loom user the item

SET in pr the item

ENDDO

GET from user the specifications

SET in pr the specifications

DO WHILE there is another vendor to add

GET from user the vendor

SET in pr the vendor

ENDDO

GET fkom user the date-required

SET in pr the date-required

Output -- partial_pr

E23 F’illinfund source

Input -- partial_pr, fund-source

Process 1.3

GET from user the fund-source

SET in pr the fund-source

Output -- funded_pr

18
E24 Correct purchase request

Input -- rejected_pr, corrections

Process 4.1

DISPLAY to user rejected_pr and explanation

DO WHILE there are more corrections

GET from user the corrections

SET in pr the corrections

ENDDO

Output -- corrected_pr

E25 Attach item tags

Input -- special_pr, item-tag

Process 3.2

DO WHILE there are more items to tag

GET fi-om user item-tag

SET iu pr the item-tag

ENDDO

Output -- taggable-pr

E26 Cancel request

Input -- active_pr, cancel_order

Process 4.2

DISPLAY to user the activegr

GET from user the cancel-order

PUT canceledgr into CANCELED

Output -- canceled_pr

E3 Routing

E31 Automated routing

Input -- active_pr

Process -- TBD

output -- active_pr

19
E32 Manual routing

Input -- active_pr

Process -- TBD

Output -- active_pr

E33 Assign Buyer

Input -- orderable-pr

Process 5.1

E4

DISPLAY to user the orderablegr

GET from user the buyer-assignment

SET in pr the buyer-assignment

SET iu pr the inbox_location to buyer

Output -- assigned_pr

Approvals

E41 Supervisory approval

Input -- funded_pr, supervisory_approvaI

Process 1.4

DISPLAY to user the fundedgr

GET from user the supervisory-approval

IF supervisory-approval is “Yes” THEN

SET in pr the supervisory-approval to “Yes”

SET in pr the request-date to today’s date

SET in pr the inbox_location to budget

ELSE

GET from user the explanation

SET in pr the supervisory_approval to “No”

SET in pr the explanation

SET in pr the inbox_location to requester

ENDIF

Output -- completed_pr, rejected_pr

20
E42 Fund source approval

Input -- completed_pr, fund_source_approval

Process 2.1

DISPLAY to user the completedgr

GET from user the fund_source_approval

IF fund_source_approval is “Yes” THEN

SET in pr the fund_source_approval to “Yes”

SET in pr.the inbox_location to certification

ELSE

GET from user the explanation

SET in pr the fund_source_approval to “No”

SET in pr the explanation

SET in pr the inbox_location to requester

ENDIF

Output -- certifiable_pr, rejected_pr

E43 Special approval

Input -- certified_pr, special_approval

Process 3.1

DISPLAY to user the certifiedgr

GET from user the special_approval

IF specialapproval is “Yes” THEN

SET in pr the special_approval to “Yes”

SET in pr the inbox_location to

property_book_officer

ELSE

GET from user the explanation

SET in pr the special_approval to “No”

SET in pr the explanation

SET in pr the inbox_location to requester

ENDIF

Output -- special_pr, rejected_pr

21
E44 Property approval

Input -- special_pr, property-approval

Process 3.3

DISPLAY to user specidpr

GET Corn user property-approval

IF property-approval is “Yes” THEN

SET in pr the property-approval to “Yes”

SET inbox_location to contracting_officer

ELSE

GET fi-om user explanation

SET in pr the property-approval to “No”

SET in pr the explanation

SET in pr the inbox_location to requester

ENDIF

Output -- orderable-pr, rejected_pr

E45 Actual cost approval

Input -- actual_pr, actual_cost_approval, explanation

Process 2.2

DISPLAY to user actudpr

GET from user actual_cost_approval

IF actual_cost_approval is “Yes” THEN

SET in pr the actual_cost_approval to “Yes”

SET in pr the inbox_location to buyer

ELSE

GET from user explanation

SET in pr the actual_cost_approval to “No”

SET in pr the explanation

SET in pr the inbox_location to requester

ENDIF

Output -- certifiable_pr, rejected_pr

22
E46 Buyer approval

Input -- assigned_pr, buyer-approval, explanation

Process 2.2

DISPLAY to user assignedgr

GET from user the buyer-approval

IF buyer-approval is “Yes” THEN

SET in pr the buyer-approval to “Yes”

ELSE

GET from user explanation

SET in pr the buyer-approval to “No”

SET in pr the explanation

SET in pr the inbox_location to requester

ENDIF

Output -- approved_pr, rejected_pr

E5 Interface with legacy systems

E51 Build block

Input -- N/A

Process 2.3

PUT to SOMARDS the block

GET from SOMARDS the return-message

Output -- N/A

E52 Certify funds

Input -- certifiable_pr

Process 2.4

GET from certifiablegr the funds

PUT to SOMARDS the block, funds

GET from SOMARDS the return-message

IF return-message is “OK” THEN

SET in pr the certification to “Yes”

SET in pr the inbox_location to speck&approval

23
ELSE

SET in pr the to certification to “No”

SET in pr the explanation to return-message

SET in pr the inbox_location to requester

ENDIF

output -- certified_pr, rejected_pr

E53 Reconcile

Input -- N/A

Process 2.5

PUT to SOMARDS the block, reconcile

GET fkom SOMARDS the return-message

Output -- N/A

E54 Upload to SAACONS

Input -- assigned_pr

Process 5. I

GET from assignedgr the upload

PUT to SAACONS the upload

Output -- N/A

E55 Download fi-om SAACONS

Input -- assigned_pr, actual-cost, vendor, delivery-date, po_number

Process 5.3,5.4

GET from SAACONS the award

IF total_actual_cost are greater than

total_estimated_cost THEN

SET in pr the explanation to “Actual cost greater”

SET in pr the inbox-location to supervisor

ENDIF

GET from SAACONS the award

SET in pr the vendor, delivery-date, PO-number, award-date

SET in pr the inbox_location to receiving

Output -- ordered_pr, actual_pr

24
E6 Receive shipment

E61 Receive shipment

Input -- ordered_pr, receipt

Process 6.1

DISPLAY to user the orderedgr

GET from user the receipt

SET in pr the receipt

Output -- received_pr

E62

E63 Check off taggable items

Input -- received_pr, item-tag

Process 6.2

DISPLAY to user receivedsr

FOR EACH item in receivedgr

IF item-tag is “Yes” THEN

GET from user the item-tag

SET in pr the item-tag

ENDIF

ENDFOR

SET in pr the inbox_location to requester

Output -- tagged_pr

E64 Accept shipment

Input -- tagged_pr, acceptance

Process 4.3

DISPLAY to user taggedgr

FOR EACH item in taggedsr

GET from user the acceptance

IF acceptance is “No” THEN

GET fi-om user the explanation

SET in pr the explanation

ENDIF

25
ENDFOR

PUT closedgr into CLOSED

Output -- closed_pr

E7 Status inquires

Input -- active_pr

Process 7.3

GET current status from ACTIVE

DISPLAY to user the status

Output -- status

E8 Generate reports

Input -- report-type

Process 7.4 -- TBD

Output -- report

E9 Navigation

E91 Navigate

Input -- TBD

Process -- TBD

Output -- TBD

E92 Logout

Input -- N/A

Process -- TBD

Output -- N/A

6. Data Dictionary

While DFDs and pseudocode (structured English) are important to system specification,

additional information is required for a complete analytical model. The content of each data or

control item should be more fully identified. A data dictionary is a quasi-formalism for describing

content of information as it flows through the system The standard notation conventions are

26
Notation

=

+

[II

t >n

0

* *

Meaning

is composed of

and

either/or

n repetitions of

optional data

comments

BuyIt prototype’s data dictionary follows. Each left-hand element is taken from the DPD

and the Process Narrative representations of the system These data items are then given an

expanded, unambiguous definition in the right-hand column.

acceptance = *requester accepts or returns shipment item*

[“Yes” I “No”]

ACTIVE =

action =

action_results =

active_pr = *purchase request at some point in the approval cycle*

actual-cost = *actual cost of an item*

*units: dollars*

actual_cost_approval =

(active_pr}

**

TBD

**

TBD

*supervisory approval of the total actual cost of the

request*

[“Yes” I “No”]

27
actual_pr = *purchase request where the total actual cost is greater than

the total estimated cost*

approved_pr + {actual-cost} + {item_tot_act_cost) +

total_actual_cost

address = **

street-address + (maiLstop) + city + state + postal_code +

(country)

al-cost =

al,regdeld =

approved_pr =

assigned_pr =

award =

awd_date =

*SAACONS line item actual cost*

actual-cost

*SAACONS delivery date*

delivery-date

*purchase request that has procurement buyer approval*

assigned_pr + buyer-approval

*purchase request that has been assigned to a buyer by the

contracting officer*

orderable-pr + buyer-assignment

*SAACONS award download information*

awd_piin + pr_num + splline + awd_status + awd_date +

al_regdeld + al-cost + desc_text + vend-name +

vend_addrssl + vend-city + vend-stat + vend_zipcode +

vend-phone

*SAACONS line item award date*

*format: DD-MON-YY”

{legal-character}

28
awd_piin =

awd_status =

award-date =

bar-code-no =

batch-no =

blank_pr =

bldg_no =

blk_no =

blk_tkt_dt =

*SAACONS purchase order number*

TBD

*SAACONS line item award status*

{numeric-digit}

*SAACONS purchase order award date*

date

*property book bar code number*

{alphanumeric}

*SOMARDS batch number*

“BuyIt”

*purchase request with the requester and delivery info

filled*

requester_userid + userjrfo

*building number*

{alphanumeric}

*SOMARDS block number*

‘ ‘W’

*SOMARDS block ticket date*

*format: MMDDYY*

date

29
block =

buyer-approval =

buyer-assignment =

buyer_userid =

cancel_order =

CANCELED =

canceled_pr =

certifiable_pr =

certification =

certified_pr =

*SOMARDS build block data*

trns_cd + user_auth_key + cmd_dsg + update-code +

bll_no + blk_tlct_dt + tot_blk + batch-no + tot-batch

*buyer approval of purchase request*

[“Yes” I “No”]

**

buyer_userid + saacons_buyer_code

**

userid

*order to cancel purchase request*

[“Yes” I “No”]

{canceled_pr }

*purchase request that has been canceled*

active_pr + cancel_order

*purchase request that has fund source approval or actual

costs approved*

[completed_pr + fund_source_approval I actual_pr +

actual_cost_approval]

*SOMARDS certification*

r‘Yes” I “No”]

*purchase request that has been certified by SOhMRDS*

certifiable_pr + certification

30
city =

CLOSED = {closed_pr }

closed_pr = *purchase request that has been accepted by the requester*

tagged_pr + {acceptance}

cmd_dsg =

company-address =

company_email =

company_fax_no =

company_name =

company_phone_no =

company_poc =

**

{alphabetic-character}

*SOMARDS CMD-DSG”

“ ,, I

**

address

**

email_address

**

phone-no

**

name

31

**

{legal-character}

**

phone-no
completed_pr =

comt_ref_no =

corrected_pr =

corrections =

country =

cum_btch_value =

date-required =

delivery-date =

desc_text =

*purchase request that has been approved by the

supervisor*

@doc_ref_no + funded_pr + request-date +

supervisory_approval

*SOMARDS document reference number*

doc_ref_no

*purchase request that has been corrected by the requester*

rejected_pr + corrections

*corrections to a rejected purchase request*

TBD

**

{alphabetic-character}

*SOMARDS cumulative batch total for the days

certification*

*units: dollars*

*date shipment is required by*

date

*estimated date for delivery from vendor*

date

*SAACONS item description*

description

32
description =

desc_text =

doc_ref_no =

en-rail-address =

EMPLOYEE =

employee =

eor =

estimated_cost =

explanation =

finished_pr =

*item description*

{legal-character}

*SAACONS description text*

description

*purchase request document reference number*

“W-” + TBD

**

TBD

k-qloy~ 1

*employee information - the bare minimum should contain*

user)info + {roles}

*funding element of resource*

(alphanumeric}

*estimated cost of an item*

*units: dollars*

*rejection, cancellation, or return explanation*

{legal-character}

*purchase request where the total actual cost is less than or

equal to the total estimated cost*

approved_pr + (actual_cost} + {item_tot_act_cost} +

total_actual_cost

33
first_name =

fimd_source =

fund_source_approval =

funded_pr =

funds =

inbox =

inbox-inquiry =

inbox_location =

item =

*a person’s first name*

{alphabetic-character}

**

jo_no + eor

*budget analyst approval of fund source*

[“Yes” I “No”]

*purchase request with a fund source*

partial_pr + fund_source

*funding information for SOMARDS certification*

trns_cd + user-au&key + cmd_dsg + update-code +

blk_no + blk_tkt_dt + batch-no + rejrept_director +

doc_ref_no + jo_no + eor + act_amt

*purchase requests requiring action from user*

{active_pr)

**

TBD

*current purchase request location*

TBD

**

@line-item-no + description + unit_of_issue + qty +

estimated_cost + actual-cost + item-tag + acceptance +

item_tot_est_cost + item_tot_act_cost

34
.

items =

item-tag =

item-tags =

item_tot_act_cost =

item_tot_est_cost =

jo_no =

last-name =

line_item_no =

mail-stop =

name =

nomenclature =

**

{item} + specifications

*property book officer inputs “yes” item is taggable,

receiving overwrites with bar_code_no*

[“Yes” I bar_code_no]

{item-tags}

*line item total actual cost*

*units: dollars*

*line item total estimated cost*

*units: dollars*

*funding job number*

{alphanumeric}

*a person’s last name*

{alphabetic-character)

*line item number*

{numeric-digit}

*mail stop or department*

{legal-character}

**

first_name + last-name

*SOMARDS certification comment field*

{alphanumeric}

35
office_symbol =

orderable-pr =

ordered_pr =

partial_pr =

phone-no =

PO-number =

postal-code =

pr_authamt =

pr_authby =

pr_buyerid =

*ARL office symbol*

“AMsRL#-” + (alphabetic-character} + “-” +

(alphabetic-character )

*purchase request that can be ordered by procurement*

taggable-pr + property-approval

*purchase request that has been ordered*

finished_pr + delivery-date + vendor + PO-number

*purchase request with items and vendors filled in*

blank_pr + date-required + priority-code + items + vendors

*a phone number*

{numeric-digit}

*purchase order number*

TBD

*postal/zip code*

{numeric-digit}

*SAACONS authorized amount*

total_estimated_cost

*SAACONS authorized by*

TBD

*SAACONS buyer code*

saacons_buyer_code

36
pr_contact =

pr_details =

pr_item =

pr_num =

pr_phone =

pr_priority =

pr_reqdeld =

pr_type =

priority-code =

property-approval =

*SAACONS purchase request point of contact*

requester-name

*details about the purchase request*

TBD

*SAACONS purchase request item details*

pr_num + splline + splum + splcost + splqty + splreqdeld +

desc_text

*SAACONS purchase request number*

doc_ref_no

*SAACONS POC phone number*

requester_phone_no

*S&ICONS priority code*

priority-code

*MACONS required delivery date*

date_required

*SAACONS purchase request type*

*request priority code*

*range:01 - l&99*

{numeric-digit}

*property book officer approval*

[“Yes” I “No”]

37
9tY =

*quantity requested*

(numeric-digit }

receipt =

received_pr =

reconcile =

rejected_pr =

rej_rept_director =

report =

report-type =

request-date =

requester_userid =

*shipment receipt*

[“Yes” I “No” ]

*purchase request that has been received*

ordered_pr + receipt

*end of the day SOMARDS reconcile info*

tms_cd + user-au&key + cmd_dsg + update-code +

blk_no + blk_&_dt + batch-no + tot_blk + tot-batch +

ty_act_cd + cum_btch_value + variance

*purchase request that has been rejected*

active_pr + explanation

“SOMARDS REJ-REPT-DIRECTOR*

**

TBD

*type of report to generate*

TBD

*date purchase request was approved by supervisor*

date

**

userid

38
return-message =

role =

room-no =

saacons_buyer_code =

sole_sourcejust =

special-approval =

special_pr =

splcost =

spline =

*message returned from SOhJAKDS process*

[“processing complete” I “bad user_auth_key” I “wrong

update code” I “blk_no/blk_tkt_dt already exists” I

“accounting class displayed” I ‘blk_no/blk_tkt_dt doesn’t

exist” I “invalid jo_no” I “invalid eor” I “insufficient funds” I

“duplicate comt_ref_no” I “cum_btch_value” I “make

changes” I “variance” ]

*user role*

{alphanumeric )

*room number*

{alphanumeric}

*buyer’s SAACONS buyer code*

TBD

*&stification for using a single vendor*

{legal-character}

*approval fi-om a special approving officials*

[“Yes” I “No”]

*purchase request with special approvals*

certified_pr + special-approval

*SAACONS estimated item cost*

estimated_cost

*SAACONS line item number*

hne_item_no

39
splum =

splqty =

splreqdeld =

state =

status =

statusjnquiry =

street-address =

.

supervisory_approval =

taggable-pr =

tagged_pr =

*SAACONS unit of measure*

umt_of_measure

,

*SAACONS quanity requested*

qtu

*SAACONS item required delivery date*

date_required

*state or province*

{legal-character )

**

TBD

**

TBD

**

{legal-character}

*approval from supervisor*

[“Yes” I “No”]

*purchase request that has had item tags attached by

property book officer*

special_pr + item-tags

*purchase request that has been received and taggable items

have been appropriately tagged*

received_pr + item-tags

40
I .

total_actual_cost =

total_estimated_cost =

tot-batch =

tot_blk =

trns_cd =

ty_act_cd =

unit_of_issue =

update-code =

upload =

*the total actual cost of the purchase request*

*units: dollars*

*the total estimated cost of the purchase request*

*units: dollars*

*SOMANX batch number*

*units: dollars*

[,‘O.OO” I cum_btch_value]

“SOMARDS total block*

*units: dollars*

[,‘O.OO” I cum_btch_value]

*SOMARDS transaction code*

[,‘003” I “004’ I “3 1 O-1

*SOMARDS action code*

“C"

**

TBD

*SOMARDS update code*

[,,cM? I “NM?‘]

41
user_auth_key =

userjnfo =

userid =

variance =

vend_addrss 1 =

vend-city =

vend-name =

vend-phonevend-stat =

vend_zipcode =

*SOMAFUX user authorization key* ~ {alphanumeric}

*user information*

name + office_symbol + phone-no + bldg_no + room-no

**

{alphanumeric )

“SOMARDS variance between tot-batch and

cum_btch_value - should be 0.00”

*units: dollars*

*SAACONS vendor address*

street_address

*MACONS vendor city*

city

*SAACONS vendor name*

company_name

*SAACONS vendor phone number*

company_phone_no

*SAACONS vendor state*

state

*SAACONS vendor zip code*

postal_code

42
vendor =

vendors =

*vendor information*

company_name + company_address + company_phone_no

+ company_fax_no + company_poc + company_email

*up to three suggested vendors*

(vendor) + sole_source_justification

43

7. References

1. Business Process Reengineering Office. To-Be Model: Small Purchase. U.S. Army

Research Laboratory, Aberdeen Proving Ground, MD, July 1995.

2. Ulery, D., B. Schallhorn, and W. Jernigan. BuyIt: Sofhyare Development Plan.

SPAS-97-01, U.S. Army Research Laboratory, Aberdeen Proving Ground, MD, to be

published.

3. Yourdon, E. Modern Structured Analysis. Englewood Cliffs, NJ: Yourdon Press, 1989.

4. Business Process Reengineering Office. ARL Small Purchase System: Report Specifications.

Draft, U.S. Arrny Research Laboratory, Aberdeen Proving Ground, MD, October 1996.

45
IN'IENTIONALLY LEFTBLANK.

46
NO. OF

COPIES

2

1

1

ORGANIZATION

NO. OF

COPIES ORGANJZATION

DEFENSE TECHNICAL 1 DIRECTOR

INFORMATION CENTER US ARMY RESEARCH LAB

DTIC DDA AMSRL D

8725 JOHN J KINGMAN RD RWWHALIN

STE 0944 2800 POWDER MJLL RD

FT BELVOIR VA 22060-62 18 ADELPHJ MD 20783-l 145

HQDA

DAMOFDQ

D SCHMIDT

400 ARMY PENTAGON

WASHINGTON DC 203 lo-0460

1 DIRECTOR

US ARMY RESEARCH LAB

AMSRL DD

J J ROCCHIO

2800 POWDER MJLL RD

ADELPHJ MD 20783-l 145

OSD

OUSD(A&T)/ODDDR&E(R)

RJTREW

THE PENTAGON

WASHINGTON DC 20301-7100

1 DIRECTOR

US ARMY RESEARCH LAB

AMSRL CS AS (RECORDS MGMT)

2800 POWDER MILL RD

ADELPHJ MD 20783-l 145

DPTY CG FOR RDE HQ

us ARMYMATERIELCMD

AMCRD

MG CAJDWELL

5001 EISENHOWER AVE

ALEXANDRIA VA 22333-0001

3 DIRECTOR

US ARMY RESEARCH LAB

AMSRL CI LL

2800 POWDER MJLL RD

ADELPHJ MD 20783-1145

INST FOR ADVNCD TCHNLGY

THE UNIV OF TEXAS AT AUSTIN

PO BOX 202797

AUSTIN TX 78720-2797

ABERDEEN PROVING GROUND

4 DIR USARL

AMSRL CI LP (305)

DARPA

B KASPAR

3701 N FAIRFAX DR

ARLINGTON VA 22203-1714

NAVAL SURFACE WARFARE CTR

CODE B07 J PENNELLA

17320 DAHLGREN RD

BLDG 1470 RM 1101

DAHLGREN VA 22448-5 100

US MILITARY ACADEMY

MATH SC1 CTR OF EXCELLENCE

DEPT OF MATHEMATICAL SC1

MAJMDPHJLLJPS

THAYERHALL

WEST POINT NY 10996-1786

47
NO. OF

ORGANIZATION COPIES 4 DIR USARL

AMRSL CI W JERNIGAN

AMSRL CI E W MCCOY

AMSRL CI E B SCHALLHORN

AMSRL CI A R ROSEN

2800 POWDER MILL RD

ADELPHI MD 20783-1145

1111

17

DIRUSARL

AMSRL CS COL K LQGAN

2800 POWDER MILL RD

ADELPHI MD 20783-lJ45

DIRUSARL

AMSRL SE S A SINDORIS

2800 POWDER MILL RD

ADELPHI MD 20783-l 145

DIR USARL

AMSRL HR SF B FONOROFF

2800 POWDER MILL RD

ADELPHI MD 20783-l 145

DIR USARJ_,

AMSRL SL EA P STAY

WSMR NM 88002-5501

ABERDEEN PROVING GROUND

DIR USARL

AMSRLHRSFBAMREIN

AMSRLWMMJGRILLS

AMSRL WM IM R MCGEE

AMSRLCSAF’DORE

AMSRL CI c NlETUB1cz

AMSRL CI I D ULERY (12 CPS) ,f

48
3uyIt Prototype Software Requirements Analysis: A C-BASS Component

3rian R. Schallhom, Wade S. Jemigan, and Dana L. UIery

REPORT NUMBER

U.S. Army Research Laboratory

AI-IN AIvlSRL-CI-E ARL-MR-444

Aberdeen Proving Ground, MD 210055067

3. SPONSORlNG/MONlTORlNG AGENCY NAMES(S) AND ADDRESS lO.SPONSORlNG/MONITORlNG

AGENCY REPORT NUMBER

11. SUPPLEMENTARY NOTES

12a. DlSTRlBUTlON/AVAlLABlLlTY STATEMENT 12b. DISTRIBUTION CODE

Approved for public release; distribution is unlimited.

13. ABSTRACT(Maximum 200 words)

This document contains the software requirements analysis for a prototype of BuyIt. As a component of the

Corporate Business Application Software System (C-BASS), this application automates small purchase requests (tmdel

§2,500). The document follows the process of structured analysis, or step-wise refinement of requirements, as applied tc

the development of BuyIt. The “environmental model” includes a high-level system description, followed by a contex

diagram and a list of events to which the system must respond. The “behavioral model” includes a data flow diagran

(DFD) for each of the seven BuyIt subsystems. From this representation, the basic functional specifications are derives

and represented in structured English (or program design language). The fmal segment of the document includes a dan

dictionary.

14. SUBJECT TERMS 15. NUMBER OF PAGES

4 6

BuyIt, software requirements, BASS, C-BASS 16. PRICE CODE

17. SECURITY CLASSlFlCATlON 18. SECURITY CLASSlFlCATlON 19. SECURITY CLASSlFlCATlON 20. LIMITATION OF ABSTRACT

OF REPORT OF THIS PAGE OF ABSTRACT

UNCLASSIFIED UNCLASSIFIED UNCLASSIFIED UL

NSN 7540-01-280-5500 A0 Standard !fprrn 298 (Rev. 2-89) n____. -- . . ._. _. _^_ _^ ^^^ -....
hTENTIONALLY LEFT BLANK.

50
USER EVALUATION SHEET/CHANGE OF ADDRESS

This Laboratory undertakes a continuing effort to improve the quality of the reports it publishes. Your comments/answers

to the items/questions below will aid us in our efforts.

1. ARL Report Number/Author

2. Date Report Received

ARL-MR-444 (Schallhorn) Date of Report Mav 1999

3. Does this report satisfy a need? (Comment on purpose, related project, or other area of interest for which the report will

be used.)

4. Specifically, how is the report being used? (Information source, design data, procedure, source of ideas, etc.)

5. Has the information in this report led to any quantitative savings as far as man-hours or dollars saved, operating costs

avoided, or effkiencies achieved, etc? If so, please elaborate.

6. General Comments. What do you think should be changed to improve future reports? (Indicate changes to organization,

technical content, format, etc.)

Organization

CURRENT

ADDRESS

Name

Street or P.O. Box No.

E-mail Name

City, State, Zip Code

7. If indicating a Change of Address or Address Correction, please provide the Current or Correct address above and the Old

or Incorrect address below.

OLD * ADDRESS

Organization

Name

Street or P.O. Box No.

City, State, Zip Code

(Remove this sheet, fold as indicated, tape closed, and mail.)

(DO NOT STAPLE)