Softcell Example Srs

SoftCell Software
Requirement
Specification
Course
CEN 3031 Software Engineering
Dr. Robert M. Cubert, Professor
Prepared by
Shintaro Agatsuma
Bojan Baltic
Kristian Damkjer
Donald Shea
Software Requirement Specification SoftCell Preface
1. Preface
This section defines the audience for this document and the current revision. It is divided
into two clauses. Clause 1 outlines the expected readers of this document. Clause 2
details the version history of this document.
1.1 Expected Readership
The expected readership of this document is as follows:
• Professors interested in using this software

• Development team (SOFTCELL) and PA, SPA
• Future support personnel that will assist the professors using this software.
1.2 Version History
Version 2.0 – November 1, 2000
Updated the System Requirements Specification to reflect the current application.
Version 1.1 – October 11, 2000
Made a name correction for George. Changed name on title page to Bojan for
consistency with class roster.
Version 1.0 – September 27, 2000
We have finalized the document by adding the System Model, System Architecture,
Glossary, and Index. We also made slight modifications to the Introduction and Software
Requirements sections. We removed the optional System Evolution section and the
Appendix section since we have no appendices.
Version 0.0 – September 20, 2000
Being the first version of this document, there have been no changes yet. Since this is a
first draft changes are expected and a new SRS will be produced as changes are made.
Page 1
Software Requirement Specification SoftCell Introduction
2. Introduction
This section provides an introduction to our system. It is broken into three clauses.
Clause 1 describes the need for this system. Clause 2 describes the functionality of the
system. Clause 3 describes how the system fits into the strategic objectives of the
commissioning organization.
2.1 Necessity
This software system will be used to facilitate communication between the professor,
students, and teaching assistants of a university course. It could also be used at other
levels of education or even outside of the educational setting.
2.2 Functionality
The system will be a web-based application for a class web site that incorporates a
professor interface, a student interface, and database of student. Below are brief
descriptions of the four parts of the system.
The professor interface will be PC based and will allow the professor to post such items
as the class syllabus, contact information for the professor and all assistants, special
announcements, and a record of all grades each student has received. The professor will
be able to easily make changes to each part.
The student interface will allow each student to view the items posted by the professor
and to access his/her grades.
The database of student information will contain such items as student names, social
security numbers, class and college, and e-mail addresses as well as identifying
information such as passwords and Social Security numbers, that will facilitate access
control.
2.3 Purpose
This system is expected to help make the learning experience more productive than
traditional paper-based systems by enabling each student to easily access updated or
changed class information as well as by allowing two-way communication between
students and instructors.
Page 2
Software Requirement Specification SoftCell Glossary
3. Glossary
All vocabulary in this document is well defined. There is no technical jargon that
requires further definition.
Page 3
Software Requirement Specification SoftCell System Architecture
4. User Requirements Definition
This section describes the services provided for the user and the non-functional system
requirements and also outlines product and process standards that must be followed. It is
broken into three clauses. Clause 1 describes services. Clause 2 describes non-functional
system requirements. Clause three provides specifications of product and process
standards.
4.1 Services
The Professor will have access to an application that will allow him to add, delete, or
alter grades, as well as student information.
Upon accessing the application, the professor will be required to enter his password to
gain access to the student grade database. The professor will be presented with a list of
student names together with their grades, and will be able to select which student's grades
he wishes to edit.
Once a student is selected, the professor will be able to select whether a grade is to be
added, deleted, or changed.
There will also be an option that will allow the professor to calculate the average grade of
a student.
The professor will be able to create a new student in the database.
Students will only have read access to the database via a course web site.
After logging on to the site, a student will need to enter his or her password, and after
that, he or she will be able to see his or her grades for each assignment, test, homework
etc. along with the grade average up to that date.
4.2 Non-Functional System Requirements
4.2.1 Product requirements
The web based application will be accessible through Internet Explorer, and Netscape.
Teacher's side of application will be implemented through JAVA, but the knowledge of
JAVA will not be required of the teacher.
Database of grades will be a simple text document.
Other features of the application will be done in HTML.
Communication between the application interface, and actual data will be accomplished
through PERL language.
Page 4
4.2.2 Organizational requirements
Being hosted on the "CISE" system, our application will conform to any standards and
rules of the same system.
4.2.3 External requirements
Use of passwords in the application will protect the privacy of any information of the
students posted on the web site.
4.3 Product and Process Standards Specification
None exist at this time.
Page 5
5. System Architecture
This section describes the modules of the system and how they relate to one another.
This section also describes how functionality will be distributed across those modules.
5.1 Professor/TA Interface Module
This module consists of five basic parts: access control, add functions, read functions,
update functions, and delete functions.
The access control will be responsible for restricting access to only the professor of the
course and the course TAs.
The add functions will interact with the database and will allow a professor or TAs to
populate the database with Student information.
The read functions will allow a professor to simply read the contents of the student
database and to read the information for a particular student.
The update functions will allow the professor to update student information in the
database.
The delete functions will allow a professor to remove a student from the database.
5.2 Database Module
This module is fairly simple in design. It will simply be a tab-delimited text file that
contains student information. It will have a fixed structure to facilitate generation by the
professor's Java application and to facilitate parsing by the PERL scripts.
5.3 CGI Module
This module will perform access control, form processing, and data parsing.
The access control will be responsible for restricting access to student information to
students enrolled in the course.
The form processing functions will be responsible for parsing the HTML form input and
constructing appropriate searched for student information
The data parsing functions will be responsible for parsing the information returned from
the student database into an HTML document that can be displayed on the student's
terminal.
Page 6
5.4 Student Interface Module
This module consists of two parts, HTML documents and Forms.
The HTML documents will contain information pertinent to the course. There will be
forms that will allow for the student to access the database via the CGI implemented with
PERL. This part of the application does very little processing of information. It is
strictly an interface and static information store.
Page 7
Software Requirement Specification SoftCell System Requirements Specification
6. System Requirements Specification
This section details the requirements of the system.
6.1 Professor and TA
Function: Adding a student
Description: Teacher accesses the database of students' grades. Teacher selects to add a
student to the list, and then inputs desired information.
Inputs: Student info
Source: Student info is input by the teacher
Outputs: New student's info
Destination: Student database
Requires: Existing database
Pre-condition: Student's record doesn't exist
Post-condition: Record exists and is displayed
Function: Deleting a student
Description: Teacher accesses the database of students' grades. Teacher selects which
student to delete from the list by entering that student's SSN at the prompt.
Inputs: Student's info
Source: Student info is input from database
Outputs: None
Requires: Existing student record
Pre-condition: Student's record exists and is displayed
Post-condition: Record doesn't exist
Page 8
Function: Updating student info
student's info to change by entering that student's SSN at the prompt, and then the desired
info.
Inputs: Student's info
Source: New student info is input by the teacher

