Requirements gathering

[yelluw]

@mjroney

The first step (that we've already discussed) is to gather the requirements for the app. Forget about code for now. Let's explain in plain words what is the problem being solved.

Example:

I want to know when an employee is able to take vacation time while avoiding scheduling conflicts.

Your turn ....

[mjroney]

For my location, we schedule all vacations prior to the start of the year, the scheduling is conducted under the following guidelines:

• Amount of days/employee is determined by years of service (benefit date)
• Order of selection is determined by seniority (seniority date)
• If an employee would earn a higher number of days during the coming year, due to their service length crossing a relevant anniversary, they would get to schedule those additional days after everyone had scheduled their days available as of Jan. 1
• the vacations should be scheduled to conform to several rules - no more than 10 single days, paid holidays cannot be single days, 3 singles in a week is max singles, full week (5 days) is allowed on holiday weeks. No more than 3 per day (scheduled) but I can waive that requirement at will
• the ability to print out reports for: those on vacation by day/by week/and full printout per person
• monthly view (simple calendar) showing days that are at max, and holidays easily picked out (bold and different color indications).

[mjroney]

Future plans

With vacations scheduled, and the ability to move them around by request, I would like to start developing the 'Report' functions.

1- email an employee all of their scheduled/taken vacation days for the year upon request. 2- text (SMS) reminders for vacations in the upcoming weeks.

Next: Using employee info and vacation info, begin to manage the tracking of overtime and training.

Reports will need to be generated for these functions, with the overtime needing to be auto-emailed on a weekly basis.

[yelluw]

Alright, this is great. I'll go ahead and look into the code and see how it matches what you described here.

[mjroney]

Cool... I wonder if a namedTuple would be better for the instance constructor. Might simplify the SQL portions. Also, is it better to store dates as Ordinal numbers? They are easier to manipulate than datetime objects, and a decorator could handle the conversion for formatting for the user.