Sei sulla pagina 1di 34

Software Engineering Fall 2000

CQI-Assessment Support Software


Software Requirements Specification
Version <1.2>
6/1/2001

CS 4310 Fall 2000 /opt/scribd/conversion/tmp/scratch6594/47771197.doc


Software Requirements Specification

Document Control
Approval
The Guidance Team and the customer, Dr. Greg Lush, will approve this document.

Document Change Control


Initial Release: January 16, 2001
Current Release: June 1, 2001
Indicator of Last Page in Document: ♦
Date of Last Review: June 1, 2001
Date of Next Review: To Be Determined
Target Date for Next Update: To Be Determined

Distribution List
This following list of people will receive a copy of this document every time a new version of this document
becomes available:
Guidance Team Members:
Dr. Ann Gates
Dr. Steve Roach
Nelly Delgado
Customer: Dr. Gregory Lush

Software Team Members:


International Software Development Corporation
OmegaSoft Development
Renaissance Software Developers
Strategic Engineering Team
Strategy X
Uni-Pro Corporation
Utopia Software

Change Summary
The following table details changes made between versions of this document
Version Date Modifier Description
1.1 2/6/01 N. Delgado Changes to sections outlined in memo dated
2/6/01
1.2 6/1/01 N. Delgado BNF update.

Knowledge is of two kinds: We know a subject ourselves, or we know where


we can find information about it. – Samuel Johnson, 1775.
TABLE OF CONTENTS
Software Requirements Specification CS 4310 Fall 2000 Date 1/17/2001 2:38 PM Page ii
Software Requirements Specification

DOCUMENT CONTROL...........................................................................................................................II
APPROVAL......................................................................................................................................................II
DOCUMENT CHANGE CONTROL........................................................................................................................II
DISTRIBUTION LIST.........................................................................................................................................II
CHANGE SUMMARY.........................................................................................................................................II
1. INTRODUCTION......................................................................................................................................1
1.1. PURPOSE AND INTENDED AUDIENCE............................................................................................................1
1.2. SCOPE OF PRODUCT..................................................................................................................................1
1.3. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS..........................................................................................2
1.3.1. Definitions......................................................................................................................................2
1.3.2. Acronyms........................................................................................................................................3
1.3.3. Abbreviations.................................................................................................................................4
1.4. OVERVIEW ..............................................................................................................................................4
1.5. REFERENCES.............................................................................................................................................4
2. GENERAL DESCRIPTION......................................................................................................................6
2.1. PRODUCT PERSPECTIVE.............................................................................................................................6
2.2. PRODUCT FEATURES.................................................................................................................................6
2.2.1. Data Management..........................................................................................................................6
2.2.2. Mapping of Outcomes....................................................................................................................6
2.2.3. Report Generation..........................................................................................................................7
2.3. USER CHARACTERISTICS............................................................................................................................7
2.3.1. Use-Case Diagram.........................................................................................................................7
2.3.2. Actors.............................................................................................................................................7
2.3.3. Use-Case Descriptions...................................................................................................................7
2.3.4. Scenarios........................................................................................................................................8
2.4. GENERAL CONSTRAINTS..........................................................................................................................12
2.5. ASSUMPTIONS AND DEPENDENCIES............................................................................................................12
3. SPECIFIC REQUIREMENTS................................................................................................................13
3.1. EXTERNAL INTERFACE REQUIREMENTS.....................................................................................................13
3.1.1. User Interfaces.............................................................................................................................13
3.1.2. Hardware Interfaces ...................................................................................................................19
3.1.3. Software Interfaces.......................................................................................................................19
3.1.4. Communications Interfaces .........................................................................................................19
3.2. BEHAVIORAL REQUIREMENTS...................................................................................................................19
3.2.1. Same Class of User......................................................................................................................19
3.2.2. Related Real-world Objects.........................................................................................................19
3.2.3. Stimulus........................................................................................................................................23
3.2.4. Related Features..........................................................................................................................26
3.2.5. Functional....................................................................................................................................30
3.3. NON-BEHAVIORAL REQUIREMENTS...........................................................................................................30
3.3.1. Performance Requirements .........................................................................................................30
3.3.2. Qualitative Requirements.............................................................................................................30
3.3.3. Design and Implementation Constraints......................................................................................30
3.4. OTHER REQUIREMENTS...........................................................................................................................31
3.4.1. Database.......................................................................................................................................31

Software Requirements Specification CS 4310 Fall 2000 Date 1/17/2001 2:38 PM Page iii
Software Requirements Specification

1. Introduction
1.1. Purpose and Intended Audience
The purpose of the Software Requirements Specification (SRS) is to give the customer a clear and precise
description of the functionality of the assessment-support software to be developed and to eliminate ambiguities
and misunderstandings that may exist. For the customer, the SRS will explain all functions that the software
should perform. For the developer, it will be a reference point during software design, implementation and
maintenance. To clarify keywords used throughout the document, a set of definitions, acronyms and
abbreviations is provided in section 1.3.
The SRS divides the system requirements into two parts, behavioral and non-behavioral requirements. The
behavioral requirements describe the interaction between the system and its environment. Non-behavioral
requirements relate to the definition of the attributes of the product as it performs its functions. This includes the
level of security, efficiency, reliability, maintainability, portability, capacity, and the standards of compliance of
the product. The intended audience of the SRS is the College of Engineering at The University of Texas at El
Paso (UTEP) and the development team. This document serves as an agreement between both parties regarding
the product to be developed.

1.2. Scope of Product


The Accreditation Board for Engineering and Technology (ABET) is responsible for accreditation of
educational institutions for engineering and engineering-related fields. In addition to setting a series of
outcomes for schools to meet, ABET also seeks to ensure that a process of continuous quality improvement
(CQI) exists within departments. Specifically, Criterion 1 of ABET Engineering Criteria 2000 specifies that
engineering programs must monitor student progress and performance towards meeting their outcomes.
Program outcomes must include those listed in Criterion 3. In addition, Criterion 3 stipulates that programs
provide evidence that graduates have met these program outcomes and that performance results are used to
develop and improve the program.
The University of Texas at El Paso Departments of Computer Science and Electrical and Computer Engineering
are collaborating to develop a software tool, Classroom Assessment for Continuous Quality Improvement
(CACQI) that establishes a process for professors to manage course section and program outcomes, students’
performance on assessment instruments (AIs), and targeted competencies of student performance. CACQI
maintains objective evidence of learning and assists a program towards meeting Criterion 1 and 3 of ABET
Engineering Criteria 2000. This is accomplished in the following ways:
• By mapping outcomes to specific items within an AI, it is possible to monitor whether course-section
outcomes are being met.
• By comparing students’ performance against pre-defined targeted competencies, it is possible to
analyze how well students are learning material in the course. Because targeted competencies are
mapped to course-section outcomes and outcomes to specific items within an AI, it is possible to
monitor students’ progress during the course with respect to course section and program outcomes.
• By analyzing the collected data, the professor can revise teaching and learning strategies. This provides
the basis for continuous quality improvement (CQI).
• By archiving course information to a central database that consolidates course results, it is possible for
a program to monitor students’ progress throughout their academic career.

