Introduction

Goals and Objectives

	The main goal of our software application is to provide a unique, easy to use interface for a University of Michigan home page link registration system. Secondary goals include minimal system administrator interaction, automation of system integrity and compliance rules, and ease of commercialization of the product. The software objectives parallel the goals of the system, a friendly user interface that automates the error checking and submission process along with the inclusion of search capabilities.
	The inclusion of search capabilities allows visitors to quickly find a specific user or topic of interest. The search engine is modeled after the search engine found on the HOTBOT portal site. Users will have the capability of searching just the list of university related websites, searching the entire website, or the entire web itself. We included this capability to increase the public’s awareness of the quality of the University of Michigan family.
	The easy to use system interface was accomplished in many subtle ways. Every major web page on the university system includes a link that lets users know that they can include their web page on the schools list of homepages, increasing student and faculty member’s awareness of the software. The list of web pages itself is easy to use, laid out in a simple pattern with the universities disclaimer at the top of the page, search engine in the middle, and the links them selves on the bottom of the page. 
	The search engine has many extra features that allow the user to make an educated search that returns matches that are as close to what the user was looking for. There are also several other ways a visitor to the system may find a specific user. There is two distinctly separate lists of links (A B C …Z) that allow visitors to go directly to a list of users delineated by name. There is also a quick jump to specific types of pages faculty, staff, and students. With the students list of web pages further broken down into categories according to which school the students are attending (Education, CASL, Engineering, management etc).

	Each section of the lists of homepages also has a help file associated with it. The user can get help on how to use the search engine capabilities, add their links, or find a specific web page by name. There are also help files and hints for users when they are filling out the forms to add their specific URL to the list. Therefore, the straightforward layout, help files, and search engine capabilities make the user interface simple and easy to use.
	The main objective of the software from the schools network administrator side is automation and ease of use. The software has been automated, as much as possible; in some cases links will be automatically listed on the spot. The system will automatically check for duplicate links or links that are just a sub-page of the main page. The system also automatically adds the links to an update file and then the system administrator has only to verify proper content, whenever they want to FTP the new list of links.
	The error handling capabilities of the software also ease the administrator’s job by sending the administrator a specific error code if a person was denied permission to load their link. The software also sends error messages to users to help them fill out the forms properly. If the user accidentally enters an incorrect email address or URL the system will prompt them as to what the correct form of input is required.

Statement of Scope

	The software consists of three main parts a CGI script that automatically generates the new html file for the system administrator, a database query system that authenticates users, and a CGI script that does the error checking on the system. The search engine is the HOTBOT search engine with all the added features, like advanced search, type of return, date link added to system etc. the web page itself has extra functionality that allows users to easily move around the page like (A B C …Z) links to an alphabetical list of names, and quick just links to specific categories.
Inputs

•	User name  first and last.
             First name  Last name
•	User identification number.
             Please enter your school identification number.
•	Type of user  Faculty, staff, or student.
             
•	Unit faculty works for  Casl, engineering, management, etc.
      
•	Unit student belongs to  Casl, engineering, management, etc.
      
•	Unit staff works for  maintenance, student services, administration, chancellor’s office, etc.
      
•	User email  error checked looking for @ and a ‘.’.
               Email in the form JohnDoe@somewhere.com
•	Home page title.
            .
•	URL  error checked for form.
             In the form of http://www.somewhere.com

Possible inputs for search engine
•	

Search smarter 
•	How to search  phrase, individual words, all the words etc
Look for?

•	Search for only the latest entry’s into the links list.
 Date added
•	Returns results or just links
 Return results
•	Language of web page English, Spanish, French etc
 Language.

The software processes the user input and has several different outputs and functionalities. The user input is first parsed to find out if the user is indeed a member of the University of Michigan family. The software then does a quick check to make sure the user email and URL are valid entries. After the validation checks are complete the software will then do a profanity check on the URL and the description, to ensure they comply with the universities policy. 
If the user has a basic error the system will politely suggest a corrected version of the input and return them to the starting page. If for some reason the system will not allow the user to add their URL, the system will remark to the user that it has sent an email to the system administrator with the proper error code for further processing. The system will then call a web spider, which will validate the suggested web site by checking to make sure the web site exists at the suggested user URL. This is done to make sure the user didn’t accidentally type in an incorrect URL.

System administrator user-interface  (system output)
 Name 		 Password

View error messages Error code library New administrator New password
New URL’s

Name	Email			URL				Error code
Larry	killer@sam.org	http://www.killer.com		none       
Moe	bob@school.edu	http://www.ajmn.com	      	122345   
Curly	nobody@nowhere.org http://www.ohboy.edu	none       

New Faculty URL’s added

Name	Email			URL				Department 
Maxim bmaxim@umich.edu	http://www.engin.CIS.edu	CIS        
Boggy 	Boss@umich.edu	http://www.engin.CIS.edu	CIS	  
Key to system administrators user interface

•	Verification  Verify there are no duplicate links.
•	Sub-page check  Verify links are not sub-pages of the same website.
o	www.ajmn.com Vs. www.ajmn.com/images.htm 
•	Verify #  Max number of links is three verify no user has more than three links.
•	Verify member exists  Member must be Faculty, staff, or student to add a link. 
•	The radio boxes if marked indicate a message from the system is waiting.
•	Spider  Verifies all existing links are valid, all new links are valid, and no profanity/porn in the new URL’s.

If the user has been verified to be an existing faculty member and has signed the policy agreement, the system will automatically add the URL to the list and make the new HTML code and web page. The faculty member then has only to refresh their web browser to see their link. For students and staff after they have signed the policy agreement the system will email the administrator about the requested link addition and make the updated html code and files. The administrator then has only to verify content of the web pages and can FTP the new link page onto the server.
The system will automatically update the list of links when the system administrator clicks the update button. If the administrator decides to not add a link for any reason all they have to do is check the box next to the name and the system will send a form email to the user explaining they were not added. Any URL’s with the delete button marked will also not be listed when the update button is clicked.

Software Context

	One of the secondary goals for the product was ease of commercialization of the product. This product can easily be used with either a Windows NT server or UNIX based server. The CGI script is easily loaded into the CGI bin on the server across any platform. Therefore, the product is easily used on any server or platform. The basic package will be free to any website on the web for maximum exposure. This package includes only the ability of the user to add a link automatically with no error checking.
	The way the basic system works will be the user trying to add their link only has 2 fields to fill-in, web page descriptor and the URL fields. The script will then generate the new HTML files and update the list on the spot; the user only has to refresh their browser to see that their link has been added. It will be the responsibility of the individual webmasters to ensure that the content is appropriate for their website and any other error checking needed.
	The next commercial package is aimed at potential university and colleges. The basic university-college package will also be free to universities or colleges. This package will include all error checking capabilities that the automated system offers. The package will not include the system administrator interface capabilities implying that any user can add their URL to the system. For a reasonable price the university package can be upgraded to the full system, which includes all features of the system and all source code. With the understanding that the source code can be modified at will but not released pass the bounds of the school system.
	The above packages will also be made available to Internet service providers and web server clients with the lone exception that the source code will not be released.  The premium package is available to businesses for a moderate price increase over the university package. Businesses will be able to use this on their intranet for any departments that have business WebPages and for a list of individual’s homepage links. 
	We will install the software on their servers and supply one training session. The training will include use of the system administrator’s interface and all other aspects of the system. The documentation included with all packages includes all user error codes and how to use the system interface. A complete guide for the system administrator on how maximizing the user interface. Including a step-by-step set of instructions on how to change the user interface and system requirements. 

Major Constraints

•	Testing client server architectures  performing system tests on as many different system architectures as possible so that the system can be sold to as many companies as possible.
•	Database is busy slowing down queries  during certain times of the year the database system is very busy, like during student registration or during business hours when administration jobs are querying the system repeatedly.
•	Test documents and help facilities  the range, accuracy, source, and frequency of use of the help files. Therefore, creations of a test plan and help facilities for different system is a challenge.
•	Types of servers CGI scripts will run on  will the CGI script work on different server platforms like Unix, Linux, and Windows NT etc. will the performance of the script be impacted by what type of server it is running on effecting other constraints known or unknown.
•	Busy server  max number of surfers on the system at any one time  how many surfers can use the system at the same time without impacting performance.
•	Number of users that can enter new links at the same time  how many surfers can utilize the software at the same time without impacting performance or at the extreme shut the system down.
•	Numbers of people who can use the search engine at the same time  how many surfers can use the search engine without impacting system performance. Can the university system support multiple searches at the same time? 
•	Backing up of the links page  how often does the server back up the files to ensure no loss of data. Does the database of emails belonging to individual users slow the system down or effect performance? Having the system automatically email users when the system crashes or loss of data for re-entry.
•	Interaction of the CGI script, html code, and user interface  how well does all the different types of code interact with each on all the different types of servers and system architectures.
•	Documentations training  during the training of business network administrators can the documentation system be adequately explained and shown how to use, to prevent multiple training sessions. 
•	Combining modules, database query system, HTML code, CGI script, and C++ code  will the system programmers be able to maintain system integrity and performance when they combine all the different types of files and codes on different servers and software packages.
•	Compatibility with existing systems and software  will the CGI script interfere of interact with other CGI scripts are ready in the servers when they are active or inactive.
•	Changes to the source code by universities affecting other system parts  limit the changes or responsibility for changes that others make to the source code.
•	Establishment of a logic based test plan  can a logic based test plan be developed that adequately tests the system logic that covers all the different types of code used in the system? Also can a logic based test plan be developed that covers the different types of servers and different software packages that might be used with the system.
•	Establishment of a data flow test plan  can a adequate test plan be made for all the different database systems that may be encountered. Can the test plan be devised that adequately works with the database query system and a CGI script?
•	Availability of database for testing queries  is the database available for a long enough period to adequately test the data flow between the two systems.
•	Different types of databases that the system has to interact with  can the system work with all the different databases on the market? Is it economical to test the system with all the different databases?
•	Different types of servers that the system has to work on  can the program work efficiently on SGI servers, Sun servers, Intel based servers, Motorola servers, and IBM servers to name a few.
•	Different types of software that is shared by servers that the system has to interact with  does the program work on all the different types of servers available Unix, Linux, Windows NT, and Novell Netware to name a few and can the system be adequately tested on all the different servers.
•	Establishment of a sound black box test plan that covers CGI script, HTML files, C++, user interface files. Is a exhaustive test plan possible.

