Church management software Part 2: Inherent requirements

So now we have a basic goal for the application; we have a vague idea what the users are going to want to do with it; the next question is, what are users never going to think about but are going to complain about if it is not present? Here's a few of those things.

#1: Security. We're talking about entering some very private information into a database here; not only are we talking about requests for charity, but personal data like social security numbers will be a likely requirement. Right now, the list of people to whom this information is available consists of: (a) the pastor, and (b) the deacons, and the file is kept locked in the pastor's office. So, while the ideal design would be a distributed one, keeping an online database behind a firewall and accessing it through a web service, I don't feel like I can guarantee the necessary security; even if I could talk all the users into keeping a nice strong password. So, for the initial pass, the data will be kept in local files on the computer. Presumably, when it is actually deployed, it will run on a single password-protected computer. I have some thoughts about using Windows Users and Groups to handle Role issues.

#2: Integrity. An important requirement for a church, huh? But specifically, I mean that the data shouldn't be corrupted; or at a minimum, regular backups should be arranged. The target audience for this project is a small church, and it's a pretty good bet that they won't be doing nightly tape backups of their systems. So at a minimum, regular backups should be done like Microsoft Word does, every minute or so; but ideally there would be a way to automatically back up to a different machine.

#3. Updatability. This is an agile requirement, really. I want to make the software very easy to update so that users will be encouraged to use the latest software at all times. This is a huge benefit for software developers. There's nothing worse than trying to figure out an issue based on a user who's running code from two releases, three service packs, and a hotfix ago. If people come to me for support, my first question will be, "Are you running the latest code? No? Update, and call me back if it's still happening."

Another agile requirement is that you avoid overdesigning the aplication. So, it's past time to write some code. One concept that really appeals to me is "Release 0". That's where you get an application out there that doesn't do anything at all except know how to update itself. Let's see if we can do that next.