MSIT-SE Practicum Railroad Configuration Rule Checker

Carnegie Mellon University CMU-MSIT-SE-RC2-SRS Master of Software Engineering MSIT-SE Practicum: Railroad Configuration Rule Checker Software Requirement Specification Version 0.1 Sep

Carnegie Mellon University CMU-MSIT-SE-RC2-SRS

Master of Software Engineering

MSIT-SE Practicum:

Railroad Configuration Rule Checker

Software Requirement Specification

Version 0.1

September 30, 2003

Revision History

The following signatures are required for approval of this document. 

_ _ Yong Hoon Choi (Engineer) Date

_ _ Gregg Beardsly (Client) Date

_ _ Greg Matoka (Client) Date

Table of Contents

1 ACRONYMS 6

2 INTRODUCTION 7

2.1 PURPOSE 7

2.2 SCOPE 7

2.3 AUDIENCE 7

2.4 REFERENCE 7

3 REQUIREMENTS 8

3.1 PRODUCT PERSPECTIVE 8

3.2 USER CLASSES AND CHARACTERISTICS 8

3.2.1 User Classes 8

3.2.2 Characteristics 8

3.3 OPERATING ENVIRONMENT 8

3.4 DESIGN AND IMPLEMENTATION CONSTRAINTS/ASSUMPTIONS 8

3.5 FUNCTIONAL REQUIREMENTS 9

3.5.1 For the text-based application 9

3.5.2 For the GUI-based application (optional) 9

3.6 NONFUNCTIONAL REQUIREMENTS 10

3.6.1 Reliability 10

3.6.2 Usability 10

3.6.3 Modifiability 10

3.6.4 Performance 10

3.6.5 Extensibility 10

3.7 USER DOCUMENTATION 10

3.7.1 Installation Guide 10

3.7.2 Language Description for Railroad Configuration Rules 10

3.7.3 User Manual 10

4 VALIDATION CRITERIA 11

5 Licensing Requirements 11

1 Acronyms

MSIT-SE Master Science in Information Technology – Software Engineering

2 Introduction

The project is one of the degree requirements for the Master of Science in Information

Technology - Software Engineering (MSIT-SE) program at Carnegie Mellon University The purpose of the project is to deliver the Railroad Configuration Rule Checker software satisfying the client’s requirements

2.1 Purpose

The purpose of this document is to describe in a specific way “what” the system should do This includes:

 Specific functionality (features)

 Constraints

 System qualities

In addition, the document shall accomplish the following goals:

 Establish the basis for agreement between the client and the MSIT-SE staff on what the software products shall do

 Reduce the development effort

 Provide a baseline for verification and validation

 Server as a basis for enhancement

2.2 Scope

The scope of this document is strictly limited to the requirements of the project It does not in any way suggest any particular design or method of software development Sufficient details are included to facilitate design of the system, and allow for validation of the deliverables

2.3 Audience

This document is written primarily for the MSIT-SE student (software engineer), the clients, and the mentors

2.4 Reference

 The SRS of the Charlatan team from MSE 2002-2003

 830-1993, IEEE Recommended Practice for Software Requirements Specifications

 The SPMP for the Railroad Configuration Rule Checker project

3 Requirements

3.1 Product Perspective

The rule checker software will examine the updated tabling file with the configuration rules and report the checking result on the screen or in a log file The baseline software system will be a command-line and stand-alone Java application with the following inputs/outputs:

 Inputs

o A tabling file which contains the railroad configuration information

o A configuration rule file which includes configuration rules expected to be observed and exception rules that provide some allowable situation even with the relevant configuration rules

 Outputs

o “OK” message which represents the correctness of the tabling file or

o Violated rules and the locations which are against the rules

o Process time

3.2 User Classes and Characteristics

3.2.1 User Classes

 Technicians who edit the tabling files

 Test engineers who proofread the tabling files

3.2.2 Characteristics

 The users are experts in the railroad configurations and their rules

 The users are beginners in the Unix operating system

 The users are intermediate users in the Microsoft Windows operating system

 The users are not familiar with formal logics

3.3 Operating Environment

 Hardware: Intel Pentium

 Operating System: Unix, Microsoft Windows

 X Windows System: Hummingbird Ltd Exceed

 Virtual Machine: Java 2 Run-Time Environment SE (Standard Edition) version 1.4.1

 Site: Union Switch & Signal, Inc

3.4 Design and Implementation Constraints/Assumptions

 The baseline system will be a text-based and stand-alone application

 The Graphic User Interface (GUI) for the software system will be considered necessarily with the capability to edit the tabling files and the configuration rule files

 The system doesn’t support any remote file access It means that all files the system deals with must be local It would be possible, however, to access remote files using other distributed file systems

3.5 Functional Requirements

3.5.1 For the text-based application

The baseline software will be a text-based, command-line, and stand-alone application It will have the following functionalities:

 Set the tabling file to be verified

 Set the configuration rule file to be used for the rule checking

 Check the configuration rules

o Syntactic checking for the tabling file

o Syntactic checking for the configuration rule file

o Semantic checking

 Display the result on the screen

o Display the line number of the VAX command which is syntactically violated

o Display the pairs of the rule violated and the line number of the VAX command which is against the rule

o Display the elapsed time for checking

 Save the result on the log file

o Save the pairs of the rule violated and the line number of the VAX command which is against the rule

o Set the file name for the log file

3.5.2 For the GUI-based application (optional)

The GUI-based application will provide an integrated environment for editing the tabling file and the configuration rule file, verifying the correctness of the configuration information, and display the checking result It will have the following functionalities

 Tabling file manipulation

o Open the tabling file

o Edit the tabling file

o Save the tabling file

 Configuration rule file manipulation

o Open the configuration rule file

o Display the elapsed time for checking

 Save the result on the log file

o Save the pairs of the rule violated and the line number of the VAX command which is against the rule

o Set the file name for the log file

3.6 Nonfunctional Requirements

3.6.1 Reliability

Since the system itself is a verifier, reliability is the most important issue The formal methods for describing the railroad configuration and its rules are required

3.6.2 Usability

The product itself should be easy to use because the purpose of the product is to facilitate the current process of the railroad configuration update In addition, the language for describing the configuration rules should be simple and easy to learn even without any expertise of formal logics The error reporting must be easy to understand when the software finds some defects in the tabling file

3.6.3 Modifiability

The railroad configuration is very dynamic and the configuration rules constantly keep changing Some modification on the language for the configuration rules will be unavoidable when a new configuration rule, which cannot be properly expressed in the language, comes up Such

modifications should be able to be done without any substantial effort

3.6.4 Performance

The process time for checking rules should be bounded by 10 seconds If the process time is not bounded to 3 seconds, the progress status should be displayed for users to ensure that the system works correctly

3.6.5 Extensibility

The system must be extensible to include new functions and application programs for future needs

3.7 User Documentation

3.7.1 Installation Guide

Installation Guide will instruct users on how to install the tool The Readme file should include

“what’s new in this release” and the known bugs It should also describe the compatibility to previous versions of the tool

3.7.2 Language Description for Railroad Configuration Rules

The language description will contain syntax/semantics definitions The complete grammar of the language will be listed in the format of a Backus-Naur Form (BNF) For better understanding, the document will provide some examples representing major use-cases

3.7.3 User Manual

The purpose of user manual is to describe, in detail, how the software works It also should provide an index and glossary of common vocabulary

4 Validation Criteria

The software must be tested against the SRS to confirm that they satisfy all the requirements A detailed validation process must be defined for the purpose

5 Licensing Requirements

The software development may use any tool, language and any source code available on the Internet Use of any third party source code should not require the publishing of the developed application source code in any manner, nor prohibit or require end-user licensing or runtime fees