"Expert Auctions Yield Superior Results"

Clarification of the Auction Rules

Typically, the implementation of auction rules is an iterative process that takes shape after reducing the rules to a test plan, a software tutorial, or actual code. On behalf of our clients or in collaboration with outside experts, Optimal Auctions addresses rule ambiguities and how they affect the software development costs. We provide creative, low-cost solutions that maintain schedule integrity and auction efficiency.

Business Requirements Document (BRD)

Any change requests to the OptimalCommerce^TM Software platform will be formalized in a Business Requirements Document (BRD) to prevent confusion about, or misinterpretation of, the required changes.

The BRD captures all descriptions, use cases, and mockups associated with changes to the platform's feature set. Usually these changes are independent of the changes to the software required by the auction rules but in certain circumstances the auctions rules can require changes to the user features. Typically, the BRD will contain an Introduction section describing the background and objectives of the project and any terminology specific to the project. Any critical dates or milestones will appear in this section. The document also captures changes to the color scheme, visual architecture, iconography, customizable fields (client logos, for example), and navigation features. Any restrictions on customizations are also articulated.

In summary, the BRD should capture all changes to the platform excluding those to market algorithm which implements the specific auction rules. These changes are captured in the Market Test Cases.

BRD Test Cases

The BRD Test Cases comprehensively examine every possible scenario in which the software may be used and provide explicit outcome expectations for each scenario. The Test Cases package consists of an overview, in which all cases are enumerated and organized, a spreadsheet, containing quick-reference shorthand descriptions of the cases and maps to the test case documents, in which the cases are spelled out in simple step-by-step instructions. Test Cases are constructed and organized very carefully by experts intimately familiar with both the software and the auction process in order to maximize testing efficiency.

The Test Cases provide the basis for software confidence. Once the auction software passes all tests, then both Optimal Auctions and the client can be confident that it will perform appropriately when deployed. Automation of the Test Cases enables a more efficient testing process, particularly when alterations to the software require significant retesting.

Market Test Cases

The auction rules specify the terms under which a market will take place. Each market must process orders (bids or trades) placed by the bidders. The rules establish certain constraints but otherwise participants are able to interact freely and independently with the market created by the rules and manifest in the software. These boundaries on the interactions of the users must be captured in the software and thoroughly tested before an event and this is the role of the market test cases.

A comprehensive test plan for each auction format and is based on the specific rules implemented. The Optimal Auctions development process includes the use of a comprehensive test plan that is developed prior to any code being written. The plan includes an overview listing each case and scripts that describe the exact actions of the testers and correct information that they should see produced by the software during each test. The purpose of the scripts is to define clearly the expected behavior of the software in representative circumstances. The formal process allows errors to be reproduced and audited. The challenge is identifying the border or rare cases which are complex but intimately related to the overall efficiency of the market. This development method is vastly superior to iterative or ad hoc software programming for several reasons. First, it is cheaper to render certain screens on paper before putting them to code. Second, the test plan, unlike human use, is verifiable and repeatable and thus increases the likelihood that ?bugs' in the software can be identified and fixed. Third, the test plan scope and results are auditable.

Additionally, certain information on the tables in the test cases is included like the rounding convention and when certain information is available to users.