Usage scenario

User profiles

	There are multiple user profiles for this system from surfers to network administrators. User profiles include novice surfers and web masters to expert system administrators and web masters. This very diverse spread of users means we have to provide excellent documentation and help files. On the other hand the system has to be advanced enough to please the expert users expected to visit the system.

•	Basic surfer  the basic surfer looking through the university web pages. Could be an ex-student looking for old friends or a surfer who has family attending or working at the university. The basic surfer is interested in ease of use with plain instructions that are easy to find. The search capabilities will be helpful for this type of user to look up friends or specific information. However, the basic surfer is not expected to spend allot of time on the system.
•	Basic user  the basic user is a first time web builder and not necessarily learned in all the intricacies of the web. They are looking for an easy to use system to add their links to, with a minimal amount of input and hassle. The basic user is not going to use the search capabilities as a rule. However, once the user realizes the power of the search engine and easy access to it, they might become repeat users especially in the university and business settings. The search engine on the business intranet may be especially useful, as the basic user does not have to leave the intranet to do a World Wide Web search, assuming their intranet is connected to the Internet.
•	System administrator  the system administrator is an advanced user and the main priority is speed and ease of use. The system is designed so that the system administrator has only to push a few buttons or check a box and the system does the rest. This is accentuated by the fact that the system administrator does not have to do any typing or other time consuming tasks.
•	Advanced surfer  the advanced surfer is interested in all the same features as the basic surfer. Plus the advanced surfer is looking for speed and advanced search features. The speed that pages load and searches returns results is of paramount importance to this type of user.
•	Advanced Webmaster  the advanced Webmaster is interested in all the same features as the basic user. Plus the advanced Webmaster is interested in the advanced search features, to ensures that they get top priority when a users does a search. This means that the advanced user wants to be at the top of the results return after someone does a search. Along with speed and ease of access for performance results.

Use–Cases

University users

•	Faculty  professor or lecturer who teaches at the school.
•	Staff  any worker at the university who draws a paycheck.
•	Student  any person takes and pays for classes at the school.
•	Network administrator  person or persons who maintain the network server.
•	Surfer  any wise person seeking knowledge and enlightenment, beauty and truth, and words of wisdom in the ways of software engineering at the University of Michigan-Dearborn.

Business or ISP users

•	Surfer  someone with to much time on their hands and a computer.
•	User  member of the business entity or member of the ISP community
•	Network administrator  person who runs the network server for the business or the ISP.

Special usage considerations

•	Are all the inputs to the system specified as to their source, accuracy, range of values, and frequency?
•	Are all the report formats specified?
•	Are all the external hardware and software interfaces specified?
•	Is the expected response time, from the user’s point of view, specified for all necessary operations?
•	Are all the communication interfaces specified including error checking and communications protocols?
•	Are all the tasks the user wants to perform specified?
•	Is the reliability specified including the consequences of software failure, vital information protected from failure, error detection, and recovery?
•	Is maximum memory specified, maximum storage specified?
•	Is the maintainability of the system specified, including the ability to respond to changes in the operating environment, interfaces with other software, accuracy, performance, and additional predicted capabilities?
•	Will the system work on the next generation of hardware and software without major changes to the system.

* please see appendix for the complete lists of requirements that we considered.

Data Model and Description

Data Description

	The data objects of a system are the objects that are primary to it.  Objects can be external to, internal to, and the system itself.  This system uses the following data objects:

•	End User -- The end user has a unique social security number, a name composed of their first and last names, an email address, the school for which they belong, and what their relationship  (student, staff, or faculty) to that school is.
•	Links -- The link of the web page to be added has a unique URL and the end user’s name composed of their first and last name.
•	URL Posting Plus! --
•	Administrators -- The administrator has a unique name.
•	Database -- The database contains information about the end user already known by the university, such as, their social security number, name, and the school that they are associated with.
•	Errors -- The error has a unique code, and a name, and a function.
•	Interface -- The interface has a unique entity for which it belongs to.
Each of the objects listed above can be related to at least one of the other objects.  These relationships are stated as follows:
•	Each end user can have multiple links.
•	Each link must have one corresponding end user.  
•	Each administrator may approve multiple links as they are submitted.
•	Each link is approved by one administrator.
•	Each user is found in one database.
•	Each database contains multiple users.
•	Each user accesses one interface.
•	Each interface receives input from multiple students.
•	Each user may receive multiple errors.
•	Each error pertains to one input or instance.
Data Model

Attribute

Relationship

Entity

Legend:

Name

E-mail

School

URL

Name

School

Type

Submits

SSN

Link

End User

Type

Received by

Belongs to

URL Posting Plus!

Checks

School

Approved by

Notifies

Returns

Type

Database

Errors

Code

Destination

Name

Administrator

Data Dictionary

	The function of the data dictionary is to define all of the data in an application (Firesmith 1995).  
Performance Issues

	The system has been designed with limited graphics and no Java applets in order to optimize the speed of loading in the users browser. However, the CGI script is a slow process and will take a small amount of time to process a users input; but will not affect the time a browser takes to load the system. Both Unix and Windows NT servers have the built in ability to support CGI scripts with the server of choice being a Unix server. The overall performance issue can be directly related to the CGI script and database query interaction.
	The size of the databases is also a factor, he larger the database the slower the queries will be. The volume of the queries to the databases from other systems will also have an impact on the speed of the system. The database system is shared by multiple numbers of other departments and the system is set up to search all databases until it finds the user. In other words the system has a has a built in error check, if for some reason the user inputs the incorrect unit that they belong to (student, staff, faculty) the system will automatically search the other database for the user. 
Therefore, this built-in redundancy could cost the user time in the short run but save time in the over all picture by preventing a user from having to submit their data twice. This is just one example of the system trying to help the user and prevent the user from having to input data multiple times. Another feature of the system that is there only for improved user interface and ease of use is system remembers all inputs. This may cost the system time and space but if the user makes a mistake it will remember all correct entries and mark the incorrect entry in red to make it easier for the user to recognize their mistake. The system will also include a small ditty that helps identify to the user their mistake and the correct way to phrase their input.
The interaction of CGI script, HTML, C++, and database query language also play an important role in performance issues. The different fragments of code must interact in intricate ways and maintain their performance. The number of users on the system at anyone time will also have an effect on the system performance. The more surfers on the University web-server will have a pronounced effect on the system speed. Also the number of users surfing the links page or trying to add links at the same time will also affect the system. Another aspect of performance is the number of users on the surfers ISP; this is not our responsibility but may lead the user to mistakenly think our system is 
slow.
In a business or ISP setting the above concerns also apply, plus a few others may affect the system. The number of users that have dialed in to the network on the ISP will affect the speed the system works at. If the ISP homepage is busy or has a small bandwidth the overall speed of the system will be decreased. In a large business setting like Ford Motor Company, the system might be slower because the company uses the web extensively in inter-department communications. 

                                                   kcn,inc.
                                   "the future of web posting today!" 

Functional Model and Description

Description for Functions:
The following section details the data flow and process specification for the "URL PostingPlus!" program. The first section illustrates the flow of information through the various functions. These functions are broken down to four levels, with the first level representing the basic interface with the program as a whole and the final level representing the most detailed base process, (student or staff/faculty identification). Within the data flow diagrams, a process listed in black type is not at its final level, where those in red are. The diagrams are successively decomposed until all states have been presented in the final level. The flow of information is depicted with solid black arrows, and notated with a "flagged" text box. The producing and consuming entities are depicted by rectangles, with data flow either emanating from or ending at each entity instance. Any operation resulting in an exception is denoted with a red dashed arrow. A data base, or any similar data repository, is represented with a "shadowed" text box.
      The "Data Flow Diagrams, (DFD)" are delineated in the following manner:
•	Level 0: This level represents the basic interface between user input and system output, with the program being depicted as an entire entity.
•	Level 1: At this level, the program is broken-up into "read input", "verify input", "process input", "error handling" and "Admin. notification". The producing and consuming entities are depicted as well.
•	Level 2: This level is broken into three components; "verify input", "process input", "Admin. notified". It is at this level that some of the final processes begin to manifest themselves.
•	Level 3: This is final level of processes. The two functions that are examined in greater detail are "student verification" and "staff/faculty verification".

                                                              

DATA FLOW DIAGRAMS:

Final level process

Data objects

System information
Producer/consumer

Process

Data repository

Exception data

User input

Database

Web site

Network admin.

URL
Posting plus

User data

Approved URL

URL/ID data

KEY

Read input

Verify input

Process input

Admin. notified

Database

User input

Network admin.

   website

User input

User data

Verified data

URL status

URL data

URL posting

URL/ID status

LEVEL 1 DFD

Error
handling

invalid entries

URL

VERIFY INPUT

URL verified
as new

Read
input

Student
verified

User
input

Staff
verified

Process input

User input

Name/ID

Name/ID

Verified data

Error
handling

Invalid entries

LEVEL 2 DFD

URL's for approval

Verified data

Add URL to web

Add URL to dbase

New URL

New URL

Admin.
notified

database

Network admin

website

Added URL

Approved URL

Added URL

PROCESS INPUT

LEVEL 2 DFD, cont.

Verify working URL

Verify validity and content

URL's for approval

Approved URL'S

Deleting
URL's

Inappropriate
link

404 error

Network admin.

ADMIN. NOTIFIED

LEVEL 3 DFD

ID
verified

Error handling

Process input

Student ID

Student name

Invalid ID

Invlalid name

Name verified

STUDENT VERIFIED

Name/ID

LEVEL 3 DFD, cont.

ID
verified

Error handling

Process input

Staff ID

Staff name

Invalid ID

Invlalid name

Name verified

STAFF/FACULTY VERIFIED

Name/ID

PROCESS SPECIFICATION:

The functions are described below in the following process narratives. Each function is at the base level and the relationship between each is depicted by the Data Flow Diagrams above.

Read input

Level 2 PSPEC: Processing Narrative for Read Input

The "Read Input" process takes all data entered into the data fields. The data to be entered includes; name, type of user, (student or staff), student ID number, staff ID number, URL(s), email and page title or description. When the user has completed filling in the fields, he/she hits the "submit URL" button. The input is then prepared for processing by the CGI script. Any invalid entries are handled in the "verify input" process.

PROCESS SPECIFICATION, cont:

URL 
Verified as new

Level 2 PSPEC: URL verified as new

Once the data has been read in, the URL is checked by the CGI script to verify that it is not a duplicate. No sub-pages are allowed. Each person submitting is allowed three SEPARATE entries. Other processes are responsible for checking a URL's validity and appropriateness. Invalid entries return an error message, and the Administrator is ultimately responsible for checking sites, validity and appropriateness.

See accompanying code

Error handling

Level 2 PSPEC: Error handling

If after three attempts to submit a link the system still rejects a URL, either due to invalid personal information or duplicate listing, the system prints an error message informing the user of the problem and advises them to see the network administrator if they have any questions.  The user's information is then forwarded to the Administrator for potential blocking.

Add URL to web

Level 2 PSPEC: Add URL to web

After the CGI has verified the student/staff identification and the uniqueness and existence of the user's site, the submission is automatically added to the appropriate page, (i.e. faculty, staff or student master link page). Upon completion of a successful submission, the user is emailed of the status.

Add URL to dbase

Level 2 PSPEC: Add URL to database

Upon verification of identification and URL validity, the URL is added to the appropriate database, (i.e. student, staff or faculty). The listing is then added to a back-up database that is kept and maintained in case of system failure.

PROCESS SPECIFICATION, cont:

Verify validity and content

Level 2 PSPEC: Verify validity and content

Once the CGI has validated the entry, it is up to the system administrator to verify that the site has content appropriate to the University and to keep track of the site's existence. This can be done with the aid of the program's survey of the site's keywords. Any site that is deemed inappropriate is removed and the user is notified of the site's removal, and the offending party is warned against any future infractions. 

Verify working URL

Level 2 PSPEC: Verify Working URL

Once the URL has been added, it is the Administrator's responsibility to keep the entries up to date. This includes periodically searching for 404 errors and well as any change in content that may be cause for a site's removal.

Deleting URL's

Level 2 PSPEC: Deleting URL's

Any URL's outdated or inappropriate are deleted from the web posting by the system Administrator. The system maintains the offending URL in its database so that any attempted re-entry can be thwarted.

Student name verified

Level 3 PSPEC: Student name verified

After receiving input, the system will perform a search for the student's name against the school's database. If no match is found, an error message is printed and the error-handling facilities are invoked.

PROCESS SPECIFICATION, cont:

Student number verified

Level 3 PSPEC: Student number verified

Once the data has been entered, the program will use a database query to match the student number. This will add an extra measure of security in the prevention against unwanted URL's. Any invalid entry will result in an error message and the exception-handling procedures will be invoked.

Staff name verified

Level 3 PSPEC: Staff name verified

Like the student entry, if a staff or faculty member wants to list a personal web page, their identity must first be verified. Upon entering the type of user, (student, staff/faculty), the staff of faculty member will be cross-referenced against the school's database by way of the system query.
Any invalid entry will result in an error message and eventually invoke the exception handling.

Staff number verified

Level 3 PSPEC: Staff number verified

Again, like the student entry, any staff of faculty must be thoroughly verified. Any employee of the University must enter their Social Security number so that the system may do a database query. No match will result in error message and eventually exception handling.

Behavioral Model and Description

Description for software behavior:
The following section demonstrates the behavior of the system. This is accomplished by the use of State Transition Diagrams, (STD), Control Flow Diagrams, (CFD), and Process Activation Tables, (PAT). The CFD represents the events and the states they effect, whereas the STD exhibits the overall behavior of the system. It should be noted that the convention for Control Specification, (CSPEC), is taken from Pressman, "Software Engineering: A Practitioner's Approach", (Pressman, 97, page 328).  In this convention, the STD and the PAT are combined to form the CSPEC.
The following events and states are found in the CFD and STD respectively:

EVENTS:						STATES:
Submit, (information submitted for approval)			Waiting State
Query, (information sent to data base for test)			Read input
Query result, (data base search result)				Process input
Process result, (result of ID and URL verification)			Error handling
Exception, (any error or exceptional event)				Post URL
URL's added						Notified Admin.
URL's rejected						Prompt for re-entry
Admin. verification						Verify input
URL accepted						Verify student
Input read						Verify Staff/faculty
Input checked						Verify URL new
Exception
Data passed
Error message

STATE TRANSITION DIAGRAMS:

Transitions  States

Events

Actions 

transition

Transition that occurs only 
after predetermined number 
of multiple events

KEY:

Waiting state

Read input

Process input

Post URL

Notify admin.

Error/exception handling

Invalid entry
Prompt user

"hit" on URL posting site
prompt user

Input entered
Process input

URL processed
Admin. notified

URL/ID invalid
Removal/prevention

URL accepted

Post URL

LEVEL 1 STD

"hit" on URL posting site

prompt user

Input entered

Input checked

Input verified

Student ID check

Input rejected

Prompt for re-entry

Input re-entered

Input re-read

ID verified

URL checked

New URL verified

URL added

New URL verified

Admin notified

New URL verified

URL posted

URL rejected

Prompt for re-entry

Student ID rejected

Prompt for re-entry

Posting completed

Awaiting input

Error message

Admin notified

REPEATED  failed entries

Error/warning message

Read input

Verify student/ staff status

Verify that URL is not already posted

Add URL to database

Wait state

Post URL on website

Verify input

Prompt for re-entry

Error message

Notify administrator

Idle

Awaiting input

URL REMOVED

URL inappropriate/ invalid

URL removed

LEVEL 2 STD, (COMBINED)

LEVEL 3 STD, (COMBINED)

Verify input

Verify student/staff name

Verify student/staff number

Verify that URL is not already posted

Prompt for re-entry

Identity verified

URL checked

Identity rejected

Prompt for re-entry

CONTROL FLOW DIAGRAMS:

Control flow item

process

Data flow, (inactive)

CSPEC  "window"

KEY:

User input

Database

Web site

Network admin.

URL
Posting plus

Posting request submitted

LEVEL 0 CFD

                                                    kcn,inc
                                             "the future of web posting today!"    

exception

Read input

Verify input

Process input

Admin. notified

Database

User input

Network admin.

   website

LEVEL 1 CFD

Error
handling

submit

DATABASE

Process result

query

Query result

Output data

Query result

VERIFY INPUT

URL verified
as new

Read
input

Student
verified

User
input

Staff
verified

Process input

DATABASE

Query

exception

verification

Error
handling

Verification of data

Rejection of data

LEVEL 2 CFD

Network admin

website

Add URL to web

Add URL to dbase

Admin.
notified

database

PROCESS INPUT

verification

completion

LEVEL 2 CFD, cont.

Admin. verify

ADMIN. NOTIFIED

Network admin.

Verify working URL

Verify validity and content

Deleting
URL's

Adding URL's

URL's added 

Rejecting URL's

Admin. verify

Accepting URL's

Input checked

ID
verified

Error handling

Process input

Name verified

STUDENT/STAFF VERIFIED

Input read

exception

verification

Error message

Data passed

LEVEL 3 CFD

PROCESS ACTIVITIES TABLES:

The following decision tables represent the various processes and the events that activate them. These tables, along with the preceding STD, comprise the Control Specification document, (Pressman, 97, page 328).

LEVEL 0  P.A.T.	
Input events
          URL posting request	
1	
Output
          Posted URL	
1	
Process activation
     URL PostingPlus!	
1	

LEVEL 1 P.A.T.	
Input events	
         Submit	1	0	0	0	0	
         Query 	0	1	0	0	0	
         Query result	0	0	1	0	0	
         Process result	0	0	0	1	0	
         Exception	0	0	0	0	1	
Output	
        Output data	1	0	0	0	0	
        Query result	0	1	0	0	0	
        Process result	0	0	1	0	0	
        Exception message	0	0	1	0	1	
Process activation	
        Verify input	1	0	0	0	0	
        Process input	0	1	1	0	0	
       Admin. notified	0	0	0	1	1	
        Error handling	0	0	1	0	1	

LEVEL 2 P.A.T.		
Input events		
       Query result	0	1	0	0	0	0	
       Exception	0	0	1	0	0	0	
       Verification	0	0	0	1	0	0	
       Admin. verify	1	0	0	0	0	0	
        Rejecting URL's	0	0	0	0	0	1	
       Adding URL's	0	0	0	0	1	0	
Output		
        Exception 	0	1	1	0	0	1	
        Verification of data	0	1	0	1	0	0	
        Added URL's	0	0	0	0	1	0	
        Accepting URL's	1	0	0	0	0	0	
        Rejecting URL's	1	0	0	0	0	1	
Process activation		
        Student verified	0	1	0	0	0	0	
        Staff verified	0	1	0	0	0	0	
        URL verified as new	0	1	0	0	0	0	
        Error handling	0	0	1	0	0	1	
        Process input	0	0	0	0	0	0	
        Add URL to web	0	0	0	1	0	0	
        Add URL to database	0	0	0	1	0	0	
        Verify validity/content	0	0	0	0	1	0	
        Verify working URL	0	0	0	0	1	0	
        Deleting URL	1	0	0	0	0	1	

LEVEL 3 P.A.T	
Input events	
     Input read	1	0	0	0	
     Input checked	0	1	0	0	
     Exception	0	0	1	0	
     Verification 	0	0	0	1	
Output 	
     Input checked	1	0	0	0	
     Error messages	0	1	1	0	
     Data passed	0	0	0	1	
Process activation	
     Named verified	1	1	0	0	
     ID verified	1	1	0	0	
     Process input	0	1	0	1	
    Error handling	0	1	1	0	

Performance Issues

	The system has been designed with limited graphics and no Java applets in order to optimize the speed of loading in the users browser. However, the CGI script is a slow process and will take a small amount of time to process a users input; but will not affect the time a browser takes to load the system. Both Unix and Windows NT servers have the built in ability to support CGI scripts with the server of choice being a Unix server. The overall performance issue can be directly related to the CGI script and database query interaction.
	The size of the databases is also a factor, the larger the database the slower the queries will be. The volume of the queries to the databases from other systems will also have an impact on the speed of the system. The database system is shared by multiple numbers of other departments and the system is set up to search all databases until it finds the user. In other words the system has a has a built in error check, if for some reason the user inputs the incorrect unit that they belong to (student, staff, faculty) the system will automatically search the other database for the user. 
Therefore, this built-in redundancy could cost the user time in the short run but save time in the over all picture by preventing a user from having to submit their data 
twice. This is just one example of the system trying to help the user and prevent the user from having to input data multiple times. Another feature of the system that is there only for improved user interface and ease of use is system remembers all inputs. This may cost the system time and space but if the user makes a mistake it will remember all correct entries and mark the incorrect entry in red to make it easier for the user to recognize their mistake. The system will also include a small ditty that helps identify to the user their mistake and the correct way to phrase their input.
The interaction of CGI script, HTML, C++, and database query language also play an important role in performance issues. The different fragments of code must interact in intricate ways and maintain their performance. The number of users on the system at anyone time will also have an effect on the system performance. The more surfers on the University web-server will have a pronounced effect on the system speed. Also the number of users surfing the links page or trying to add links at the same time will also affect the system. Another aspect of performance is the number of users on the surfers ISP; this is not our responsibility but may lead the user to mistakenly think our system is slow.
In a business or ISP setting the above concerns also apply, plus a few others may affect the system. The number of users that have dialed in to the network on the ISP will affect the speed the system works at. If the ISP homepage is busy or has a small bandwidth the overall speed of the system will be decreased. In a large business setting like Ford Motor Company, the system might be slower because the company uses the web extensively in inter-department communications. 

Design Constraints

•	Interaction of the different subsystems.
•	Is the reliability specified including the consequences of software failure, vital information protected from failure, error detection, and recovery?
•	Is maximum memory specified, maximum storage specified?
•	Is the maintainability of the system specified, including the ability to respond to changes in the operating environment, interfaces with other software, accuracy, performance, and additional predicted capabilities?
•	Will the system work on the next generation of hardware and software without major changes to the system.
•	Is each requirement testable?
•	Does it have strong cohesion – doing one and only one thing extremely well?
•	Does it have loose coupling – is the connection to other routines small, intimate, visible, and flexible?
•	Are all interface assumptions testable?
•	Is each input variable needed?

* For the complete list of constraints, risks, and requirements please consult the appendix.

Software Interface Design

	The user interface is simple in design and powerful in concept and performance.  We established links on a majority of the schools main web pages, so that university members and visitors can easily be made aware of the system tools available to them. University members and visitors can use the powerful search tool to search the complete University of Michigan-Dearborn system, the World Wide Web, or search the list of university member homepage links.
	The search tool has multiple capabilities concerning the list of university homepage links page. The user can search for a particular individual, like a professor, student, or staff member. The user can also search for a specific topic, subject, or set of keywords they are interested in and can be found in the homepages. This powerful separation of search capabilities is made possible by the fact that the user can specify how and where they want to search.
	Once a user enters the homepage system they are greeted with a general disclaimer absolving the university of the peculiarity of taste shown by some of the users WebPages. Stating that the web pages in no way express the views and opinions of the university and that comments about the web pages should be directed to the author of the web pages. Once the user/visitors gets the small print out of the way they have multiple options available to them.

External Machine Interfaces

	The system requires access to the student and faculty/staff authentication servers to verify user names and identification numbers. The URL PostingPlus system is a CGI script and will have to be able to interface with the database query language that is used by the database. URL PostingPlus will also have to interface with the web-server system to be able to send emails and update the system administrator user interface along with maintaining the actual HTML files.

External System Interface

	The system is housed on the university web-server or the network server in the case of a business or ISP. The URL PostingPlus is a CGI script that must interact with other CGI scripts, HTML code, database query language, and C++ code. The help files and GUI systems are made up of C++ code. The duplicate link processor, profanity checking system, and server spider system is a CGI script, and the administrator system interface and the web pages themselves are HTML files. 
	All the above listed systems are based on the web-server or business network. The system has to interact with a database query system and the search engine has to interact with HOTBOT’s system. The systems will also have to be connected to the Internet for full functionality. 

Human Interface

	Once the user gets past the above mentioned university policy statement they are presented with a couple of different choices. The user has the choice of doing a search for a particular user or surf the system without the aid of the search engine. If they surf through the system there are four separate ways to find a specific web page. There is a quick surf link with all the names of the users listed in alphabetical order (A B C… Z). all the user has to do is click on a letter and they will be taken to a list of all the names that start with that letter that have web pages in the list.

(A B C D E F G H I J K L M N O P Q R S T U V W X Y Z)

	

Nugent
Nugentski
Nuggent
Nietzsche

Quick Search

The surfer also has the choice of narrowing down their search even further by clicking on a pull down menu. The menu’s break down the students, faculty, and staff into the unit they work for or school that they attend.

  Faculty	  Students	 Staff	
•	Casl	•	Casl	•	Administration	
•	Education	•	Education	•	Maintenance	
•	Management	•	Management	•	CCPD	
•	Engineering	•	Engineering	•	Counselors	
•	CIS	•	CIS	•	Liberians	
		•	Field house	

	For a user who wants to add their link to the page they have to click on the button that says.  They are then taken to a page that has the schools disclaimer on it and prompted to either agree or disagree with the disclaimer. If the user disagrees they are booted from the system back to the Individual Homepage page. Once the user agrees with the disclaimer they are prompted to fill out six fields and make a choice in four separate pull down menu systems. 
The fields are plain and easy to read and fill out (First name, Last Name, School identification number, Email, title of homepage, and URL of their homepage). The pull down menus is a way of defining the type of user they are (Faculty, Staff, Student). The menus delineate where a faculty/staff member works or what school a student attends. The system will either automatically add a faculty member’s link or send a message to the system administrator for student and staff member’s requests.
The system then waits for the system administrator intervention. The system administrator user interface has six buttons and five radio buttons. The radio buttons indicate that the system has a message for the system administrator (email from the system, Error messages, new faculty member added, new links requested, or other messages from the system). The buttons are for the system administrator to take a specific action or control an event. 
•	Verify  Verify there are no duplicate links
•	Sub-page  checks the whole system to ensure there are no sub-page links like www.ajmn.com and www.ajmn.com/images.
•	Verify #  verify that a new user has no more than three separate links to their name.
•	Verify member  verifies that all links belong to a member of the University of Michigan-Dearborn family.
•	Spider  verifies that all links are still good; this includes new links to add and all existing links.
•	Update  adds the requested links to the system and emails the user to notify them as to the status of their links; either has been or has not been added to the system.

Restrictions, Limitations, and Constraints

•	Network system administrator  only one network administrator may use the system at any one time. The opening of a second administrator user interface will cause the system to issue a warning when the second administrator tries to sign in. the system will then boot the second administrator and continue working with the first administrator and send a signal to him or her and inform them that someone else tried to access the system at the same time.
•	User restriction  when the network administrator is updating the system the automated user interface aspects of the system will still be active but proceed at a much slower pace. A warning will be sent to any users at this time to expect small delays while the administrator is processing data. an option will be given to the user to submit their data directly to the administrator and the administrator will do the automated tasks. This is another example of trying to make the user interface friendly and easy to use. However this aspect may slow the system down slightly to make the system friendlier.
•	User restriction  the system will not be able to process a URL that is more than eight levels deep or 50 characters long due to space limitations in memory and on the HTML page itself.
•	User restriction  email address has to be 40 characters or less due to importing restriction and size limitations generated inside the CGI script.
•	User restriction  title of the web page has to be 40 characters or less due to space limitations on the link page itself.
•	Testing client server architectures  performing system tests on as many different system architectures as possible so that the system can be sold to as many companies as possible.
•	Database is busy slowing down queries  during certain times of the year the database system is very busy, like during student registration or during business hours when administration jobs are querying the system repeatedly.
•	Test documents and help facilities  the range, accuracy, source, and frequency of use of the help files. Therefore, creations of a test plan and help facilities for different system is a challenge.
•	Types of servers CGI scripts will run on  will the CGI script work on different server platforms like Unix, Linux, and Windows NT etc. will the performance of the script be impacted by what type of server it is running on effecting other constraints known or unknown.
•	Busy server  max number of surfers on the system at any one time  how many surfers can use the system at the same time without impacting performance.
•	Number of users that can enter new links at the same time  how many surfers can utilize the software at the same time without impacting performance or at the extreme shut the system down.
•	Numbers of people who can use the search engine at the same time  how many surfers can use the search engine without impacting system performance. Can the university system support multiple searches at the same time? 
•	Backing up of the links page  how often does the server back up the files to ensure no loss of data. Does the database of emails belonging to individual users slow the system down or effect performance? Having the system automatically email users when the system crashes or loss of data for re-entry.
•	Interaction of the CGI script, html code, and user interface  how well does all the different types of code interact with each on all the different types of servers and system architectures.
•	Documentations training  during the training of business network administrators can the documentation system be adequately explained and shown how to use, to prevent multiple training sessions. 
•	Combining modules, database query system, HTML code, CGI script, and C++ code  will the system programmers be able to maintain system integrity and performance when they combine all the different types of files and codes on different servers and software packages.
•	Compatibility with existing systems and software  will the CGI script interfere of interact with other CGI scripts are ready in the servers when they are active or inactive.
•	Changes to the source code by universities affecting other system parts  limit the changes or responsibility for changes that others make to the source code.
•	Establishment of a logic based test plan  can a logic based test plan be developed that adequately tests the system logic that covers all the different types of code used in the system? Also can a logic based test plan be developed that covers the different types of servers and different software packages that might be used with the system.
•	Establishment of a data flow test plan  can a adequate test plan be made for all the different database systems that may be encountered. Can the test plan be devised that adequately works with the database query system and a CGI script?
•	Availability of database for testing queries  is the database available for a long enough period to adequately test the data flow between the two systems.
•	Different types of databases that the system has to interact with  can the system work with all the different databases on the market? Is it economical to test the system with all the different databases?
•	Different types of servers that the system has to work on  can the program work efficiently on SGI servers, Sun servers, Intel based servers, Motorola servers, and IBM servers to name a few.
•	Different types of software that is shared by servers that the system has to interact with  does the program work on all the different types of servers available Unix, Linux, Windows NT, and Novell Netware to name a few and can the system be adequately tested on all the different servers.
•	Establishment of a sound black box test plan that covers CGI script, HTML files, C++, user interface files. Is an exhaustive test plan possible?
System Communication pathway

Validation Criteria

Classes of Tests

	Validation, Verification, and Testing (V,V&T) is a process of review, analysis, and testing applied throughout the software development’s life span.  The Validity of the software, which is discussed in this section of the Software Requirements Specification (SRS), is what determines the correctness of the end product or in this case an automatic link editor.  The correctness of this link editor is evaluated with respect to the SRS (Andriole 1986).  Software validation is achieved by way of a series of tests known as “black-box” testing.  One of two possible conditions may follow each validation test: (a) The test was successful and the characteristic which was tested is acceptable and conforms to the SRS, or (b) the test was unsuccessful and deviates from the SRS.  If deviation occurs then a list is formed for these deficiencies.
	In order to test the validity of the software being produced a series of tests called “black-box” tests (as stated above) must be introduced.  The purpose of these tests are to attempt to find errors in the following classes: (1) incorrect or missing functions (2) interface errors (3) errors in data structures or external database access (4) performance errors, and (5) initialization and termination errors.  These tests are used to answer the following questions: How is functional validity tested? What classes of input will make good test cases?, Is the system particularly sensitive to certain input values?, How are the boundaries of a data class isolated?, What data rates and data volume can the system tolerate?, What effect will specific combinations of data have on system operation? The tests that we have devised for this system are as follows:
•	Systems  The systems testing involves a few different tests.  First, End users may link up to three different web pages.  The user may not link the same page more than once.  This includes sub pages within the users main page. For example, if the address of the main page were www.mypage.com then the page www.mypage.com/image would not be allowed as another link on the home page directory.  If the URL’s are completely different, such as, www.mypage.com, www.mywork.com, and www.home.com the individual could publish all three on the appropriate directory.  Second, The individual must be one of three entities on campus.  They must be a student, staff, or faculty member of the university in order to add a link to the directory.  This means that the social security number input by the user must match with one that exists in the university’s database.  If the user does not exist they may try up to two more times (three total) to input the correct information before an error message is sent to alert an administrator.  Then, The content of the web page must adhere to the policies and principles of the university.  This results in a keyword search of the title of the web page.  If any words seeming to deal with pornographic content or profanity are found then the page is rejected and an error code is sent to alert an administrator.  Next, all parts of the system must follow the same protocols or rules.  Since this system uses the Internet the major protocol TCP/IP must be followed.  Also since communication with databases is required any protocols needed with respect to those must be implemented.  Finally, The system as a whole must be tested.  This means that valid web pages submitted by students and staff are sent to the administrator for final approval before being added to the student or staff directory. If a valid faculty member submits a web page it is automatically added to the faculty directory, approval of administrator is not required.  Testing of the complete system also includes making sure that the correct error messages are displayed for their respective errors made. 

•	GUI   There are several ways in which the GUI (Graphical User Interface) may be tested.  Some possible tests are: Is all data content contained within the window properly addressable with a mouse, function keys, directional arrows, and the keyboard? Are all functions that relate to the window available when needed?, Are all relevant pull-down menus, tool bars, scroll bars, dialog boxes, and buttons, icons, and other controls available and properly displayed for the window?,  Is all the information needed from the user accessible from the interface tools?,  Does the window close properly?, Do all tools on the interface serve a function?, Were 	any functions not represented by a tool?, Is the appropriate menu bar displayed in the appropriate context?,  Do interface tools work properly?, Do the cursor, processing indicator, and pointer properly change as different operations are invoked?, Is alphanumeric data entry properly input into the system?, Is invalid data properly recognized? (Pressman 1997)  

*Please see appendix for all GUI tests considered.

•	Documentation and Help  Documentation and help files allow naive users to use the system.  If the documentation and help files of the system are inadequate or non-existent then unexpected and/or unexplained errors can not be diagnosed. Some possible tests include: Does the documentation accurately describe how to accomplish each mode of use? Are examples accurate?,   Are all error codes described within the documentation? (Pressman 1997)  

