Thursday, March 31, 2005

Church management software

One thing I'm looking to do is to make this blog a little more technically oriented. My other blog is really an Interactive Intelligence thing - the site is, and it's named after the Interactive product ClientCOM; so it really seems most sensible to keep posts to that blog on ClientCOM - tips and tricks for using it, etc. Unfortunately, soon after I started that blog, I stopped focusing on ClientCOM in order to do other things, so it has been dark for quite a while. I'd like this blog to be about some technical work I'm doing, as well as the books and plays I'm currently seeing. (Once again - blog categories. C'mon, Blogger!)

So my church is looking for a better way to handle benevolence requests. These are requests that come in from people who need charity - say, $100 for fuel in the winter, or help with gas to visit a sick mother. I was casting about for things I might do as a Micro-ISV, so I thought I might be able to help out - and perhaps, if it works out well for this one church, be able to sell the application to others as well. That's a bit of a ways off, though.

So I'm tackling this project; more or less on my own as far as the design goes. I don't think my "customers" are going to be too demanding, so I'll have to keep on top of them to make sure that the application is actually useful to them. I'll be creating the design and requirements, etc., myself, so I think this is a good application to use some agile methodologies on. Specifically, this project will have: Test-driven development, frequent iterations, and easy updates.

So what are the requirements? If I ask the pastor, I'll get an easy answer: A way to enter benevolence requests online, without paper forms. A surprising addition, to my mind, is: A way to track down resources that might be able to fulfill a request. What this is, basically, is an algorithm for finding places that will take vouchers for gas; maybe food banks that could help a hungry person, etc. To my mind, these are such different goals that I'll just be ignoring this one, until I get further along in the development. So I'll concentrate first on the paperless form.

So the next question is, as a techie, what requirements do I see that underlie this prime requirement?
  • A backing store
  • Data entry screens
  • Reports

Seem to be the minimum. I'll think about how I'll be fulfilling these requirements next time.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.