software requirements specification (srs) template€¦ · web viewcmps 285. team 2. team...

Software Requirements Specifications Document

CMPS 285

Team 2

Team Comeback

Software Requirements Specification

Document

Version: (1) Date: (09/25/2008)

Fall 2008 of 19 05/25/23f


Table of Contents

1. Introduction 4

1.1 Purpose 4

1.2 Scope 4

1.3 References 4

1.4 Overview 4

2. The Overall Description 5

2.1 Product Perspective 52.1.1 System Interfaces 52.1.2 Interfaces 52.1.3 Hardware Interfaces 52.1.4 Software Interfaces 62.1.5 Communications Interfaces 62.1.6 Memory Constraints 62.1.7 Operations 62.1.8 Site Adaptation Requirements 7

2.2 Product Functions 8

2.3 User Characteristics 9

2.4 Constraints 9

2.5 Assumptions and Dependencies 9

3. Specific Requirements 9

3.1 External Interfaces 12

3.2 Functional Requirements 12

3.3 Performance Requirements 12

3.4 Logical Database Requirements 12

3.5 Design Constraints 133.5.1 Standards Compliance 13

3.6 Software System Attributes (Non-Functional) 133.6.1 Reliability 133.6.2 Availability 133.6.3 Security 133.6.4 Maintainability 133.6.5 Portability 133.6.6 Usability 143.7.1 System Mode 143.7.2 User Class 143.7.3 Objects 143.7.4 Feature 143.7.5 Stimulus 143. 7.6 Response 143.7.7 Functional Hierarchy 15

Fall 2008 of 19 05/25/23f


4. Change Management Process 15

5. Document Approvals 15

6. Supporting Information 16

Appendix 16

Glossary 17

Fall 2008 of 19 05/25/23f


1. Introduction

The following sections provide an overview of the software requirements for the Student Academic Advisory System (SAAS) for the computer science department at Southeastern Louisiana University. This document is not intended to be used for design, but will describe what the system will do in order for the developers to build it.

1.1 Purpose

The overall objective of the SAAS is to help the computer science department at Southeastern Louisiana to make necessary classes available for its students.

This document is intended to be a support document describing the requirements of the SAAS for the potential client while also serving as a guide for the developers.

1.2 Scope

This plan establishes the efficiency, performance, and development requirements for Release 1 of the Student Academic Advisory System (SAAS). This system will be used to help students choose a class to take for next semester as well as assist the Computer Science department at Southeastern Louisiana University to schedule classes needed for the following semester.

1.3 References

Andrew Stellman, Jennifer Greene, “Head First C#”, O'Reilly Media, Inc. (2007). SAAS -Student Academic Advisory System: The acronym given to the developing system in progress.

1.4 Overview

Section 1 identifies the software purpose, document scope, and a list of reference documents. Section 2 provides a general idea of the system, and the overall description of the architecture and functionality of the software.

Section 3 identifies the specific requirements for the software system and the organization of these requirements.

Section 4 identifies the management process when changes are necessary to the software system.

Section 5 identifies the document approvers. Section 6 consists of the supporting information for the SRS document.

Fall 2008 of 19 05/25/23f


2. The Overall Description

The following sections provide an overview of the customer’s specifications for the SAAS.

2.1 Product Perspective

SAAS is intended for the Computer Science department at Southeastern Louisiana University and students who major in Computer Science. The students need assistance in scheduling necessary classes and the University does not schedule every semester. The Administration needs assistance in knowing how many students desire to take these seldom offered courses and schedule accordingly. This can be accomplished through the SAAS. The SAAS must be user-friendly and reliable for this academic planning system.

SAAS is projected to be a stand-alone system and should not require the use of other software. It should run on a Windows XP or Vista platform.

2.1.1 System Interfaces

2.1.2 Interfaces

The system will consist of an administrative interface and a user interface. The administrative interface will allow the administrator to add, delete, or modify majors, courses, catalog years, and semesters. The Administrator will also be able to print a database of course requests in order to make more courses available for the following semester. The user interface must allow the user to enter their unique ID, called a W number, then select a catalog year and major. A list of courses and electives for selected majors with options to move or delete courses must also be provided. Transfer courses, pre-requisites, course grade requirements, and the course rotation plan must also be taken into consideration at a later date. The administrative interface and the user interface must be user friendly.

