Software Requirements Specification

for

APMS

Version 1.0 Prepared by:

Mountain High Consulting TEAM 2 Cathleen Brown Lull Mengesha Robert Ward Gary Westcott

November 24, 2007

Software Requirements Specification for APMS

Table of Contents Revision History ......................................................................................... iii 1. Introduction ........................................................................................... 1 1.1 Purpose........................................................................................... 1 1.2 Intended Audience and Reading Suggestions ........................................ 1 1.3 Project Scope ................................................................................... 1 1.4 References....................................................................................... 1 2. Overall Description ................................................................................. 2 2.1 Product Perspective........................................................................... 2 2.2 Product Features .............................................................................. 2 2.3 User Classes and Characteristics ......................................................... 2 2.4 Operating Environment...................................................................... 3 2.4.1 APMS Small Business Edition O.E. .................................................... 3 2.4.2 APMS Enterprise Edition O.E. ........................................................... 4 2.5 Design and Implementation Constraints ............................................... 4 2.6 User Documentation.......................................................................... 5 2.6.1 User Manuals ................................................................................ 5 2.6.2 Tutorial ........................................................................................ 5 2.6.3 On-Line Help ................................................................................. 5 2.7 Assumptions and Dependencies .......................................................... 5 3. System Features..................................................................................... 6 3.1 Functional Requirements.................................................................... 6 3.1.1 Functional Requirements................................................................. 6 3.2 Use Cases...................................................................................... 11 4. Other Nonfunctional Requirements ...................................................... 16 4.1 Performance Requirements .............................................................. 16 4.2 Portability Requirements .................................................................. 16 4.3 Reliability Requirements .................................................................. 17 4.4 Usability Requirements .................................................................... 17 4.5 Security Requirements .................................................................... 18 4.6 Scalability Requirements.................................................................. 18 5. Other Requirements ............................................................................. 19 Appendix A: Glossary ................................................................................ 19 Appendix B: Analysis Models..................................................................... 19 Appendix C: Issues List ............................................................................. 19 Tables Table Table Table Table Table Table Table Table Table Table Table Table Table 1: Revision History .............................................................................. iii 2. Intended audience of this document .................................................... 1 3: References ...................................................................................... 1 4: User Classes and Characteristics ......................................................... 2 5: Constraints...................................................................................... 4 6: Functional Requirements ................................................................... 6 7: Use Cases ..................................................................................... 11 8: Performance Requirements .............................................................. 16 9: Portability Requirements.................................................................. 16 10: Reliability Requirements ................................................................ 17 11: Usability Requirements .................................................................. 17 12: Security Requirements .................................................................. 18 13: Scalability Requirements................................................................ 18 Figures Figure 1: Product Features ............................................................................. 2

Page ii

Software Requirements Specification for APMS

Revision History
Table 1: Revision History
Name Original Date 11/24/2007 Original Release Reason For Changes Version 1.0.0

Page iii

Software Requirements Specification for APMS

1. Introduction
1.1 Purpose
The purpose of this document is to further define requirements for the APMS system.

1.2 Intended Audience and Reading Suggestions

Table 2. Intended audience of this document
Group of the readers APMS CEO APMS Management APMS Sales and Marketing Mountain High Consulting APMS System Architects APMS Developers/System Analysts Reasons for reading To be kept informed of the teams progress To give feedback about the requirements To ensure the requirements continue to be feasible To get feedback from others on the accuracy and completeness of the requirements To ensure continued accuracy of the system design and commence architectural design To give feedback about the requirements and commence functional design

1.3 Project Scope

Advanced Project Management Systems (APMS) is a 100 Million Dollar, privatelyowned company, specialized in software tool development. APMS would like to become a major player in the market for Distributed Project Management (DPM) software tools. Advanced Project Management Systems (APMS) specializes in software development. The company is proposing to become a major player in the market for Distributed Project Management (DPM) software tools. Their vision is to become the premier provider of high-quality, distributed project management tools to organizations worldwide. APMS will compete with all key players in the market by coming up with better tools that support planning, tracking, collaborating, replanning, closeout, reflection, and historical data update in a distributed environment. This project encompasses APMS efforts to design and construct a world class DPM software package including capability for both large and small projects.