Software Requirements Specification CS 4310 Fall 2000 Date Page


1/17/2001 2:38 PM 1
Software Requirements Specification

1.3. Definitions, Acronyms, and Abbreviations

1.3.1. Definitions

The definitions in this section are given in the context of the product being developed. This intention is to assist
the user in their understanding of the requirements for the system.

TERM DEFINITION
A-K Program outcomes defined by ABET Engineering Criteria 2000. Please
refer to [1] for a complete list.
Accreditation Process of determining whether colleges or departments meet a set of
standards as set forth by an accrediting agency, such as ABET.
Archive To maintain data in a designated repository; in CACQI, data will be
maintained in the central database.
Assessment The systematic and periodic evaluation of whether students are achieving
the learning outcomes associated with a given course.
Assessment instrument a) The tool used to assess students’ skills and knowledge in a course, e.g,
test, quiz, report, observation.
b) An assessment instrument is composed of one or more assessment
instrument parts.
Assessment instrument part An assessment instrument unit or a set of assessment instrument parts.

Assessment instrument unit An element of an assessment instrument for which grades may be assigned
and that maps to a single outcome, e.g., a question on an exam.
Call Number A course request number

Cell The intersection of a row and a column in a spreadsheet.

Central database An Oracle relational database maintained by the College of Engineering to


store course data from all departments.
Continuous Quality Improvement The systematic pursuit of excellence and satisfaction of the needs of
constituencies, in a dynamic and competitive environment.
Course number Identifier assigned by the university that names a course when used with a
subject identifier.
Course section A course identified with a course request number.
Course-section outcome Measurable statements of the knowledge, skills, attitudes, and habits of
mind that students are equipped with when graduating from an educational
program; also called objectives in some communities.
Course Request Number Unique, five-digit identifier assigned by the university to identify each
course.
Download Transferring data files from a main source to a secondary source.

Encrypt The alteration of data so that it is meaningful only to the intended receiver.

Software Requirements Specification CS 4310 Fall 2000 Date Page


1/17/2001 2:38 PM 2
Software Requirements Specification

Local database An Oracle relational database stored on one or more machines at the
departmental level.
Mapping The linkages of two objects, e.g., an outcome to an assessment unit.

Navigation tree A hierarchical representation of a tree in which each successor node is


indented to the right of its predecessor node and all nodes at the same level
are uniformly indented.
Owner The general user that defined a new course is considered the owner of the
course.
Program outcomes A set of skills, knowledge, attitudes, and habits of mind that students are
equipped with when they graduate from an engineering educational
program, e.g., computer science or civil engineering.
Property list A list of properties or attributes associated with an object; in CACQI this is
a list of login names of the users who can access course data and the list is
associated with a course section.
Ranking The level of importance of an outcome.

Section number A 3-digit field that corresponds to a course.

Server The main computer in a network. A central computer that connects and
services those computers (clients) attached to it.
Spreadsheet The work area for entering grades that appears as a table with rows and
columns.
Subject identifier A 4-character field that corresponds to a subject.

Targeted competency A quantitative reference for student performance on a particular outcome;


quantifies how well students are expected to perform.
University database An Oracle relational database, maintained by the university, that stores
student and course information.
User A person who provides the data for a computer system, updates the data,
and uses reports from the system in his or her daily work.
User profile User characteristics maintained by the system
Weight A factor used to adjust a value.

1.3.2. Acronyms

ACRONYM MEANING
ABET Accreditation Board for Engineering and Technology
AI Assessment Instrument
AIP Assessment Instrument Part
AIU Assessment Instrument Unit
BNF Backus Naur Form
CACQI (pronounced Khaki) Classroom Assessment for Continuous Quality Improvement
CQI Continuous Quality Improvement
CRN Course Request Number
Software Requirements Specification CS 4310 Fall 2000 Date Page
1/17/2001 2:38 PM 3
Software Requirements Specification

DBMS Database Management System


DFD Data Flow Diagram
GUI Graphical Use Interface
OMT Object Modeling Technique
SRS Software Requirements Specification
TBD To Be Determined
UTEP The University of Texas at El Paso

1.3.3. Abbreviations

ABBREVIATION MEANING
e.g. For example
id Identification
i.e. Such as
info. Information

1.4. Overview
The SRS is divided into three major sections: Introduction (Section 1), General Description (Section 2), and
Specific Requirements (Section 3). This overview describes Section 2 and Section 3 of the SRS.
Section 2 includes five subsections. Section 2.1 provides a description of the product, its overall structure, and
its functionality. Section 2.2 summarizes the main features of the software from a high-level point of view.
Section 2.3 identifies the different users of the system. This is accomplished through use-cases. A summary of
the actors, use-cases, and scenarios is given. Section 2.4 states existing constraints. Section 2.5 gives the
assumptions and dependencies of CACQI.
Section 3 includes four major subsections. External Interface Requirements (Section 3.1) gives the
requirements for user, hardware, software and communications interfaces. Behavioral Requirements (Section
3.2) organizes the requirements in the following categories: same class of user, related real-world objects,
stimulus, related features and functional requirements. Non-behavioral Requirements (Section 3.3) consists of
performance and qualitative requirements, as well as design and implementation constraints. Section 3.4
outlines database, operations and site adaptation requirements.

1.5. References
[1] “ABET Homepage: Accreditation Board of Engineering and Technology.” December 15, 2000. Online
Posting. Available: http://www.abet.org/
[2] Gates, A., Requirements Definition, CS4310 Handout, September 6, 2000.
[3] Gates, A., Memorandum RE: ABET CQI Project, e-mail message dated 11/12/2000, 2:31 p.m.
[4] Gates, A., Message from Dr. Lush, e-mail message dated 11/14/200, 5:58 p.m.
[5] International Software Development, OmegaSoft Development, Renaissance Software Developers,
Strategic Engineering Team, Strategy X, Utopia Software, Interview Report. September 2000.
[6] International Software Development, OmegaSoft Development, Renaissance Software Developers,
Strategic Engineering Team, Strategy X, Utopia Software, Feasibility Report, September 2000.

Software Requirements Specification CS 4310 Fall 2000 Date Page


1/17/2001 2:38 PM 4
Software Requirements Specification

[7] International Software Development, OmegaSoft Development, Renaissance Software Developers,


Strategic Engineering Team, Strategy X, Utopia Software, Interface Prototype, October 2000.
[8] International Software Development, OmegaSoft Development, Renaissance Software Developers,
Strategic Engineering Team, Strategy X, Utopia Software, Draft SRS, November 2000.
[9] Software Engineering - Project Information. 17 Nov 2000. Available: http:/www2.cs.utep.edu/~cs4310

