Client View: Spec Writer Contest

Contents of this Page:

Rules
Ideas
How to Enter
What Makes a Good Spec?
Key Components Your Spec Should Contain
Sample Project Overview
Sample Programming Instruction
Tips on Constructing a Spec Document
Using Our Word Template
Techniques for Making Screen Mockups
Other Helpful Resources
Download the brochure
Download the Word Template (Word 2003)

A new contest to reward the software designer hidden inside you:

$2,500 for the best specification!

Are you a closet software designer looking for expression? Do you have a cool idea for a big new CU*BASE or It's Me 247 feature? Are you good at explaining complex concepts in writing?

Designing software requires equal parts imagination, visualization, logic, organization, and strategy. If you are a creative inventor that's also good at solving logic problems and thinking three moves ahead when playing chess, you might just have what it takes to design CU*BASE tools!

If you enter the CU*Answers 2010 Spec Writer Contest, not only will you see your project idea come to fruition, you will also have a chance to win $2,500 in cash!

Contest Rules

Spec must be submitted in a Microsoft Word (2003 or 2007) formatted document (can include attachments like calculation worksheets or graphics if appropriate).
Must be a minimum of 7 pages* of content.
Must include a thorough big-picture introduction suitable to be adapted for the Release Summary when the project is implemented.
Must include mockups of all related screens with explanations and illustrations of the specific changes to be made. (Instructions on how to use our standard template will be provided; see "How to Enter" below.)
Must follow the good spec guidelines when it comes to detail and structure, as outlined below.

The spec that is judged by our panel of expert software designers and developers to be closest to programmer-ready (requiring minimal or no editing before development can begin) will win!

* This is the average length of our specifications, but it is not unusual for a spec to run 10-25 pages long. So if you are one of those people who writes, "I can't believe you are making me write 50 words on this subject" on an Idea Form, then this contest might not be for you.

Project Ideas

Choose from the following sample list of projects, or, better yet, pick one of your own:

