Stimulus response requirements specification notation: An empirically evaluated requirements specification notation

This research has focussed on the development of a formal requirements specification notation that is suitable for the specification of large scale systems with complex data and logical requirements. Examples of such systems include air traffic control systems and automated on-line library systems. The motivation for defining the stimulus response requirements specification (SRRS) notation is to provide a notation that is readable (like natural language) and yet at the same time is amenable to automated tool support. Automated tool support such as parsers, typecheckers, analysis tools, and translators are extremely valuable in the effort to make the requirements specification phase of software development better, faster, and cheaper. The quality of the requirements specification may be improved as authors use the tool support to identify and remove defects in the specification before a peer review. The improvement in the quality of the specifications allows a peer inspection to take place in less time. The improvement in quality and the reduced inspection time means that the requirements specifications cost less to create. Additional quality, time, and cost improvements may be made by automating the generation of test specifications for the system level testing phase in the software development lifecycle.; The SRRS notation is evaluated in a controlled experiment to determine the costs and benefits of using the notation with its tool support in comparison to a similar, semi-formal notation. The experimental results show a significant reduction in defects detected in a peer review (81%) and a significant reduction in the amount of time to write, review, and correct a specification (39%). The costs include an increase in the training time: the subjects need two days of training, however, instead of one day.; The problem of defining a requirements specification notation that is suitable for describing systems with intricate data and logical conditions is complex. The decomposition of the problem led to a divide and conquer approach that solves the problem. The result is a set of two notations. The first notation (SRRS) is tailored for specifying requirements. The second notation is a core, or foundation, notation that is tailored to manage the data and logical condition complexity. The second notation is called the data specification (DSPEC) notation. As a core notation, DSPEC may be re-used with other notations that are well suited for other phases of the lifecycle. For example, a system level test specification notation could be defined that re-used the DSPEC notation.; The process of developing the formal SRRS notation is also presented in this work. The process begins with a notation that is currently being used at Raytheon Canada Systems Ltd. called Thread-Capability. The notation is evaluated and updated to create the semi-formal SRRS. The semi-formal notation is evaluated in industry in a case study and the notation is formalized by defining it syntax and semantics. A generalized process for formalizing an existing notation is included so that the work may be re-used.