Payment Management Function

By Patrick Young,2014-11-26 12:21
12 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