OORT's - Horizontal Reading
v3.2
Reading 6 -- Sequence Diagrams x Requirements and Use–Cases
Goal: To verify that the Sequence Diagrams associated with a use–case, describes a set of objects and actors that work together by exchanging messages to implement the capability defined by the use–case, and that the use–cases satisfy all the requirements.
Inputs:
1. 2. 3. The set of functional and level–of–service requirements for the system. The set of Use–Case Diagrams and Use–Case Descriptions from the Behavior Model. The Sequence Diagrams associated with each use–case.
Process:
A. Verify that all functional and level–of–service requirements are well defined. INPUTS: OUTPUTS: 1. Functional and Level–of–Service Requirements from System and Software Requirements Definition (SSRD). Discrepancy reports.
For each functional and level–of–service requirement in the SSRD, verify that the Name and description of the requirement are a meaningful, and that the description is Measurable, Achievable, Relevant, and Specific (M.A.R.S.). Add a discrepancy to the Discrepancy Report Form if based on your development experience, you determine that the name is not meaningful or that the description does not satisfy the M.A.R.S. criteria.
B. Verify that each use–case is related to appropriate functional requirement and level–of–service requirements. INPUTS: Functional and Level–of–Service Requirements from System and Software Requirements Definition (SSRD); Use–Case Model (including both diagrams and descriptions). Discrepancy reports.
OUTPUTS:
For each Use–Case Description, 1. For each functional and level–of–service requirements that are listed in the Requirements field of the description, find the requirement in the SSRD. If found, write the use–case’s id next to the functional or level–of–service requirement, and mark the requirement’s representation in the Requirement field with a star using a colored pen. Add a discrepancy to the Discrepancy Report Form if 2. A functional or level–of–service requirement is listed in the Requirements field that is not listed in the SSRD (possible incorrect fact). No functional requirements are listed in the Requirements field of the Use–Case Description (possible omission).
Evaluate the appropriateness of the relations. Add a discrepancy to the Discrepancy Report Form if A requirement is listed by a use–case that in your judgment is unrelated (possible incorrect fact). A requirement is not listed by a use–case that in your judgment is should be related (possible omission).
UMCP/ESEG http://www.cs.umd.edu/projects/SoftEng/ESEG/
Page 1
GHT/FS/JC
OORT's - Horizontal Reading
v3.2
C. Verify that all functional and level–of–service requirements are satisfied by related use–cases. INPUTS: Functional and Level–of–Service Requirements from System and Software Requirements Definition (SSRD); Use–Case Model (including both diagrams and descriptions). Discrepancy reports.
OUTPUTS:
For each Use–Case Description, 1. Verify that each functional requirement listed in the Requirement field of the Use–Case Description is implemented in description of the Courses of Action. a) If no Courses of Actions are described, add a discrepancy to the Discrepancy Report Form (possible omission — this is not critical if the use–case is not high risk or architecturally significant in the early phases of the development process, i.e. pre–IOC).
b) If Courses of Actions are described, identify the steps relate to the requirement. If a whole Course of Actions is related, mark with the Requirement ID. If only a subset of steps is related, mark the steps. Add a discrepancy to the Discrepancy Report Form if 2. No steps are found that relate to the requirement (possible omission). In your judgment, the identified steps do not correctly implement the requirement (possible incorrect fact).
Verify that each level–of–service requirement listed in the Requirement field of the Use–Case Description is achievable. a) If no Courses of Actions are described, add a discrepancy to the Discrepancy Report Form (possible omission — this is not critical if the use–case is not high risk or architecturally significant in the early phases of the development process, i.e. pre–IOC).
b) If Courses of Actions are described, identify the steps relate to the requirement. If a whole Course of Actions is related, mark with the Requirement ID. If only a subset of steps is related, mark the steps. Add a discrepancy to the Discrepancy Report Form if 3. No steps are found that relate to the requirement (possible omission). In your judgment, the steps cannot achieve the required level of service (possible incorrect fact).
Review the Use–Case Description for extraneous Courses of Actions or steps. If
D. Verify that the use–case a properly realized by its Sequence Diagrams. INPUTS: OUTPUTS: Use–Case Descriptions Sequence Diagrams. Discrepancy reports.
For each use–case, perform the following steps. 1. Find all Sequence Diagrams that are related to the use–case. (Note: you may have to separate Sequence Diagrams into design–level and implementation–level sets.) If found, list the Sequence Diagram name on the Use–Case Description, and mark the Sequence Diagram with a star in a colored pen. If no Sequence Diagrams are related to a use–case, add a discrepancy to the Discrepancy Report Form (possible omission — this is not critical if the use– case is not high risk or architecturally significant in the early phases of the development process, i.e. pre–IOC). Verify that the actors listed in the Use–Case Description for the use–case and its ancestors are consistent with the actors that are shown on the related Sequence Diagram. Page 2 GHT/FS/JC
2.
UMCP/ESEG http://www.cs.umd.edu/projects/SoftEng/ESEG/
OORT's - Horizontal Reading
v3.2
a)
For each actor listed in the Actor field of the Use–Case Description for the use–case and its ancestors, find all Sequence Diagrams related to the use–case that the actor appears on. If you cannot find the actor on any related Sequence Diagrams, add a discrepancy to the Discrepancy Report Form (possible omission).
b) For each actor shown on Sequence Diagrams find the actor name in the Actor field of the Use–Case Description. If you cannot find the actor name in the Actor field of the Use–Case Description, add a discrepancy to the Discrepancy Report Form (possible omission — implementation–level Sequence Diagrams may have ―internal‖ actors, which should not appear in the Actor field of the Use–Case Description). 3. Verify that all Courses of Actions are correctly implemented by the Sequence Diagram. a) If the Sequence Diagrams describe all Courses of Actions in a single sequence, then For each step in every Course of Actions (1) Identify the subset of objects, actors, sequence of messages, and related notes (e.g. describing method details or constraints) on the Sequence Diagram that implement the step. Circle the set of message sequence and write the step description or step number in the left margin of the diagram near the circle. Add a discrepancy to the Discrepancy Report Form if no message sequence relates to the step (possible omission). (2) Verify that the sequence of messages and related notes correctly implements the step. Add a discrepancy to the Discrepancy Report Form if There is any error in the message sequence, e.g. an incorrect condition (possible incorrect fact). The message sequence may not achieve a level–of–service requirement that applies to the step (possible incorrect fact).
b) If each Sequence Diagrams describes one Courses of Actions, then For each Course of Action, (1) Identify the related Sequence Diagram (usually by diagram name). If no Sequence Diagrams is related to the Course of Actions, add a discrepancy to the Discrepancy Report Form (possible omission). (2) Verify that the Sequence Diagram implements all steps in the Course of Actions. For each step in the Course of Actions (a) Identify the subset of objects, actors, sequence of messages, and related notes (e.g. describing method details or constraints) on the Sequence Diagram that implement the step. ―Circle‖ the set of message sequence and write the step description or step number in the left margin of the diagram near the circle. Add a discrepancy to the Discrepancy Report Form if no message sequence relates to the step (possible omission). (b) Verify that the sequence of messages and related notes correctly implements the step. Add a discrepancy to the Discrepancy Report Form if There is any error in the message sequence, e.g. an incorrect condition (possible incorrect fact). The message sequence may not achieve a level–of–service requirement that applies to the step (possible incorrect fact).
E. Review Sequence Diagrams for extraneous information INPUTS: OUTPUTS: 1. Use–Case Descriptions Sequence Diagrams. Discrepancy reports.
Verify that all Sequence Diagrams represent the implementation of a use–case or an operation. Page 3 GHT/FS/JC
UMCP/ESEG http://www.cs.umd.edu/projects/SoftEng/ESEG/
OORT's - Horizontal Reading
v3.2
For each Sequence Diagram, a) Identify the use–case or operation that the Sequence Diagram describes the implementation. If you have done step D.1 correctly, the Sequence Diagram will have a star if it describes use–cases. If the Sequence Diagram is not associated with a use–case, determine whether it describes the implementation of an operation (usually can be identified by diagram name). Add a discrepancy to the Discrepancy Report Form if the Sequence Diagram is not related to either a use–case or operation.
2.
Verify that all objects, actors, messages, and related notes on the Sequence Diagram relate to one or more steps in at least on Course of Actions of the use–case. If you have done step D.3 correctly, every object, actor, message, and related note on a Sequence Diagram will have been related to a step. If any object, actor, message, and related note is not enclosed in a circle, add a discrepancy to the Discrepancy Report Form (possible incorrect fact).
UMCP/ESEG http://www.cs.umd.edu/projects/SoftEng/ESEG/
Page 4
GHT/FS/JC