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

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

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 .

Online Voting System SRS1. Introduction2. Overall Description3. Requirements

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms and Abbreviations

1.4 References

1.5 Overview

2. Overall Description

2.1 Use-Case Model Survey

2.1.1 Introduction

2.1.2 Survey Description

2.1.3 Use-Case Model Hierarchy

2.1.4 Diagrams of the Use-Case Model

2.2 Assumptions and Dependencies

3. Requirements

3.1 Use-Case Specifications

3.2 Functionality

3.3 Usability

3.3.1 Windows Compliance

3.3.2 Design for Ease-of-Use

3.3.3 Online Help

3.3.4 Windows Compliance

3.3.5 Design for Ease-of-Use

3.4 Reliability

3.4.1 Availability

3.4.2 Mean Time Between Failures

3.5 Performance

3.5.1 Simultaneous Users

3.5.2 Database Access Response Time

3.5.3 Transaction Response Time

3.6 Supportability

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

3.7.1 Platform Requirements

3.7.2 Internet Browsers

3.8 Online User Documentation and Help System Requirements

3.9 Purchased Components

3.10 Interfaces

3.10.1 User Interfaces

3.10.2 Hardware Interfaces

3.10.3 Software Interfaces

3.10.4 Communications Interfaces

3.11 Licensing Requirements

3.12 Legal, Copyright and Other Notices

3.13 Applicable Standards

继续阅读