Docstoc

Version History Table - Google Code

Document Sample
Version History Table - Google Code Powered By Docstoc
					      Software Requirements Specification
          (SRS) for the Task Manager
      Version History Table
Version   Date        Originator     Reason for change   Review        Approval
number                                                                 (initials,
                                                                       date)

1.0       3/9/2009    Hassan       initial draft         team review   RM, JS,
                      Sobhie, John                       process       PS, HS -
                      Spencer,                                         3/9/2009
                      Parag Shah,
                      Rich Moffitt

1.1       3/26/2009                  Incorporate         Team          RM, JS,
                                     feedback from       review        PS, HS -
                                     Professor and       process       3/28/2009
                                     update
                                     accordingly to
                                     sync with SDD.
1.2       5/2/2009    Hassan         For final project   Team          RM, JS,
                      Sobhie, John   Submission and      review        PS, HS
                      Spencer,       Traceability to     process       05/2/09
                      Parag Shah,    source code
                      Rich Moffitt




Table of Contents
 Software Requirements Specification (SRS) for the Task Manager
 Version History Table
 1. Introduction
 1.1 Purpose
 1.2 Scope
 1.3 Documents Definitions
 1.4 References
 2. Overall Description
 2.1 Product perspective
 2.1.1 System Interfaces
 2.1.2 User interfaces
 2.1.3 Hardware interfaces
 2.1.4 Software interfaces
 2.1.5 Communications interfaces
 2.1.6 Memory constraints

                                           1
2.1.7 Operations
2.1.8 Site adaptation requirements
2.2 Product functions

2.2.1 Administrator
2.2.1.1 Positions (Job Titles)
2.2.1.2 Task States
2.2.1.3 Categories
2.2.1.4 Projects
2.2.2 Manager
2.2.2.1 Users
2.2.2.2 Task
2.2.2.3 Milestone

2.2.3 Contributor

2.2.3.1 Detail

2.2.4 Reporting
2.2.4.1 List Tasks by Project
2.2.4.2 List Milestones per Project
2.2.4.3 List Tasks by Milestone
2.2.4.4 List Tasks by User Assignment
2.2.4.5 List Project with Task Time Estimates
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
2.6 Apportioning of requirements
3. Specific Requirements
3.1 External Interfaces
3.2 Functional Requirements organized by Role and UI
3.2.1 Administrator: User interfaces and Use Cases
3.2.1.1 Positions (Job Titles)
3.2.1.2 Task States
3.2.1.3 Categories
3.2.1.4 Projects
3.2.1.5 Users
3.2.2 Manager: User interfaces and Use Cases
3.2.2.1 Managing Users
3.2.2.2 Task
3.2.2.3 Milestone
3.2.3 Contributor: User interfaces and Use Cases
3.2.3.1 Detail
3.2.4 Reporting: User interfaces and Use Cases
3.2.4.1 User Interface Screens [Essential]
3.2.4.2 Report results and filter criteria [Essential]

                                       2
   3.2.5 Login and Application Shell: User interfaces and Use Cases
   3.3 Performance Requirements
   3.4 Logical Database Requirements
   3.5 Design Contraints
   3.5 Standard Compliance
   3.6 Software System Attributes
   3.6.1 Reliability
   3.6.2 Availability
   3.6.3 Security
   3.6.4 Maintainability
   3.6.4.1 Application updates/maintenace.
   3.6.5 Portability
   3.7 Organizing Specific Requirements
   3.7.1 System Mode
   3.7.2 User Class
   3.7.3 Objects
   3.7.4 Feature
   3.7.5 Stimulus
   3.7.6 Response
   3.7.7 Functional Hierarchy
   3.8 Additional Comments
   4. Supporting Information
   4.1 Appendixes



1. Introduction
1.1 Purpose

This document provides all of the requirements for the Task Manager
application. Parts one and two are intended primarily for customers of
the application to help ensure the application will meet their needs.
This document will also be of interest to software engineers building or
maintaining the software to gain a high level understanding of the
application. Part three is intended primarily for software engineers who
will use the details specified to help their design efforts, but this part
will also be of interest to customers who want a more detailed
understanding of the application.

