Customization of SysML Requirement Types
When you need to record system requirements, both functional and non-functional, requirement modeling will be helpful. Through requirement modeling, requirements are recorded and presented visually as boxes, with a name that summarize the requirement and a set of attributes that define the requirement. The default requirement 'box' allows specifying general attributes like ID, source, kind, verify method, risk and status. You may, however, define your own requirement types that contain attributes related to your domain.
| April 8, 2010 | |
User Rating:
/ 5
|
|
| Views: 4,779 | |
|
PDF
Link
Link: |
Add comments |
| Edition: Standard or above (Edition comparison) | |
- Start VP-UML in a new workspace.
- Create a new project by selecting File > New Project from the main menu. Name the project as My System.
-
We are going to record the requirements of two screens of a system - The registration screen and the login screen. Create two requirement diagrams for them. To create a requirement diagram, right click on Requirement Diagram in Diagram Navigator and select New Requirement Diagram from the popup menu. Name the diagram in the box at the top left corner of diagram.
We shall create two diagrams with names: The registration screen and The login screen. Stay at diagram The registration screen.
- On the left hand side of the diagram you can see the diagram toolbar, where you can pickup a tool like a Requirement, a Model or a Test Case and click on the diagram to create a shape. Normally you will make use of the Requirement tool to create requirements. But in this tutorial, we are going to define our own types first. Select Tools > Configure Requirements from the main menu.
-
The Configure Requirements dialog box appear, with the default requirement type requirement listing there. We need to create two types of requirement:
Type Description User Interface A type of requirement which consists of properties about a screen design. Checking A type of requirement which consists of rules for validating input and the proper response to bad input. - Create type User Interface first. Click Add at the bottom left of dialog box. In the Name field, enter User Interface.
-
What makes the type User Interface meaningful is its unique attributes (i.e. properties). For type User Interface, the following attributes are needed:
Attribute Description description A description of the screen being documented. screen-id A unique and internal value for identifying the screen being documented. allow-reset Determine whether there is a Reset button for clearing fields on the screen. allow-cancel Determine whether there is a Cancel button to close the screen without proceeding.
We need to define those properties above. Click Add at the right hand side of the dialog box and select Text Attribute from the popup menu. - Enter description as name.
- Follow the previous steps to add text attribute screen-id.
- Now comes the third attribute allow-reset. We expect that this is an enumeration attribute which enables the selection Yes or No. Click Add and select Enumeration Attribute from the popup menu. Click on Edit Enumeration... below the attribute list.
- In the Edit Enumeration dialog box, click Add and enter Yes. Click Add again and enter No. This specify the two possible values, Yes or No, for this attribute. Click OK to go back to requirement configuration.
- With similar steps, create enumeration attribute allow-cancel with possible values - Yes and No (same as what we have done in previous steps for allow-reset).
- The four attributes are all defined. Besides defining requirement attributes, we can define the formatting attributes for fill, line and font styles. Let's try a different fill color. Click the ... button for Fill.
- In the Format Fill dialog box, select yellow and click OK.
-
This ends the configuration of type User Interface. Follow step 6 to add another requirement type Checking. Here is a list of attributes:
Attribute Description description A description of checking needed to perform policy Determine the action to take when a bad input is detected upon checking. We may allow user to try again, or just cancel the action immediately. allowed-attempts The number of attempt user can make. -
Follow step 7 and 8 to define attribute description. To define enumeration attribute policy, click Add and select Enumeration Value from the popup menu. Click Edit Enumeration.... In the Edit Enumeration dialog box, add the following values:
Value cancel action for invalid entry allow re-try - In most checking, we allow user to try again. Therefore, select allow re-try and check Default value at the bottom. Click OK to go back to requirement configuration.
- Now comes the final attribute - allowed attempts. It is an attribute that requires a numeric input. Therefore, click Add and select Integer Attribute. Enter allowed attempts as name.
- Requirement types are configured. Click OK to go back to diagram.
- We can now create requirements with defined types. In the diagram toolbar, expand the tool Requirement and select User Interface.
- Click on diagram to create a requirement. Name it as Register Form. You got a requirement like this:
- Double click on the attribute description and enter Provide a page for user registration as description. Similarly, double click on screen-id and enter UI-001.
- Remember allow-reset and allow-cancel are enumeration attribute? Double click on allow-reset, you can see that the value is restricted to either Yes or No, as defined. Select Yes.
- Same for attribute allow-cancel. Choose Yes.
- Now, make use of type Checking to specify a requirement for validating form input. Expand User Interface in diagram toolbar and select Checking. Click on diagram to create a requirement. Name it as Email Validation.
- Double click on attribute description and enter When submit, check and warn for bad email address. Example : address with '@' sign as description.
- It is fine to let user re-enter the correct email address. Therefore, just keep the policy as allow re-try. Leave allowed-attempts empty to indicate that there is no restriction on the number of attempts.
-
Open diagram The login screen. Create the following requirements by following the step 20 to 27.
<<User Interface>> Login Screen description Provide a page for login screen-id UI-002 allow-reset No allow-cancel Yes <<Checking>> Empty Field Checking description When submit, warn if either or both user name and password fields are empty. policy allow re-try allowed-attempts <<Checking>> Login Checking description When submit, verify and disallow invalid login. policy cancel action for invalid entry allowed-attempts
Finally, you should have a diagram like this:
Rate this Article
Click on one of the stars below to rate this article from 1 (lowest) to 5 (highest).
Comments (0)