Software Requirements Specification CS 4310 Fall 2000 Date Page


1/17/2001 2:38 PM 5
Software Requirements Specification

2. General Description
2.1. Product Perspective
CACQI is designed to provide departments with a tool that facilitates the monitoring and evaluation of a
student’s progress throughout his or her college education. The system provides management of course and
student data, the ability to map outcomes to assessment items, and report generation. A more complete
description of CACQI’s functionality can be found in Section 2.2.
There are various existing products that have similar functionality to CACQI [6]. 1st Class GradeBook manages
student grades for a particular assignment. In addition, this application generates spreadsheets and graphs that
compare students’ grades with each other on one or more assignments. Standards-based Gradebook is similar
to 1st Class Gradebook, but it is also able to monitor students’ performance against standards. Other
applications that support functionality provided by CACQI include the following:
• Gradebook Power: provides the ability to calculate grades.
• Seagate Crystal Reports: supports report generation.
• PostgreSQL: provides database management and report generation.
Although the above software products provide many of CACQI’s features, the ability to manage and map
outcomes to assessment items is not supported.

2.2. Product Features


The main purpose of CACQI is to enable the user to organize and store all information that is relevant to the
CQI process in the College of Engineering. The three main features of CACQI are: managing all course-related
data, mapping course outcomes, and generating reports.
The subsections below provide a summary of each function. The flow of data between these functions is
illustrated in the Data Flow Diagram (DFD) given in Appendix A.

2.2.1. Data Management


When managing course-related data, the system will allow the user to perform operations such as entering
course outcomes, entering targeted competencies, AI, and assessment results. Data management includes the
entry, storage, and manipulation of different methods of assessment. CACQI will calculate averages, support
entry of grades, and provide useful information for assessment throughout the duration of a course. The
academic history of students will also be maintained by the system, as the user will be able to archive course
data.
CACQI will also provide users with a tool with which to calculate grading information for every course s/he
teaches. This includes exceptional grading features such as displaying grades in three levels: by category, by
AI, and by individual assessment instrument units (AIUs). In order to allow the user to personalize the grading
portion of the software to meet his/her individual needs, the system allows the user to perform operations such
as defining his/her own formulae to calculate grades, and setting the numerical range that will be used in
calculating letter grades.

2.2.2. Mapping of Outcomes


The system will also support the mapping of outcomes. This is done by enabling the definition of course
outcomes, ranking of course outcomes, and the mapping of an AIU to an outcome. The user will be able to enter
different types of AIs, weights, scales, and grading formulae. Once entered, the user is able to map course
Software Requirements Specification CS 4310 Fall 2000 Date Page
12/11/2010 13:37 A12/P12 6
Software Requirements Specification

outcomes to program outcomes and to associate a targeted competency with each outcome. Using these
targeted competencies, CACQI will be able to determine the degree to which AIUs count towards achieving a
specific outcome.

2.2.3. Report Generation


CACQI will allow the user to generate reports that are designed to assist in the CQI process. These reports will
provide different perspectives of students’ performance with respect to course outcomes.

2.3. User Characteristics


The main user of CACQI is the general user. S/he is the person who is primarily in charge of a particular
course for which CQI is being performed. Because the system will have a GUI with a standard format, the
general user will not need to have a high level of technical expertise.
The following subsections present the Use-Case model for CACQI. After presenting the use-case diagram, the
section describes the actors, use cases, and scenarios. See Appendix A for the high-level use-case diagram.

2.3.1. Use-Case Diagram

See Appendix B for a high-level, use-case diagram

2.3.2. Actors
CACQI classifies the actors of the system into three groups:
General User: The general user can enter data into the system, save course-work descriptions, archive data,
calculate grades, and view reports for the courses h/she can access.
Central Database: The central database is responsible for storing data at the end of the semester. The central
database is an external entity, which can only be written to at the end of the semester.
Local Database: The local database stores all the information needed by the system during the semester.
Information is read from and saved to the local database during the semester.
University Database: The university database (Goldmine) stores student and course information.

2.3.3. Use-Case Descriptions


The following is a list of the use cases that have been developed for the Assessment-Support Software:
• Manage course information: the general user can use the system to enter and modify course
information. The local database maintains the information.
• Manage student information: the general user can use the system to enter and modify student
information, or to download student information from the university database. In addition, the user can
delete a student from a course. The local database maintains the information.
• Enter outcomes: the general user can use the system to enter course outcomes. The user can assign a
ranking to each course outcome. The local database maintains the information.
• Enter targeted competency: the general user can use the system to select one of two types of targeted
competencies that can be used to automatically check progress toward achieving course outcomes; the
user can enter values associated with the different types. The user can enter a description of a targeted
competency that can be used for manual checking. The local database maintains the information.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 7
Software Requirements Specification

• Map entities: the general user can use the system to map course outcomes to program outcomes; to
map AIUs to course outcomes; and to map course outcomes to targeted competencies. The local
database maintains the information.
• Define AIs: the general user can use the system to enter information related to an AI. For each
instrument, the stored information includes such items as description, category, assessment instrument
part (AIP) label and description, AIU label and description, AIU point value. For each student, the user
can enter the points earned for each assessment unit. The local database maintains the information.
• Modify AIs: the general user can use the system to modify information related to an AI. The local
database maintains the information.
• Enter grades: the general user can use the system to enter student grades related to an AI and to enter
formulae for calculating grades. The local database maintains the information.
• Generate reports: the general user can use the system to display, print, or download a predefined report
to the local database. The general user can query the system to calculate individual or class grades, to
determine the mean or median grade on an individual AI or collection of instruments.
• Archive course and student information: the general user can use the system to archive course and
student information to the central database from the local database at the end of the semester.

The use cases that are associated with an include relationship are as follows:
• Access the system: the general user can access the system through a unique login name and password.
• Open course: the general user can select a course from the list of courses that s/he owns.

The use cases that are associated with an extend relationship are as follows:
• Set password - The user can set the password for accessing and entering information on the course.
• Set property list – The user can set the property list that gives the login names for the users who can
access a course.
• Enter formula: the general user can define the formulas that will be used to calculate students’ grades
on an AI, assessment category, or course.

2.3.4. Scenarios
Use Case: Manage course information
Actor: General user and local database
Scenario:
1. The user enters values for the following attributes:
a. subject identifier
b. course number
c. CRN
d. section number
e. course title
f. professor login
g. semester
h. year
i. AI categories (e.g., Exam)
j. AI weights for each category.
k. grade-to-letter conversion scheme
2. The user saves the information to the local database.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 8
Software Requirements Specification

Alternatives:
1. The user does not enter all required information.
2. The user modifies a value in an existing attribute.
3. The user enters a new value to an existing attribute.
4. The user enters an incorrect value for course number.
5. The user enters an incorrect value for CRN.
6. The user enters percentages for each instrument category and the sum exceeds 100%.

Use Case: Manage student information