2.1.3 Hardware Interfaces

The minimum requirements for the SAAS are: 450 MHz CPU 256 MB RAM, 800x60 display, 5400 RPM hard disk

Otherwise, there are no special hardware interface requirements for this system.

Fall 2008 of 19 05/25/23f


2.1.4 Software Interfaces

SAAS will use an SQL database and Microsoft suggests it should run on a Windows XP or Vista operating system.

2.1.5 Communications Interfaces

We are using Visual Studio C# to do our programming and .NET web services which provide a simple, flexible, standards-based model. This will allow assemblance of applications regardless of the platform used. It will also have capabilities of XML web service which is a programmable unit of software which can be accessed over the Internet. The following is an example of the code taken from a sample in C# program:

x:Class = "WpfBrowserApplication1.Page1" xmlns = "http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x = "http://schemas.microsoft.com/winfx/2006/xaml" Title = "Page1"> <Grid>

2.1.6 Memory Constraints

When running Visual Studio there is an IDE (Integrated Development Environment) which takes a large amount of memory space. For instance, there are sound files, tutorials, a large set of operators, arithmetic and logical operators to name a few.

You are able to download VS 2008 onto your system if you have 128MB. But it is not advisable. Microsoft (Microsoft.com) recommends a minimum of 256MB of RAM to run Visual Studios 2008 efficiently and without bogging your computer down. In our changing times, coupled with the low cost of hardware, our programmers suggest upgrading to a minimum of 256MB RAM to run your programs with peak proficiency.

Backup of software should be made daily. Depending on usage and system, backing up data to a secondary “stand alone” storage device should be performed weekly. If there is heavy usage, more than one hundred students per week, back up should be performed twice a day and a secondary storage should be performed bi-weekly at the very least. Compression of files is recommended, as data can become cumbersome.

2.1.7 Operations

(1) This program is written using Microsoft C# and Visual Studio 2008 Professional edition. It will be linked to an SQL database consisting of information for current students to input data into the system, any time available to them, which will

Fall 2008 of 19 05/25/23f


request classes for the following semester and generate a report for the Department Head of Computer Science, Administrator.

(2) Students will be able to request classes for the upcoming semester by mid-term of the previous semester. Therefore, the system will be inactive from April 2 to August 15 of any given year.

(3) During the above mentioned ‘inactive’ time frame, the system will undergo maintenance which includes file maintenance and file compression, as well as checking the system for duplicates, and maintenance of data which programmers deem necessary. Upgrades will be performed at this time as well as restore points.

(4) Backup of data will be performed and restore points will be checked and re-set if necessary during the summer break as well. For regular interval backups we will cooperate with the Computer department to set daily backup intervals.

2.1.8 Site Adaptation Requirements

(1) The following drawing illustrates the establishment of the Initialization Sequence of the client and server capabilities. As you can see, from top to bottom: the Server synchronizes the initial state of the client and server clipboards, and exchange settings. When the client receives from the server it sends the clipboard capabilities PDU to the server, processes data, and so forth. Much detail is intentionally left out for readability. What you should notice is where ‘client’ is this is the computer the students will put their data into. The Server will disseminate the information, store, exchange information, computation, and then synchronize the information to be extracted at a later date for the Administrator’s report. Because of this synchronization, each instance of the program can be run from any Internet capable computer and uses little or no memory for program or storage of data.

Fall 2008 of 19 05/25/23f


Figure 1: Clipboard Redirection Initialization Sequence (www.msdn.microsoft.com/library with expressed “student permission” to use)

(2) For users/current students the requirements will be a computer with internet access. This system is able to work on any computer with Internet access.

(3) For client, the Administrator, the requirements will be a computer with 256MB RAM, MS operating system XP or Vista, Microsoft Visual Studio 2008, and internet access.

(4) Backup of database will be performed via .NET interface. Disk backup will be performed in conjunction with the computer CD capabilities via internet at intervals predescribed.

(5) New data tables created for this system must be installed on the company’s existing DB server and populated prior to the system activation. This is a stand alone DB and server.

2.2 Product Functions

