An Automobile Example Using the SysML Basic Feature Set
Sanford Friedenthal , ... Rick Steiner , in A Practical Guide to SysML (Third Edition), 2015
4.3.2 Capturing the Automobile Specification in a Requirement Diagram
The requirement diagram for the Automobile System is shown in Figure 4.2. The upper left of the diagram shows req to indicate its kind as a requirement diagram and displays the diagram name as Automobile System Requirements. The diagram header also indicates that the diagram frame corresponds to a Package.
FIGURE 4.2. Requirement diagram showing the system requirements contained in the Automobile Specification.
The diagram presents the requirements that are typically captured in a text specification. The requirements are shown in a containment hierarchy to represent their parent–child relationships. The line with the crosshairs symbol at the top denotes containment. The Automobile Specification is the top-level requirement that contains the other requirements.
The Automobile Specification contains requirements for Passenger and Baggage Load, Vehicle Performance, Riding Comfort, Emissions, Fuel Efficiency, Production Cost, Reliability, and Occupant Safety. The Vehicle Performance requirement contains requirements for Maximum Acceleration, Top Speed, Braking Distance, and Turning Radius. Each requirement includes a unique identification and the text of the requirement, and can also include other user-defined properties that are typically associated with requirements, such as verification status and risk. The text for the Maximum Acceleration requirement is "The vehicle shall accelerate from 0 to 60 mph in less than 8 seconds under specified conditions" and the text for the Fuel Efficiency requirement is "The vehicle shall achieve a minimum of 25 miles per gallon under specified driving conditions."
The requirements may have been created in the SysML modeling tool or, alternatively, in a requirements management tool or a text document and imported into the model. Once captured in the model, the requirements can be related to other requirements, design elements, analysis, and test cases using derive, satisfy, verify, refine, trace, and copy relationships. These relationships can be used to establish requirements traceability to ensure requirements are satisfied and verified, and to manage change to the requirements and design. Some relationships are highlighted in Section 4.3.18.
Requirements can be presented using multiple display options to view the requirements, their properties, and their relationships. A tabular presentation is one display option. Chapter 13 provides a detailed description of how requirements are modeled in SysML, and Chapter 17, Section 17.3.7, gives additional guidance for modeling requirements.
Philippe Desfray , Gilbert Raymond , in Modeling Enterprise Architecture with TOGAF, 2014
Description of the artifact
The requirement diagram presented here is based on the SysMLb standard.
•
Requirement
•
Goal
•
Interaction component
•
Use case
•
Breaks a requirement down into more elementary requirements.
•
Describes the manner in which a model element or a set of model elements can be used to refine a requirement.
•
Determines that a model element is used to satisfy a requirement by supporting the requested function or by responding to the formulated constraint. Very often an application component satisfies a requirement.
•
Defines the manner in which a test case (which can be a use case) verifies a requirement. For example, a use case can express test sequences, which check whether or not a requirement is satisfied.
Requirements can be presented in graphical form. Here, requirement modeling enables requirements to be positioned and several types of links to be defined between requirements and the rest of the model. Requirements often appear in architecture models, to remind us which requirements refer to which represented model elements. Matrices can be used instead of diagrams.
These links between requirements and the architecture model are used to measure:
•
Whether or not each requirement is satisfied by at least a part of the system
•
Whether or not at least one test case is planned for each requirement
•
Which model elements satisfy no requirements
Thus, requirements are justified through their links to goals, and the model itself is justified through its links to requirements. Moreover, requirements enable us to closely monitor how well the model respects the specifications.
In Figure 7.5, the "IS access via website" requirement guarantees the "Reservation via the Internet" goal. It is satisfied by the "TripReservationSite" component, and will be verified by the "Reserve trip" and "Cancel trip" use cases.
Figure 7.5. Example of a requirement diagram with different types of links.
Bruce Powel Douglass Ph.D. , in Agile Systems Engineering, 2016
3.2.4 Requirement Diagram
A requirement diagram is a diagram meant to show sets of requirements and their relations. SysML added the new Requirement stereotype and new kinds of relationship «contain», «refine», «satisfy», «allocate», and «verify». I use requirement diagrams sparingly but I do put requirements on other diagrams quite a bit. For example, I commonly create a use case diagram with a single use case surrounded by requirements allocated to it (see Figure 2.4 in the previous chapter).
Figure 3.7 shows a typical requirement diagram. The relationship with the circular crosshairs is the «contain» relation, and provides a means of decomposing abstract requirements into more concrete parts.12 The requirement at the crosshairs logically contains the requirement at the other end of the relation. Two other relations are also depicted. The «derive» relation points towards from the base requirement towards the derived requirement and the «trace» relation is just a navigable traceability relation.
Figure 3.7. Requirement diagram.
Requirements diagrams depict relations among requirements but this is, relatively speaking, of little concern. The requirements themselves are the things of importance. For the most part, requirements are best shown in a requirements table, such as that shown in Figure 3.8. Even if you use requirement diagrams as a data entry mechanism, in my experience, you will spend more time visualizing them in tabular format generated from the data so entered.
Figure 3.8. Requirement table.
A problem I see in the application of SysML in engineering organizations is too much attention to decomposing relations among requirements and too little focus on ensuring the requirements themselves are correct. My recommendation is only to add relations to requirements when it helps clarify, understand, or verify the requirements. Don't add relations just because they're in the toolbox.
Modeling Text-Based Requirements and Their Relationship to Design
Sanford Friedenthal , ... Rick Steiner , in A Practical Guide to SysML (Third Edition), 2015
13.2 Requirement Diagram
Requirements captured in SysML can be depicted on a requirement diagram, which is particularly useful in graphically depicting hierarchies of specifications or requirements. Because this diagram can depict large numbers of relationships for a single requirement, it is useful in representing the traceability of a single requirement to examine how that requirement is satisfied, verified, and refined, and to examine its derived relationships with other requirements. The requirement diagram header is depicted as follows:
req [model element kind] model element name [diagram name]
The requirement diagram can represent a package or a requirement, as designated by the model element kind in square brackets. The model element name is the name of the package or requirement that sets the context for the diagram, and the diagram name is user defined and often describes the purpose of the diagram. Figure 13.1 presents an example of a requirement diagram that contains some of the most common symbols.
FIGURE 13.1. Generic example of a requirement diagram.
This example highlights a number of different requirements relationships and alternative notations. For example, Camera satisfies the requirement called Sensor Decision. In addition to the satisfy relationship, the figure also includes examples of containment, the deriveReqt, and the verify relationship. The relationships are depicted using a combination of the direct notation, compartment notation, and callout notation. Only one of these notations is typically used for a particular relationship. The relationships and notation options are discussed later in this chapter. Tables A.25 through A.27Table A.25Table A.26Table A.27 in the Appendix contain a complete description of the SysML notation for requirements.
A requirement can be shown directly on block definition diagrams, package diagrams, and use case diagrams, along with its relationships to other model elements on the diagram. However, a requirement cannot be shown directly on other diagram kinds, such as internal block diagrams. For all diagram kinds, the relationships between a requirement and the other model elements can be represented using compartment and/or callout notations (see Sections 13.5.2 and 13.5.3 for examples). Alternative ways to view requirements are discussed in Section 13.7 (tabular views) and Section 13.9.1 (browser view).
Bruce Powel Douglass Ph.D. , in Agile Systems Engineering, 2016
4.5.3 Visualizing Requirements
There are a number of ways to visualize there requirements. Certainly, a requirements diagram (see Figure 3.7 from the previous chapter) is one way, particularly when you want to depict the relations among requirements.
A requirements table is a good summary view of the requirements. A partial example for an aircraft surface control system is shown in Figure 4.9.
Figure 4.9. Requirements table.
Another useful view of requirements is to put them on other diagrams to show the allocation of requirements. Such a use case diagram for the same aircraft Manage Control Surfaces system (that interacts with the aircraft's Attitude Management and Pilot Display systems) is shown in Figure 4.10.
Figure 4.10. Use case requirements allocation.
This diagram not only shows the allocation, it also supports traceability, as the relations are navigable and searchable links. Of course, the traceability of the requirements to various elements can be summarized in matrix form as well, as shown in Figure 4.11.
Bruce Powel Douglass Ph.D. , in Agile Systems Engineering, 2016
7.4 Allocate System Requirements to Subsystems
Once we've got an architecture, we can start allocating requirements to it. For some requirements, that means nothing more than a simple allocation and SysML provides a relation just for that. For others, multiple subsystems must collaborate in some way to realize the requirement, and that means that requirement must be decomposed into derived requirements that can be allocated to a single subsystem. There may also be some "cross-cutting requirements" that apply equally to many subsystem (such as "Coding must be done in MISRA C" or "The system must comply with The Electronic Product Radiation Control Provisions of the FDA 21 CFR 1020.33"). Since we're doing an incremental, iterative approach, we'll do requirements allocation on a relatively small number of requirements at a time. However, as the architecture evolves, we'll need to revisit past allocations to make sure that the allocations still make sense.
Why do this? It is important for the subsystem teams to know, clearly and completely, what is expected of the subsystems they are tasked to create. To do this they need four basic types of information: the properties their subsystem is required to have (static, dynamic, and dependability), the architectural framework into which their subsystem must fit, the interfaces they must provide to others, and the interfaces they can rely on from others. The first item we normally think of as requirements and the last three are aspects of what we normally consider architecture (sometimes known as design requirements or what DO-178 refers to as "low-level requirements" [6]).
The most common way to represent this information is in a requirement x subsystem table, but it can also be done graphically on requirements diagrams, by annotating requirements in a requirements database, or even by creating separate requirements databases for each subsystem. What is important is to have traceability so that:
•
from the subsystem perspective, the team can easily identify all their requirements while not being burdened with the requirements for all the other subsystems
•
from a system perspective, the lead engineer can ensure that all requirements are allocated
•
from a test perspective, the testing team can identify what they need to test and where it is allocated
•
from a dependability perspective, the impact the architecture and allocation decisions have on the safety, reliability, and security of the system.
Sanford Friedenthal , ... Rick Steiner , in A Practical Guide to SysML (Third Edition), 2015
3.7 Questions
1.
What are five aspects of a system that SysML can represent?
2.
What is a package diagram used for?
3.
What is a requirement diagram used for?
4.
What is an activity diagram used for?
5.
What is the block definition diagram used for?
6.
What is an internal block diagram used for?
7.
What is a parametric diagram used for?
8.
What are some of the common elements of the user interface of a typical SysML modeling tool?
9.
Which part of the user interface presents a hierarchical view of the model elements contained in the model?
10.
What is the purpose of applying an MBSE method?
11.
What are the primary activities of the simplified MBSE method?
Discussion Topics
What are some factors that contribute to the challenges of learning SysML and MBSE, and how do they relate to the general challenges of learning systems engineering?
0 Response to "How To Draw Requirement Diagram"
Post a Comment