Payment Management Function

By Patrick Young,2014-11-26 12:21
13 views 0
Payment Management Function

Appendix CRequirement Drafting Guidelines

    Our goal is to publish a comprehensive set of functional requirements that can be used by agencies and vendors in developing more effective acquisition systems. To help ensure that our efforts produce consistent and accurate requirement text, we have adopted drafting guidelines for each type of requirement we deal with. The requirement types found in this document are as follows:

    ; Configuration

    ; Input

    ; Process

    ; Query

    ; Report

    ; Interface

    ; Non-functional.

    Our drafting guidelines call for starting every requirement statement with a standard verb as defined in this appendix. Definitions of other key terms that could affect an agencys

    interpretation of individual requirements can be found in the glossary. In reading each functional requirement, please assume the following opening statement:

    Deliver an automated capability to:

    A key objective in drafting these requirements is to eliminate ambiguous phrasing such as as

    applicable, as appropriate, or at a minimum.

    Examples, where included in requirement text, are not intended to be definitive. They are used only to help clarify the intent. Examples are identified with the lead-in phrase for example or

    such as.

    Configuration Requirements

    Configuration requirements describe functionality needed by an agency to create tables, structures, codes, labels, access rights, and rules.

    ; We use maintain when specifying functionality that will allow the user to directly enter,

    change, or delete configurable table items. For example:

    Maintain a unique procurement instrument identifier (PIID) structure.

Exposure Draft Version 1.008/17/2007 C-1

    Appendix CRequirement Drafting Guidelines

    ; We use define when the intention of the requirement is to allow the agency to specify

    edits, business rules, workflows, required code values, or other conditional processes.

    For example:

    Define required levels of approvals by document type and processing actions.

    ; We use customize when referring to the ability to allow the agency to enter and

    modify displayed field labels, report tiles, column headings, or user interface settings.

    For example:

    Customize the text to be displayed on system-generated bills.

    Input Requirements

    Input requirements describe how different types of information are to be entered into the system. Input requirements cover individual data elements and documents.

    ; We use associate when referring to establishing a relationship (i.e., link) between data

    records. Associations are normally created automatically by the underlying database

    software when new records are added. For example:

    Associate order/contract documents with original acquisition action request


    ; We use capture when the intention of the requirement is to store new information or

    link other stored data to a new record. Captured data can be user entered or system

    generated. The ability to subsequently retrieve, modify, or delete captured information is

    assumed. For example:

    Capture document modifications at the line item level.

    Capture suggested sources (multiple).

    ; We use classify when referring to capturing attributes that are used to categorize

    documents, data, and records. For example:

    Classify contracts by the following procurement elements:

    ; We use update when the intention of the requirement is to allow the agency to modify

    an existing data record. Updates can be entered online or generated from an imported

    transaction file. For example:

    Update payment terms.

    Process Requirements

    Process requirements describe automated tasks performed on data entered into the system. Processes include validating data, generating reports, and notifying users. Because process requirements cover a wide range of functionality, they are written using a variety of standard syntax rules.

