Requirements Definition

(an Outline of Design Decisions made so far)

Please excuse the quality of images in this doc. The emphasis here on is being "fast to view", rather than having "great quality images"to view. I will put some links to better quality versions of these images soon (just in case anyone is actually that interested in the details).

Table of Contents

1. Project Definition & Criteria

1.1 Description of program

1.2 About this document:

1.3 Success Criteria and Limitations of program

1.4 Security

1.5 Download a demo!

2. Use Cases (things that this program is likely to be used for):

2.1 Program User

2.2 Entering contacts

2.3 Changing a contact's details

2.4 Entering new schedules

2.5 Changing existing schedules

2.6 Searching (alarms and schedules)

2.7 Checking for valid alarms

2.8 Changing program settings

3. User Interface Definition (what the program will look like):

4. Possible Functional Extensions: The sky's the limit!

4.1 Inter-office messaging:

4.2 Dynamic Refreshing of data:

4.3 SMS alarm checker:

4.4 Distributed "Jobs" Application:

4.5 Offline ability (for portables and telecommuters over internet connections):

4.6 Export/Import functions:

4.7 Localisation:

4.8 Encrypion:

4.9 "Daily View" And "Month View" for schedules:

5. Relational Database Model:

6. Updated Gantt chart:

 

 

1. Project Definition & Criteria

1.1 Description of program

The softorganiser needs a back end that can communicate with a sql compatible server (like MS SQL server or mysql, or ODBC). Initially this will exist on the same network, but an option is that a socket might be served on the net for a more open architecture.

The "Front end" of the program will be written with a "kit" that can compile and run on as many different types of clients as possible. This is likely to be the wxwindows kit, which is very similar to Microsoft's MFC toolkit, but is supported across many platforms and is open source. A downside to the wxwindows toolkit is that the networking support is still fairly platform dependent, so another solution may need to be "plugged in" as a back-end so that all clients can communicate with the same server, regardless of platform.

This program is support users and groups, so that a contact or schedule can be designated public (all can see it), private (only the local user that created the contact can see it), or belonging to a particular group so that all members of that group can see it. An example of this would be if two users in an office are members of a group called " sales", so that they can share contacts and schedules that others in the office will not see, unless they are also a member of the "sales" group.

It is intended that the program offer to create or select a user when the program is first run on any computer. If the user is validated by the right password, the program then belongs to that user, but if a new user and password are entered, the program will create a user, and group of the same name, and the program will automatically add the new user to the group called "everbody".

Any further administration work, such as creating the above group called "sales" and adding users to it, will need to be done by a separately written administration program (not intended to be written at this stage), or by a database management program that can work with the format of the database being used.

This heterogenous database problem is likely to be solved with ODBC socket server kit, which is a kit that serves an ODBC "socket" from a Windows 98 or Windows NT computer. The kit also includes basic source code for clients, which should compile fairly easily on any number of platforms.

Note that all these kits are written in C, and some in C++. Because of the heterogenous nature of this project, Rapid Application Development solutions are limited. This is why wxwindows was chosen, because of its similarity with Microsoft's MFC.

1.2 About this document:

This document is intended for a non-technical audience. For that reason, the use-cases appearing later in the document aren't in expanded form. At this stage the user only needs to agree that these are important aspects of the program. The use-cases will be more fully expanded as they are unearthed by the "iterative and incremental" building of the program.

1.3 Success Criteria and Limitations of program

The program will only be tested with three users, with the expectation that up to a dozen users won't notice much response time degradation. Any more users than this may cause the response time of the program to fall below standard. Standard response expected on a modern local area network should fall between a quarter and a half a second.

The program will be tested to ensure it carries out the expectations listed for it in "2: Use Cases". At this point the program will be considered finished. Any further work toward the optional extensions listed in 5: Possible Functional Extensions will be considered extra work.

The user is responsible for all data entry and user and group administration. The program may or may not be supplied with some sample data in a database file or files, depending on the platform.

1.4 Security

The users and groups in this program aren't meant to replace a secure network. These are merely meant as a convenient way of filtering messages. No responsibility can be taken for private, sensitive data stored using the softorganiser system. This version of the program will not encrypt any data before it is passed around the network. This may be an option if the kit used for the backend is updated to encrypt network data.

 

1.5 Download a demo!

A project has been started at sourceforge for the softorganiser. The latest version of it can be downloaded and tested... any feedback welcome:

http://softorganiser.sourceforge.net/

 