1.4 References
Table 3: References
Name of the document User Requirements of 11/10/2007 ConOps of 10/27/2007 project Concept of Operations Document, dated October 27, 2007 for the APMS project Short description of the document contents User Requirements Document, dated October 10, 2007 for the APMS

Page 1

Software Requirements Specification for APMS

Recommendation of 10/13/2007 Recommendation for Design and Development of Distributed Project Management Software for Advanced Project Management Systems

2. Overall Description
2.1 Product Perspective
This Distributed Project Management (DPM) software product is a new development, planned to meet the needs of companies managing projects on a global basis. It is a self-contained product but includes the facilities required to export and import data in recognized, standardized formats.

2.2 Product Features

Figure 1: Product Features

C re a te , M a in ta in , R e p o rt C P M S c h e d u le

M a in ta in P ro je c t

M a in ta in R e s o u r c e T a b le

M a in ta in S c h e d u le

M a in ta in R e s o u rc e R e q u ire m e n ts

M a in ta in C o s t D a ta

A n a ly z e C P M N e tw o rk

A n a ly z e R e s o u r c e R e q u ire m e n ts

R e p o r tin g

C r e a te P r o je c t

C re a te R e s o u rc e T a b le

C r e a te S c h e d u le

E n te r R e s o u rc e R e q u ire m e n t o n S c h e d u le A c tiv ity

B u d g e t D a ta

P e rfo rm C a lc u la tio n s

S u m m a riz e R e s o u rc e s

S c h e d u le R e p o r ts

M o d ify P r o je c t

E n te r R e s o u r c e

E n te r A c tiv ity

M o d ify R e s o u r c e R e q u ire m e n t o n S c h e d u le A c tiv ity

E n te r o n S c h e d u le A c tiv ity M o d ify o n S c h e d u le A c tiv ity

D ia g n o s e E rr o r s

L e v e l R e s o u rc e s

T a b u la r R e p o r ts

G r a p h ic R e p o r ts

D e le te P ro je c t

M o d ify R e s o u rc e

M o d ify A c tiv ity

D e le te R e s o u r c e R e q u ire m e n t o n S c h e d u le A c tiv ity

D e le te o n S c h e d u le A c tiv ity

R e s o u r c e R e p o r ts

D e le te R e s o u rc e

D e le te A c tiv ity

A c tu a l D a ta T a b u la r R e p o r ts E n te r o n S c h e d u le A c tiv ity M o d ify o n S c h e d u le A c tiv ity

E n te r C o n s tra in t

G r a p h ic R e p o r ts

M o d ify C o n s tr a in t

C o s t R e p o r ts D e le te o n S c h e d u le A c tiv ity

T a b u la r R e p o r ts D e le te C o n s tra in t F o r e c a s t D a ta G r a p h ic R e p o r ts

E n te r o n S c h e d u le A c tiv ity M o d ify o n S c h e d u le A c tiv ity D e le te o n S c h e d u le A c tiv ity

2.3 User Classes and Characteristics

Table 4: User Classes and Characteristics
Number of User Group Large System Planner/Schedulers Responsible for schedule development and maintenance. 10 + Description Users Priority

Page 2

Software Requirements Specification for APMS

Number of User Group Engineers Cost Analyst Description Responsible for schedule status inputs. Responsible for input and maintenance of committed and actual cost data, along with estimates to complete. Responsible for input and maintenance of physical complete data along with remaining work. Also provide estimates for changes. Responsible for overall management of specified portions of the project. Responsible for overall project management primarily read and reporting access for schedule data, input and maintenance of budgetary data. Users 50 + 20 + Priority

Quantity Surveyors

20 +

Managers

30 +

Project Manager

1+

Small System Planner/Schedulers Responsible for schedule development and maintenance. Responsible for schedule status inputs. Responsible for input and maintenance of committed and actual cost data, along with estimates to complete. Responsible for input and maintenance of physical complete data along with remaining work. Also provide estimates for changes. Responsible for overall management of specified portions of the project. Responsible for overall project management primarily read and reporting access for schedule data, input and maintenance of budgetary data. 1+

