Hatley-Pirbhai method for functional specifications and requirements representations

The book: https://www.amazon.com/Strategies-Real-Time-System-Specification-Hatley/dp/0932633110

 

1. Functional specifications

The function specifications interact with each other in the manner shown in the overall data flow diagram (DFD). The requirements within each function are allocated to each module by “superbubbles ” in the overall data flow diagram. See also DFD: https://blog.csdn.net/jackjones_008/article/details/80493569

Each function specification contains three elements: Feature Behavior Summary, Context diagram, and a Feature Behavior Detail. The Feature Behavior Summary cites the purpose of the function, the Context diagram depicts the overall I/O of the function, and the Feature Behavior Detail, details the requirements allocated to the function. The process Specifications are a set of numbered and indentured English statements, a decision table, and/or state transition Diagrams (STD's).

The requirements in this specification are partitioned into processes with data flowing between them. This Partitioning is represented in the data flow diagrams. Each process is represented by a bubble. Data flows are Represented by arrows, with the direction indicating the direction of the flow of information. Within each process, the required functionality is described in the form of text, decision tables, and state transition diagrams, and/or state transition tables.

To show by representation the difference between volatile memory and non-volatile memory data storage symbols.
The non-volatile memory data storage symbol representation is 2 horizontal lines, one line above and one line below the non-volatile dataflow name. The volatile memory data storage is represented by 2 horizontal bars with solid / filled boxes at the end of each line, one line above and one line below the volatile dataflow name.

2. Requirements representations

Within each process, the required functionality is described in the form of text, decision tables, state transition diagrams and/or state transition tables.
Decision tables show combinational logic where Inputs are on the left side of the table and Outputs are on the right side of the table. A double vertical line separates inputs and Outputs. Each row has a unique number to allow reference to that particular requirement.

State transition diagrams and state transition tables contain four key elements: states, transitions, events, and actions. States represent a known condition with the model. Transitions represent the interaction of the states.
Events represent the conditions, which must be true for a transition to be taken. Actions represent the operations that must be accomplished when a transition is taken. State diagrams use the following conventions: States are represented by rectangles. Arrows represent transitions. The symbols _, ->, and => mean “transitions to” and represent an event occurring at a specific point in time. The events and actions for a transition are in text with the events listed before a "/" and the actions following the "/". For example:

The unique requirement ID given in the headline of any requirement follows the requirement throughout the development process. The requirement ID format follows a well-defined syntax.
All identifiers in an ECU Functional Spec shall be composed of 4 parts:
• A leading prefix, which indicates the type of requirement (R=Requirement, UC=Use Case, SC=Scenario, …)
• A prefix, which indicates the abstraction level (F=Feature, FNC=Function, CMP = component).
• Followed by a name, indicating the scope, which the requirement belongs to (e.g. feature or function name )
• Ending with the actual requirement number, i.e. R_FNC_xxxxx_00001