Basic ReqIF Concepts
A ReqIF model is a structured collection of natural language requirements. However, it comes with its own terminology. For instance, a "Requirement" is called "SpecObject" in ReqIF:
A ReqIF model has some similarities to a Excel Spreadsheet, although there are some notable differences. It's simply meant as a starting point to get a feel for ReqIF.
The following table compares a Spreadsheet model with a ReqIF model, introduces the terminology and explains it:
|ReqIF Term (RIF Term)||Excel Analog||Traditional RM&E Term||Description|
|Specification (SpecHierarchyRoot)||Sheet||Document||A ReqIF model consists of an arbitrary number of Specifications. The Specification is the "Container" for the Requirements. Think of an Excel Document, that allows you to create an arbitrary number of Sheets. There are two differences to Excel: (1) The requirements in the Specification are references (which means that the same requirement can appear in multiple places); (2) The content of Specification is hierarchical.|
|SpecObject||Row||Requirement||A SpecObject represents the actual Requirement. A requirement typically has a number Attributes. Again compared with Excel, each row in a Sheet represents a requirement. In contrast to Excel, the ReqIF model may contain SpecObjects that do not appear in any Specification (whether this is useful is a different question).|
|Attribute||Cell||Attribute||Besides the actual text of the requirement, typical Attributes include ID, Status, etc. Note that there are no "standard" Attributes. The ReqIF model contains the definitions of the Attributes. Here the Excel analogy starts to break down. In Excel, each row has the same columns. Different SpecObjects may have different sets of Attributes.|
|SpecObjectType (SpecType)||n/a||Requirements Type||Each SpecObject has a SpecObjectType. The SpecObjectType contains a list of Attributes for the SpecObject. For instance, the SpecObjecType "Headline" may have only one Attribute "HeadlineText". Another SpecObjectType "Requirement" may have three Attributes, "ID", "Description" and "Status". A Specification may then contain a mixture of SpecObjects with different types.|
There are many more concepts, but this is enough to get us started.
Let's look at a concrete example to understand this. Here is a sniplet of a Specification:
The table shows the first four SpecObects, as visualized in a Specification. The tree-like structure is recognizable: INF-1 is a node with three children, REQ-1, REQ-2 and REQ-3 (this can be seen by the indentation). Let's look at INF-1 and REQ-1. If they would be selected in the GUI, the Property pane would show their Attributes, as it is shown to the right.
INF-1 has two attributes, "Description" and "ID". The SpecObjectType is "Information Type" (shown as the root in the properties view).
REQ-1 has three attributes, "Description", "ID" and "Status". The SpecObjectType is callse "Requirements Type". Let's have a closer look at that one.
The "Requirements Type" SpecObjectType is shown in the picture, with arrows indicating how the Attributes relate to the SpecObjectType (a simple one-to-one relationship). A SpecObjectType has one entry for each Attribute, consisting of a name and a Datatype. For instance, the first entry has the name "ID" and the datatype "T_ID_REQ". Note that multiple Attributes may have the same Datatype: "Description" and "Status" both have the Datatype "String32k".
Last, The Datatypes must be defined as well. In this example, there are two Datatypes, "String32" and "T_ID_REQ". These are finally based on a number of standard types that ReqIF supports.
NOTE: As of this writing, we only implemented the simple and the enumeration ReqIF types. This leaves out the complex ones (rich text, attachements, embedded files, etc.) for now.