The software will provide the Administrator of the Computer Science Department a comprehensive report in the middle of the semester, April 2 and November 2, for students to request classes. It streamlines the Administrator’s task of scheduling classes for the following semester based upon student needs. Current Students will add their unique W#. Then, the current students will be allowed to make a request for classes. This software DB will be mainly static, using mostly Boolean variables, students will not be able to change the controls. There will be a SQL database connected to collect data for analyzing and a report generator for the end user, the Administrator.

(1) The functions will be organized in a way that makes the list of functions understandable to the current students or to anyone else reading the document for the first time.

(2) There will be a sign on for current students, which they will have to enter their W# - a unique identifier, to ensure no unwanted data is stored in the system from persons not currently enrolled at Southeastern Louisiana University.

(3) We will use Boolean variables to simplify the process of tracking the classes previously taken.

(4) There will be a drop down box for classes a student can request for the following semester. Students will be able to choose at least two classes for the following semester.

(5) The Administrator will be able to generate and print a report for class requests for the following semester.

(6) The Administrator can change security settings, install software and hardware, and access all files on the computer. Update catalog year if necessary. The Administrator will not be able to change the user requests once submitted.

(7) The Administrator will not be able to change data on the report generated at the end of the semester.

Fall 2008 of 19 05/25/23f

http://www.msdn.microsoft.com/library


2.3 User Characteristics

The intended users are current students in the Computer Science department at SELU, are undergraduates, friendly, and intelligent. The technical expertise of these students is outstanding; all are versed in the latest and most cutting edge technology. In this field of study, students are required to analyze, design, and implement software as well as hardware issues. They study higher forms of mathematics, computer theory and practical perspectives of computer systems, study computing activities, and extensive sciences.

Because of the aforementioned students, simplicity is not needed but desired and time is valuable. It is anticipated that the students will be comfortable with the design and will be able to navigate it easily.

2.4 Constraints

(1) Learning curve on C#, .NET, and SQL by team members. (2) Criticality of the application by current students wanting to make changes.

2.5 Assumptions and Dependencies

The Student Academic Advisory System will be programmed using Visual Studio 2008. This software has specific links for .NET interface.

A concern of the team is security; the ability for someone other than a Computer Science major to enter the database using his/her W#.

We would like to add pre-requisites if time allows. If we can find a way to add the controls.

We would like to add other Computer Science degrees at a later date.

3. Specific Requirements

In order for this program to be implemented it must possess a computer with 256MB RAM, monitor, and keyboard.

Microsoft Windows XP or later version of Windows software. Microsoft Visual Studio 2008 or later. Internet accessible to access the .NET software and input summon the

database.

Fall 2008 of 19 05/25/23f


Unique Identifier -- A W# is a unique SELU identification for each student registered at the college. Students will put their W# in and sign on. At this point there will be verification of the W#.

Students will be asked if grade of “C” or better, then this will generate the labels to check the classes in the checkbox (see below) to become active.

The students will check classes taken by selecting a Boolean variable check box; this is either a true or false statement. Each Boolean variable will have a label for each class taken.

Each member of the database should have a numerical assignment with no duplicates. Labels will be generated from a list of classes for the 2007-2008 school years. The following data taken from the Bachelor of Science in Computer Science will be linked to the SQL database:

CMPS 161 Algorithm Design and Implementation ICMPS 257³ Discrete StructuresCMPS 280 Algorithm Design & Implementation II

CMPS 285 Software Design and Professional PracticeCMPS 293 Introduction to Assembly LanguageCMPS 375 Computer ArchitectureCMPS 390 Data StructuresCMPS 391 Numerical MethodsCMPS 401 Survey of Programming LanguagesCMPS 411 Software EngineeringCMPS 431 Operating SystemsCMPS 479 Automata and Formal LanguagesCMPS 481 Seminar

There will be a checklist box to allow students to select two classes they would like to schedule for the following semester. The student will only be able to select two items from the checklist box.

Each member of the database should have a numerical assignment with no duplicates. The information contained in the checklist box will be all CMPS classes offered in the 2007-2008 catalog, from SLU as follows:

CMPS 257 Discrete StructuresCMPS 262 COBOL ProgrammingCMPS 273 Software Storing and Analyzing DataCMPS 280 Algorithm Design & Implementation IICMPS 285 Software Design and Professional PracticeCMPS 293 Introduction to Assembly LanguageCMPS 294 Internet ProgrammingCMPS 295 Special ProblemsCMPS 297 Digital LogicCMPS 309 Computer NetworkingCMPS 315 System AdministrationCMPS 319 Principles of Information AssuranceCMPS 320 Applied Graphical User Interface (GUI) ConceptsCMPS 335 Advanced Web PublishingCMPS 355 Object-Oriented Programming

