Problem
Organisations and individuals could derive great benefits from an all-in-one Time Management Wizard. Although there exist various tools such as Calendars and Timesheets, they are often not integrated/synchronised and require much manual effort to enter the same record into different tools for different purposes. For example, timer, logbook, time sheet, and appointment book are often used to record and report time required/spent on the same event. Accordingly it is proposed to consider what would need to be developed to provide a better software solution to this problem.
Overview
The broad statement of needs and system outline that have surfaced to date include the following:
This will be an online tool that can be accessed from any wired/wireless network enabled device.
A user should be able to access timer (with alarm), appointment book/calendar (with reminder), and timesheet, logbook with the wizard.
The wizard should be able to link and synchronise the timer, appointment book, timesheet and logbook. For example, an eventuated appointment on a user's calendar should be automatically populated into the user's timesheet; a user may choose to use a timer to track time spent on certain activity, and the duration should be automatically entered into the user's time sheet.
The web interface should be customisable to the user's needs.
A small application should be easily downloadable to any applicable device to assist in the execution of the service provide by the tool.
The system should be able to create accounts as requested. An account is assigned to a single user.
A user should be able to get SMS and/or email reminders for appointments booked.
A user should be able to create open or hidden (details only visible to self) entries. Hidden entry will show in logbook/timesheet as a "personal" entry.
The tool should allow typical modification of entries, including the removal and editing of an entry.
A user should be able to create a logbook for activities with certain attribute (e.g., a specific project) based on his/her time sheet.
An organizational administrator should be able to create rolled-up reports with individual users' timesheet data.
It is expected that the output from a request could include any of the following elements:
- Text-based descriptions
- Diagrammatic/tabular view of the results if appropriate
- Any other form of response that suits the purpose
This system is intended for professional as well as personal use so consideration for accessibility and level of complexity should be built into the system.
You should take into consideration the development of the data. Users/administrators should be able to make changes to the data, or create new data with ease.
Security/confidentiality for certain tasks is an important consideration and should be implemented to avoid accidental or unauthorised changes to the elements within the system.
It may be assumed the current computer systems infrastructure and resources are sufficient to support this initiative.
Notes
The statement of needs above is not a statement of requirements, and it can be assumed that further investigation will reveal a number of additional items that may result in specific requirements for this project.
Requirements must not involve specific instruction about the type of interfaces used, and especially not about the look and feel of any interface. It becomes the task of the design and implementation teams to decide on the best methods to satisfy the requirements.
Groups may choose to make additional assumptions, or modify any stated assumptions, but such amendments will need to be properly explained and justified in your submissions, and you are advised to discuss major changes with your tutor.
Introduction
This assignment is the first part of a 2-part assignment for this topic. It is a relatively small assignment which has the following aims:
To provide a forum for your group to practise its communication skills in promoting and sharing of ideas, formulating a group response, and submitting a completed group document;
To convert a broad needs statement into a more structured format;
To enable thinking about what constitutes a software system and how to describe system requirements both as a user and as a developer;
To appreciate the challenges in documenting requirements so that they can be effectively communicated to others;
To draft your preliminary ideas of likely functionality of the proposed system.
There is a quite short timeline on the completion of this assignment, so issues will need to be addressed and resolved promptly.
Group Work
Each group will produce one document as the result of this phase. This brief document will take the form of a system overview report summarising the outcome of the group's discussions of and decision making about customer and user requirements for the Project.
It is likely that some of the group members' ideas may be conflicting; the group will therefore need to decide on how best to resolve such matters. Given that this is meant to be a brief document, the group will need to decide on what it believes is important to include and what may be omitted.
Every student is expected to participate in the group's discussions and idea generation. The group can decide for itself whether this is to be done as one group or as some sub-groups focussed on specific parts (or sections). Also the group should decide how it wants the discussion process to proceed.
Tasks
To produce the required document, the group must initially agree on what will be the standard document format, file naming conventions etc. Much of this should have been resolved in the first group meeting (see Tutorial/Workshop #1)
Each group should allocate the following roles to various members: -
collator - student(s) to put the various parts of the document together, including revised versions of parts. The document should be uniform in its presentation e.g. font and page layout.
publisher - student(s) to put the final document together, to check the overall look and finish of the document.
drafter - student(s) to draft the initial version of each part, to make any necessary modifications to it, and to do the initial proof reading (Reading out loud is always a good check.)
proof reader - student(s) to check the syntax and content of parts, to provide editorial comments. All group members could make comments but this role involves a commitment to make comments and/or corrections.
Each section could have a drafter and a proof reader assigned if deemed appropriate.
Note that:
Simple short sentences tend to make for the most understandable English. Fancy formats, colour printing etc do NOT make up for lack of quality in content. Any material, directly quoted or paraphrased (restated), from the work of others must have the source acknowledged. No part of the document will be very large but parts may vary in size. Each member of a team must cooperate to get the team's report in before the deadline. The group should determine a timetable for completing the necessary tasks and review it regularly.
Should any student for medical or compassionate reasons find that they are unable to make the necessary contribution to the group work, they should immediately let the group know, and, let the topic coordinator know, in writing or via email. Please include group identification. Supporting documentation may be required.
If a group's document is incomplete at the deadline, it should still be submitted and group members should make clear on their contribution declarations reasons for the lack of completeness. Group members are not expected to do extra work to make up for the failure of a member to deliver, but each group is expected to monitor it's own progress and manage issues that arise, and may be asked to provide evidence of such monitoring/management (e.g. entries in the group blog).
Deliverables
Details of the required project overview are given below. The completed overview is to be handed in as a print-out to the SE1/SE1GE group submission handin box by the stated deadline. Diagrams (if any) aside, the submission is to be no more than 4 single-side A4- pages with a size 12 font and single-line spacing. Anything beyond this limit will be ignored.
In assessing the submission, quality of content and clarity of presentation will be the deciding factors. Submissions should be placed in the folder available from the school office and must have the group cover sheet as the first page.
Each student is to complete an individual contribution declaration and submit it to the SE1/SE1GE individual submission handin box by the relevant deadline. Contribution covers both contribution to the content quality of the deliverable and also contribution to the group process that produced that deliverable. If more than one page, this should be stapled in the top left hand corner.
An unsatisfactory, unreadable, incomplete, or frivolous contribution declaration will be taken to indicate an insignificant contribution to group submission and group operation and result in minimal marks being awarded.
System Overview Document
The document to be produced is based on what is often used in the industry to overview a project. In the following specification of the required system overview you should note:
This is a document intended for a potentially wide audience. Any jargon or technical terms used should have their meaning explained. It should be understandable to anyone (with reasonable association to the project) who has occasion to read it.
This document is intended to be an overview of the key or main system requirements from the customer/user perspective. There is no single correct overview. Any reasonable ideas are acceptable and indeed innovative (but sensible) ideas are encouraged.
Comments in { }'s indicate content that needs to be supplied. They should be removed from the final document.
The values in []'s indicate the relative percentage value of the section to the overall mark.
This is also an indicator of the likely relative length. However these values are only indicative since all sections have to be consistent and together present a coherent, cohesive, correct and complete (as far as expected) overview of the system. For instance, any user type identified must have system functions that they use.
Examples supplied have been kept very brief and relate to a totally different system.
The group submission should be longer and of course relevant to the specific project; and should use full sentences. Point form may be appropriate in some parts but all points in a list of dot points need to be logically related and any such list must have a lead-in sentence and possibly a trailing sentence that ties the list in with the surrounding text.
Document Structure
1. 1 Introduction
1.1. System identification: {This should name the system being overviewed - if an abbreviation is to be used, both the full and abbreviated name should be given here}
1.2. Author identification: {This should identify who has produced the document and when.}
1.3. Document purpose: {This should indicate what the document is intended to do and indicate for whom it is intended. It often ends with a brief description of the document structure.}
1.4. Problem/Opportunity: {This should be a statement of the major problem(s) or opportunity(s) to be addressed by the system. It is meant to be a statement of fact that provides the basis or rationale on which to build the system. Example: The decline in staff morale is due to not having accurate nor timely information.}
2. System Overview
2.1. System Purpose: {This should clearly state the main purpose (goal) of the system so that all readers may know what is intended to be accomplished. This is effectively the short paragraph "mission statement" for the system.}
2.2. Users: {This should identify the types of users of the system. "Users" here can refer to people or other systems. For each user type, the manner in which they interact with the system should be identified and briefly described. Users typically may be providers of inputs, receivers of outputs, or initiators of actions to be performed.}
2.3. Functions: {This should detail a decomposition of the purpose into a set of necessary and sufficient functions (or services) that need to be provided by or within the system. The sum of these functionalities should enable the scope (or boundaries) of the system to be determined; identify what are the major activities that the system is to support. It should also identify any notable omissions. Functions that depend on other functions should also be identified.}
It is expected that the functions are grouped for each user type, rather than appear as a composite list of functions. Indeed this is both a good way to develop the function list but also a way to check that the list is complete. Note that a function is a task from the user perspective such as "update information about the designated event" - it is not a simple system operation like "write a record".
Characteristics: {This should indicate the major non-functional i.e. not activity-related features of the system. If relevant, this includes any particularly significant aspects of interfaces (human and (other) systems), performance, environmental (such as platform), and, key quality attributes such as reliability, security, and extensibility. Example: It is particularly important that the system's user interface be able to be used without formal training.. ...The system needs to be robust and handle input errors with meaningful error messages.}
Restrictions: {This should identify any major external factors that may limit how well the system achieves its purpose i.e. supplies the required features and displays the required characteristics. It should also identify what the system will not do (that could otherwise be in scope). Example: The ability of the system to transmit multimedia information may be constrained by the capacity of the existing network.}
Assumptions: Any extensions or variations from the initial outline specifications must be identified and justified. These should be minimal or perhaps even none.
Conclusion: The conclusion for this assignment should be a group review of the structure and appropriateness of the prepared document compared with the suggestions given in your text, particularly section 6.5.