<Online Voting System>
Modern Software Requirements Specification
Version <1.0>
[Note: The Software Requirements Specification (SRS) captures the complete software requirements for the system, or a portion of the system. The Modern SRS is a typical SRS outline for a project using use-case modeling. This artifact consists of a package containing use cases of the use-case model and applicable Supplementary Specifications and other supporting information. For a template of an SRS not using use-case modeling, which captures all requirements in a single document, with applicable sections inserted from the Supplementary Specifications (which would no longer be needed), see /program files/Rational/ RequisitePro/Outlines/ rup_srs.dot.]
Many different arrangements of an SRS are possible. Refer to [IEEE93] for further elaboration of these explanations, as well as other options for SRS organization.]
Revision History
Date | Version | Description | Author |
2005-2-22 | <1.0> | Create the documentation | Le Jianping |
|
|
|
|
|
|
|
|
|
|
|
|
Table of Contents
1. Introduction 3
1.1 Purpose 3
1.2 Scope 3
1.3 Definitions, Acronyms and Abbreviations 3
1.4 References 3
1.5 Overview 3
2. Overall Description 3
2.1 Use-Case Model Survey 3
2.1.1 Introduction 3
2.1.2 Survey Description 3
2.1.3 Use-Case Model Hierarchy 3
2.1.4 Diagrams of the Use-Case Model 3
2.2 Assumptions and Dependencies 3
3. Requirements 3
3.1 Use-Case Specifications 3
3.2 Functionality 3
3.2.1 <Functional Requirement One> 3
3.3 Usability 3
3.3.1 <Usability Requirement One> 3
3.4 Reliability 3
3.5 Performance 3
3.5.1 <Performance Requirement One> 3
3.6 Supportability 3
3.6.1 <Supportability Requirement One> 3
3.7 Design Constraints 3
3.7.1 <Design Constraint One> 3
3.8 Online User Documentation and Help System Requirements 3
3.9 Purchased Components 3
3.10 Interfaces 3
3.10.1 User Interfaces 3
3.10.2 Hardware Interfaces 3
3.10.3 Software Interfaces 3
3.10.4 Communications Interfaces 3
3.11 Licensing Requirements 3
3.12 Legal, Copyright and Other Notices 3
3.13 Applicable Standards 3
Modern Software Requirements Specification
1. Introduction
1.1 Purpose
This document will define all system requirements for the Online Voting System . The intended audience for the SRS includes the users, developers and testers .
1.2 Scope
A majority of Process Impact employees presently spend an average of 30 minutes on
voting their opinion about some issue about their work or other things. Before, we must have a meeting in every department to draw a conclusion. All employees must leave their seat and go to the meeting-room for discussion. It is time-waste and need a lot of meeting-room.
Many employees have requested a system that would permit them to voting on-line, to be delivered to a designated company discussion board at a specified time and date. Such a system would save those employees who use the service considerable time. This would improve both their quality of work life and their productivity.
1.3 Definitions, Acronyms and Abbreviations
1.4 References
² IEEE Standards “Software Engineering , Volume Two , Process Standards,” Std 830-1998,1999 Edition .
² The Unified Development Process , I.Jacobson , G. Booch, J. Rumbaugh, January 1999
² Software Engineering –A Practitioner’s approach , Roger S. Pressman, 1992
1.5 Overview
This document will describe all the specific requirements for the Online Voting System . All nonfunctional requirements will be defined in state form . Each nonfunctional requirements will be mmeasurable or be able to be checked off as met or not met . Software requirements are described in terms of the entities , or classes , that make up the system . The software requirements were gathered and analyzed with an object-oriented approach coupled with a screen prototyping and storyboarding approach . coupled with a screen prototyping and storyboarding approach . The artificats developed through this process will be maintained as attachments to this document . These artifacts include the Use Case Models , Use Case specifications , Analysis Class Diagram , sequence Diagrams , and the screen prototypes/storyboards .
2. Overall Description
This section of the Modern SRS should describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in section 3, and makes them easier to understand. Include such items as product perspective, product functions, user characteristics, constraints, assumptions and dependencies, and requirements subsets.
2.1 Use-Case Model Survey
This section contains an overview of the use-case model or the subset of the use-case model that is applicable for this subsystem or feature. This includes a list of names and brief descriptions of all use cases and actors, along with applicable diagrams and relationships. This section describes the use-case model comprehensively, in terms of how the model is structured into packages and what use cases and actors there are in the model. If you are using packages, the document shows the model structure hierarchically.
2.1.1 Introduction
The use-case model provides a special to let the user know how to operate the system and the devision of the software .
2.1.2 Survey Description
The use case model can help develop to understand the need of the system
2.1.3 Use-Case Model Hierarchy
This section presents the use-case packages hierarchically, explains the dependencies among them, and shows the content of each package recursively. If the model has several levels of packages, those at the top-level are presented first. The packages within these are presented next, and so on, all the way down to the packages at the bottom of the hierarchy. For each package include:
· The Name.
· A Brief Description explaining the package's function and role in the system. The description must be understandable to any developer who wants to use the package.
· A list of the use cases owned by the package, including the name and brief description of each use case.
· A list of actors owned by the package, including the name and brief description of each actor.
· A list of relationships owned by the package, including the name and brief description of each relationship.
· A list of the packages directly owned by the package, with each package presented in the same hierarchical manner as above
2.1.4 Diagrams of the Use-Case Model
use-case diagrams, of the entire use-case model are included here:
2.2 Assumptions and Dependencies
We assume that the system is not very focused on security and there is another system is used as a forum in the system . All the information inputted by the operator is well enough to use .
3. Requirements
This section of the Modern SRS contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. When using use-case modeling, the majority of these requirements are captured in the use cases.
3.1 Use-Case Specifications
In use-case modeling, the use cases often define the majority of the functional requirements of the system, along with some non-functional requirements. For each use case in the above use-case model, or subset thereof, enclose the use-case specification here. If you have documented use cases in an separate document, cross reference to all applicable external use-case specifications in this section.
3.1.1 Login/Logoff Use Case
Actor(s):
User , Administrator
Description
This use case describes how a user logs into the Online Voting System .
The actors starting this use case are User and the administrator of the system .
Preconditions:
There are no preconditions associated with this use case ..
Postconditions
There are no postconditions associated with this use case ..
Priority:
Normal
Normal Course Of Events:
1.The system validates the actor’s password and logs him/her into the system.
2.The system displays the Main Form and the use case ends.
Alternative Courses:
1.Invalid Name / Password
If in the basic flow the system cannot find the name or the password is invalid, an error message is displayed. The actor can type in a new name or password or choose to cancel the operation, at which point the use case ends.
Exceptions:
Any connections to the database but return by an unthinkable result is regarded as an Exception , the hospital response will be sent to the user interface while the system error log will be created and sent to the administrator of the Online Voting System .
Includes:
Notes and Issues:
3.1.2 Voting
Actor(s):
Users , Administrators
Description
The users can answer to the questions listed on the Internet or voting for a result on the basis of the items listed bellowing list box .
Preconditions:
The user login to the Online voting system so that he or she can do the voting .
Postconditions
The statistics of the voting system can only be used after other people do the voting .
Priority:
Normal
Normal Course Of Events:
1. User login into the voting system .
2. User select the thesis that the user want to do the voting .
3. User Click the result and finish the voting .
Alternative Courses:
The user can answer the question or make some memory for some special thesis .
Exceptions:
The voting process is as usual , but the result cannot be seen or the submit form provide with an error message . .
Includes:
Includes nothing in the serious tasks
Notes and Issues:
3.1.3 See Voting Results
Actor(s):
Users , Administrators
Description
The user can browsing the thesis on the web and see the results of the voting .
Preconditions:
The user has login into the Online Voting System .
Postconditions
There are not postconditions for this use case .
Priority:
High
Normal Course Of Events:
1. User login into the Online Voting System .
2. User select the thesis of the online voting System .
3. The voting result can be seen on the web by clicking the thesis of the system .
Alternative Courses:
The user begin to vote for the thesis after seeing the result of the voting .
Exceptions:
There are no exception for the project .
Includes:
Notes and Issues:
3.1.4 Publish the Result .
Actor(s):
Administrators
Description
The administrator of the system can publish the result of the system .
Preconditions:
1. The administrator login into the Online Voting System .
2. The user has the authority to publish the result of the voting thesis .
Postconditions
The user can see the result of the online voting system after the result is published .
Priority:
High
Normal Course Of Events:
1.User login into the Online Voting System .
2.User select the thesis of the online voting System .
3. The user publish the result of the thesis of the project .
4.The voting result can be seen on the web by clicking the thesis of the system .
Alternative Courses:
1. The login user doesn’t have the authority to publish the Result so that the system provide the user with an information that he or she is not capable of this function .
Exceptions:
There are no exception for the project .
Includes:
Notes and Issues:
3.1.5 Publishing the issue .
Actor(s):
Board Manager , Administrator
Description
This function is used to put out the issue that needed to be voted on the Internet .
Preconditions:
1. User must login into the system
2. User has the authority to publish issue to be voted on .
Postconditions
Users can see the issues after the
Priority:
Normal
Normal Course Of Events:
1.User login into the Online Voting System .
2.User select the thesis of the online voting System .
3.The user publish the issue which is to be pubished
4.The issue can be seen on the internet after other’s coming to the internet .
Alternative Courses:
Error occurred whey user submit the issue .
Exceptions:
No exception on this use case .
Includes:
Notes and Issues:
3.2 Functionality
This section describes the functional requirements of the system for those requirements that are expressed in the natural language style. For many applications, this may constitute the bulk of the Modern SRS Package and thought should be given to the organization of this section. This section is typically organized by feature, but alternative organization methods, for example organization by user, or organization by subsystem may also be appropriate. Functional requirements may include: feature sets, capabilities and security.
Where application development tools (requirements tools, modeling tools, etc) are employed to capture the functionality, this section document will refer to the availability of that data and indicate the location and name of the tool which is used to capture the data.
3.3 Usability
This section lists all of those requirements that relate to, or affect, the usability of the system.
3.3.1 Windows Compliance
The desktop user-interface shall be Windows 95/98 and above OS environment compliant.
3.3.2 Design for Ease-of-Use
The user interface of the Software Engineer Tiniy tool system shall be designed for ease-of-use and shall be appropriate for a computer-literate user community with no additional training on the System.
3.3.3 Online Help
Each feature of the Online Voting System shall have built-in online help for the user. Online Help shall include step by step instructions on using the System. Online Help shall include definitions for terms and acronyms.
This section lists all of those requirements that relate to, or affect, the usability of the system.
3.3.4 Windows Compliance
The desktop user-interface shall be Windows 95/98 and above OS environment compliant.
3.3.5 Design for Ease-of-Use
The user interface of the Software Engineer Tiniy tool system shall be designed for ease-of-use and shall be appropriate for a computer-literate user community with no additional training on the System.
3.4 Reliability
This section lists all reliability requirements.
3.4.1 Availability
The Online Voting System shall be available 24 hours a day, 7 days a week. There shall be no more than 4% down time.
3.4.2 Mean Time Between Failures
Mean Time Between Failures shall exceed 300 hours.
3.5 Performance
The performance characteristics of the system are outlined in this section.
3.5.1 Simultaneous Users
The system shall support up to 50 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time.
3.5.2 Database Access Response Time
The system shall provide access to the legacy course catalog database with no more than a 7 second latency.
3.5.3 Transaction Response Time
The system must be able to complete 80% of all transactions within 2 minutes
3.6 Supportability
This section defines any requirements that will enhance the supportability or maintainability of the system being built.
3.6.1 New Releases Downloadable
Upgrades to the PC client portion of Software Engineer tiny tool System shall be downloadable from the UNIX Server over the internet. This feature enables students to have easy access to system upgrades.
3.7 Design Constraints
This section lists any design constraints on the system being built.
3.7.1 Platform Requirements
The client portion of the Online Voting System shall operate on any personal computer with a PII processor or greater. The client portion shall require less than 100 MB disk space and 64MB RAM.
The server portion of the Software Engineer Tiniy tool system shall operate on the Wylie College UNIX server.
3.7.2 Internet Browsers
The web-based interface for the Software Engineer tiny tool System shall run in Netscape 4.0.4 and Internet Explorer 4.0 browsers.
3.8 Online User Documentation and Help System Requirements
Since the system is too easy to use , online documentation is almost not necessary .
3.9 Purchased Components
There are no purchased components in this project .
3.10 Interfaces
This section defines the interfaces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, etc, so that the software can be developed and verified against the interface requirements.
3.10.1 User Interfaces
The user interface shall require a distributed environment to allow users in various physical locations to access the system . Specific information about the Graphical User Interface is included in paragraph below .
3.10.2 Hardware Interfaces
No hardware interfaces are required .
3.10.3 Software Interfaces
No current software interfaces are required .
3.10.4 Communications Interfaces
No communications interfaces are required .
3.11 Licensing Requirements
The document is licensed to the owner of the system together with the develop stadium , any use of the source code should under the permission of the leader of the two perspectives . If not so , the lawyer will penalty you on the issue .
3.12 Legal, Copyright and Other Notices
©opyright 2005 , Online voting system fulcalty .
3.13 Applicable Standards
The software should be used by all the uses listed above and any one will learned to use the application in 3 days with an advanced user’s training .