Actor: General user, local database, and university database
Scenario:
1. The user enters values for the following attributes:
a. student name (first, last, middle initial)
b. student id number
c. student classification
2. The user saves the information to the local database.
Alternatives:
1. The user downloads the information from the university database.
2. The user does not enter all required information.
3. The user modifies a value in an existing attribute.
4. The user enters a new value to an existing attribute.
5. The user enters an incorrect value for student id number.
6. The user deletes a student because s/he has withdrawn from the course.

Use Case: Enter outcomes


Actor: General user and local database
Scenario:
1. The user enters values for the following course outcome attributes:
a. label (short description, e.g., teamwork)
b. description
c. ranking
2. The user saves the information to the local database.
Alternatives:
1. The user does not enter all required information.
2. The user modifies a value in an existing attribute.
3. The user enters a new value to an existing attribute.

Use Case: Enter targeted competency


Actor: General user and local database
Scenario:
1. The user selects a template for a targeted competency.
2. The user enters values for the attributes in the template.
3. The user saves the information to the local database.
Alternatives:
1. The user chooses to enter a description of a targeted competency that can be used for manual checking.
2. The user does not enter all required information.
3. The user modifies a value in an attribute for a template of a targeted competency.
4. The user enters an incorrect value for the targeted competency.

Use Case: Map entities


Actor: General user and local database
Scenario:
1. The user selects a course outcome.
2. The user selects a program outcome.
3. The user chooses the option to link the outcomes.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 9
Software Requirements Specification

4. The user saves the information to the local database.


Alternatives:
1. The user chooses to map assignment units to course outcomes.
2. The user chooses to map course outcomes to targeted competencies.

Use Case: Define AIs


Actor: General user and local database
Scenario:
1. The user chooses the option to define a new AI.
2. The user enters the following information:
a. label (short description, e.g., Test 1)
b. date
c. description
d. category of instrument (e.g., Exam)
3. The user enters a label and description for each AIP.
4. The user subdivides AIP #2 into 2 AIPs.
5. The user enters a label and description for each AIP in the subdivision.
6. The user enters the number of points for each AIP defined in step 4.
7. The user saves the information to the local database.
Alternatives:
1. The user does not enter all required information.
2. The user chooses not to subdivide the AIPs.
3. The user enters an incorrect value for the number of points for an AI.
4. The user chooses to subdivide an AIP from step 4.

Use Case: Modify AIs


Actor: General user and local database
Scenario:
1. The user chooses to modify an existing AI that has more than two AIPs defined.
2. The user decreases the number of AIPs to one.
3. The user saves the information to the local database.
Alternatives:
1. The user decreases the number of AIPs to two or more.
2. The user modifies an AI that has one or more AIPs by adding another AIP.
3. The user modifies an AIU by subdividing it into two or more AIPs.
4. The user changes the label, date, description, or category of the AI.

Use Case: Enter grades


Actor: General user and local database
Scenario:
1. The user chooses an AI to enter grades.
2. The user chooses the Individual Assessment Instrument Spreadsheet.
3. The user enters the number of points for each student in each AIU.
4. The user saves the information to the local database.
Alternatives:
1. The user enters a formula to calculate totals for the AIP(s) and the AI.
2. The user selects a cell to modify and enters a new grade.

Use Case: Generate reports


Actor: General user and local database
Scenario:
1. The user chooses the option to display a predefined report.
2. The user chooses the specific report he/she would like to view.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 10
Software Requirements Specification

Alternatives:
1. The user chooses the option to save the predefined report to a file.
2. The user chooses the option to print the report.

Use Case: Archive course and student information


Actor: General user, local and central database
Scenario:
1. The user chooses the option to archive course and student information from the local database to the
central database.
2. The central database verifies that a course grade has been assigned to each registered student.
3. The central database stores the newly transferred data.
Alternatives:
1. The user attempts to archive before the semester is over.

Use Case: Access the system


Actor: General user, local database
Scenario:
1. The user enters a login name.
2. The user enters a password.
3. The local database confirms the password through the local database.
Alternatives:
1. The user enters an incorrect login name.
2. The user enters an incorrect password.

Use Case: Open course


Actor: General user, local database
Scenario:
1. The user selects a course from a list of courses that s/he owns.
2. The general information about the course is displayed.
Alternatives:
None

Use Case: Set password


Actor: General user, local database
Scenario:
1. The user selects the option to change password.
2. The system prompts the user for a password.
3. The user enters a password.
4. The system prompts the user to renter the password.
5. The system accepts the new password
Alternatives:
1. The password that the user enters the second time does not match the previously entered password.

Use Case: Set property list


Actor: General user, local database
Scenario:
1. The user selects the option to enter a property list for a course.
2. The user enters a list of login names.
Alternatives:
1. A login name is invalid.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 11
Software Requirements Specification

2.4. General Constraints


The general constraints on the development of the system are as follows:
• The system will not be accessible to unauthorized users.
• All data transmitted to the central database will be encrypted.
• The system will be completed by the end of April 2001.

2.5. Assumptions and Dependencies


The assumptions are as follows:
• The university database is the Banner system.
• Each professor has access to a desktop computer.
• A table with login and password has been set up for each professor in the departments of the College
of Engineering and is maintained in the local database.
• The initial login and password for general users will be encrypted.
• The timeframe to upload data to the central database is the day that grades are due to the university and
one week before the start of the new semester.
• Program outcomes that include ABET outcomes a-k and additional program outcomes are stored in the
local database.
• Once a student is dropped, the information associated with the student cannot be removed or modified.
• The development team will use this SRS to implement the system.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 12
Software Requirements Specification

3. Specific Requirements
3.1. External Interface Requirements
The following section discusses the requirements related to the interfaces used to communicate with external
entities. These entities include human users and other hardware and software interfaces that permit the system
to carry out its tasks.

3.1.1. User Interfaces


The requirements presented in this section describe the interfaces for CACQI. The requirements do not assume
a particular interface; however, the requirements are grouped according to the main features (as defined by the
use cases) provided by the system. Note that the requirements that follow a subheading support the activities
associated with the feature named by the subheading.

3.1.1.1. Interface Formats

[SRSreq 1] All screens will have the name of the system, CACQI, displayed on the screen.

[SRSreq 2] After the login screen, all screens will provide the user with the ability to navigate through the
system, i.e., to select different functions of the system. See 2.3.3.

[SRSreq 3] After a course has been selected, all screens will display the course number and course title.

[SRSreq 4] The user will have the option to save changes to information stored in the local database.

[SRSreq 5] The user will have the option to cancel a submission to the local database.

[SRSreq 6] The user will have the option to print displayed information.

3.1.1.2. System Entry

[SRSreq 7] Upon entry to CACQI, the system will display the following welcome screen and prompt the user
for a login and password.

Classroom Assessment Continuous Quality Improvement (CACQI)


Version X.X
The University of Texas at El Paso
College of Engineering
A tool that supports a process for assessment and continuous quality improvement in the classroom
and program.

