As promised in my last post, the topic for this article will continue the discussion on using GENESYS to develop your specification in a truly model-based fashion. In the last post, I started with a description of the standard GENESYS spec template, the sections included in it, and began a more detailed look at each section. In this post, we will continue that detailed look at more sections in our GENESYS generated specification. Understanding the relationships and attributes that are used to build a specification is such important and fundamental knowledge for doing good MBSE.
In my last post I left off with describing the functional capability section of the specification. A specification is all about specifying the needs of the procuring organization, therefore the capability section of a specification is probably one of the most important sections in the specification. Yet often it’s overlooked or downplayed, so before we move on – don’t do that! Realize how important the capability, or functional section of the specification is. Realize how the functional requirement statements should flow from your functional model, how they should flow in lock step with your behavioral flows modeled in GENESYS. If you take away anything from this series of posts, realize that there is a better way to develop your specifications, a truly model based approach!
External Interfaces
Alright, to get down to the purpose of this post, let’s explore the next couple of sections that come after the functional capability section. After the functional requirements comes the external interface portion of the specification. This section looks at your systems links and creates sections that correspond to each interface between your system component (remember specs are written to specify the procurement of a component), and other external systems.
The external interface section will pull the interface diagrams that encapsulate the component your specification is reporting and place them in the report. It then goes on to build a table view that depicts which links connect to which components. After the interface table, it will go through your model and output the descriptions of your links, reporting on any requirements that are specifying your link. So, be sure to fill in your descriptions!
Finally, for each link the report is processing in the external interface section, the specification report will build a table of the items that are being transferred by the external links. This table will show the name, number, description (fill them in!) and other attributes of the Item. This repeats for every link that’s connected between the specification’s component and external components.
Internal Interfaces
After the external interface section, the specification moves on to outputting internal interface information. I’d like to point out that for some organizations this section can be somewhat controversial, as there is definitely some overlap over what can go here in the system specification, and what belongs in an Interface Requirements Document (IRD). If your organization prefers to put this information into a separate IRD document, then by all means this section can be removed from your specification. If the choice is made not to output this section, keep the Section title in the specification. This will aid in keeping the flow of the sections aligned with the template. In that case, simply mark the section N/A.
The internal interface follows the same pattern as the external interface section. The report looks at interfaces between components that are children of the reported-on component. Once those interfaces are found, their descriptions and any requirements linked to the interface are output. Next, a table of the internal interfaces, links and their interfacing components is output.
Once the internal interface is produced, the report will look at the links that comprise the interface, and output them in their own sections including their usual suspects – description, direction (if specified), specified requirements and finally a table of items similar to what was in the external interface section. A section is output for each link.
Internal Data Requirements
Next up we have a section that details the internal data requirements in our specification. Any ideas where in the GENESYS database that information may come from? Items that flow on those internal links perhaps? If that’s what you’re thinking, then youare right! The items that flow across the internal links form the basis of this section. Each item is output to a section containing the item’s description and any requirements that specify the item.
Keep in mind that GENESYS will descend the decomposition of the items that are on the internal links and make a section for every child of an item that’s being transferred by the link. This is a place where, if you were keeping your item’s decompositions in lock step with your functional decomposition, you’ll get a cleaner output here. That way the leveling will be more consistent.
Categorized Requirements (Constraints)
After the internal interface section, but still inside the overall requirements section, comes the section I call the “Constraints” section. This section outputs all the requirements that fall into the specification categories laid out in the constraint specification format. There are 17 different categories that requirements that constrain the physical design can be categorized into. It’s a simple matter in GENESYS to categorize the requirements and get the report to place in the appropriate category.
The report will query and return all the requirements that specify the component directly, and the requirement is “categorized by” a predefined category entity in the database. The category entity names must align with the section headers for the categorized requirement section. The returned requirements are then placed in the appropriate section. The categories are as follows:
3.6 Adaptation Requirements
3.7 Safety Requirements
3.8 Security and Privacy Requirements
3.9 System Environment Requirements
3.10 Computer Resource Requirements
3.10.1 Computer Hardware Requirements
3.10.2 Computer Hardware Resource Utilization Requirements
3.10.3 Computer Software Requirements
3.10.4 Computer Communications requirements
3.11 System Quality Factors
3.12 Design Construction Constraints
3.13 Personnel-Related Requirements
3.14 Training-Related Requirements
3.15 Logistics-Related Requirements
3.16 Other Requirements
3.17 Packaging Requirements
While the report does not check for the type of the requirement to be set to constraint, it’s a best practice to set the type attribute to constraint for everything to be categorized. If the requirement isn’t a constraint, then it’s probably functional or performance and should be part of your behavior model.
Conclusion
In this post I’ve mainly covered the interface sections of the specification, but I also covered the categorized requirements (the constraints!). In my next installment we’ll cover the qualification section (AKA Verification), the Requirements Traceability Matrix, and the inclusion of the behavior diagrams to aid in understanding the requirements in your spec. I hope that following the relations between the pieces of information that represent a variety of concepts in the architecture model and showing how the report follows them and extracts the information into a specification document has been helpful so far! Until next time…