Old student info is input from database
Outputs: None
Pre-condition: Student's record exists, and is displayed
Post-condition: Student's record exists, and is altered
Function: Calculating grade average
student record will be accessed by entering the student's SSN. Program calculates grade
average.
Inputs: Student info (including Grades)
Source: Student info is from the database
Outputs: Calculated average grade
Requires: Password
Existing student record
Pre-condition: Grades exist but average is unknown
Post-condition: Calculated average is known and displayed
Page 9
Function: Viewing student info
Description: Teacher accesses the database of students' grades. At the prompt, teacher
selects whether he will view one student or all students. If the former, he inputs the
student's SSN to view that students complete information. If latter, all students' names
and grades will be displayed.
Inputs: Student info (including Grades)
Source: Student info is from the database
Outputs: Names and grades
Pre-condition: Info exists in the database
Post-condition: Info is displayed on the screen
Page 10
6.2 Student
Function: Accessing grades
Description: Student accesses the web site with all students' grades. The student enters
his or her password, which selects his or her record
Inputs: Student's password

Student Information
Source: Password is input by the student at a prompt

Student info is from the database
Outputs: Student's grades
Requires: Student's Password

Existing student info
Pre-condition: Student's record exists and Student's password is correct.
Post-condition: Student's record exists and is displayed
Page 11
Function: Calculating grades information
Description: Student accesses the database of students' grades by entering the password
in the designated area. If their record exists it will be returned to the screen with the
following information about the grades:
• average grade for each exam
• standard deviation for each exam
• highest grade for each exam
• lowest grade for each exam
• student exam average
• class exam average
Inputs: Student's password