1.2 Scope

This document covers the requirements for Task Manager. This
document will identify features for the initial release and also features
planned for future releases to achieve a full-scale application. Since
this is a student team project for a single semester, all of the

                                          3
requirements described in this document will not be implemented and
will be identified. However, if the team or subset of the team chooses
to continue work on the application beyond the end of the semester,
this document will be referenced and updated accordingly.
By detailing the complete feature set, the software engineers on this
student team can make design decisions during the initial phase to
include the eventual full-scale application feature set.

1.3 Documents Definitions


Term                Definition

Task                A unit of work to be performed by an individual. A task is
                    associated with one person at a time.

Milestone           A collection of tasks that comprise a major deliverable in the
                    course of a project.

Project             The highest level of organization in the Task Manager. A
                    project contains milestones and tasks.



1.4 References

      Introduction to Software Engineering By Eric Braude and Michael
       Bernstein (Wiley, 2008)
      Software Project Management Plan (SPMP) for Task Manager
       version 1.3
      Software Design Description (SDD) for Task Manager version 1.6



2. Overall Description
The Task Manager will be a web-based application used by a team,
group, or department in an enterprise to track and organize
individual tasks that comprise a project. Its purpose is to assist with
the organization functions of estimation, planning, and execution of a
team’s progress.

Users of Task Manager will be assigned one or more of the following
roles: Administrator, Manager, and/or Contributor.

                                     4
Administrators are granted rights to customize the application based
on the organization using the application.

Managers are granted rights to execute functionality such as changing
Task assignments, and add/delete/update Tasks, etc.

Contributors track the time they are working on various Tasks
assigned to them.

Further details describing the functionality that can be performed for
the Roles: Administrator, Manager, and Contributor are described in
section three.

Various reporting capabilities are provided that can be performed by
both Managers and Contributors.


2.1 Product perspective

The Task Manager is a subset of an overall Project Management suite.
Other Project Management applications outside the scope of Task
Manager include: Source Control and Defect/Bug Tracking.
There are applications that perform similar functionality that is
described in this requirements document. In some cases these
products are part of application suites or available as standalone
products in open source. Our goal, intentionally, when defining the
requirements for this application was to not evaluate or study these
products. Our student team has diversified software development
experience and wanted to draw on our experience when defining these
requirements without bias or comparison to other applications. We
feel this was the best approach to maximize our learning of the
Software Engineering principles gained through this course.

2.1.1 System Interfaces

Intentionally omitted.

2.1.2 User interfaces (Implemented )

All the user interfaces are specified in detail in section 3.2. At a high
level, the Task Manager is a web-based application and follows
generally accepted web design standards.




                                     5
The main user interface consists of a left-hand menu and a large area
where content relating to a particular function is displayed.




                           Main User Interface




2.1.3 Hardware interfaces

None.

2.1.4 Software interfaces

None.

2.1.5 Communications interfaces

None.

2.1.6 Memory constraints

Server side memory requirements:
The maximum memory and disk space constraints have not been
determined as of yet. A better understanding to make estimates will
take place after a prototype is developed.

Client side memory requirements:

                                   6
Task Manager will be a web based application and hence will require at
least the same memory as required by the web browser loading the
application.

2.1.7 Operations

None.

2.1.8 Site adaptation requirements

Task Manager only supports English Locale. (ISO-8859-1 character
set)

2.2 Product functions

The following is functional description of the Product functions. In
the detail requirements section 3, these functions are expanded with
User Interface screenshots and corresponding Use Cases. The
subsection numbers here in section 2 and in section 3 are
synchronized so it is easy to match and follow the requirement from
high level to detail level. This layout structure helps provide
traceability of the requirements.

Users of Task Manager will be assigned one or more of the roles:
Administrator, Manager, and/or Contributor.

2.2.1 Administrator)

An Administrator will customize the Task Manager application for the
needs for the user community. Areas requiring customization include:
Positions (job titles), Task States, and Categories. These areas are
explained below.

2.2.1.1 Positions (Job Titles)
An Administrator will customize the set of Positions based on the set of
users. Examples of Positions include the job titles in a software
development organization: Software Engineer 1, Software Engineer 2,
Senior Software Engineer, Principal Software Engineer, Project Leader,
Engineering Manager, Director of Engineering, and VP of
Engineering. Positions (Job Titles) are assigned to a User to describe
what position they hold in a company/organization.




                                   7
2.2.1.2 Task States
An Administrator will customize the set of Task States that are used to
describe the current state of a Task. Examples of Task States are:
Started, Finished, Hold, Not Started, and Roadblock. Tasks are
described later.

2.2.1.3 Categories
An Administrator will customize the set of Categories. For example, in
a software development organization, this would include: Design,
Implementation, Testing, Bug Fixing, and Maintenance. When a user
works on a Task and creates a Detail, one of the Category selections is
assigned. Categories are assigned to a Detail to describe the type of
work completed by a user. Tasks and Details are described later.

2.2.1.4 Projects
An Administrator will customize the set of Projects. The Manager user
(described below) will assign one or more Milestones to a Project.
Projects are used for reporting and tracking purposes.


2.2.2 Manager

A Manager will perform functions such as adding, deleting, and
updating Tasks. In addition, a Manager will also assign Tasks to one or
more Users to work on it. Other responsibility of a Manager includes
creating various Milestones and assigning them to Projects.

2.2.2.1 Users
An Administrator will create the set of Users who can use the
application. The User’s first and last names are entered along with the
selection of their Position (described above). The Manager will assign
Tasks to one or more Users.

2.2.2.2 Task
A Task describes a unit of work that must be accomplished. The
Manager will create Tasks and assign them to one or more users. As a
user works on an assigned Task, one or more Details are created to
track their work on the Task. Details are described below. In order to
identify the current state of the Project, estimated time to complete a
Task will be entered. This estimate compared with the sum of actual
time entered by users can be used to report on the state of the
project.



                                   8
2.2.2.3 Milestone
A Manager will create the list of Milestones. Examples of Milestones
are: Alpha, Beta, Release Candidate1, etc. A set of Tasks will be
assigned to a Milestone to form a group, also accomplished by the
Manager. This grouping of Tasks into a Milestone is used primarily for
reporting and tracking purposes.

2.2.3 Contributor

A Contributor is a user that tracks the time they are working on one or
more Tasks assigned to them. They are the primary users of the
application. These users track their work on a Task by using Details.


2.2.3.1 Detail
Details are used to provide additional information to a Task as it is
worked on by a Contributor user. Detail information a user would
provide includes, when the user started to worked on a task with
month and time information, the amount of time spent on a Task, the
current state of the Task (see Task States above), and the category
(see Categories above) of work completed. Optionally, a User will
provide a comment to annotate/describe the work completed.


2.2.4 Reporting

Both Manager and Contributor users will have access to reports. The
following reports will be provided.

2.2.4.1 List Tasks by Project
In grid format, this report shall list tasks and their status, organized by
project. The report must display active projects and tasks, their
owners, their due date, and their status.

2.2.4.2 List Milestones per Project
In grid format, this report shall list milestones and their status,
organized by project. The report must display active milestones, their
owners, their due date, and their status.

2.2.4.3 List Tasks by Milestone
In grid format, this report shall list tasks and their status, organized by
milestone. The report must display active tasks and milestones, their
owners, their due date, and their status.


                                     9
2.2.4.4 List Tasks by User Assignment
In grid format, this report shall list tasks and their status, organized by
user assignment (owner). The report must display active tasks, their
due date, and their status.

2.2.4.5 List Project with Task Time Estimates
In grid format, this report shall display results in the same order as
requirement 2.2.4.1, “List Tasks by Project”. Instead of displaying
task status information, time estimates and actual times for each task
should be displayed. The sum of all times for tasks belonging to a
project should be taken and listed for each project.

2.3 User characteristics

Users should feel comfortable with using a web browser in order to use
this application.

2.4 Constraints

Server side constraints: Task Manager will operate on systems that
support running Java (a.k.a Java Runtime Environment (JRE) )

Client side constraints: Task Manager application will be developed
as a web application. This will have a minimum foot print and requires
no client installation. Being a web application, Task Manager can be
run from any computer with a browser.

2.5 Assumptions and dependencies

We are going to assume that the Task Manager application will work
with predefined user roles of Administrator, Manager and Contributor.
Creating/Assigning new role to a user -functionality may be developed
in future.

2.6 Apportioning of requirements

The high level requirements described in sections 1 and 2 of this
document have a corresponding detail requirement in section 3. In
section 3, these detailed requirements are marked as
"Implemented", and “Not Implemented”. Due to time constraints
we only implemented the login, main interface, positions and task
details.



                                    10
3. Specific Requirements
3.1 External Interfaces

Intentionally omitted.

3.2 Functional Requirements organized by Role and UI

3.2.1 Administrator: User interfaces and Use Cases

The following section organizes the functional requirements by Role
and within each a set of user interface (UI) screenshots. Each
screenshot is accompanied by one or more use cases that provide
additional details in describing the user interactions with the UI.

Section 2.2 above described the functionality of this application at a
high level. The subsection numbers are synchronized to easily
reference the high level and detail level information. This section will
describe the details by including user interface screenshots
accompanied with use cases.

A design layout theme to the following user interface screens was a
conscious decision to help ensure consistency between the various
screens presented below. We feel this will also assist in making it
easier for users to learn how to use the screens, since they have a
consistent layout and workflow.

It is likely that the actual look of the user interface screens will change
somewhat in the actual implementation. The following screens marked
as “Not Implemented” were mocked up with a Windows XP look;
however, screens indicated as “Implemented” are real user interfaces
created using Flex. These will look slightly different than the others not
implemented yet.




                                    11
3.2.1.1 Positions (Job Titles) ( Actual Implemented UI )




[Essential]Positions Use Cases:

Actor: User with Administrator role assignment

Use case – Create Position:

    User selects the “Create Position” button.
    Position Form appears.
  - User enters: Position ID, Position Name, Description, Minimum
  Salary, and Maximum Salary.




  - User can: Save position, Clear Form, or Cancel the Form


                                 12
Use case - Update Position:

     User selects an existing Position from the list of positions and
      clicks update position. Position Form appears




  -   User can edit and change any of the Position ID, Position Name,
      Description, Minimum Salary, Maximum Salary.
  -   User can Save Position, Clear Form, or Cancel

Use case - Delete Position:

     User selects an existing Position from the list of positions
     User selects the “Delete” button to delete position

Use case – Reload Data:

     User selects an existing Position from the list of positions
     User selects the “Reload Data” button to reload position
  

3.2.1.2 Task States ( Not Implemented )




                                    13
[Essential]Task States Use Cases

Actor: User with Administrator Role

Use Case -Since this user interface is identical to Positions interface,
all buttons will have exact same functionality as described in section
3.2.1.1.




                                    14
3.2.1.3 Categories ( Not Implemented )




Categories Use Cases

Actor: User with Administrator Role

Use Case -Since this user interface is identical to Positions interface,
all buttons will have exact same functionality as described in section
3.2.1.1.




                                    15
3.2.1.4 Projects ( Not Implemented )




[Essential]Project Use Cases

Actor: User with Administrator role assignment

Use case - New Project:

     User selects the “New” button.
     The user input areas for Name, Description are cleared and the
      cursor is placed in the Name input area.
     The user enters the Project name and description by entering the
      pertinent information in the input areas.
     User selects one or more Milestones available from the bottom
      left portion of UI. Selected milestones will be moved to right
      portion of the UI.
     Refer: Apply, OK, Cancel Use case below.

                                  16
Use case - Edit Project:

      User selects an existing Position from the list of positions in the
       upper left hand portion of the UI.
      User selects the “Edit” button.
      The details for the selected position are displayed in the input
       areas.
      User can change/update one or more of the input areas.
      User can add new milestones to the project by selecting new
       milestones from bottom left portion of UI. User can remove
       assigned milestones to the project by selecting them from
       bottom right right portion of UI and then clicking <-- button.
      Refer: Apply, OK, Cancel Use case below.

Use case - Delete Project:

      User selects an existing Project from the list of projects in the
       upper left hand portion of the UI.
      User selects the “Delete” button.
      The Project is removed from the list of projects.
      Refer: Apply, OK, Cancel Use case below.

Use case - Apply, OK, Cancel buttons:

      User selects Apply which creates/edits/details
       the Project and Project UI remains open.
      User selects the OK which creates/edits/details the Project and
       the Project UI closes.
      User selects Cancel and no changes are saved and the Project UI
       closes. A warning dialog will be presented to the user that they
       will lose their changes by selecting Cancel.


3.2.1.5 Users ( Not Implemented )




                                     17
[Essential]Users Use Cases

Actor: User with Administrator role assignment

Use case - Since this use case is identical to Projects use case, all
buttons will have exact same functionality as 3.2.1.4.

3.2.2 Manager: User interfaces and Use Cases

3.2.2.1 Managing Users ( Not Implemented )




                                    18
[Essential]Managing Users Use Cases

Actor: User with Manager role assignment

Use case - Assigning tasks to existing users.

     Manager selects user from top. Selected User's first name, last
      name and position displays in detail section.
     Manager then selects the “Assign Task” button.
     Bottom left side multicolumn table becomes available and
      Manager can select new task to be assigned to selected user.
      Click --> button to actually assign selected task to selected user.
     Refer: Apply, OK, Cancel Use case below.

Use case - Remove Tasks assigned to User

     Manager selects user from top. Selected User's first name, last
      name and position displays in detail section.
     Manager then selects the “Remove Task” button.

                                   19
      Bottom right side table becomes available and Manager can
       select existing task assigned to selected user and click <--
       button. Task will no longer be assigned to the selected user.
      Refer: Apply, OK, Cancel Use case below.

Use case - Apply, OK, Cancel buttons

      User selects Apply which assigns/removes tasks assigned to the
       selected user and User UI remains open.
      User selects Cancel and no changes are saved and the User UI
       closes. A warning dialog will be presented to the user that they
       will lose their changes by selecting Cancel.


3.2.2.2 Task ( Not Implemented )




[Essential]Managing Tasks Use Cases

Actor: User with Manager role assignment

Use case - Since this use case is identical to Positions use case, all
buttons will have exact same


                                    20
3.2.2.3 Milestone ( Not Implemented )




[Essential]Managing Milestones Use Cases

Actor: User with Manager role assignment

Use case - Since this use case is identical to Projects use case, all
buttons will have exact same functionality as 3.2.1.4.

3.2.3 Contributor: User interfaces and Use Cases




                                    21
3.2.3.1 Detail (Actual Implemented UI        )




Use case – Create Detail

     User selects Create Detail Button. Detail Form appears




  -User Enters Detail ID, Time Amount, Comment
  -User can Save Detail, Clear Form, Cancel

Use case –Update Detail




                                  22
   -   User selects Update Detail
   -   Detail From appears
   -   User can Save Detail, Clear Form, or Cancel

Use case –Delete Detail


-User Selects Delete Detail
-Detail Form appears
- User Delete Detail


Use case –Reload Detail


   -   User selects Reload Detail
   -   Detail Form appears
   -   User Reloads Detail

3.2.4 Reporting: User interfaces and Use Cases




3.2.4.1 User Interface Screens [Essential]   (Not Implemented )


The reporting screens consist of three main parts:
1) Report selection
2) Filter / search criteria
3) Report data

                                     23
The following screens outline the basic required elements in the
reporting module.




3.2.4.2 Report results and filter criteria [Essential]   (Not Implemented )


Each report will display information differently. All reports will be
displayed in a grid format. Depending on the report, different column
headings will be shown. The following illustrates different column
names for the various reports, with essential headings shown.




                                       24
3.2.4.2.1 Report: List Tasks by project
Headings: Item (project or task), Owner, Due Date, Status
Filter criteria: Project, [optional] Due Date range, Status

3.2.4.2.2 Report: List tasks by milestone
Headings: Item, Owner, Due Date, Status
Filter criteria: Project, [optional] Due Date range, Status

3.2.4.2.3 Report: List tasks by user assignment
Headings: Owner, Item, Due Date, Status
Filter criteria: Owner, [optional] Due Date range, Status

                                    25
3.2.4.2.4 Report: List project / task time estimate (Not
Implemented)


Headings: Owner, Item, Estimated hours, Actual hours, Due date
Filter criteria: Project, Owner, [desirable] Over estimate*, [optional]
Due date

* Over estimate filter criteria lists all tasks or projects that have
already gone over their estimated time estimates.

[Essential] Task Detail reporting ( Not Implemented )

In addition to the reports above, contributors and managers must be
able to view reports on task details in a format emulating the following
screen.




                                     26
3.2.5 Login and Application Shell: User interfaces and Use
Cases

[Essential] Login Screen   ( Actual Implemented UI )

                               27
The login screen consists of a web page with a login form. The server
must verify that a session exists before allowing a user to interact with
other parts of the application. The login method shall utilize forms-
based authentication.

A sketch of the login page is shown below.




                               Login Screen


3.3 Performance Requirements

None

3.4 Logical Database Requirements

3.5 Design Constraints

Task Manager will be designed as web application which only requires
web browser on user's computer. Application will be implemented in
Java and deployed on web server like Apache Tomcat, Oracle
Container for Java (OC4J)

3.5 Standard Compliance

Intentionally omitted.

3.6 Software System Attributes

                                   28
3.6.1 Reliability

No reliability requirements are established for this version of the
product. Integrity of Task Manager information is dependent on the
underlying database system and is subject to the reliability
requirements of the database management team.

3.6.2 Availability ( Not Implemented )

Application will be available 24x7 except for the maintenance window
which will be from Saturday 7pm to Sunday 7am.

3.6.3 Security (Not Implemented )

In order to use the Task Manager application, user needs to provide
login credentials. Once a user is logged in, the user's role will be
identified and he/she will only be allowed to perform tasks available to
user's role.

The following security features are not planned for the initial release,
but are presented below for future versions.

[optional] Task Manager shall have the capability to run over HTTPS as
a web application. HTTPS is HTTP running over SSL, which encrypts all
data that passes between the web browser and the server. Refer to
Appendix for more information regarding HTTPS and SSL.

[optional] Task Manager shall have the capability to allow users to
login with a username and password, with the password stored in MD5
encryption format in the database. Refer to Appendix for more
information regarding MD5.

[optional] Additional login functionality supporting LDAP servers for user
authentication shall be supported in a future version where username
passwords and authentication are handled separately using Directory
Services that supports LDAP. Refer to Appendix for more information
regarding LDAP and Directory Services.



3.6.4 Maintainability ( Implemented )




                                    29
3.6.4.1 Application updates/maintenance.
[essential] Application will be accessible from generic URL that will never
change. Any bug fix release, patches, updates to the application will be
transparent to the end user.


3.6.5 Portability ( Implemented )



Client application: Application will be accessible from any web browser.

Server application: The application shall be written in Java, so it may be
run on system platforms that run J2EE server.


3.7 Organizing Specific Requirements


3.7.1 System Mode

Intentionally omitted.

3.7.2 User Class

Intentionally omitted.

3.7.3 Objects

Intentionally omitted.

3.7.4 Feature

Intentionally omitted.

3.7.5 Stimulus

Intentionally omitted.

3.7.6 Response

Intentionally omitted.

3.7.7 Functional Hierarchy

                                     30
Intentionally omitted.


3.8 Additional Comments

None

4. Supporting Information
4.1 Appendixes

The following URLs, provide additional information regarding SSL and
HTTPS:
http://www.webopedia.com/TERM/S/SSL.html
http://www.snopes.com/computer/internet/https.asp

The following URLs, provide additional information regarding LDAP and
Directory Services:
http://www.webopedia.com/TERM/L/LDAP.html
http://www.openldap.org/

Microsoft Active Directory:
http://www.microsoft.com/windowsserver2003/technologies/directory/
activedirectory/default.mspx

Novell eDirectory:
http://www.novell.com/products/edirectory/




                                  31

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:4/16/2013
language:English
pages:31