This project is read-only.

Actors

(indicated by a bold word within curly brackets { } )
  1. {User} - A person who must record times against project tasks
  2. {Group Admin} - A person who can administer a |Group| of users (Note: they can be a {User} themselves in one or more groups)
  3. {Global Admin} - A person who can administer all |Group|s (Note: they can also be a {Group Admin} in one or more groups and thus a {User} in one or more groups)
  4. {T-Rec} - The core system for time recording which this project relates to
  5. {Source Of Project Tasks} - One or more systems external to T-Rec which can be a source of Project and Task information

Components

(indicated by a bold word within angle brackets < > )
  1. <Client UI> - The User Interface(s) which a {User} has access to
    1. <Client UI Wnd> - The windows <Client UI>
    2. <Client UI Web> - The web <Client UI>
  2. <Group Admin UI> - The User Interface(s) which a {Group Admin} has access to
  3. <Global Admin UI> - The User Interface(s) which a {Global Admin} has access to
  4. <T-Rec DataSource> - The source of data which is stored for use with {T-Rec}
  5. <Project Task DataSource> - The source(s) of data exposed to {T-Rec} by {Source Of Project Tasks}

Business Concepts

(indicated by a bold word within pipes | | )
  1. |Timesheet| - A collection of times recorded between a start and end period
  2. |Signoff| - At the end of a |Timesheet| period, the times recorded can be 'signed off' or 'approved'
  3. |Group| - A group of one or more {User}s which is administered by one or more {Group Admin}s
  4. |UserId| - The unique identifier for a user within the system

Functional Requirements

  1. <Client UI Wnd> must be able to run as a system tray icon in Windows XP & Vista
  2. <Client UI Wnd> must be able to run with a different |UserId| or the logged on windows user
  3. <Client UI Web> must be accessible via a web front end
  4. <Client UI Wnd> must have a prompt appear when the system tray icon is available which reminds {User} to enter times periodically when their PC is active (not locked or logged out)
  5. <Client UI Wnd> must provide the ability to show data entered
  6. <Client UI Web> must provide the ability to show data entered
  7. <Client UI Wnd> must provide the ability to record and store times against selected project tasks, where a project and a related task can be selected. The selected project and task to store times against can come from within {T-Rec} or from a {Source Of Project Tasks}
  8. <Client UI Web> must provide the ability to record and store times against selected project tasks, where a project and a related task can be selected. The selected project and task to store times against can come from within {T-Rec} or from a {Source Of Project Tasks}
  9. <Client UI Wnd> must allow past times to be edited
  10. <Client UI Web> must allow past times to be edited
  11. <Client UI Web> must allow future times to be edited

Business Rules

  1. BR001 - A {User} can only see their own data
  2. BR002 - A {Group Admin} can see the data for all {User}s within their |Group|
  3. BR003 - Times entered against a task can not overlap (Only one task can be worked on at any time)
  4. BR004 - A {User} cannot see any data until they are logged in

Business Processes

BP001

Description:

{User} views entered times for a particular period from within their Windows session

Actors:

  • {User}
  • {T-Rec}

Triggers:

  1. {User} clicks button from windows task bar <Client UI Wnd>

Preconditions:

  • {User} is a part of one or more |Group|s
  • <Client UI Wnd> is installed and running

Process Description:

  1. The {User} clicks on the icon in their Windows system tray <Client UI Wnd> and a screen appears
  2. The screen shows the data entered into {T-Rec} by the {User} for the current day by default
  3. The {User} can apply a filter to the results to show all past and future results

Post Conditions:

Business Rules:

  • BR001

Issues:

Notes:

BP002

Description:

{User} adds a new time entry from within their Windows session

Actors:

  • {User}
  • {T-Rec}

Triggers:

  1. {User} clicks button from windows system tray <Client UI Wnd>
  2. {T-Rec} pops up a reminder dialog after a (defined) interval of time <Client UI Wnd>