Exposure Draft Version 1.008/17/2007 C-2

    Appendix CRequirement Drafting Guidelines

    ; We use activate when requiring the system to make provisions and clauses available

    for use, upon the prescribed effective date. We use deactivate to make the

    provisions/clauses unavailable to the system.. For example:

    Activate or deactivate provisions/clauses for use based on effective date. ; We use allow when referring to functionality inferred to be available in the system;

    indicating that the functionality exists in the system and the user is permitted to used it.

    For example:

    Allow users to hold documents for data entry completion or processing at a later

    date. Identify held documents as distinct from system suspended documents ; We use apply when requiring the system to automatically initiate an action based upon

    agency business rule.

    Apply validation edits to all documents regardless of their original source. ; We use archive to specify functionality used to store processed, non-current data to a

    segregated storage area, subject to read access and retrieval. For example:

    Archive closed acquisition action request, synopsis, solicitation, order, and

    contract documents.

    ; We use assign when requiring the system to automatically determine which CS/CO is

    to be responsible for the action; route the action to the CS/CO; identify and capture the

    assignation based upon established agency business rules.

    Assign person (by user ID) authorized access to source selection and business

    sensitive information.

    ; We use calculate when referring to system functionality needed to compute a result

    based on a defined arithmetic formula. For example:

    Calculate period of performance end date.

    ; We use consolidate when requiring the system to identify associated line items based

    upon the business rules of the system and agency, combine them, and omit duplications.

    Consolidate line items from multiple AARs onto one Acquisition plan.

    ; We use determine when referring to functionality the system uses in applying business

    rules. For example:

    Determine offeror/bidder eligibility based on EPLS data.

    ; We use the FAR term distribute when referring to the system functionality which

    allows a user to send a document to a defined list of people.

    Distribute final award document and associated notifications to the user-defined

    distribution list based on notification rules.

    Exposure Draft Version 1.008/17/2007 C-3

    Appendix CRequirement Drafting Guidelines

    ; We use flag to refer to the marking of records to indicate a status or the need for future

    action. For example:

    Flag ineligible vendors.

    ; We use generate when the system must originate information. For example:

    Generate a report of AARs.

    ; We use identify to refer to the lookup/retrieval of information based on an entered

    parameter. For example:

    Identify contracts that use the following provisions/clauses.

    ; We use monitor to refer to the management of the review status or financial status of

    a contract. For example:

    Monitor the status of reviews and approvals required for any financing, interim,

    and partial payments.

    ; We use notify when the system must issue an e-mail or other online message to

    inform or send an alert to the user. For example:

    Notify contracting officer of changes in payment status, reviews, and approvals. ; We use prevent when the system is required to stop a user from completing an entry

    or initiating a process. In some cases, actions that are prevented are subject to override.

    For example:

    Prevent the deactivation of vendors that have unliquidated obligations or unpaid

    invoices in the system.

    ; We use process to refer to the system manipulation of captured data. Processing can

    involve multiple steps. Processing can be triggered by user request, job submission, or

    other internal system logic. For example:

    Process suspended documents upon changes to funding data.

    ; We use reference to refer to the association of document line items to prior document

    lines. For example:

    Reference multiple prior documents in a processing chain.

    ; We use route when referring to the integrated workflow management capability which

    allows the user to send documents to the appropriate selected people, usually for


    Route plan for review and approval based on agency-defined workflow.

    Exposure Draft Version 1.008/17/2007 C-4

    Appendix CRequirement Drafting Guidelines

    ; We use select when requiring the system to identify information, and then flag it or add

    to an internal list available to query or report on.

    Select attachments, such as specifications and standards, engineering drawings,

    and other technical data applicable to Section J of the UCF.

    ; We use store when referring to the storage of documents or data within documents in

    the acquisition system. For example:

    Query agency procurement history for recent vendor procurement actions. Store

    data for use during evaluation, negotiation, and selection phase.

    ; We use suspend when requiring the system to place a document or other work item

    into a holding queue subject to later retrieval, correction, and completed processing. For


    Suspend incomplete documents and those that fail edits (i.e., save for later

    retrieval and processing).

    ; We use validate when requiring the system to confirm the validity of entered

    information against a defined business rule. For example:

    Validate that funds are available before recording the modifications.

    Query Requirements

    Queries are requirements for accessing system-maintained information online. By default, query requirements must be satisfied using real-time Acquisition system application screen displays on demand. As an option, some complex, high-volume queries can be satisfied using a separately delivered business information query (BIQ) tool (e.g., data warehouse). Unlike Acquisition system queries, BIQ queries are generally scripted, stored, and queued for execution. The following applies to formatted online displays of system-maintained information.

    ; We use query to specify data selection, summarization, and display. For example:

    Query documents. Parameters include any document number. Result is a list of

    all related documents in the documents processing chain. Drill down to

    supporting transactions. Parameters include any document number. Result is all

    document line items from documents in the parameter documents processing


    ; We use parameters include to specify the selection criteria. When multiple

    parameters are listed, it is understood that one or more (any combination) of the

    parameters are to be applied. Parameters should allow for selection of one value, a

    range of values, or all values. For example:

    Parameters include vendor number, vendor legal name, vendor DBA name,

    vendor division, vendor TIN, DUNS number, IRS 1099 indicator.

