Saturday, May 9, 2009

The Summer Project 2009, Part 1: Ye Olde Requirements Gathering

Computers, being machines, do what they are instructed to do, exactly as they are instructed, whether it's what you actually wanted or not. And you can't tell the machine what to do if you can't communicate what you want. Specifically. With every contingency covered. Formally, the task of documenting what software should do (or provide) for the user is called Requirements Gathering. Incorrect or incomplete requirements will lead to a project that doesn't meet its intended need. Overly inclusive or optimistic requirements can lead to epically long schedules and a complete lack of income. Imprecise requirements can lead to bad assumptions and headaches for everyone involved. Requirements gathering is crucial to the success of a software project, and the task goes on from before it is conceived throughout the construction of the software, and often even after a project is complete. It's also a difficult, often thankless task of trying to build a communications bridge between the people who create the software and the people who use it. Neither party tends to have a clear idea of the end goal, especially early in the process. Luckily for me, all the voices I need to hear for this particular project already live in my head.

Now that I've written a whole paragraph about how important requirements are, let me see if I can actually come up with some for my money tracker. Let me see... I need to be able to enter transactions, both coming in and going out, which assign monetary values to descriptive categories. These transactions each belong to a single account, but the categories are the same across all the accounts. There will be more than one account to track. Transactions should be editable, including the ability to void them. I should be able to mark a transaction as reconciled against a statement. Once transactions are marked as reconciled, they should no longer be (easily) editable. I would like to be able to generate reports for a given time period about income vs. outlay and for all the transactions per category across all accounts. That's probably plenty for starters.

I'm intentionally being very informal with these requirements. Sometimes, programmers have the luxury of having a nice, tight, technical set of functional requirements provided to us, but most of the time we don't. Instead, we start with a bit of ambiguity built in, and refine as we go (hopefully with input from all the necessary stakeholders). Next time, I'll look at some ways of figuring out what these requirements mean in the realm of a computer program.

No comments: