WWW-Based Software Engineering:
Requirements Monitoring

Introduction

The Summer'97 WWW-Based Software Engineering reading project will focus on the theory and implementation of requirements monitoring. Requirements monitoring is a technique which tracks the run-time behavior of a system to notice when it deviates from its design-time specification. Requirements monitoring is useful in the following contexts:

Complex requirements or domain
It is too difficult to prove all system properties, so assumptions are made as part of the requirements definition process. These assumptions are monitored at run-time. Should the assumptions fail, a predefined procedure is invoked (e.g., notification to the designer). Note, such monitoring is different from exception handling in that it: (1) considers the combined behavior of events occurring in multiple threads or processes, (2) links run-time behavior with the actual design-time requirements, (3) provides sufficient information to allow for the run-time reconfiguration of software or software components.
Flexible requirements
Some requirements are best stated in terms of the ideal behavior along with a recovery action to be followed when the ideal behavior is not met. For example, consider a project tracking database with entities: Project, and ProjectLeader. The organization specifies that there should be a one-to-one relationship between Project and ProjectLeader. However, this relationship can be broken for short periods of time; for example, a project may be defined, but a leader should be assigned within a month, once assigned a leader, no project should be without a leader for more than a week. Using a requirements monitor, this can be specified as a 1:N relation between Project, and ProjectLeader with an associated monitor for the time periods in which the 1:N constraint is allowed to be optional. Using a monitor in this case, rather than allowing an optional relation in all cases, simplifies the database design and captures the true intent of the relationship.

Other examples of requirements monitoring include: monitoring a system's environment for changes which require a known upgrade (e.g., adding licenses to a server licensing model), or monitoring interactive processes, such as workflow or software process models, for compliance.

Requirements monitoring was originally proposed by Fickas and Feather, mainly to monitor environmental assumption in order to allow the dynamic reconfiguration or redesign of component software. Finkelstein has since illustrated how the technique may be used to monitor process compliance; for example, organizational compliance to ISO 9000 or IEEE process descriptions. However, only Feather has actually constructed a working prototype.

Feather's system, called FLEA, allows one to define interesting events in a requirements monitoring language. The implemented system captures interesting events as assertions in a database. (An external system must actually insert the assertions into the database.) When a monitored condition occurs, its defined action is executed. An AP5 database provides for triggered actions. Thus, monitoring mainly consists of the translation of higher-level requirements monitoring descriptions to AP5 triggered actions.

Course Objectives

The objective of this course are:

To understand and further develop the theory of requirements monitoring
To gain software engineering skills useful in the design and construction of WWW software
To create a working prototype demonstration of requirements monitoring

Course Activities

In this course, the student will engage in the following activities, in roughly the order listed:

Reading and discuss articles on requirements monitoring
Define an scenario concerning the use of HyperDealMaker which would be interesting to monitor (e.g., compliance to IEEE or ISO requirements processes)
Design and build a working prototype which supports the above defined scenario. This will consist of:
Modification of HyperDealMaker to support the scenario (input)
Definition of ConceptBase triggered actions to provide monitoring for the defined scenario
Modification of HyperDealMaker to provide for alerts or other actions that arise from the requirements monitor
Run the scenario and describe implications for requirements monitoring
Document the working prototype

Course Theory and Technology

In addition to supervision of the project, the instructor will provide the following theory and technology to support the student course activities:

Requirements monitoring papers
Electronic discussions with the authors of requirements monitoring: Fickas, Feather, and Finkelstein.
User accounts
HyperDealMaker and HyperNews installation, source, and documentation
ConceptBase installation and documentation
HTML, Perl/CGI, and ConceptBase tools and guidance
Project guidance, redirection

Student Evaluation

To fulfill the five (5) credits associated with this Directed Reading (CIS 838), the student will complete the above defined activities within one quarter. Each week the instructor and student will agree upon score for the previous week. At the end of the quarter, the weekly scores will be aggregated. To receive an 'A', the student must complete each of the above activities and average a 90 percent score throughout the quarter; each ten percent drop will result in a lower letter grade.

To complete these tasks, the student may receive substantial help from the instructor or other outside sources; however, it is the responsibility of the student to complete the final deliverables.

Terms

HyperNews is WWW-based discussion software produced by NCSA
ConceptBase is an object-oriented database produced by Aachen University
DealMaker and HyperDealMaker are WWW-based prototype produced at GSU/CIS to facilitate the collaboration agent or individuals in tasks such as: requirements negotiation and contract negotiations.