Application Development Part 2: Preliminary requirements

In Part 1 of this series I explained my need for better time and goal management software, and my rationale for creating that app rather than using one or more off-the-shelf products. Time flies - I need this app yesterday!

Now it's time to start sketching out a few requirements:

• Enter goals

• Enter tasks

• Assign tasks to goals (tasks to goals is a many to many relationship)

• Easily track time allocated to tasks

• Pop up a reminder when the computer has been idle, asking what to do with apparently unallocated time

• When switching to a new task, immediately stop tracking time on any previous task

• Allow for categorization of tasks

• Add tasks without allocating them to a category or a goal - a way to jot down notes and figure out what to do with them later

• Pre-allocate blocks of time in a day for certain tasks/categories and have the app remind me when it's time to switch

• Report on a day or week or any arbitrary block of time and see

  • How much time was spent per category

  • How much time was spent per goal

  • How much time was spent per task

  • How much of the budgeted time was used, and whether it was used for its intended purpose

• Have templates for pre-allocated blocks so I don't have to enter them each time

• Add appointments/events to a calendar

• When appointments/events come up, have the option to defer or reschedule

• Mark appointments/events as completed

• Show a running tally of time used compared to time as planned

• When creating a new task, look for older tasks that may be a match just in case I've already been there and have forgotten

• Be able to assign values for importance and urgency (a long time ago I wrote a "four quadrant" todo list manager based on Stephen Covey's technique, and I still have a fondness for that approach)

I'm always amazed at how simple requirements grow into complex requirements. I really didn't think I was contemplating anywhere near that many features until I wrote them down. And I'm sure others will come to mind as I go along. 

I still have lots of questions. I'm a little fuzzy on how I want to handle categorizing of tasks. OfficeTime uses projects and categories, neither of which is dependent on the other. That's okay, but I've found it a bit clunky as changing tasks usually involves changing projects and changing categories. I almost think I want to be more task-centric - when I set up a task I assign whatever categories I need to assign, and then I switch between tasks (somehow) with a single click. 

But I'm probably ready to start putting my ideas together into something approaching the very beginning of a design.

Where to start?

There are a million different ways to arrive at a software design; what I'm describing here is a fairly simple example, and you don't have to follow my approach slavishly. 

I have a fondness for entity-relationship diagrams; they not only help me visualize the relationships between groups of data, they often get me thinking about how I want to structure the code that will manipulate that data. 

Here's the first cut of my ERD:

Open

Years ago, when I got to this stage, I'd dive into the data dictionary. Or maybe I'd be in the dictionary from the very first thought about the app. Clarion devs always start with the dictionary, don't they? 

Well here' s my first and most important principle for software development:

Yes, I'm shouting. Data dictionaries are massively useful things in Clarion development, but too often they come into the picture way too early. 

But if the dictionary isn't the first step, what is? 

You'll have to wait for the next installment to find out. In fact you'll have to wait a little longer, because in order to take the next step (here's your clue) there's a certain freely available library that I need to update for Clarion 9 (and which I need to bring back into the ClarionMag sphere).