[SRSreq 8] The user will have the option to reset his/her password.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 13
Software Requirements Specification

3.1.1.3. Course Section

[SRSreq 9] The user will be able to select an existing course section to which s/he has access, i.e., the user is
owner of the course section or the user is on the property list.

[SRSreq 10] The user will be able to select the option to define a new course section and associated attributes as
described in Section 3.2.2.4.

[SRSreq 11] The user will be able to select the option to define students who are registered for a course section,
using the attributes given in Section 3.2.2.7.

[SRSreq 12] Only the owner of a will have the option to add or delete a user login to the property list.

[SRSreq 13] The user will be able to choose the AI categories that will be used in the course section as follows:

 select one or more categories from a list of pre-defined instrument categories (see Section
3.2.2.1)
 define one or more new instrument categories.
[SRSreq 14] The user will be able to set a weight for each instrument category.

[SRSreq 15] The user will be able to define the range for each letter grade.

[SRSreq 16] The user will be able to view, modify, or delete all information related to a course section.

3.1.1.4. Outcomes

[SRSreq 17] The user will be able to select the option to enter course-section outcomes.

[SRSreq 18] The user will be able to enter the label and description associated with one or more course-section
outcomes. See Section 3.2.2.5.

[SRSreq 19] The user will be able to select the ranking of a course-section outcome from predefined choices.

[SRSreq 20] The user will have the option to view course-section outcomes or program outcomes.

3.1.1.5. Targeted Competencies

[SRSreq 21] The system will display the following choices and the user will be able to select one:

 x% of students will achieve y% or higher.


 The students will achieve an average of y% or higher.
 Other
[SRSreq 22] The user will be able to view a list of pre-defined course-section outcomes and will be able to map
a targeted competency to a course-section outcome.

[SRSreq 23] The user will be able to view the targeted competency that is associated with an outcome.

[SRSreq 24] The user will be able to modify the targeted competency that is associated with an outcome.

[SRSreq 25] The user will be able to enter a formula using (or selecting) AIUs and Boolean logic for calculating
the targeted competency.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 14
Software Requirements Specification

3.1.1.6. Assessment Instruments

An AI can be viewed as a tree structure. See Figure 1 for an example AI and corresponding structure.

[SRSreq 26] The user will have the option to define a new AI.

[SRSreq 27] For an AI, the user will be able to select an AI category as defined during course section set-up
(see Section 3.2.2.1).

[SRSreq 28] For an AI, the user will be able to enter associated attributes as described in Section 3.2.2.1.

[SRSreq 29] The user will be able to define multiple AIPs or AIUs that are associated with an AI.

Test 1
Q1 AIU

Q2 AIU AI
Q3
a AIU
AIP
b AIU

Figure 1: Hierarchical structure of an example assessment instrument.

[SRSreq 30] For an AIP or an AIU, the user will be able to enter associated attributes as described in Sections
3.2.2.2 and 3.2.2.3, respectively.

[SRSreq 31] The user will be able to define multiple AIPs or AIUs that are associated with an AIP.

[SRSreq 32] The system will allow the user to map each AIU to one and only one course-section outcome using
the pre-defined list of course-section outcomes.

3.1.1.7. Mapping
A mapping links two entities by defining a relation, i.e., an association between the two.

[SRSreq 33] The user will be able to select the option to map a course-section outcome to one or more than one
program outcome.

[SRSreq 34] The user will be able to select the option to map an AIU to a course-section outcome.

[SRSreq 35] The user will be able to modify the mappings between a course section and program outcome.

[SRSreq 36] The user will be able to modify the mappings between an AIU and a course-section outcome.

[SRSreq 37] The user will be able to view the program outcomes that are associated with a course-section
outcome.

[SRSreq 38] The user will be able to view the AIUs that are associated with a course-section outcome, and the
AIUs will be identified by their label appended to the AI label and associated AIP labels, if
applicable.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 15
Software Requirements Specification

3.1.1.8. Grades

[SRSreq 39] The user will have the ability to enter a formula for calculating the totals in each of the
spreadsheets, see Section 3.2.4.2.

[SRSreq 40] The formula created from the assessment category weights is the default setting for calculating
totals.

[SRSreq 41] The user will be able to choose a spreadsheet format for viewing scores for all students in a course
section. For each format, the first two columns are reserved for student name (last name, first
name, middle initial) and id. The options and formats are as follows:

 Assessment Instrument Category Spreadsheet: for each category, the category label will
appear in a column heading and the student's average weighted score or value resulting from
the user-defined formula for each category will appear in the rows below. See Figure 2a.
 Assessment Instrument Summary Spreadsheet: for each AI in which grades have been
entered, the label will appear in a column and, in each row below, the students' total score for
each AI (grouped by category) will appear. See Figure 2b. Note that AI refers to an AI label.
 Individual Assessment Instrument Spreadsheet: for a selected AI, the scores associated with
AIUs and the totals for the AIPs are displayed. See Figure 2c. Note that U n refers to the label
of an AIU and Pn refers to the label of an AIP.

ASSESSMENT INSTRUMENT CATEGORY SPREADSHEET

C C C T L

Figure 2a. Assessment Instrument Category Spreadsheet

ASSESSMENT INSTRUMENT SUMMARY SPREADSHEET

Categ C Category n
ory 1

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 16
Software Requirements Specification

Figure 2b. Assessment Instrument Summary Spreadsheet View

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 17
Software Requirements Specification

INDIVIDUAL ASSESSMENT INSTRUMENT SPREADSHEET


<ASSESSMENT INSTRUMENT LABEL>

Name Id <U1> <P2> …. <Pn> Total

<U2.1> <U2.2> Total <Pn.1> … Total


<Un.1.1> … Total

Mean
Median

Figure 2c. Example Individual Assessment Instrument Spreadsheet

[SRSreq 42] In an Individual Assessment Instrument Spreadsheet, the user will be able to enter or modify
grades for a student.

[SRSreq 43] The user will have the option to use the formulas automatically created from the assessment
category weights, to enter a user-defined formula, or to reset the formulas to the default setting.

3.1.1.9. Reports

[SRSreq 44] The user will be able to view a report associated with an outcome associated with one of the
following two targeted competencies:

 Targeted competency type 1: x% of students will achieve y% or higher on the outcome.


 Targeted competency type 1: The students will achieve an average of y% or higher.
[SRSreq 45] Each report will display the following information:

 The text of the outcome statement.


 An indication either by text or color or both whether the outcome was achieved.
 The formula for calculating the respective targeted competency, e.g., OUTCOME1 was
measured by (E1.Q1 AND E1.Q5) OR F1.Q15.P2.
[SRSreq 46] The report for targeted competency type 1 will also display the following statements:

 w% of the students scored y% or higher on the outcome (where w is the actual performance.)
 x% of the students scored v% or higher on the outcome (where v is the student performance
level you must drop down to indicate the xth percentile).
[SRSreq 47] The report for targeted competency type 2 will also display the following statements:

 The students achieved an average of u% or higher (where u is the actual performance).

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 18
Software Requirements Specification