Student info (including Grades)
Source: Password is input by the student

Student info is from the database
Outputs: Calculated grade information
Requires: Student password

Existing student record
Pre-condition: Grades exist
Post-condition: Information is calculated and displayed
Page 12
Software Requirement Specification SoftCell System Models
7. System Models
Depicted below are the modules that make up our application and the relationships
between them.
Professor/TA Interface Student Interface
Documents
Forms
Access Control
Update Functions
Delete Functions CGI
Access Control
Read Functions
Form Processing
Add Functions
Data Parsing
Student Information Database
Page 13
Software Requirement Specification SoftCell Index
Index
Functionality 2
Glossary 3
Introduction 2
Necessity 2
Product
Requirements 4
Standards 5
Professor
Functions 8-11
Interface 8
Preface 1
Purpose 2
Readership 1
Requirements
External 5
Functional 8
Non-functional 4
Organizational 5
Product 5
Process 5
User 4
Services 4
Student
Functions 12
Interface 12
System
Architecture 6
Functional Requirements 8-11
Models 14
Non-functional Requirements 4
TA
Functions 8-11
Interface 8
Versioning 1

Softcell Example Srs

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Softcell Example Srs

Hochgeladen von

Copyright:

Verfügbare Formate

SoftCell Software

1.1 Expected Readership

The expected readership of this document is as follows:

• Professors interested in using this software

1.2 Version History

Version 2.0 – November 1, 2000

Updated the System Requirements Specification to reflect the current application.

Version 1.1 – October 11, 2000

Version 1.0 – September 27, 2000

Version 0.0 – September 20, 2000

4. User Requirements Definition

The professor will be able to create a new student in the database.

4.2 Non-Functional System Requirements

4.2.1 Product requirements

4.2.2 Organizational requirements

4.2.3 External requirements

4.3 Product and Process Standards Specification

None exist at this time.

5.1 Professor/TA Interface Module

5.2 Database Module

5.3 CGI Module

5.4 Student Interface Module

This module consists of two parts, HTML documents and Forms.

6. System Requirements Specification

This section details the requirements of the system.

6.1 Professor and TA

Function: Adding a student

Inputs: Student info

Source: Student info is input by the teacher

Outputs: New student's info

Destination: Student database

Requires: Existing database

Pre-condition: Student's record doesn't exist

Post-condition: Record exists and is displayed

Function: Deleting a student

Inputs: Student's info

Source: Student info is input from database

Destination: Student database

Requires: Existing student record

Pre-condition: Student's record exists and is displayed

Post-condition: Record doesn't exist

Function: Updating student info

Inputs: Student's info

Source: New student info is input by the teacher

Destination: Student database

Requires: Existing student record

Pre-condition: Student's record exists, and is displayed

Post-condition: Student's record exists, and is altered

Function: Calculating grade average

Inputs: Student info (including Grades)

Source: Student info is from the database

Outputs: Calculated average grade

Destination: Student database

Pre-condition: Grades exist but average is unknown

Post-condition: Calculated average is known and displayed

Function: Viewing student info

Inputs: Student info (including Grades)

Source: Student info is from the database

Outputs: Names and grades

Destination: Student database

Requires: Existing student record

Pre-condition: Info exists in the database

Post-condition: Info is displayed on the screen