Preconditions:

  • {User} is a part of one or more |Group|s
  • <Client UI Wnd> is installed and running

Process Description:

  1. The {User} clicks on the background Windows task bar <Client UI Wnd> and the time entry screen is brought to the foreground
  2. The screen shows the fields for entering a new time entry with the End Time default to the current time, the Start Time default to the end time of the most recently added time, the Project Task select list default to the most recently added task entry, and an option to allow the user to create a new task. A list of the most recent entries is also displayed below from which the {User} can select to pre-populate the emtry fields
  3. The {User} can save the new entry, which is stored in the <T-Rec DataSource>

Post Conditions:

  • Validation messages appear and nothing is saved
  • The time entry is added in the <T-Rec DataSource>

Business Rules:

  • BR001
  • BR003

Issues:

Notes:

If the assigned task is from a linked Source Of Project Tasks, that Source Of Project Tasks will not be updated. This is considered out of scope.

BP003

Description:

{User} has a shared login PC and thus wants to run <Client UI Wnd> using different credentials (e.g. Active Directory)

Actors:

  • {User}
  • {T-Rec}

Triggers:

{User} clicks button from windows system tray <Client UI Wnd>

Preconditions:

  • {User} is a part of one or more |Group|s
  • <Client UI Wnd> is installed and running
  • {User} is not logged in to {T-Rec} OR {User} is logged into {T-Rec} uwing the current windows login OR {User} is logged into {T-Rec} using a username and password

Process Description:

  1. The {User} is presented with a 'login' screen
  2. The {User} enters a username and password
  3. The {User} presses a login button

Post Conditions:

  • Validation messages appear and the application is left in it's initial state
  • {T-Rec} shows data relevant to the logged in {User}

Business Rules:

  • BR004

Issues:

Notes:

BP000

Description:

Actors:

Triggers:

Preconditions:

Process Description:

Post Conditions:

Business Rules:

Issues:

Notes:

Last edited Apr 15, 2008 at 9:28 PM by nootn, version 10

Comments

samunro Jun 26, 2008 at 12:43 AM 
Hi. Here are a couple of ideas.
- use a provider architecture to allow for the development of custom export formats - clients often have their own formats in which timesheet information should be submitted.
- use a provider architecture to allow for the development of custom <Project Task DataSource>s.
- allow for project/task quotas. Info such as remaining hours for each task could be displayed in the project/task selection tool. Projects that are over quota could be displayed in red for example.
- I did not see any mention of a 'comments' field in BP002. This should be included.

nootn May 23, 2008 at 3:19 PM 
Paul, the 'default logged in user' will be whatever the person logged into windws as. If they logged in as an AD user, then yes, but if they are not even on a network and they just logged into their stand-alone pc, it will pick up that local username. I guess we will have to determine what types of authentication and users we support when we do the admin side. So, when we set up a user, we say 'this is an AD user' therefore when that user attempts to put a time in, we need to check that they are an AD user. But, if we set up a userid/password user, then it will probably need to pass the userid and password every time.

So in the AD example, lets say we set up an AD user to have access in the AD domain called 'COMPANY' and the AD userid is 'USER123'. When they attempt to connect to put a time in (Authenticate), it will pass the domain and userid so we cross check both. If the user set up an account on their local PC called 'USER123', and tried to connect, then the domain would be null and we can tell that it was not the AD user account. There might be more things we can check but this would be a simple way of doing it. The only way around that would be if the user created their own AD with the same domain, but in that case I don't think they would be able to connect to both networks at once, not sure though.

PBB Apr 13, 2008 at 10:38 AM 
Under Functional requirements: <Client UI Wnd> must be able to run with a different |UserId| or the logged on windows user
Andrew, do you mean by default the logged in user is the UserId (via Active Directory or alternative authentication?) and then that another valid user can authenticate via the <Client UI Wnd> ?