3.1.1.10. Archive course section and student information

[SRSreq 48] The user will have the ability to archive course section and student information from the local
database to the central database.

3.1.2. Hardware Interfaces

There are no hardware interface requirements specified at this time.

3.1.3. Software Interfaces

[SRSreq 49] The system will interface with the following software systems:

 Oracle
 Banner/Goldmine

3.1.4. Communications Interfaces

[SRSreq 50] The system will run over the existing campus network.

[SRSreq 51] The system will be developed as a client-server application with the server providing data access
services only.

3.2. Behavioral Requirements

3.2.1. Same Class of User


The general user is the only type of user of the system; however, to use the system the user must be authorized
and, to access information in course sections, the user must be on the property list for the section. The
requirements in this section address authorization and access issues.

[SRSreq 52] The first time, a user logs into CACQI, the system will ask the user to enter a new password.

[SRSreq 53] Only users whose login are in the property list for a course section, or who own the course section,
will be able to view, modify, or delete information on a course section.

3.2.2. Related Real-world Objects


Real-world objects are entities with either physical or conceptual counterparts in the real world. The object
modeling diagram is given in Appendix A. The requirements associated with the objects presented in this
diagram are presented in this section.

3.2.2.1. Assessment Instrument

[SRSreq 54] The information associated with an AI is the following:

 label: a description that names the instrument, e.g., Test1

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 19
Software Requirements Specification

 date: a date of the form MMM-DD-YYYY where MMM represents the month using 3-
characters, DD represents the day using two digits, YYYY represents the year using four
digits, e.g., Sep-10-2000
 description: a description of the instrument, e.g., Test 1 covering Chapters 1-10
 category: one of the user-defined categories
 path name (optional): the path where the AI file is stored on the user's machine
[SRSreq 55] The number of AIPs defined for an AI will be one or greater.

[SRSreq 56] The pre-defined AI categories are as follows:

 Attendance
 Exams
 Final
 Homework
 Participation
 Presentation
 Project
 Quiz
 Reading
 Report

3.2.2.2. Assessment Instrument Part

[SRSreq 57] The information associated with an AIP is the following:

 label: a description that names the AIP, e.g., Q1


 description (optional): a description of the AIP
[SRSreq 58] The number of AIPs associated with a predecessor can be 0 or greater. Note that if the number of
AIPs is 0, then the AIP is an AIU.

3.2.2.3. Assessment Instrument Unit

[SRSreq 59] The information associated with an AIU is the following:

 label: a description that names the AIU, e.g., A


 description (optional): a description of the AIU
 maximum AIU point value: a number indicating the maximum value of the AIU, e.g., 10.
[SRSreq 60] For each AIU, there is one and only one course-section outcome that can be associated with it.

[SRSreq 61] The user will be able to define an “assesses” relation from an AIU to a course-section outcome.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 20
Software Requirements Specification

3.2.2.4. Course Section

[SRSreq 62] The information associated with a course section is the following:

 course section title: e.g., Software Engineering I


 subject identifier: e.g., ART
 course number: e.g., 4310
 CRN: e.g., 12345
 section number: e.g., 001
 semester: one of the following - spr, sum, fall
 year: a 4-digit number, e.g., 2000
 professor login: e.g., agates, glush
 AI categories (optional): a list that describes collections of AIs, e.g., Exam, Project
grade-to-letter conversion scheme (optional): user-defined pairing of point or percentage
ranges and letter grades, e.g., (90-100, A)
[SRSreq 63] The user will be able to define the numeric range for the following letter grading scale:

 A
 B
 C
 D
 F

3.2.2.5. Course-section outcomes

[SRSreq 64] The user will be required to define at least one course-section outcome.

[SRSreq 65] The information associated with each course-section outcome is the following:

 label: a description of the course-section outcome, e.g, dataflow level-1


 description: a statement of the course-section outcome, e.g., “The students will be able to
draw a level-1 dataflow diagram from a requirements definition.”
 ranking: one of the following - "critical," "important," or "relevant"
[SRSreq 66] The default setting for ranking is “relevant.”

[SRSreq 67] The user will be able to define an “is-associated-with” relation from course-section outcome to a
program outcome.

[SRSreq 68] The user will be able to define an “is-assessed-by” relation from course-section outcome to an
AIU.

[SRSreq 69] The user will be able to associate a course-section outcome to more than one program outcome.

[SRSreq 70] Each course outcome will be associated with one and only one targeted competency.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 21
Software Requirements Specification

3.2.2.6. Spreadsheet

The CACQI spreadsheet differs from an Excel-like spreadsheet because in an Excel-like spreadsheet there may
be cells available for constants and work values. The CACQI spreadsheet (henceforth referred to as
spreadsheet) does not allow this. Every cell corresponds to a field in a record in a database table. Therefore,
there are no absolute addresses in these formulae. A cell range is a contiguous rectangular set of cells. Cell
addresses do not row identifiers only column identifiers unless the formula applies to a particular row, i.e., a
student.

[SRSreq 71] A cell will contain a number, a formula or a text string as allowed by the BNF given in Figure 3.

[SRSreq 72] A column in a spreadsheet will represent such items as AIU, AIP, AI, total, name, id, and letter
grade.

[SRSreq 73] The rows in a spreadsheet will represent values associated with an individual student.

[SRSreq 74] Legal values for scores entered into columns labeled AIU are floating point values greater than or
equal to 0.

[SRSreq 75] The empty string will be considered a valid entry.

[SRSreq 76] Valid cell addresses will be a column identifier or a row and column identifier.

[SRSreq 77] When copying a formula from one cell to another there will be two cases.

 When copying a formula from one cell to a cell below or above it, the cell addresses in the
copied formula will refer to the row that is the target of the copy.
 When copying a formula from one cell to a different cell in the same row, the columns will be
adjusted in the copied formula.

3.2.2.7. Student

[SRSreq 78] The information associated with a student is the following:

 last name
 first name
 middle initial
 student id: a 9-character string in which the first character may be a digit, @, or D, and the
remaining characters are digits.
 classification: FR, SO, JR, SR, GR
[SRSreq 79] For any row containing student information, the user will be able to attach a comment.

[SRSreq 80] If the user deletes a student from a course section:

 the student will be marked as deleted,


 the information entered to date will not be removed, and
 the user will not be able to modify, add, or delete information associated with the student.
[SRSreq 81] A dropped student's grades will not be considered in the calculation of a targeted competency or in
grade calculations.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 22
Software Requirements Specification

3.2.2.8. Targeted Competency

[SRSreq 82] The values entered for the percentages on templates must be between 0 and 100%.

[SRSreq 83] A targeted competency will be associated with one and only one course-section outcome.