Fall 2008 of 19 05/25/23f


CMPS 375 Computer ArchitectureCMPS 383 Information SystemsCMPS 387 Statistical ComputingCMPS 389 Computer GraphicsCMPS 390 Data StructuresCMPS 391 Numerical MethodsCMPS 393 Fundamental AlgorithmsCMPS 394 Web systems and technologiesCMPS 400 InternshipCMPS 401 Survey of Programming LanguagesCMPS 409 Advanced computer NetworkingCMPS 411 Software EngineeringCMPS 420 Human Computer InteractionCMPS 421 Computers in EducationCMPS 431 Operating SystemsCMPS 432 Compiler constructionCMPS 435 Real Time Software SystemsCMPS 439 Database SystemsCMPS 441 Artificial IntelligenceCMPS 443 Simulations and ModelingCMPS 447 Robotic SoftwareCMPS 449 Communications in ComputingCMPS 455 Computational Aspects of Game ProgrammingCMPS 458 Expert SystemsCMPS 460 Design and Implementation of Neural NetworksCMPS 470 Machine LearningCMPS 479 Automata and Formal LanguagesCMPS 481 SeminarCMPS 487 Introduction to Operations ResearchCMPS 491 Selected topics in Computer ScienceCMPS 495 Special Problems

The student will hit the ‘save’ button at this point the data will be stored then added to a report for the administrator’s office.

There will be a calendar linked so the program automatically shuts off on a pre-determined date. The date will be determined as April 1 and November 1 of each school year. The software will no longer be activated until the following semester.

The calendar will allow students to enter information from January 25 to April 1 and August 30 to November 1 of any given year.

The Administrator will be able to generate a report only from data collected during the semester. There is no need for the Administrator to add data to the system interface.

Software maintenance shall be performed during this time including file compression, deleting graduated students; testing software, updating, and setting restore points.

Fall 2008 of 19 05/25/23f


On April 2 and November 2 a report shall be generated by the Administrator for the sole purpose of collecting data which assists in a planning for the following semester.

3.1 External Interfaces

The user face for the Student Academic Advisory System will consist of two interfaces. The first external interface will be the end-user application featuring a window where the user will be allowed to login or create a new account. If chosen to create a new account, the window will redirect to another where the user can enter their W-number, catalog year, and major. This information will be stored within the SQL database and a password will be created and assigned. The window will redirect to the home screen to allow login from the user. When this is completed, a new corresponding window with 5 tabs will be accessible. The tabs will allow the user to switch between the next four years available from their catalog year. Each tab will have two panels. The first tab will display the user’s information along with two panels. The first panel will show corresponding courses retrieved from the database. The second panel will be for containing courses the user has already taken. The remaining four tabs will be divided into fall and spring semesters. Here the user will have the ability to select certain courses, send them to specified locations, and save changes. Before the courses are sent, a Boolean check will be completed to ensure that all requirements are satisfied for the new location. Upon exiting, the user will be prompted to save changes.

In addition to the end-user interface is the administrative interface. The administrative interface will have sole access to inputting and updating the SQL database, except for the creation of accounts from the end-user. The database will be designed to contain all viable information including user accounts, courses, catalog years, and majors. The database will store and send appropriate data according to the user input in the end-user and administrative interfaces. The end result will provide the user with an organized and efficient way to visually plan upcoming semesters.

3.2 Functional Requirements

(See 3.7)

3.3 Performance Requirements

The system should respond to user request within 2 seconds and support multiple users simultaneously.

3.4 Logical Database Requirements

Fall 2008 of 19 05/25/23f


All data will be saved in the database which will include the user accounts, courses, catalog years, and majors. Access to altercate the database will only be given to the administrative user. The database allows concurrent access and will be kept consistent at all times, requiring a well developed database design. The database will have integrity constraints foreign key, not null, unique, and check.

3.5 Design Constraints

3.5.1 Standards Compliance The design constraints of the system will include:1) Time Constraints

a) Design schedule for planning project b) Development schedule

