CT1404 Lecture 2 Requirement Engineering and Use Cases 1

Today's Lecture Concept of system requirements Techniques to solicit requirements Elaboration of use case diagrams Organization and documentation of system requirementsintheformofUseUseCases 2

3

CONCEPT OF SYSTEM REQUIREMENTS 5

FUNCTIONAL REQUIREMENT Functional requirements will specify a behavior or function. The official definition of ‘a functional requirement’ is that it essentially specifies something the system should do.

FUNCTIONAL REQUIREMENT Some of the more typical functional requirements include: Business Rules Transaction corrections, adjustments and cancellations Administrative functions Authentication Authorization levels Certification Requirements Reporting Requirements

NON-FUNCTIONAL REQUIREMENT The definition for a non-functional requirement is that it essentially specifies how the system should behave and that it is a constraint upon the systems behavior. One could also think of non-functional requirements as quality attributes for of a system. Simply put, the difference is that non-functional requirements describe how the system works, while functional requirements describe what the system should do.

NON FUNCTIONAL REQUIREMENT Some typical non-functional requirements are: Performance – for example Response Time Capacity Availability Reliability Recoverability Maintainability Security Regulatory Usability Interoperability

Stakeholders 10 People or organizations that are affected by the proposed system or have a potential influence on the requirements. Includes: –Client –User –Development –Others involved in context of use Important to involve key stakeholders in requirements capture process

11 Requirements capture techniques: – Observation – Interview – Questionnaires – Scenario Walkthroughs – Focus groups – Prototypes. Approaches to requirements capture

Result: Large legalistic documents Easy to misinterpret Changes hardto manage EasyEasytotomiss/omitrequirements 12

Modern approach – Model using UML Use cases are used – Use Case Diagram to capture functional requirements – Set of Use Case descriptions 13 Approaches to requirements capture

USE CASES

14 05-USE-CASES WHAT IS A USE-CASE A use-case captures some user visible function This may be a large or small function A use-case achieves a discrete goal for the user Examples  Format a document  Request an elevator

15 05-USE-CASES USER GOALS VERSUS USER INTERACTIONS Consider the following when formatting a document  Define a style  Change a style  Copy a style from one document to the next versus  Format a document  Ensure consistent formatting of two documents The first are user interactions  Things the user does to the system to achieve the goal The last is a user goal  Something the user wants to achieve

16 05-USE-CASES GOALS AND INTERACTIONS There is a place for both goals and interactions Understand what the system shall do  Capture the user goals Understand how the user will achieve the goals  Capture user interactions  Sequences of user interactions Thus, start with the user goals and then refine the user goals into several (many) user interactions

17 USE-CASE DIAGRAMS (POST) CustomerCashier Buy Item Log In Refund a Purchased Item POST Use Case System Boundary POST: Point of Sale Terminal

Avoid analysis paralysis: Use cases help break up the problem so it can be solved incrementally. Do just enough analysis to get started but we don’t have to worry that it’s hard to come back later and add more. Avoid gold plating: Using use cases to derive functional requirements avoids stating a functional requirement that is not directly tied to a user task needed to accomplish a business goal. Advantages of Use Cases

19 05-USE-CASES WHEN TO USE USE-CASES In short, always!!! Requirements is the toughest part of software development  Use-Cases is a powerful tool to understand  Who your users are (including interacting systems)  What functions the system shall provide  How these functions work at a high level Spend adequate time on requirements and in the elaboration phase

UseCaseDiagrams  A cashier uses the to scan an item. POSsystem  A cashier usesthePOSsystem totototalitems. 20

SystemBoundary  Marks off the system as separate from its environment  Actors are outside  When no system boundary is shown, thesystemis assumed 21

Actor  Someone or something outside the system that interacts with it  Actors represent “roles” individuals not Smith 22

ACTORS An actor represents a set of roles that users of use case play when interacting with these use cases. Actors can be human or automated systems. Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions. Actors are not part of the system. Name

USE CASES AND ACTORS From the perspective of a given actor, a use case does something that is of value to the actor, such as calculate a result or change the state of an object. The Actors define the environments in which the system lives

UseCase  A use case achieves a goal of value to an actor Defines a task which must be supported by the system What system is for not how it does it Starts with an active verb from    thepoint ofviewofofthe system 23

Communications Called relations Lines between Actor and Use Case summarize interactions graphically Actors and use cases exchange information to achieve the goal but the details of interaction are not shown 24

RELATIONSHIPS BETWEEN USE CASES 1. Generalization - use cases that are specialized versions of other use cases. 2. Include - use cases that are included as parts of other use cases. Enable to factor common behavior. 3. Extend - use cases that extend the behavior of other core use cases. Enable to factor variants.

1. GENERALIZATION The child use case inherits the behavior and meaning of the parent use case. The child may add to or override the behavior of its parent. parent child

ניתוח מערכות מידע 29 registration graduate registration non-graduate registration MORE ABOUT GENERALIZATION

30 05-USE-CASES 2. INCLUDES AND EXTENDS Includes  You have a piece of behavior that is similar across many use cases  Break this out as a separate use- case and let the other ones “include” it  Examples include  Valuation  Validate user interaction  Sanity check on sensor inputs  Check for proper authorization Extends  A use-case is similar to another one but does a little bit more  Put the normal behavior in one use- case and the exceptional behavior somewhere else  Capture the normal behavior  Try to figure out what can go wrong in each step  Capture the exceptional cases in separate use-cases  Makes it a lot easier to understand

INCLUDE AND EXTEND baseincluded > baseextending >

INCLUDE updating grades output generating verifying student id >

EXTEND

> 39

Example of Use Case Variants > Place order Open account Place back order Extension Point Place back order > Supply Customer Data Arrange delivery shared functionality 41 additional functionality