Engineers Cost Analyst

10 + 2+

Quantity Surveyors

5+

Area Managers

5+

Project Manager

1+

2.4 Operating Environment

2.4.1 APMS Small Business Edition O.E. APMS Small Business Edition will be able to operate on the following platforms: Microsoft 2003 Server, Enterprise Server and Small Business Server Linux Server All Major Business Versions The Server software will have fail over capability between two servers as well as replication capability. The UI will be functional on all major browsers including Internet Explorer 6.0 and higher, as well as Mozilla and Firefox. APMS SBE will be able to functionally interact with Adobe Acrobat, Microsoft Office product suite and the Star Office product suite. APMS will have a UI and functionality designed for PDAs including the Blackberry, Compaq, and the Palm.
Page 3

Software Requirements Specification for APMS

2.4.2 APMS Enterprise Edition O.E. APMS Enterprise Edition will be able to operate will be able operate across multiple geographical sites to truly be a world wide system. The system will be able to utilize DNS and site replication, operate on a cluster server environment. The system will be operational on all server systems listed for APMS Small Business Edition as well as the Sun and HP UNIX platforms. APMS will be operational with both Oracle and Microsoft SQL Server version 2000 or higher. All browser, software interoperability and PDA functionality required of the APMS Small Business Edition operating environment will apply to APM Enterprise Edition operating environment.

2.5 Design and Implementation Constraints

Table 5: Constraints
Traces to use ID C1 Ver 1 Constraint The user interface must run on any well-known browser including IE, Opera and Mozilla. Source Technical Coordinator N.N Rationale People have different browsers we want to serve them all. Priority Must Status Proposed cases All use cases involving a browser interface, login, update, etc. C2 1 Activity must function on single server small business system as well as international system which multiple servers and locations utilizing DNS and replication. C3 1 System will have operative functionality on portable handheld devices (PDAs, Blackberrys, etc.) C4 All A new or emerging Technical requirement C5 1 Confusion between where business rule ends and technical requirements begin C6 4 As application systems live longer and grow in size and complexity, there is an ever increasing need for methods and tools that can support software builders in constructing maintainable, wellstructured and consistent systems. Software applications Software constraints make rules and conventions commonly agreed to in a given programming environment explicit and automatically checkable. TBD TBD TBD New development Business rule Portability Users are constantly on the go, and may not have access to PC or laptop. Adapting to new changes in technical software Both systems are closely ingrained Must Proposed TBD Must As needed Must Proposed All use cases where performance is a Quality Attribute. As needed Scalability Changes in scalability will not impact product performance for any product version Must Proposed All use cases where performance is a Quality Attribute.

Page 4

Software Requirements Specification for APMS

2.6 User Documentation

2.6.1 User Manuals A user manual and a reference manual will be provided. The user manual will be organized by function within the application, allowing the user to read the details associated with each portion of the application. The reference manual will be organized like an encyclopedia, allowing the user to look up specific topics for explanation. 2.6.2 Tutorial A tutorial will be provided. The tutorial will step a user through the complete process of setting up a project, entering data, performing calculations, and outputting reports using example data which will also be provided in a tutorial folder upon installation of the application. 2.6.3 On-Line Help On-line, context sensitive help will be provided for all screens and menus. The help will be accessible via the F1 function key and right mouse click.

2.7 Assumptions and Dependencies

Assumed factors and constraints that could affect the requirements stated in this SRS: 1. Changes or upgrades to Operating Systems APMS runs on. Any changes would require retesting of software. 2. Changes or upgrades to Software interoperable with APMS, i.e. browsers, MS Office, Star Office, etc. Any changes would require retesting of software. 3. Changes or upgrades operating systems running on PDAs or other portable device hardware. Any changes would require retesting of software

Page 5

Software Requirements Specification for APMS

3. System Features
3.1 Functional Requirements
Table 6: Functional Requirements

3.1.1 Functional Requirements Priority Legend M Must Have

ID P1 Ver 1 Feature Maintain Project

S Should Have
Requirement User shall be able to create project database file User shall be able to modify project database file User shall be able to delete project database file Source

N Nice to Have
Traces to use Rationale cases 1.1, 2.1 Priority Stable\Unstable Risk

Project Must be able to create a Manager (DA) project database file to contain all project data Project Must be able to modify a Manager (DA) project database file

stable

P2

Maintain Project

TBD

stable

P3

Maintain Project

Project Must be able to delete a Manager (DA) project database file

TBD

stable

RT1

Maintain Resource User shall be able to Table create an available resource table

Planner Must be able to create a Scheduler (HB) table containing all available resources

1.1, 2.1

stable

RT2

Maintain Resource User shall be able to enter Planner Must be able to enter 1.1, 2.1 Scheduler (HB) available resource records Table a resource into the available resource table Maintain Resource User shall be able to Table modify an existing resource in the available resource table Maintain Resource User shall be able to Table delete an existing resource from the available resource table Planner Must be able to modify or 1.3 Scheduler (HB) update available resource records

stable

RT3

stable

RT4

Planner Must be able to delete 1.3 Scheduler (HB) available resource records

stable

Page 6

Software Requirements Specification for APMS

M Must Have
ID S1 Ver 1 Feature

S Should Have
Requirement Source

N Nice to Have
Traces to use Rationale cases Priority Stable\Unstable stable Risk

Maintain Schedule User shall be able to create a schedule database

Planner Must be able to create a 1.1 Scheduler (HB) schedule database file to contain a schedules data 1.1, 2.1

S2

Maintain Schedule User shall be able to enter Planner Must be able to add new Scheduler (HB) activity to the schedule an activity into the database schedule database

stable

S3

Planner Maintain Schedule User shall be able to Must be able to modify an 1.3, 1.4 modify an existing activity Scheduler (HB) existing activity in the schedule database Planner Maintain Schedule User shall be able to Must be able to delete an 1.3, 1.4 delete an existing activity Scheduler (HB) existing activity from the schedule database Maintain Schedule User shall be able to enter Planner Must be able to enter logic 1.2, 2.2 Scheduler (HB) constraints linking a constraint into the activities to model the schedule database work flow in the schedule Planner Maintain Schedule User shall be able to Must be able to modify an 1.4 Scheduler (HB) existing logic constraint modify an existing constraint in the schedule database Maintain Schedule User shall be able to delete an existing constraint from the schedule database Planner Must be able to delete an 1.4 Scheduler (HB) existing logic constraint

stable

S4

stable

S5

stable

S6

stable

S7

stable

RR1

TBD Maintain Resource User shall be able to add a Planner Must be able to add a Requirements resource requirement to Scheduler (HB) required resource to a schedule activity in order an activity in the schedule to support resource database scheduling Planner Maintain Resource User shall be able to Must be able to modify an TBD Scheduler (HB) existing resource on an Requirements modify a resource activity requirement on an activity in the schedule database

stable

RR2

stable

Page 7

Software Requirements Specification for APMS

M Must Have
ID RR3 Ver 1 Feature

S Should Have
Requirement Source

N Nice to Have
Traces to use Rationale cases Priority Stable\Unstable Risk

Maintain Resource User shall be able to Requirements delete a resource requirement from an activity in the schedule database Maintain Cost Data

Planner Must be able to delete an TBD Scheduler (HB) existing resource from an activity

stable

C1

User shall be able to enter Cost Analyst (AC) budget cost data on schedule activity

TBD Must be able to enter budget cost data on each schedule activity in order to summarize project budgets Must be able to modify TBD existing budget cost data on a schedule activity TBD Must be able to delete existing budget cost data from a schedule activity TBD Must be able to enter actual cost data on each schedule activity in order to summarize project actual costs Must be able to modify existing actual cost data on a schedule activity Must be able to delete existing actual cost data from a schedule activity TBD

stable

C2

Maintain Cost Data

User shall be able to modify budget cost data on schedule activity User shall be able to delete budget cost data from schedule activity

Cost Analyst (AC)

stable

C3

Maintain Cost Data

Cost Analyst (AC)

stable

C4

Maintain Cost Data

