Before we can begin any serious coding of the recently introduced "dotNetRegister" reference app, we need to define some some requirements. As with any good agile development effort, I want to create a backlog of features that need to be implemented and then prioritize development from there. I even intend to work on this application in sprints, though clearly, as a part time project, I don't expect to have a stellar burn-down rate.
ASIDE: If any of these agile terms- like backlog, sprint, or burn-down rate- are unfamiliar to you, I highly encourage you to spend a little time becoming more familiar with agile development. Agile is an excellent way to manage many projects, not just development projects (in theory, you could do "agile honey-dos"), so it's well worth your time to understand its core concepts.
To begin defining our functional requirements, let's first establish the scenarios we want our v1 dotNetRegister to support:
- Exhibitor Registration- We want our system to intuitively support any event that needs to collect registrations from companies that will be exhibiting at the event (usually in a booth). We want this process to be very flexible, though, so the exhibitor registration should also support sponsorship options. In fact, maybe sponsor registration should be spun-out in to its own process since many events have sponsors that do not exhibit. We'll have to keep this in mind as we refine what our exhibitor registration process should like; for now we'll make sponsor processing part of exhibitor registration.
- Attendee Registration- We want our system to optionally support attendee registration for events. Many events, like code camps, conferences, and job fairs, require that attendees register before arriving. Attendee registration is often as simple as an RSVP process, but for larger conferences it's a complete process that requires payment processing. We need our system to be configurable enough to handle this range of scenarios.
If we build a system that is flexible and configurable, with easy to use front-end registration tools backed by simply powerful admin management tools, we should have a system that is capable of handling everything from college job fairs to code camps to shows like TechEd. To help provide some focus for early development though, I will focus on serving the needs to two particular use cases:
- Job Fairs (my domain expertise)
- Code Camps (different enough from job fairs and a good target user for our system)
Beyond our primary scenarios and use cases, at high level we also want our system to be able to:
- Process credit card payments (with a configurable architecture for plugging-in different payment processors via configuration files)
- Support a "sandbox" mode (for easy regression and integration testing)
- Pass the Mom Test (many organizers of events are non-tech people and we want the system to be as intuitive as possible for them)
- Run in .NET 2.0 + ASP.NET AJAX or .NET 3.5 environments (including shared hosting)
- Be quickly configured (via config files for basic app settings and interactive wizards for event setup)
- Support multiple clients (that means web services- we want to be able to have mobile and client UIs to manage our data)
- Support multiple simultaneous events (a single system should be able to process registrations for multiple events)
- Track event history (in other words, be able to "instance" events for historical reporting)
That's a good place to start for now. There are many, many more specific functional requirements for the system, but we'll start here. In my next update, I'll build and explain several use cases that will support our application design process. And once we have our use cases, we finally move-on to creating some code. In the mean time, let me know what you think of these requirements. Would you like to make sure the system covers other specific scenarios? If so, share your ideas in the comments and we'll use those to refine our initial requirements.