c) Production schedule d) Delivery schedule for end product

2) Security Constraints for user access 3) Data naming in application

3.6 Software System Attributes (Non-Functional)

3.6.1 Reliability The required reliability of the system at time of delivery is 100%. This will place a reliability goal for each component at 33.33% failure rate.

3.6.2 Availability The availability and support of the system will be at the highest, allowing the user to have constant access. The system will have checkpoints in case of system failure every ten minutes to reduce loss of input. If system failure occurs, the user is advised to restart application.

3.6.3 Security To assure appropriate access of user accounts using the W#. End-users and administrative users will be denied access to opposing interfaces. End-users will not be allowed to modify or access the database, only to submit and edit their account.

3.6.4 Maintainability The administrative user will constantly maintain the database through SQL with the addition of new courses, catalog years, and majors. The end-user will constantly maintain their account information.

3.6.5 Portability

Fall 2008 of 19 05/25/23f


The system will be constructed with C#, a proven portable language and compiler.

3.6.6 Usability The system will be completely user friendly. The end-user and administrative interfaces will be easy to learn, and require little effort to submit input and comprehend output.

3.7 Organizing the Specific Requirements

3.7.1 System Mode

The interface and performance are not dependent on the mode of operation. It does not directly apply a computer's various capabilities in the performance of tasks that benefit the user.

3.7.2 User Class

The system will have provisions for two different classes of users: Current students and Administrator. Computer Scientific Concentration majors.

3.7.3 Objects

There will be several classes: Student Information, Course Major Information, and Combined Information. There will also be several methods within the System. The GetMajor() will prompt the user for his or her computer science concentration. The CourseOrder() will allow the student to place one’s courses in the order that one intends to take it. The Prerequisite() method will warn the user that a prerequisite is needed in order to take that course.

3.7.4 Feature

The program will have features that allow users and administration access to data that may be relative information. This correlates to the following stimulus and response counterpoints below.

3.7.5 Stimulus

Stimulus (1): The program prompts the user for his or her information-W#.Stimulus (2): The program allows the user to simulate his or her course undertakings.Stimulus (3): The program allows the administration to access the data collectively.

Fall 2008 of 19 05/25/23f


3. 7.6 Response

Response (1): The user will enter his or her information, W#.Response (2): The program will display the appropriate hierarchy of data.Response (3): The program will allow access to a SQL database to allow administration the necessary information and generate a report.

3.7.7 Functional Hierarchy

4. Change Management Process

In order to reflect changes in project scope and requirements to the SRS, there must be team consensus. After the team consensus, there must also be authorization from the Group Leader and Instructor. Changes to the requirements must be submitted formally in writing, this also includes electronic mail. The change management process that consists of identifying, logging, evaluating, and updating information will be done through electronic mail. This will ensure formal documentation of said aforementioned consensus.The change management will consist of the SQL database that will allow the user to log into the database to change, alter, or update the student’s information. The information from the data will be able to be dynamically updated upon request from the administration.

5. Document Approvals

Herein, the SRS documentation must be approved by the following:

Ghassan Alkadi (Instructor) ______________________________________Katie Wallace (Group Leader) ______________________________________

Fall 2008 of 19 05/25/23f


Diana Chatagnier (Group Member) ______________________________________Rhonda Plaisance (Group Member) ______________________________________Samantha Zambo (Group Member) ______________________________________

6. Supporting Information

Appendix

The Appendices included in the SRS document should explicitly be included as part of the requirements.

The courses listed are Computer Science Department for Bachelor of Science, Science concentration majors. These are courses that each student must choose as a major concentration. These courses are taken from the 2007-2008 Southeastern General Catalog. These are examples of the optional courses that might be listed in the database.

COMPUTER SCIENCE Bachelor of Science2007-2008CMPS 161 CMPS 257CMPS 280 CMPS 285 CMPS 293 CMPS 375 CMPS 390 CMPS 391 CMPS 401 CMPS 411 CMPS 479 CMPS 481 CMPS ElectiveCMPS Elective

Fall 2008 of 19 05/25/23f


Glossary

A-H

ANSI. American National Standards Institute.

ASCII. American Standard Code for Information Interchange.

asynchronous. Occurring without a regular time relationship, i.e., timing independent.

