RSML(ID:7788/)

Hardware requirements DT language 

Requirements state machine language


Related languages
RSML => Tablewise   Influence
References:
  • Jaffe, M. S., Leveson, N. G., Heimdahl, M. P. E., And Melhart, B. E. Software requirements analysis for real-time process control systems. IEEE Trans. Softw. Eng. SE-17, 3 (Mar 1991), pp241–258. view details
  • Leveson, N. G. ; M. P. E. Heimdahl, H. Hildreth, and Reese, J. D. Requirements specification for process control systems. IEEE Transactions on Software Engineering, 20(9):684-707, Sept. 1994 view details
  • Heimdahl, M. P. E. And Leveson, N. "Completeness and consistency analysis of statebased requirements" in Proceedings of the 17th International Conference on Software Engineering (ICSE ’95) (Seattle, Wash., Apr.). ACM, New York, 3–14. 1995 view details
  • Heitmeyer, Constance L.; Jeffords, Ralph D.; Labaw, Bruce G. "Automated Consistency Checking of Requirements Specifications" ACM Transactions on Software Engineering and Methodology July 1996 view details Extract: RSML
    RSML
    The Requirements State Machine Language (RSML) [Heimdahl and Leveson 1995; Jaffe et al. 1991; Leveson et al. 1994], which was developed to describe real-time process control systems, uses a combination of graphical and tabular notations. RSML’s graphical notation (e.g., its superstates and AND-decomposition) is largely borrowed from Statecharts [Harel 1987]. Additional features of RSML include directed one-to-one communication among high-level state machines and the introduction of AND/OR tables to describe the guards on state transitions. Each table in RSML describes the conditions under which a given state machine can make a transition from one state to a second state under a specific input event. An output event may be associated with each table. The format of RSML tables resembles the format of Table X, except (as in Tablewise) conditions label the rows of the table rather than the columns. Also, in contrast to Table X, different conditions need not be disjoint; events do not appear as table entries; and modes (that is, modes defined explicitly as functions of input variables) are not used.
    A prototype tool has been developed for checking RSML specifications for “completeness” (i.e., every possible input event and the system’s response to the event must be stated explicitly) and “consistency” (i.e., no input event can cause a transition to two different system states). The tool, which has been applied to large portions of the requirements specification of TCAS II, a collision avoidance system for commercial aircraft, detected errors not caught by an extensive manual review.