*Please see appendix for a complete list of the documentation/help tests considered.

•	Data Flow  This system uses HTML, CGI Script, C++, and database query languages (depending on the database being used).  Each component of the system is made from one of the above languages.  For example, the user interfaces (written in HTML) must communicate with the link adder (written in CGI script) in order to insert the users home page link to the directory.  The information 	flowing from one program must be useable by the next. 

Expected Software Responses 

	In order for any test to be of use there must be an expected response.  If the final test response matches the expected test response then the test was successful.  If the final test response does not match the expected test response then the test was unsuccessful.  Using the assumption that all other components of the system are not a factor in the test being accomplished at any given time unless otherwise stated.  The expected responses of the above tests are as follows:
Systems
•	Quantity  (1) If a student/staff member is adding a link and has not added three links or more and the link is not a sub page of an already existing link then the link will be sent to the administrator’s interface for approval.  However, (2) if a student/staff member is adding a link and has already added three links the user will get a message saying that the link is under consideration by the administrator.  (3) If a student/staff member is adding a link to a sub page for an already existing link they will receive an error message saying that they may not add that link.  (4) If a faculty member is adding a link and has not added three links or more and the link is not a sub page of an already existing link then the link will be automatically added to the faculty link directory.  (5) If a faculty member is adding a link and has already added three links they will get a message saying that the link is under consideration by the administrator.  (6) If a faculty member is adding a link to a sub page for an already existing link they will receive an error message saying that they may not add that link.
•	Type  Every individual attempting to add a link to a directory must input their school id/social security number.  This number is checked against the university database to make sure that the individual is one of three entities (student, staff, and faculty). (1) If the individual inputs a valid number their URL is sent to the administrator’s inter-face for approval. (2)If the individual inputs an invalid number the system will prompt them to re-enter it.  If the individual enters an invalid number three times in a row then an error message is sent to the individual and they will be booted back to the home page main page.  The individual will then have to re-enter the system to attempt adding their link again if they so choose.  
•	Content  The title of the web page is checked for content.  This is because the page must adhere to the policies and principles of the University.  (1) If a word pertaining to pornography or profanity is found in the title then an error message 	will be sent to the administrator’s interface it will also inform the individual that this 	error message has been sent.  (2) If the title is found to have no indecent content then the URL will be sent to the administrator’s interface for approval.
•	Protocols  If the correct protocols are not used then the system components will not be able to interface or communicate with each other.  (1) If the protocols are correct then the system will run normally and receive all information needed to add the link or contact the administrator for errors and approval.  (2) If the protocols are not correct for database interfacing then the system may not check database information and an error will be sent to the administrator that the information cannot be obtained.  (3) If the protocols for the Internet are not correct then the links will be unable to be added for faculty and the link cannot be sent to the administrator for approval.  Therefore, the link will not be added to the directory in either case.  An error message will also tell the individual that there was an error in sending the information and to try again at a later time. 
•	System  (1) If all conditions are met with valid responses then the link will b sent to the administrator for approval if the link is for a student/staff member.  (2) If the link is for a faculty member and all conditions are met then the link will simply be 	added to the faculty directory.  (3) If not, for both faculty and student/staff member then the appropriate error message will be displayed meaning that all possible errors have been acknowledged and system will not crash. 

GUI’s
•	Window  (1) All data contained within the window is able to be addressed by the mouse, function keys, directional arrows, and the keyboard.  (2) All functions 	within the window are available as needed.  (3) Proper display of pull-down 	menus, tool bars, scroll bars, dialog boxes, buttons, icons, and other controls are in 	the window.  (4) All information needed from the user is accessible from the 	interface tools.  (5) The window can be closed. (6) The above responses can be combined as a whole for the GUI window.  If any are unmet then the GUI window is unsuccessful and must be corrected.   
•	Tools  (1) Any menu bars displayed are displayed in the appropriate context.  (2) All tools displayed work properly.  (3) All tools on the interface do have an associated function.  (4) The cursor, processing indicator, and pointer properly change as different operations are invoked.  (5) The above responses can be combined as a whole for the GUI tools.  If any are unmet then the GUI tools are unsuccessful and must be corrected.
•	Data Entry  (1) Alphanumeric data entry is properly input into the system.  (2) Invalid data is properly recognized.  (3) The above responses can be combined as a whole for the GUI data entry.  If any are unmet then the GUI data entry is unsuccessful and must be corrected.
Documentation and Help
(1)	Documentation accomplishes an accurate description for each mode of use. 
(2) Examples are accurate.
(3) Error codes are accurately described.
Data Flow
 (1) The HTML interface must be able to interface with a database query language in order to check the appropriate information.  If so, then the user will receive the appropriate response as to whether the system accepted their id or not.  
(2) Information flowing from the HTML interfaces must be readable by CGI script.  If so, then the link will be added to the appropriate link directory.  		

Performance Bounds

	Any system is subject to limitations due to extenuating circumstances beyond the control of the system itself.  These limitations can be a minor inconvenience or a major 
setback to the user and system.  These bounds may be:
•	If multiple users are trying to add a link at the same time, this could cause the system to be slow.
•	The number of users surfing the University of Michigan’s web site is directly proportional to the time to access the URL Posting Plus System.  So as the number of surfers increase so does the time to access the system.
•	The number of individuals using the search capabilities on the system can affect the performance of the system.  As the number of users using the search capabilities increases the system slows down.
•	If data base is being queried at the same time this could slow down the system
•	If the database is a considerable size this could affect the querying time.
•	The type of browser being used.  For example, Netscape versus Internet Explorer.
•	The type of network being used. For example, UNIX versus Windows NT versus NetWare.
•	The Internet service provider that the individual is using may be a contributing factor to the speed of the system.

Testing Criteria 

GUI

1.	Will the window open properly based on related typed or menu-based commands?
2.	Can the window be resized, moved, and scrolled?
3.	Is all data content contained within the window properly addressable with a mouse, function keys, directional arrows, and keyboard?
4.	Does the window properly regenerate when it is overwritten and then recalled?
5.	Are all functions that relate to the window available when needed?
6.	Are all functions that relate to the window operational?
7.	Are all relevant pull-down menus, tool bars, scroll bars, dialog boxes, and buttons, icons, and other controls available and properly displayed for the window?
8.	When multiple windows are displayed, is the name of the window properly represented?
9.	Is the active window properly highlighted?
10.	If multitasking is used, are all the windows updated at appropriate times?
11.	Do multiple or incorrect mouse picks within the window cause unexpected side effects?
12.	Are audio and/or color prompts within the window or as a consequence of window operations presented according to specification?
13.	Does the window properly close?
14.	Is the appropriate menu bar displayed in the appropriate context?
15.	Does the application menu bar display system related features?
16.	Do pull-down operatons work properly?
17.	Do breakaway menus, palettes, and tool bars work properly?
18.	Are all menu functions  and pull-down subfunctions  properly listed?
19.	Are all menu functions properly addressable by the mouse?
20.	Is the text typeface, size, and format correct?
21.	Is it possible to invoke each menu function using its alternative text-based command?
22.	Are menu functions highlighted based on the context of current operations within a window?
23.	Does each menu function perform as advertised?
24.	Are the names of menu functions self-explanatory?
25.	Is help available for each menu item, and is it context sensitive?
26.	Are the mouse operations properly recognized in context?
27.	If the mouse has multiple buttons, are they properly recognized in context?
28.	Do the cursor, processing indicator, and pointer properly change as different operations are invoked?
29.	Is alphanumeric data entry properly echoed and input to the system?
30.	Do graphical modes of data entry work properly?
31.	Is invalid data properly recognized?
32.	Are data input messages intelligible?

Testing documentation and help

1.	Does the documentation accurately describe how to accomplish each mode of use?
2.	Is the description of each interaction sequence accurate?
3.	Are examples accurate?
4.	Are terminology, menu descriptions, and systems responses consistent with the actual program?
5.	Is it relatively easy to locate guidance within the documentation?
6.	Can troubleshooting be accomplished easily with the documentation?
7.	Are the document table of contents and index accurate and complete?
8.	Is the design of the document conducive to understanding and quick assimilation of information?
9.	Are all error messages displayed for the user described in more detail in the document?
10.	 If hypertext links are used, are they accurate and complete?  

Requirements

•	Are all the inputs to the system specified including their source, accuracy, range of values, and frequency? 
•	Are all the outputs from the system specified including their destination, accuracy, range of values, frequency, and format? 
•	Are all the report formats specified? 
•	Are all the external hardware and software interfaces specified? 
•	Are all the communication interfaces specified including handshaking, error checking, and communication protocols? 
•	Is the expected response time, from the user's point of view, specified for all necessary operations? 
•	Are other timing considerations specified, such as processing time, data transfer, and system throughput? 
•	Are all the tasks the user wants to perform specified? 
•	Does each task specify the data used in the task and data resulting from the task? 
•	Is the level of security specified? 
•	Is the reliability specified including the consequences of software failure, vital information protected from failure, error detection, and recovery? 
•	Are acceptable tradeoffs between competing attributes specified, for example, between robustness and correctness? 
•	Is maximum memory specified? 
•	Is the maximum storage specified? 
•	Is the definition of success included? Of failure? 
•	Is the maintainability of the system specified, including the ability to respond to changes in the operating environment, interfaces with other software, accuracy, performance, and additional predicted capabilities? 
•	Where information isn't available before development begins, are the areas of incompleteness specified? 
•	Are the requirements complete in the sense that if a product satisfies every requirement, it will be acceptable? 
•	Are you uneasy about any part of the requirements? Are some parts impossible to implement and included just to please your customer or boss? 
•	Are the requirements written in user language? Do the users think so? 
•	Do all the requirements avoid conflicts with other requirements? 
•	Do the requirements avoid specifying the design? 
•	Are the requirements at a fairly consistent level? Should any requirement be specified in more detail? Should any requirement be specified in less detail? 
•	Are the requirements clear enough to be turned over to an independent group for implementation and still be understood? 
•	Is each item relevant to the problem and its solution? Can each item be traced to its origin in the problem environment? 
•	Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied? 
•	Are all possible changes to the requirements specified including the likelihood of each change? 

Quality Assurance Program
•	Have you identified specific quality characteristics that are important to your project? 
•	Have you made others aware of the project's priorities? 
•	Have you differentiated between internal and external quality characteristics? 
•	Have you thought about the ways in which some characteristics may compete with or complement others? 
•	Does your program use several different error-detection techniques suited to finding several different kinds of errors? 
•	Does your program take steps to assure software quality during each stage of software development? 
•	Is the quality measured in some way so that you can tell whether it's is improving or degrading? 
•	Does management understand that quality assurance incurs additional costs up front in order to save costs later? 

High Quality Routines
•	Is the reason for creating the routine sufficient? 
•	Have all parts of the routine that would benefit from being put into routines of their own been put into routines of their own? 
•	Is the name a strong, clear verb-object name for a procedure or an object name for a function? 
•	Does the name describe everything the routine does? 
•	Does it have strong cohesion—doing one and only one thing extremely well? 
•	Does it have loose coupling—is the connection to other routines small, intimate, visible, and flexible? 
•	Is the length of the routine determined naturally by its function and logic, rather than artificially by a coding standard? 
•	Are assertions used to document assumptions? 
•	Does the routine protect itself from bad input data? 
•	Does the routine handle bad data gracefully? 
•	Is the routine designed to handle changes gracefully? 
•	Have debugging aids been installed in a way that they can be activated or deactivated without a great deal of fuss? 
•	Have errors been fire walled so they don't affect code outside the routine? 
•	Does the routine check function return values? 
•	Is the defensive code that's left in production code designed to help the user rather than the programmer? 
•	Do the formal and actual parameters match? 
•	Are the routine's parameters in a sensible order, including matching the order of similar routines? 
•	Are interface assumptions documented? 
•	Does the routine have seven or fewer parameters? 
•	Are only the parts of structured variables that are needed passed to the routine, rather than the whole variable? 
•	Is each input parameter used? 
•	Is each output parameter used? 
•	If the routine is a function, does it return a value under all possible circumstances? 
•	Does the module have a central purpose? 
•	Is the module organized around a common set of data? 
•	Does the module offer a cohesive set of services? 
•	Are the module's services complete enough so that other modules don't have to meddle with its internal data? 
•	Is the module independent of other modules? Is it loosely coupled? 
•	Does the module hide implementation details from other modules? 
•	Are the module's interfaces abstract enough so that you don't have to think about how its services are implemented? Can you treat it as a black box? 
•	Have you thought about subdividing the module into component modules and subdivided it as much as you can? 
•	If you're working in a language that doesn't fully support modules, have you implemented programming conventions that support them? 
Effective inspections
•	Do you have checklists that focus reviewers attention on areas that have been problems in the past? 
•	Is the emphasis on defect detection rather than correction? 
•	Are inspectors given enough time to prepare before the inspection meeting and is each one prepared? 
•	Does each participant have a distinct role to play? 
•	Does the meeting move at a productive rate? 
•	Is the meeting limited to 2 hours? 
•	Has the moderator received specific training in conducting inspections? 
•	Is data about error types collected at each inspection so that you can tailor future checklists to your specific organization? 
•	Is data about preparation and inspection rates collected so that you can optimize future preparation and inspections? 
•	Are the action items assigned at each inspection followed up, either personally by the moderator or with a re-inspection? 
•	Does management understand why it should not attend inspection meetings? 

Test Cases
•	Does each requirement that applies to the routine have its own test case? 
•	Does each design element that applies to the routine have its own test case? 
•	Has each line of code been tested with at least one test case? Has this been verified by computing the minimum number of tests necessary to exercise each line of code? 
•	Have all Defined-Used data-flow paths been tested with at least one test case? 
•	Has the code been checked for data-flow patterns that are unlikely to be correct, such as Defined-Defined, Defined-Exited, and Defined-Killed? 
•	Has a list of common errors been used to write test cases to detect errors that have been common in the past? 
•	Have all simple boundaries been tested--maximum, minimum, and off-by-one boundaries? 
•	Have compound boundaries been tested, that is, combinations of input data that might result in a computed variable that's too small or too large? 
•	Do test cases check for the wrong kind of data, for example, a negative number of employees in a payroll program? 
•	Are representative, middle-of-the-road values tested? 
•	Is the minimum normal configuration tested? 
•	Is the maximum normal configuration tested? 
•	Is compatibility with old data tested? And are old hardware, versions of the operating system, interfaces with other software tested? 
•	Do the test cases make hand-checks easy? 

Project risks 

Schedule creation
•	Schedule, resources, and product definition have all been dictated by the customer or upper management and are not in balance 
•	Schedule is optimistic, "best case," rather than realistic, "expected case" 
•	Schedule omits necessary tasks 
•	Schedule was based on the use of specific team members, but those team members were not available 
•	Cannot build a product of the size specified in the time allocated 
•	Product is larger than estimated (in lines of code, function points, or percentage of previous project’s size) 
•	Effort is greater than estimated (per line of code, function point, module, etc.) 
•	Re-estimation in response to schedule slips is overly optimistic or ignores project history 
•	Excessive schedule pressure reduces productivity 
•	Target date is moved up with no corresponding adjustment to the product scope or available resources 
•	A delay in one task causes cascading delays in dependent tasks 
•	Unfamiliar areas of the product take more time than expected to design and implement 

Organization and management
•	Project lacks an effective top-management sponsor 
•	Project languishes too long in fuzzy front end 
•	Layoffs and cutbacks reduce team’s capacity 
•	Management or marketing insists on technical decisions that lengthen the schedule 
•	Inefficient team structure reduces productivity 
•	Management review/decision cycle is slower than expected 
•	Budget cuts upset project plans 
•	Are the best people available
•	Do the people have the right kind of skills
•	Are enough people available
•	Are staff committed for the duration
•	Will some staff be working part-time
•	Do staff have the right expectations about the job at hand
•	Has the staff received the necessary training
•	Will staff turnover be low enough to allow continuity
•	Management makes decisions that reduce the development team’s motivation 
•	Non-technical third-party tasks take longer than expected (budget approval, equipment purchase approval, legal reviews, security clearances, etc.) 
•	Planning is too poor to support the desired development speed 
•	Project plans are abandoned under pressure, resulting in chaotic, inefficient development 
•	Management places more emphasis on heroics than accurate status reporting, which undercuts its ability to detect and correct problems 

•	Facilities are not available on time 
•	Facilities are available but inadequate (e.g., no phones, network wiring, furniture, office supplies, etc.) 
•	Facilities are crowded, noisy, or disruptive 
•	Development tools are not in place by the desired time 
•	Development tools do not work as expected; developers need time to create workarounds or to switch to new tools 
•	Development tools are not chosen based on their technical merits, and do not provide the planned productivity 
•	Is a software project management tool available
•	Is a software process management tool available
•	Are tools for analysis and design available 
•	Do analysis and design tools deliver methods that are appropriate for the project to be built
•	Are compilers or code generators available and appropriate for the product to be built
•	Are software configuration management tools available
•	Does the environment make use of a database or repository
•	Are all software tools integrated with each other
•	Have members of the project team received training in each of the tools
•	Are local experts available to answer questions about the tools
•	Is on-line help and documentation for the tools available