application software. (IEEE) Software designed to fill specific needs of a user; for example, software for navigation, payroll, or process control

benchmark. A standard against which measurements or comparisons can be made.

client-server. A term used in a broad sense to describe the relationship between the receiver and the provider of a service. In the world of microcomputers, the term client-server describes a networked system where front-end applications, as the client, make service requests upon another networked system. Client-server relationships are defined primarily by software. In a local area network [LAN], the workstation is the client and the file server is the server. However, client-server systems are inherently more complex than file server systems. Two disparate programs must work in tandem, and there are many more decisions to make about separating data and processing between the client workstations and the database server. The database server encapsulates database files and indexes, restricts access, enforces security, and provides applications with a consistent interface to data via a data dictionary.

constraint analysis. (IEEE) Evaluation of the safety of restrictions imposed on the selected design by the requirements and by real world restrictions. The impacts of the environment on this analysis can include such items as the location and relation of clocks to circuit cards, the timing of a bus latch when using the longest safety-related timing to fetch data from the most remote circuit card, interrupts going unsatisfied due to a data flood at an input, and human reaction time.

database. (ANSI) A collection of interrelated data, often with controlled redundancy, organized according to a schema to serve one or more applications. The data are stored so that they can be used by different programs without concern for the data structure or organization. A common approach is used to add new data and to modify and retrieve existing data.

documentation, software. (NIST) Technical data or information, including computer listings and printouts, in human readable form, that describe or specify the design or details, explain the capabilities, or provide operating instructions for using the software to obtain desired results from a software system.

end user. (ANSI) A person, device, program, or computer system that uses an information system for the purpose of data processing in information exchange.

Fall 2008 of 19 05/25/23f


Failure Modes and Effects Analysis. (IEC) A method of reliability analysis intended to identify failures, at the basic component level, which have significant consequences affecting the system performance in the application considered.

feasibility study. Analysis of the known or anticipated need for a product, system, or component to assess the degree to which the requirements, designs, or plans can be implemented.

hardware. (ISO) Physical equipment, as opposed to programs, procedures, rules, and associated documentation.

I-S

interface. (ISO) A shared boundary between two functional units, defined by functional characteristics, common physical interconnection characteristics, signal characteristics, and other characteristics, as appropriate. The concept involves the specification of the connection of two devices having different functions.

maintainability. (IEEE) The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment.

memory. Any device or recording medium into which binary data can be stored and held, and from which the entire original data can be retrieved. The two types of memory are main; e.g., ROM, RAM, and auxiliary; e.g., tape, disk.

operation and maintenance phase. (IEEE) The period of time in the software life cycle during which a software product is employed in its operational environment, monitored for satisfactory performance, and modified as necessary to correct problems or to respond to changing requirements.

PDL. program design language.

protocol. (ISO) A set of semantic and syntactic rules that determines the behavior of functional units in achieving communication.

RAM. random access memory.

ROM. read only memory.

relational database. Database organization method that links files together as required. Relationships between files are created by comparing data such as account numbers and names. A relational system can take any two or more files and generate a new file from the records that meet the matching criteria. Routine queries often involve more than one data file; e.g., a customer file and an order file can be linked in order to ask a question that relates to information in both files, such as the names of the customers that purchased a particular product.

requirement. (IEEE)) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.

server. A high speed computer in a network that is shared by multiple users. It holds the programs and data that are shared by all users.

Fall 2008 of 19 05/25/23f


simulation. (1) (NBS) Use of an executable model to represent the behavior of an object. During testing the computational hardware, the external environment, and even code segments may be simulated.

software. (ANSI) Programs, procedures, rules, and any associated documentation pertaining to the operation of a system.

specification. (IEEE) A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior,or other characteristics of a system or component, and often, the procedures for determining whether these provisions have been satisfied.

S-Z

structured query language. (SQL) A language used to interrogate and process data in a relational database. Originally developed for IBM mainframes, there have been many implementations created for mini and micro computer database applications. SQL commands can be used to interactively work with a data base or can be embedded with a programming language to interface with a database.

Testability. (IEEE) The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.

Testing, Interface. (IEEE) Testing conducted to evaluate whether systems or components pass data and control correctly to one another.

Fall 2008 of 19 05/25/23f

software requirements specification (srs) template€¦ · web viewcmps 285. team 2. team...

Documents