User shall be able to enter Cost Analyst (AC) actual cost data on schedule activity

stable

C5

Maintain Cost Data

Cost Analyst User shall be able to modify actual cost data on (AC) schedule activity User shall be able to delete actual cost data from schedule activity Cost Analyst (AC)

stable

C6

Maintain Cost Data

TBD

stable

C7

Maintain Cost Data

User shall be able to enter Cost Analyst (AC) forecast cost data on schedule activity

TBD Must be able to enter forecast to complete cost data on each schedule activity in order to summarize project forecasted costs

stable

Page 8

Software Requirements Specification for APMS

M Must Have
ID C8 Ver 1 Feature Maintain Cost Data

S Should Have
Requirement Source

N Nice to Have
Traces to use Rationale Must be able to modify existing forecast to complete data on a schedule activity Must be able to delete existing forecast to complete data from a schedule activity TBD M stable cases Priority Stable\Unstable Risk

Cost Analyst User shall be able to modify forecast cost data (AC) on schedule activity

C9

Maintain Cost Data

User shall be able to delete forecast cost data from schedule activity

Cost Analyst (AC)

TBD M stable

AN1

Analyze Network

User shall be able to perform CPM analysis calculations on schedule

Planner Must be able to perform Scheduler (HB) critical path analysis on the schedule in order to calculate the dates

1.5 M Stable

AN2

Analyze Network

User shall be able to diagnose CPM analysis errors from schedule

Planner Must be able to diagnose 1.5 Scheduler (HB) any error that occur during schedule analysis TBD

Stable

AR1

Analyze ResourcesUser shall be able to Must be able to Planner summarize required Scheduler (HB) summarize the resource resource quantities by requirements by time month and resource name period and resource in order to plan resources across schedule across the project

Stable

AR2

Planner Analyze ResourcesUser shall be able to Must be able to manage TBD perform resource leveling Scheduler (HB) the resource requirements on schedule to constrained resource availability levels Reporting Area Manager Must be able to produce User shall be able to tabular schedule reports produce tabular schedule (JS) to represent and reports communicate the work flow across the project User shall be able to produce graphical schedule reports TBD

Stable

R1

Stable

R2

Reporting

Area Manager Must be able to produce TBD (JS) graphical schedule reports to represent and communicate the work flow across the project

Stable

Page 9

Software Requirements Specification for APMS

M Must Have
ID R3 Ver 1 Feature Reporting

S Should Have
Requirement Source

N Nice to Have
Traces to use Rationale cases Priority Stable\Unstable Risk

Area Manager Must be able to produce TBD User shall be able to tabular resource reports produce tabular resource (JS) to represent and reports communicate the resource requirements across the project User shall be able to produce graphical resource reports Area Manager Must be able to produce TBD (JS) graphical schedule reports to represent and communicate the resource requirements across the project Area Manager Must be able to produce TBD (JS) tabular cost reports to represent and communicate the project costs Area Manager Must be able to produce TBD (JS) graphical cost reports to represent and communicate the project costs

Stable

R4

Reporting

Stable

R5

Reporting

User shall be able to produce tabular cost reports

Stable

R6

Reporting

User shall be able to produce graphical cost reports

Stable

Page 10

Software Requirements Specification for APMS

3.2 Use Cases

Table 7: Use Cases
Use Case Description Actors Assumptions Use Case 1.1 - Interactive Gantt Chart Add Activity Goal: Activity, with associated resources, added to schedule. Source: Interactive Web Gantt Chart Project Scheduler Planner New activity is required to describe a work task. Planner/Scheduler has access to the application. 1. User accesses application opens applicable schedule file. 2. User selects Gantt Chart from menu bar. 3. Application displays interactive Gantt chart screen. 4. User selects Add Activity from menu bar 5. Application provides New Activity input form. 6. User completes required fields. 7. User clicks on Add Activity button. 8. Application adds activity to database. 9. Application presents Add Constraint? dialog to user. 10. User clicks either Yes or No If Yes - application presents Add Constraint form (see Use Case 1.2) If No application returns to interactive Gantt chart screen. None Pe1, Po1, Po2, Se1 Se4, R1 R3, U1, U3