[SRSreq 84] The user will be able to enter a formula for combining AIUs, using AIU labels and boolean logic,
to determine whether a targeted competency has been met. For example:
(E1.Q1 AND E1.Q5) OR F1.Q15.P2

[SRSreq 85] The default targeted competency for each course-section outcome is as follows: “90% of the
students will achieve 70% or higher.”

[SRSreq 86] The user will be able to define an “is-associated-with” relation from a targeted competency to a
course-section outcome.

3.2.3. Stimulus
The following requirement applies to all user-entered values. Valid ranges and values should be checked against
the specification of the tables given in Appendix B.

[SRSreq 87] If the user enters an invalid value or range, an error message will be displayed.

[SRSreq 88] Whenever the user submits information to the database, the system will ask the user to confirm the
submission.

3.2.3.1. Enter Login

[SRSreq 89] After the user enters a login and password, the system will validate the password. If the password
is validated, then the welcome screen will appear. If the password is not validated, then the
system will display:
Incorrect login. Please try again.

[SRSreq 90] If the user selects the option to reset his/her password, the system will prompt the user for a new
password and will ask the user to renter the password.

[SRSreq 91] When the user reenters a new password after selecting the option to change his/her password, the
system will check the password against the newly entered password.

[SRSreq 92] When the user selects the option to change his/her password, the system will check whether the
new password is greater than six characters and less than 20 characters.

[SRSreq 93] When the user enters an incorrect login or password for the third time, the system will lock the
application for two minutes and send a message to a log file. See Section 3.3.2.1.

3.2.3.2. Select Assessment Instrument

[SRSreq 94] If the user deletes an AIP that has successors, the following message will display:
Warning: This AIP has descendants. Deletion will result in deletion of all
descendants. Do you wish to proceed?

[SRSreq 95] The entered AIPs will be associated with the AI or predecessor AIP, depending on which one
initiated the entry.
Software Requirements Specification CS 4310 Fall 2000 Date Page
12/11/2010 13:37 A12/P12 23
Software Requirements Specification

[SRSreq 96] If the user selects the option to define a relation between an AIU and a course-section outcome, the
labels of the AIUs will be displayed. The user will be able to view a list of pre-defined course-
section outcomes and will be able to link an AIU to a course-section outcome.

[SRSreq 97] If the user defines an “is-assessed-by” relation from course-section outcome to an AIU, the
association is maintained in a table.

3.2.3.3. Select Course Section

[SRSreq 98] When the user creates a new course section, the system will make the user the owner of the course
section.

[SRSreq 99] When the owner of a course section selects the option to add a user login to the property list, the
login will be maintained in a table in the local database that stores the property list.

[SRSreq 100] If the user selects the option to add a user login to the property list, the following message will
display, and the user will be able to select another option:
You are unauthorized to change property list.

[SRSreq 101] If the user selects the option to delete a student, the following message will appear:
Are you sure you want to delete student XX?

[SRSreq 102] When the user enter ranges for letter grades, the system the check the ranges for overlaps and
display the following message if any are found:
Overlapping ranges for letter grade. Please reenter range.

[SRSreq 103] If the user selects the option to view a course section, the course section attributes as defined in
Section 3.2.2.4 will display.

3.2.3.4. Select Course-Section Outcomes

[SRSreq 104] If the user selects the option to associate a course-section outcomes to a program outcome, a list
of pre-defined course section and program outcomes will be displayed, and the user will be able
to link a course-section outcome to one or more program outcomes.

[SRSreq 105] If the user defines an “is-associated-with” relation from course-section outcome to a program
outcome, the association is maintained in a table.

[SRSreq 106] If the user selects the option to view outcomes, the system will display the attributes of the
outcomes as described in Section 3.2.2.5 and the mappings from the course-section outcome to a
program outcome.

[SRSreq 107] If the user modifies or deletes a course-section outcome that is associated with other entities, the
following message will display:
Warning: This change may invalidate existing mappings. Do you wish to continue?

3.2.3.5. Select Download

[SRSreq 108] When the user selects the option to download student information from the database, the system
will connect to university database over the network.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 24
Software Requirements Specification

[SRSreq 109] When the user selects the option to download student information from the university database
for a CRN, the system will connect to the university database and retrieve the following
information for the students registered in the CRN:

 Last name
 First name
 Middle initial
 Id
 Classification

3.2.3.6. Select Spreadsheet

[SRSreq 110] If the user chooses the option to display grades in the Assessment Instrument Category
Spreadsheet or the Assessment Instrument Summary Spreadsheet and a formula has not been
entered, the system will calculate the totals based on an even distribution within each AI
category, and the grand total will be the sum of the weighted averages in each AI category.

[SRSreq 111] If the user chooses the option to display grades in the Assessment Instrument Category
Spreadsheet or the Assessment Instrument Summary Spreadsheet and the user selects to enter a
formula, the entered formula will override the default setting.

[SRSreq 112] If the user chooses the option to display grades, the grades will be displayed on a spreadsheet
with AIs grouped by category, and the headings displayed as given in Section 3.1.1.8 (depending
on the spreadsheet requested).

[SRSreq 113] If the user chooses the option to display grades in the Assessment Instrument Category
Spreadsheet or the Assessment Instrument Summary Spreadsheet, the "Letter Grade" field will be
automatically generated by determining the interval in which the grand total lies with respect to
the user-defined letter grade ranges.

[SRSreq 114] When the user selects the option to view the Individual Assessment Instrument Spreadsheet, the
user will have the option to select an AI from a predefined list of AIs.

[SRSreq 115] If the user modifies a grade on the spreadsheet, the newly entered grade will replace the existing
grade in the database and all formulas associated with that grade will be updated.

[SRSreq 116] If the user chooses the option to enter grades and no course-section outcomes have been defined,
the system will display the following message and the system will go back to the "Select Option"
state.
At least one course-section outcome must be defined.

[SRSreq 117] If the user enters a grade value that is greater than the maximum AIU point value, the following
message will display:
Warning: The points entered exceed the maximum AIU point value. Would you like
to proceed?

3.2.3.7. Select Targeted Competency

[SRSreq 118] If the user selects the template, the user will be able to enter values for the percentages. Refer to
3.1.1.5.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 25
Software Requirements Specification

[SRSreq 119] If the user selects the template, the values entered for the percentages will be greater than 0 and
less than or equal to 100. Otherwise, an the following error message will appear:
Percentage must be greater than 0 and less than or equal to 100. Please reenter.

[SRSreq 120] If the user selects the “Other” option, the user will be able to enter text.

[SRSreq 121] If the user defines an “is-associated-with” relation from a targeted competency to a course-section
outcome, the system will maintain the association in a table.

3.2.3.8. Select Archive

[SRSreq 122] If the user selects the option to archive information into the central database, then all tables in the
local database will be transferred to the central database.

[SRSreq 123] If the user attempts to archive data into the central database before the end of the semester, the
following message will appear:
The time frame for archiving data is invalid.

