Stimulus response requirements specification notation, an empirically evaluated requirements specification notation
Bibliographic record
Abstract
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.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.039 | 0.129 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.002 | 0.002 |
| Science and technology studies | 0.001 | 0.002 |
| Scholarly communication | 0.004 | 0.005 |
| Open science | 0.003 | 0.002 |
| Research integrity | 0.001 | 0.002 |
| Insufficient payload (model declined to judge) | 0.006 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".