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:
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:
Beyond our primary scenarios and use cases, at high level we also want our system to be able to:
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.
@toddanglin on Twitter