[SRSreq 124] If the user selects the option to archive information into the central database and the system
successfully initiates the archive, the following message will display:
Archive in progress. Please wait for confirmation of completion.

[SRSreq 125] When the archive into the central database completes, the user will be notified of its completion.

3.2.4. Related Features

3.2.4.1. Spreadsheet

[SRSreq 126] The Individual Assessment Instrument Spreadsheet will display raw scores, i.e., the actual scores
assigned to an AIU.

[SRSreq 127] In an Individual Assessment Instrument Spreadsheet, the total represents the summation of the
AIPs (AIUs) with respect to its predecessor AIP or the result of a user-defined formula, and the
final column gives the grand total for the AI or the result of a user-defined formula.

[SRSreq 128] In an Individual Assessment Instrument Spreadsheet, the totals will be automatically calculated.

[SRSreq 129] For any spreadsheet format, the mean and median will be computed for each column and will be
displayed at the end of the class list.

[SRSreq 130] For the Assessment Instrument Summary Spreadsheet and Assessment Instrument Category
Spreadsheet, the grand total and the intermediate total for the Category Summary will be
displayed based on the selections of the user. See Section 3.2.2.4.
[SRSreq 131] The user will not be able to modify a system-calculated total.

3.2.4.2. User-Defined Formula


The BNF presented in Figure 4 is subject to change.

[SRSreq 132] The user will be able to define a formula as specified by the BNF presented in Figure 4.

[SRSreq 133] The meanings of the operations are given in Table 1.


Software Requirements Specification CS 4310 Fall 2000 Date Page
12/11/2010 13:37 A12/P12 26
Software Requirements Specification

[SRSreq 134] Operators +, -, *, and / will have the standard meanings.

[SRSreq 135] Relational operators <, <=, >, >=, =, != will have the standard meanings.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 27
Software Requirements Specification

EXPRESSION ::= <TERM> [<ADDOP> <TERM>]*


MULTOP ::= * | /
TERM ::= <FACTOR> [ <MULTOP> <FACTOR>]*
ADDOP ::= + |-
FACTOR ::= ( <EXPRESSION> )
| <NUM>
| <CELLADDRESS>
| <FUNCTION>
FORMULA::= = <EXPRESSION>
NUM ::= <DIGITSERIES>
| <DIGITSERIES> . <DIGITSERIES>
| . <DIGITSERIES>
DIGITSERIES ::= DIGIT | DIGIT <DIGITSERIES>
DIGIT ::= 0|1|2|…|9
CELLRANGE ::= <CELLADDRESS> [ : <CELLADDRESS>]
CELLRANGELIST ::= <CELLRANGE> [ , <CELLRANGE>] *
CELLADDRESS ::= [<ALPHASERIES> | <DIGITSERIES> ] *
ALPHASERIES ::= <ALPHA> | <ALPHA> <ALPHASERIES>
ALPHA ::= a | b | .. | z | A | B | … | Z
FUNCTION ::= MAX ( <CELLRANGELIST> )
| MIN ( <CELLRANGELIST> )
| AVG ( <CELLRANGELIST> )
| MEDIAN ( <CELLRANGELIST> )
| COUNT ( <CELLRANGELIST> )
| PERFECT ( <CELLRANGELIST> )
| POWER(NUM, <CELLADDRESS>)
| SUM ( <CELLRANGELIST> )
| SUMBEST (DIGITSERIES, <CELLRANGELIST> )
| IF ( <CONDITION> , <EXPRESSION> , <EXPRESSION> )
CONDITION ::= <BTERM> [ OR <BTERM]*
BTERM ::= <BFACTOR> [ AND <BFACTOR>]*
BFACTOR ::= ( <CONDITION> )
| <EXPRESSION> <CONDOP> <EXPRESSION>
CONDOP ::= < | <= | = | >= | > | !=

Figure 4. BNF for User-Defined Formula

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 28
Software Requirements Specification

Signature Definition Description

Avg =
1 ∑ Xi The arithmetic average of a
n i=1 collection of cells.
where n is the number of non-empty cells in
AVG (<CELLRANGELIST>)
the cells specified
Xi is the value contained in the ith cell of
the <CELLRANGELIST>

1. count = 0 Returns the number of non-empty


2. For each cell in the cells specified do cells
COUNT (<CELLRANGELIST>)
if cell is not empty, then count++
3. Return count

1. Perform an ascending sort on the values. The median is the halfway point
2. If n is odd, the median is the value in of an ordered list.
index (n + 1)/2.
MEDIAN (<CELLRANGELIST>)
3. If n is even, the median is the value in
indices (n/2) and n/2 + 1.
4. Return the value of the cell(s) in the
median position of the sorted list.

1. Search for the smallest value in the list The smallest value in an ordered
MIN (<CELLRANGELIST>) for the specified cells. list.
2. Return this value.

1. Search for the largest value in the list for The largest value in an ordered
MAX (<CELLRANGELIST>) the specified cells. list.
2. Return this value.

1. Sum the "maximum AI or AIP point The maximum possible points


PERFECT(<CELLRANGELIST>)
value" for the cells specified. that can be obtained on an AI or
2. Return this value. AIP.

IF (<CONDITION> , if <condition> then If returns the value of the


<EXPRESSION> , <expression1> expression1 if the condition
<EXPRESSION> ) else evaluates to true; otherwise, it
<expression2> returns the value of expression2.

Table 1. User-Defined Formulas

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 29
Software Requirements Specification

3.2.5. Functional

Functional requirements are specified in other sections.

3.3. Non-behavioral Requirements

3.3.1. Performance Requirements

[SRSreq 136] With client and server running on the same machine, response time will be a maximum of two
seconds.

3.3.2. Qualitative Requirements

3.3.2.1. Security
This section is not complete. Additional requirements will follow.

[SRSreq 137] Each time there is a security violation, the log file will be updated with the login, date, and time.

3.3.2.2. Maintainability

[SRSreq 138] The system will be designed to allow the following changes:

 Reports consisting of plots and graphs


 Administration of accounts, ABET outcomes, mapping of ABET outcomes to program
outcomes, definition of program outcomes.
 Database queries
 Administration of Oracle
 Archive files to central database

3.3.2.3. Portability
[SRSreq 139] The system will run on multiple platforms, in particular Windows, Unix, and Macintosh.

3.3.3. Design and Implementation Constraints

[SRSreq 140] The system will be designed for the following future extensions:

 Archive course-section data


 Use of existing course information as template for creation of a new course section
 Administration of database
 Student access
 Prorated grade calculation

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 30
Software Requirements Specification

3.4. Other Requirements


This section includes requirements relating to database structures and operations, any special operations
required by the user, and any installation or software portability issues.

3.4.1. Database

This section describes requirements associated with a database. The database schema will be provided at a later
date.

[SRSreq 141] All information created, modified, or deleted through CACQI will be stored in the local database.

Software Requirements Specification CS 4310 Fall 2000 Date Page


12/11/2010 13:37 A12/P12 31