Idea	Description
Skip-a-Pay for Loans	An on-demand process for when a member opts in for a credit union's skip-a-pay program (regular loans only, since we already have skip-pay tools for online credit cards). Detail the exact calculations, file maintenance, screens and workflow, etc., to accomplish this from a programming standpoint.
Recurring Wires	A configuration and work process to handle common wire transfers. Include detailed specifications on how data should be stored, retrieved, what the screens will look like, how the workflow will work, etc.
Savings Bond Redemptions	(Integrated into teller processing.) A complete flow with screens and instructions for how the process will interface with the teller drawer and G/L, configurations, file maintenance, etc.
Next Suggested Products	(Calculation "engine" and integration into CU*BASE and It's Me 247.) Either flesh out one of the new ideas from the project outline introduced during CEO Strategies, or come up with your own calculation, configuration, and workflow that defines how the system should suggest new products and services to members.
Any other project you are passionate about!	Just keep in mind the contest rules and propose a project with enough complexity to warrant at least 7 pages of content.

The fine print: Whether you choose one of our ideas or develop one of your own, CU*Answers reserves the right to schedule completion of your project according to current priorities and resource availability. We also reserve the right to make adjustments to the final design according to software standards and compatibility with existing tools and technology.

How to Enter

To enter: Send your spec document(s) via email to Dawn Moore, VP Writing Team/Product Design. All entries become the property of CU*Answers, Inc.

Deadline: All entries must be received and acknowledged no later than April 30, 2010. Judging will take place during May and the winner will be announced at the 2010 Leadership Conference on June 23, 2010.

What Makes a Good Spec?

Writing a project spec requires the ability to imagine and clearly explain a big-picture, high level overview of a project, and get down to the nitty-gritty details that define how the software will behave and what the end-user experience will be.

Key Components Your Spec Should Contain

Part 1:	Introduction/Project Overview	This is the elevator speech that defines the overall scope of the project, introduces key concepts, and explains the overall purpose and goals of why the project needs to be done. Imagine explaining your vision to a colleague at another credit union. Items to include in this section: Purpose and goals of the project; expectations from an end-user's standpoint Timeline and general deadline, if any (i.e., reg. change date, etc.) Outline of any future enhancements anticipated in the long term
Part 2:	File Changes Overview	A quick overview of what new files and new fields, if any, are anticipated with the project.
Part 3:	Changes to Screens, New Screens, Workflow, Field Specifications	This is the "meat" of the spec and includes mockups of how the screen(s) should look, changes to screen layout, instructions on workflow, detailed field specifications, descriptions of how all command keys should work, and so on. Every screen throughout CUBASE that will be affected must be detailed. Do Account Inquiry screens need to change? Which ones? How? Do the main Phone Op, Inquiry and/or Teller Verify Member screens need to be modified? How? What about maintenance screens such as Update Membership Info or Update Account Info? Which screens and how? All screen changes must be clearly mocked up and included in the spec document itself (not screen prints with handwriting on them). These sections should also include specific messages and verifications the program should use to prevent common user mistakes. We call these "edits" and they are generally instructions like this: "If Activate...* is set to Y, also require a valid, eligible account # to be entered."
Part 4:	Changes to Reports and Report Selection Screens	If a report is involved, whether a new one or changes to an existing one, include a mockup of the changes to the report selection screen. Also include a sample of the printed report with specifics on how the data will lay out, mocked up with sample data.
Part 5:	Menu Changes Overview	A quick list of new menu options that might be needed, with ideas about where they should be located.

If you're wondering what our judges will be looking for, consider the following examples:

Sample Project Overview

Instead of:	Try something like this:
Create a debit card round up program to round up purchases to the nearest dollar and deposit them to a savings account.	This project represents our take on the KeepTheChange© program from Bank of America and similar programs that help members save by automatically "rounding up" each purchase made via a debit card and depositing the extra money into a designated savings account. The most important element of this product is one that might not be obvious at first glance when you read marketing materials from BofA and other financial institutions: *The round up process is not* posted immediately, on a per-transaction basis.** Instead, a daily process will calculate the round up amount for all debit card transactions posted that day and post a single transfer from the checking account to the savings account. To put it another way, if you go to Macy's and spend $94.73, the transaction that posts to your account will be exactly $94.73, not $95.00. At the end of the day, that extra 27¢ (along with any other amounts calculated on other purchases throughout the day) will be transferred from your checking to your savings account.

Instead of:

Try something like this:

Create a debit card round up program to round up purchases to the nearest dollar and deposit them to a savings account.

This project represents our take on the KeepTheChange© program from Bank of America and similar programs that help members save by automatically "rounding up" each purchase made via a debit card and depositing the extra money into a designated savings account.

The most important element of this product is one that might not be obvious at first glance when you read marketing materials from BofA and other financial institutions: The round up process is not posted immediately, on a per-transaction basis. Instead, a daily process will calculate the round up amount for all debit card transactions posted that day and post a single transfer from the checking account to the savings account.

To put it another way, if you go to Macy's and spend $94.73, the transaction that posts to your account will be exactly $94.73, not $95.00. At the end of the day, that extra 27¢ (along with any other amounts calculated on other purchases throughout the day) will be transferred from your checking to your savings account.

Sample Programming Instruction

Instead of:	Try something like this:
Write out a Tracker record	When the user presses F10 to save the CTR at any point (every time it gets edited, whether the first time through or later on), write a note to the member's Audit Tracker (Type AT) - don't need to display any Tracker screens for user input or provide any confirmation message; just create the note behind the scenes: Use Memo Code CT (code description "CTR form") CONVERSION NOTE: Doesn't look like this is one of our standard ones, but will still need to verify all CU configs for this memo code; please advise if this is already used by any CUs, then arrange for a conversion program to create this code in all CU libraries upon implementation Use the following text in the Tracker note: "CTR form created / modified" and include the date and time, Employee ID, and CTR form number.

Instead of:

Try something like this:

Write out a Tracker record

When the user presses F10 to save the CTR at any point (every time it gets edited, whether the first time through or later on), write a note to the member's Audit Tracker (Type AT) - don't need to display any Tracker screens for user input or provide any confirmation message; just create the note behind the scenes:
Use Memo Code CT (code description "CTR form")
CONVERSION NOTE: Doesn't look like this is one of our standard ones, but will still need to verify all CU configs for this memo code; please advise if this is already used by any CUs, then arrange for a conversion program to create this code in all CU libraries upon implementation
Use the following text in the Tracker note: "CTR form created / modified" and include the date and time, Employee ID, and CTR form number.

See the difference?

Other Things That Lead to Good Specs

Use examples to illustrate complex calculations or scenarios that the software is intended to handle. If you are mocking up a screen sample, put in some realistic data to help illustrate how it will look and be used.
Include more detail than what you think the programmer needs. Don't make assumptions. Better to be too clear than to leave something out.
If you are making a change to an existing screen or feature, showing both a "before" and "after" view can make it much easier to see what is changing.
Remember that the project must be testable, so thinking about how you might test the changes can help you write clearer, more complete instructions in the specs.
Include notes about converting existing data to any new uses/formats.
Include documentation/end-user notes to explain difficult concepts or to justify a particular method selected (i.e., why did you do it that way?).
Keep the end-user in mind and anticipate their questions to make the workflow, field labels, and layout as intuitive and easy to use as possible. Longer field labels are better than short ones if they eliminate questions and keep someone from having to open help or call a CSR.
Follow standard screen layout conventions for consistency and to make the software easy to learn.

Tips on Constructing a Spec Document

Using Our Word Template

You can organize and format your spec document any way you wish, but if you want a sample layout to get started, open the Project Spec template that our designers use (Word 2003 format). Then simply copy, delete, rearrange, and modify the sample content from this template as needed.

Techniques for Making Screen Mockups

One method for making screen mockups showing your changes is to use any graphic editing tool to mock up a screen in the GOLD format. Our Word template contains a sample empty GOLD panel you can copy and modify. Make sure your spec content still defines field lengths and other details clearly.

Another method is to do what our spec writers do: mock up a host screen change. If you right-click on the title bar of any CU*BASE GOLD screen and choose "Show Emulator" you'll see what a host screen looks like. By copying this plain-text data into a properly formatted Word document, you can manually type field labels and rearrange screen information as needed to illustrate how the user interface should look. This format is particularly handy because it makes it easy to show field lengths.

CU*BASE A sample blank screen is provided in the Word template. If you are modifying an existing screen, follow these steps to pull the existing screen into your spec:

Navigate to the screen in CU*BASE GOLD
If you haven't already, right-click on the title bar and choose "Show Emulator" to view a separate window showing the host layout
With your mouse, click and drag to drag a rectangle around the entire colored area of the screen. When you let go of the mouse, everything in the outlined area is automatically copied to your clipboard (you don't have to choose copy)
In your Word document, position the cursor where the screen should appear
Apply the ScreenShots3 style
From the Edit menu, choose Paste

Other Helpful Resources

If you want to see some samples of specs from recent projects, contact Dawn Moore dmoore@cuanswers.com. We can pass along the spec from a specific project or just provide a sampling of several different-sized projects, including some that have been implemented as well as ones that are currently in development.