we are? Process Requirements Concepts functional non-functional Specification user stories natural language (agile) use cases diagrams (UML) * SRS Planning Modeling Coding Deployment
Case Diagrams • Use case –put the title of one requirement inside. Use cases capture requirements. • Actor –put the name of an actor at the bottom side. An actor specifies a role played by an external entity requirement title actor name
• Generalization/Specialization (Inheritance) – used when there is common behavior between two use cases and also specialized behavior specific to each use case. • Generalization/Specialization (Inheritance) –of an actor means that one actor can inherit the role of the other actor
• Show that behavior of the included use case (addition) is inserted into the behavior of the including (base) use case. • A dashed line with an open arrowhead directed from the including use case (base) to the included (addition) use case. The arrow is labeled with the keyword «include». • The include relationship is used to (1) simplify large use case by splitting it into several use cases, (2) extract common parts of the behaviors of two or more use cases. base addition
• Extending use case defines optional behavior that is not necessarily meaningful by itself. • Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the extended (base) use case. The arrow is labeled with the keyword «extend». base extension
for Use Cases • Titles begin with a verb – A use case models an action so the name should begin with a verb. • Make the name descriptive – This is to give more information for others who are looking at the diagram. For example “Print Invoice” is better than “Print”. • Highlight the logical order – For example if you’re analyzing a bank customer typical use cases include open account, deposit and withdraw. Showing them in the logical order makes more sense. • Place use cases to the right of the primary actor and to the left of secondary actors • Place inheriting use case below parent use case
for Actors • Give meaningful business relevant names for actors • Actors model roles (not positions) • External systems are actors • Actors don’t interact with other actors • Place inheriting actors below the parent actor