End users
•	End-user insists on new requirements 
•	End-user ultimately finds product to be unsatisfactory, requiring redesign and rework 
•	End-user does not buy into the project and consequently does not provide needed support 
•	End-user input is not solicited, so product ultimately fails to meet user expectations and must be reworked 
•	Customer insists on new requirements 
•	Customer review/decision cycles for plans, prototypes, and specifications are slower than expected 
•	Customer will not participate in review cycles for plans, prototypes, and specifications or is incapable of doing so—resulting in unstable requirements and time-consuming changes 
•	Customer communication time (e.g., time to answer requirements-clarification questions) is slower than expected 
•	Customer insists on technical decisions that lengthen the schedule 
•	Customer micro-manages the development process, resulting in slower progress than planned 
•	Customer-furnished components are a poor match for the product under development, resulting in extra design and integration work 
•	Customer-furnished components are poor quality, resulting in extra testing, design, and integration work and in extra customer-relationship management 
•	Customer-mandated support tools and environments are incompatible, have poor performance, or have inadequate functionality, resulting in reduced productivity 
•	Customer will not accept the software as delivered even though it meets all specifications 
•	Customer has expectations for development speed that developers cannot meet
•	Have you worked with the customer in the past
•	Does the customer have a solid idea of what is required
•	Will the customer agree to spend time in formal requirements gathering meetings to identify project scope
•	Is the customer willing to participate in reviews
•	Is the customer technically sophisticated in the product area
•	Is the customer willing to let your people do their job – that is will the customer resist looking over your shoulder and make changes as you go
•	Does the customer understand the software process

Contractors
•	Contractor does not deliver components when promised 
•	Contractor delivers components of unacceptably low quality, and time must be added to improve quality 
•	Contractor does not buy into the project and consequently does not provide the level of performance needed 
•	Requirements have been baselined but continue to change 
•	Requirements are poorly defined, and further definition expands the scope of the project 
•	Additional requirements are added 
•	Vaguely specified areas of the product are more time-consuming than expected 
•	Error-prone modules require more testing, design, and implementation work than expected 
•	Unacceptably low quality requires more testing, design, and implementation work to correct than expected 
•	Development of the wrong software functions requires redesign and implementation 
•	Development of the wrong user interface results in redesign and implementation 
•	Development of extra software functions that are not required (gold-plating) extends the schedule 
•	Meeting product’s size or speed constraints requires more time than expected, including time for redesign and reimplementation 
•	Strict requirements for compatibility with existing system require more testing, design, and implementation than expected 
•	Requirements for interfacing with other systems, other complex systems, or other systems that are not under the team’s control result in unforeseen design, implementation, and testing 
•	Pushing the computer science state-of-the-art in one or more areas lengthens the schedule unpredictably 
•	Requirement to operate under multiple operating systems takes longer to satisfy than expected 
•	Operation in an unfamiliar or unproved software environment causes unforeseen problems 
•	Operation in an unfamiliar or unproved hardware environment causes unforeseen problems 
•	Development of a kind of component that is brand new to the organization takes longer than expected 
•	Dependency on a technology that is still under development lengthens the schedule 
•	Estimated size of the product in LOC or FP
•	Degree of confidence in estimated size estimate
•	Estimates size of product in number of programs, files, transactions
•	Percentage deviation in size of product from average for previous products
•	Size of data base created or used by the product
•	Number of users of the product
•	Number of projected changes to the requirements for the product before delivery after delivery
•	Amount of reused software
•	Effect of this product on company revenue
•	Visibility of this product to senior management
•	Reasonableness of delivery deadline
•	Number of customers who will use this product and the consistency of their needs relative to the product
•	Number of other products/systems with which this product must be interoperable
•	Sophistication of end users
•	Amount and quality of product documentation that must be produced and delivered to the customer
•	Governmental constraints on the construction of the product
•	Costs associated with late delivery
•	Costs associated with a defective product
•	Product depends on government regulations, which change unexpectedly 
•	Product depends on draft technical standards, which change unexpectedly 
•	Is the technology to be built new to your organization
•	Do the customers requirements demand the creation of new algorithms or input and output technology
•	Does the software with new or unproven hardware
•	Does the software interface with vender supplied software
•	Does the software interface with unproven database technology
•	Is a specialized user interface demanded by product requirements
•	Do requirements for the product demand the creation of program components that are unlike any previously developed by your organization
•	Do requirements demand the use of new analysis, design, or testing methods
•	Do requirements demand the use of unconventional software development methods
•	Do requirements put excessive performance constraints on the product
•	Is the customer uncertain that the functionality requested is doable

•	Hiring takes longer than expected 
•	Task prerequisites (e.g., training, completion of other projects, acquisition of work permit) cannot be completed on time 
•	Poor relationships between developers and management slow decision making and follow through 
•	Team members do not buy into the project and consequently does not provide the level of performance needed 
•	Low motivation and morale reduce productivity 
•	Lack of needed specialization increases defects and rework 
•	Personnel need extra time to learn unfamiliar software tools or environment 
•	Personnel need extra time to learn unfamiliar hardware environment 
•	Personnel need extra time to learn unfamiliar programming language 
•	Contract personnel leave before project is complete 
•	Permanent employees leave before project is complete 
•	New development personnel are added late in the project, and additional training and communications overhead reduces existing team members’ effectiveness 
•	Team members do not work together efficiently 
•	Conflicts between team members result in poor communication, poor designs, interface errors, and extra rework 
•	Problem team members are not removed from the team, damaging overall team motivation 
•	The personnel most qualified to work on the project are not available for the project 
•	The personnel most qualified to work on the project are available for the project but are not used for political or other reasons 
•	Personnel with critical skills needed for the project cannot be found 
•	Key personnel are available only part time 
•	Not enough personnel are available for the project 
•	People’s assignments do not match their strengths 
•	Personnel work slower than expected 
•	Sabotage by project management results in inefficient scheduling and ineffective planning 
•	Sabotage by technical personnel results in lost work or poor quality and requires rework 
•	Overly simple design fails to address major issues and leads to redesign and reimplementation 
•	Overly complicated design requires unnecessary and unproductive implementation overhead 
•	Inappropriate design leads to redesign and reimplementation 
•	Use of unfamiliar methodology results in extra training time and in rework to fix first-time misuses of the methodology 
•	Product is implemented in a low level language (e.g., assembler), and productivity is lower than expected 
•	Necessary functionality cannot be implemented using the selected code or class libraries; developers must switch to new libraries or custom-build the necessary functionality 
•	Code or class libraries have poor quality, causing extra testing, defect correction, and rework 
•	Schedule savings from productivity enhancing tools are overestimated 
•	Components developed separately cannot be integrated easily, requiring redesign and rework 
•	Amount of paperwork results in slower progress than expected 
•	Inaccurate progress tracking results in not knowing the project is behind schedule until late in the project 
•	Upstream quality-assurance activities are shortchanged, resulting in time-consuming rework downstream 
•	Inaccurate quality tracking results in not knowing about quality problems that affect the schedule until late in the project 
•	Too little formality (lack of adherence to software policies and standards) results in miscommunications, quality problems, and rework 
•	Too much formality (bureaucratic adherence to software policies and standards) results in unnecessary, time-consuming overhead 
•	Management-level progress reporting takes more developer time than expected 
•	Half-hearted risk management fails to detect major project risks 
•	Software project risk management takes more time than expected 
•	Does senior management support a written policy statement that emphasizes the importance of a standard process for software development
•	Has your organization developed a written description of the software process to be use on this project
•	Are staff members “signed up” to the software process as it is documented and willing to use it
•	Is the software process used for other projects
•	Has your organization developed or acquired a series of software engineering training courses for managers and technical staff
•	Are published software engineering standards provided for every software developer and software manager
•	Have documentation outlines and examples been developed for all deliverables defined as part of the software process
•	Are formal technical reviews of the requirements specification, design, and code conducted regularly
•	Are formal technical reviews of test procedures and test cases conducted regularly
•	Are the results of formal reviews documented, including errors found and resources used
•	Is there some mechanism for ensuring that work conducted on a project conforms with software engineering standards
•	Is configuration management used to maintain consistency among system software requirements, design, code, and test cases
•	Is a mechanism used for controlling changes to customer requirements that impact the software
•	Is there a documented statement of work, a software requirements specification and a software development for each subcontract
•	Is a procedure followed for tracking and reviewing the performance of subcontractors
•	Are facilitated application specification techniques used to aid in communication between the customer and developer
•	Are specific methods used for software analysis
•	Do you use a specific method for data and architectural design
•	Is more than 90 percent of your code written in a high order language
•	Are specific conventions for code documentation defined and used
•	Do you use specific methods for test case design
•	Are software tools used to support planning and tracking activities
•	Are configuration management software tools used to control and track change activity throughout the software process
•	Are software tools used to support the software analysis and design process
•	Are tools used to create software prototypes
•	Are software tools used to support the testing process
•	Are software tools used to support the production and management of documentation
•	Are quality metrics collected for all software projects
•	Are productivity metrics collected for all software projects

Note: the main sources of risks came from Pressman 1997 and construx.com see reference sheet for more detail

Bibliography

 Andriole, Stephen J., Software Validation,verification,testing, and documentation, Petrocelli Books,inc., 	1986
Firesmith, Donald G. and Eykholt, Edward M., Dictionary of Object Technology, SIGS Books, Inc., 1995
Lefkovits, Henry C., Data Dictionary Systems, Q.E.D. Information Sciences, Inc., 1978