Exposure Draft Version 1.008/17/2007 C-5

    Appendix CRequirement Drafting Guidelines

    ; We use drill down to specify functionality used to display detailed supporting entries

    for a query-selected summary record. This action typically follows a specified query. For


    Drill down from listed documents to document details.

    ; We use result is to specify the output to be presented in the sequence requested. This

    action typically is at the end of a query. For example:

    Result is a display of all vendor data for the specified vendor. Output options

    include an Excel formatted data file. (See requirement AQ-SMB-01 for complete

    list of elements.)

    Report Requirements

    Report requirements describe system-generated outputs that have predefined form and content. They can be scheduled or generated on demand. All reports must be printable. Some reports also are designated as being online. Online reports are usually subject to additional drill-down. Report requirements also specify the data to be listed or summarized.

    ; We use generate a report to describe the users requirements for formatted output.

    For example:

    Generate a status report of contract file items. Select contract documents based

    on any combination of the following parameters entered by the user (e.g.,

    contracting officer, vendor name, date range). List the contract file items for each

    contract number, contract status, vendor, program office, agency, contract value,

    and date of award.

    ; We use output options include to specify sorting options or other special format

    requirements. Reports must be printable by default. Some reports can be designated as

    online and subject to additional drill-down. For example:

    Output options include sorting and summarizing reported data by contract

    number and contract status.

    Interface Requirements

    Interface requirements define the need to exchange transactional data with another internal agency or an external governmentwide system. An example of an internal transactional requirement is the requirement for an acquisition system to generate transactions needed to send and post solicitations in the FedBizOpps system. An example of an external interface requirement is the requirement for the Core system to provide accounting classification data to inform the Acquisition system that funds are available for obligation or the requirement for the Acquisition system to generate transactions needed to establish commitments in the Core system.

    ; We use interface when requiring the system to provide an operational link with another

    identified internal or external system. For example:

    Interface with the agencys Core Financial Management system.

Exposure Draft Version 1.008/17/2007 C-6

    Appendix CRequirement Drafting Guidelines

    ; We use import when requiring the system to receive and process data originated in

    another financial or mixed system. For example:

    Import vendor updates from the CCR system.

    ; We use export when the intention of the requirement is to generate and send a

    transaction file to another system for processing. For example:

    Export the notice of the proposed contract action synopsis to FedBizOpps (see

    FAR 5.1).

    Non-Functional Requirements

    Non-functional requirements do not specify a system capability. They are generally references to standards, rules, or policies maintained by others. These types of requirements are found more frequently in the technical area.

    ; We use comply with a defined external standard. For example:

    Comply with Workflow Management Coalition (WFMC) Workflow Standard


    ; We use deliver to specify non-functional features that must be included as part of the

    baseline product. For example:

    Deliver user, system, and operating documentation.

    ; We use support for requirements referencing a defined government policy. For


    Support direct EDI translation compliant with American National Standards

    Institute (ANSI) X-12 standards.

    ; We use incorporate to specify principles and best practices that should be reflected in

    a delivered package. For example:

    Incorporate open-systems architecture.

    ; We use operate to specify computing environments in which a package should or must

    be designed to run. For example:

    Operate in a server computing environment running under UNIX, LINX, Windows

    Server 2000 or above.

Exposure Draft Version 1.008/17/2007 C-7

Appendix CRequirement Drafting Guidelines

Exposure Draft Version 1.008/17/2007 C-8

Report this document

For any questions or suggestions please email