Steps

Variations Traces to Quality Attributes:

Use Case Description Actors Assumptions

Use Case 1.2 - Interactive Gantt Chart Add Constraint Goal: Constraint added to schedule. Source: Interactive Web Gantt Chart Project Scheduler Planner New constraint is required to describe relationship between two work tasks. Planner/Scheduler has access to the application. 1. User accesses application, opens applicable schedule file. 2. User selects Gantt Chart from menu bar. 3. Application displays interactive Gantt chart screen. 4. User selects Add Constraint from menu bar 5. Application displays Gantt chart of activities and constraint dialog panel. 6. User locates and clicks on first activity, then clicks on appropriate identifier (predecessor or successor) in constraint dialog panel. 7. User locates and clicks on second activity, then clicks on appropriate identifier (predecessor or successor) in constraint dialog panel. 8. User completes additional information in constraint dialog panel type of constraint, delay. 9. User clicks on Add Constraint button. 10. Application adds constraint to database. 11. Application presents Add Additional Constraint? dialog to user. 12. User clicks either Yes or No If Yes - application presents Add Constraint form (see Use Case 1.2 If No application returns to interactive Gantt chart screen. None Pe1, Po1, Po2, Se1 Se4, R1 R3, U1, U3

Steps

Variations Traces to Quality Attributes:

Page 11

Software Requirements Specification for APMS

Use Case Description Actors Assumptions Use Case 1.3 - Interactive Gantt Chart Modify Activity Goal: Activity, with associated resources, modified in schedule. Source: Interactive Web Gantt Chart Project Scheduler Planner An activity describing a work task requires modification. Planner/Scheduler has access to the application. 1. User accesses application, opens applicable schedule file. 2. User selects Gantt Chart from menu bar. 3. Application displays interactive Gantt chart screen. 4. User right clicks on activity to be selected 5. Application provides dialog panel. 6. User clicks on Modify Activity option. 7. Application provides Activity Information panel. 8. User completes/modifies required fields. 9. User click on Save Activity button. 10. Application saves modified activity to database. 11. Application returns to interactive Gantt chart screen. None Pe1, Po1, Po2, Se1 Se4, R1 R3, U1, U3

Steps

Variations Traces to Quality Attributes:

Use Case Description Actors Assumptions

Use Case 1.4 - Interactive Gantt Chart Modify Constraint Goal: Activity, with associated resources, modified in schedule. Source: Interactive Web Gantt Chart Project Scheduler Planner A constraint linking activities requires modification. Planner/Scheduler has access to the application. 1. User accesses application and opens applicable schedule file. 2. User selects Gantt Chart from menu bar. 3. Application displays interactive Gantt chart screen. 4. User right clicks on selected activity 5. Application provides dialog panel. 6. User clicks on Modify Constraint option. 7. Application provides list of constraints linked to selected activity. 8. User clicks on constraint requiring modification. 9. Application provides Constraint Information panel. 10. User completes/modifies required fields. 11. User click on Save Constraint button. 12. Application saves modified constraint to database. 13. Application returns to interactive Gantt chart screen. None Pe1, Po1, Po2, Se1 Se4, R1 R3, U1 U3

Steps

Variations Traces to Quality Attributes:

Page 12

Software Requirements Specification for APMS

Use Case Description Actors Assumptions Use Case 1.5 - Interactive Gantt Chart Perform CPM analysis Goal: Analyzed Critical Path Schedule. Source: Interactive Web Gantt Chart Project Scheduler Planner Schedule has been modified, requires (re)analysis. Planner/Scheduler has access to the application. 1. User accesses application and opens applicable schedule file. 2. User selects Gantt Chart from menu bar. 3. Application displays interactive Gantt chart screen. 4. User selects Analyze Schedule from menu bar 5. Application provides Schedule Analysis dialog panel. 6. User completes required fields Status Date. 7. User clicks on Analyze Schedule button. 8. Application performs CPM analysis on schedule. If Errors Application displays diagnostics dialog panel If No Errors Application displays success dialog panel with information about results of analysis. 9. User clicks OK button 10. Application returns to interactive Gantt chart screen. None Pe1, Po1, Po2, Se1 Se4, R1 R3, U1 U3

Steps

Variations Traces to Quality Attributes: Use Case Description Actors Assumptions Steps

Use Case 2.1 - Interactive Network Diagram Chart Add Activity Goal: Activity, with associated resources, added to schedule. Source: Interactive Web Network Chart Project Scheduler Planner New activity is required to describe a work task. Planner/Scheduler has access to the application. 1. User accesses application, opens applicable schedule file. 2. User selects Network Diagram from menu bar. 3. Application displays interactive network diagram screen. 4. User selects Add Activity from menu bar 5. Application provides New Activity input form. 6. User completes required fields. 7. User clicks on Add Activity button. 8. Application adds activity to database. 9. Application presents Add Constraint? dialog to user. 10. User clicks either Yes or No If Yes - application returns to network diagram screen (see Use Case 2.2) If No application returns to interactive network diagram screen. None Pe1, Po1, Po2, Se1 Se4, R1 R3, U1, U3

Variations Traces To Quality Attributes:

Page 13

Software Requirements Specification for APMS

Use Case Description Actors Assumptions Use Case 2.2 - Interactive Network Diagram Add Constraint Goal: Constraint added to schedule. Source: Interactive Web Network Diagram Chart Project Scheduler Planner New constraint is required to describe relationship between two work tasks. Planner/Scheduler has access to the application. 1. User accesses application, opens applicable schedule file. 2. User selects Network Diagram from menu bar. 3. Application displays interactive network diagram screen. 4. User locates and clicks on first activity. 5. User drags line to second activity and releases mouse button. 6. Application presents Constraint Information dialog panel. 7. User completes additional information in constraint dialog panel type of constraint, delay. 8. User clicks on Add Constraint button. 9. Application adds constraint to database. 10. Application returns to interactive network diagram screen. None Pe1, Po1, Po2, Se1 Se4, R1 R3, U1, U3

Steps

Variations Traces To Quality Attributes:

Use Case Description Actors Assumptions

Use Case 3.1 Issue Log Add issue Goal: Issue is added to the log Source: Interactive Web Team Member New issue has been raised and needs to be documented 1. User accesses Web and opens issue log. 2. User selects add issue from menu. 3. Next available issue number is displayed. 4. User selects his name as Originator from dropdown menu. 5. Users enters project name from dropdown menu. (Optional step depending on needs of the company) 6. User enters a title for the issue. 7. User enters description of the issue. 8. User sets the status to new from a dropdown menu. 9. User selects priority from dropdown menu. 10. User clicks on submit button. 11. Application adds issue to the log. 12. Application returns to main Issue Log menu. Step 5 is optional. A small company may only have one project. In a large company with many projects related issues may want/need to be grouped together. Pe1, Po1, Po2, Se1 Se4, U1 - U3, Sc1, R1 R3

Steps

Variations Traces to requirements

Page 14

Software Requirements Specification for APMS

Use Case Description Actors Assumptions Use Case 3.2 Issue Log Update Existing Issue Goal: Issue is updated either status or responsible person Source: Interactive Web Originator of Issue, Responsible person, or Project Manager (PM) Existing Issue needs to updated 1. User accesses Web and opens issue log. 2. User selects Update Issue from menu. 3. List of Issue numbers and titles is displayed. 4. User selects issue. 5. Issue is displayed. 6. User updates field(s) as needed using dropdown menus where available. 7. User clicks on submit button. 8. Application updates issue in the log. 9. Application returns to main Issue Log menu. If a non-PM tries to update responsible person field an error message will be generated and that field will not be updated. Pe1, Po1, Po2, Se1 - Se4, U1 - 3 R1 R3

Steps

Variations Traces to requirements

Use Case Description Actors Assumptions

Use Case 3.3 Issue Log Request Report Goal: A report is generated Source: Interactive Web Team Member User requests a report 1. User accesses Web and opens issue log. 2. User selects Request Report from menu. 3. List of reports is displayed. 4. User selects report. 5. Report is displayed. 6. User is asked if he wants to print the report, save the report, request another report, or return to main menu. 7. User clicks on appropriate button. 8. The application takes appropriate action. 9. When reporting requests are complete user clicks on return to main menu button. 10. Application returns to main Issue Log menu. Steps 2 through 8 may be repeated multiple times. Pe2, Po1, Po2, Se1 Se4, U1 - U.3, R1 R3

Steps

Variations Traces to

Page 15

Software Requirements Specification for APMS

4. Other Nonfunctional Requirements

4.1 Performance Requirements
Table 8: Performance Requirements
Quality Attribute ID Pe1 Ver 1 Requirement System response time less than two seconds Type Performance Rationale System network latency must be kept to a minimum. Multiple users making multiple updates simultaneously. Pe2 1 Report must be generated within 10 seconds. Performance Processing large volumes of data may take more than 2 seconds. 3.3 M Stable Traces to use cases All except 3.3 M Stable Priority Stable\Unstable Risk

4.2 Portability Requirements

Table 9: Portability Requirements
Quality Attribute ID Po1 Ver 1 Requirement System response time less than 8 seconds on wireless devices. Type Portability Rationale System network latency must be kept to a minimum. Multiple users making multiple updates simultaneously. Network latency can be expected to be greater on wireless or non T1 networks. Po2 1 Any work done off line will automatically synchronize upon networking device. Portability Users must be able to synchronize their offline changes as quickly as possible after networking. All M unstable Dependent on network connectivity M unstable Dependent on network connectivity Traces to use cases All Priority Stable\Unstable Risk

Page 16

Software Requirements Specification for APMS

4.3 Reliability Requirements

Table 10: Reliability Requirements
Quality Attribute ID R1 Ver 1 Requirement Data input into the system will have multiple daily incremental backups as well as daily full backups. R2 1 Data backup on large systems will be replicated to other site locations for fail over disaster recovery. R3 1 Data recovery will take no more than 30 minutes from the time user contacts the help desk. M Unstable Reliability Reliability Larger volumes of data are harder to recover so storing in a separate location makes good sense. The Users inability to do their work will be kept to a minimum. All Assumes 24/7 support team. Scalability (large geographical coverage could impact restore time). All M Stable Type Reliability Rationale Data will be restored as close to the time it is lost as possible. Traces to use cases All S Stable Priority Stable\Unstable Risk

4.4 Usability Requirements

Table 11: Usability Requirements
Quality Attribute ID U1 Ver 1 Requirement System shall be menu driven Type Usability Rationale Menus make it easy to navigate and will encourage exploration of the system. U2 1 System shall use dropdown menus where feasible. Usability Dropdown menus show the valid options and makes learning quicker and easier. 1.4, 1.5, 3.1, 3.2, 3.3 S Stable Traces to use cases All M Stable Priority Stable\Unstable Risk

Page 17

Software Requirements Specification for APMS

Quality Attribute ID U3 Ver 1 Requirement The user interface will be intuitive and easy to negotiate. Type Usability Rationale Users will not spend unnecessary time navigating the UI. Traces to use cases All M Stable Priority Stable\Unstable Risk

4.5 Security Requirements

Table 12: Security Requirements
Quality Attribute ID Se1 Se2 Ver 1 1 Requirement Only registered users are allowed to use the system User Name and password are encrypted. Se3 Se4 1 1 Data is encrypted when traveling over http. Access to menus/functions is based on the role of the user. Security Security Security Type Security Rationale Confidential information must not leak out of the company. http is easily hackable. Identities would be compromised. Hackers can easily hack into http systems to steal data. Only the authorized role can perform certain functions. All M Stable All M Stable All M Stable Traces to use cases All M Stable Priority Stable\Unstable Risk

4.6 Scalability Requirements

Table 13: Scalability Requirements
Quality Attribute ID Sc1 Ver 1 Requirement Menus can be added or deleted as needed Type Scalability Rationale Not all menus or options are needed for a small business N Unstable Traces to use cases 3.1 Normally this functionality is added at install. Priority Stable\Unstable Risk

Page 18

Software Requirements Specification for APMS

5. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each SRS.>

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.>

Appendix C: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>

Page 19