2. Use Cases (things that this program is likely to be used for):

2.1 Program User

 

2.2 Entering contacts

 

2.3 Changing a contact's details

 

2.4 Entering new schedules

 

2.5 Changing existing schedules

 

2.6 Searching (alarms and schedules)

Implementation Note 1: Searching contacts and schedules have been implemented independently of each other.

Implementation Note 2: Searching can only "see" the records the current user can see, as a result of their group membership. It was decided that there is no point in searching (and then showing) data that other users have decided to keep restricted.

2.7 Checking for valid alarms

Implementation Note: Alarm announcement dialogs don't allow editing of alarm. This is because alarms can be found easily using the search facility. The contact is also easily found with the search facility.

 

2.8 Changing program settings

Implementation Note: It didn't make sense to have a default pre-alarm time. The user can set this directly with the schedules interface (on the schedules panel).

3. User Interface Definition (what the program will look like):

Here are some screen dumps of the proposed interface. The final program will not necessarily look exactly the same as this (because of the differences in "widgets" across programming kits), but the number and type of components will probably stay the same.

The interface will have two main screens, contacts and schedules.

 

The contacts screen is for managing contacts. You will be able to scroll backwards and forwards through the contact "records" in the database, and create and change existing records. There will be some type of slider in the middle of the screen that allows display of an associated company's details. If the slider is moved to show company details, and there is no company associated with the individual, the user will be presented with some options. The user will be able to select a previously created company, or create a new company, to associate with the individual. A third option the user will be presented with is to create a company that isn't associated with any individuals. In this latter case, the name and email address at the top of the screen will become blank, and will stay that way when ever this company is displayed, as long as no individual is associated with this company.

 

Implementation Note: The pre-alarm and alarm times can be set on the schedules panel, rather than using buttons to launch a time-setting dialog. This happened mainly because I didn't expect the widgets all to fit on the one panel.

 

4. Possible Functional Extensions: The sky's the limit!

4.1 Inter-office messaging:

If the database is refreshed dynamically, an extra button could easily be added to the schedule screen that allowed users to send each other messages. This could be displayed as an alarm would be, the only difference being that the description might be prefixed with something like "Message from Sue: " In the Windows environment "send message to another user" could be added to the menu that appears when the system tray icon is right-clicked.

4.2 Dynamic Refreshing of data:

If the user's custom settings had a timestamp, this could be checked periodically, say once a minute, and if it is found to be newer than last time the data was refreshed, a refresh could occur. This would lend itself to dynamic alarms, like users sending messages to each other in an office.

4.3 SMS alarm checker:

A module could be written that checks alarms for a specified user (or users) that sends alarm notifications to an SMS service (or similar) for display on mobile phones and pagers.

4.4 Distributed "Jobs" Application:

This application could be expanded to allow for distributed "jobs"... or another similar application could be written to read extra data from the schedule, like job description, etc. For example, this could be extremely useful for an office, where a person uses a computer as a mobile data terminal, while the office books jobs. The program could have a jobs dialog launched from a button on the schedules page.

4.5 Offline ability (for portables and telecommuters over internet connections):

The program could be extended to synchronise viewable records in the online database with a local version of the database, so that the computer could be removed from the network and only re-connected intermittently. When the user selected a menu option something like "go offline" the program would synchronise each record one-after-the-other to an offline database (stored locally on the computer itself). When the user de-selected the "go offline" option, the program could check for any changes made to the offline database (in a log kept of all changes made while working offline), and offer to synchronise these changes with the online database, or delete all changes made to the offline database. The implementation of the offline database may have to be platform dependant, but that shouldn't cause too much of a problem.

4.6 Export/Import functions:

The program could be extended to export data in several formats, for example a comma-delimited text file, that could then be used in other programs.

4.7 Localisation:

At this stage it is not intended that this program be localised, unless the wxwindows programming kit includes inherent support for this. Otherwise this could be an extension that an overseas customer either requests or performs themselves.

4.8 Encrypion:

The ODBC socket server kit has data encryption included in its wish-list as quite a high priority. If somebody includes an encryption scheme into this kit, it may be possible to upgrade the back-end of the program quite simply to one that does encrypt/decrypt its data transmissions.

 

4.9 "Daily View" And "Month View" for schedules:

If there is a demand for this, various views of schedules could be created, so that the softorganiser could be better used to organise a business' daily, weekly, monthly and even yearly activities.

 

 

5. Relational Database Model:

6. Updated Gantt chart: