Chapter 3: Requirements Modeling Requirements Engineering
Objectives In this chapter, you will learn about: Functional requirements Modeling requirements Overview of basic modeling paradigms Gus Requirements Engineering 2
Functional Requirements Functional Requirements Specification is the second step in Requirements Engineering Functional Requirements define the solution space for the problem Our goal is to use the customer s needs (see lecture notes 2) and create: 1. Graphical representations of the required interactions, behaviors and activities 2. Narrative of the required interactions, behaviors and activities 3. Algorithms to support your views (You may skip this step for your class project. This step is typically handled by SMEs. It falls mainly in the HOW domain. If you are not an SME, then you will need to brainstorm initially with various Subject Matter Experts) The deliverables of the Functional requirements provide a framework for deriving i and structuring t systems requirements Gus Requirements Engineering 3
Functional Requirements Modeling 1. Modeling is a method to schematically describe our perceived representations of the customer s s needs, behaviors and interactions for the problem domain What are the advantages of Modeling? Allows you to restate t the requirements in a format different from the original i customer s requests Force the customer to examine your models in order to validate the model s accuracy Helps you to better understand d the customer s requirements Multiple, conflicting outputs to the same input is an indication of inconsistencies in the requirements Allows consideration of multiple interacting aspects and views of the system apriori Allows requirements specifications to be visualized in diagrams ( A picture is worth a thousand words ) Facilitates efficient communications between the different SDLC organizations Gus Requirements Engineering 4
Modeling Requirements Modeling Techniques: There are several eral modeling notations to express info about problem s concept, behavior and interactions (properties) New (customized) notations are being introduced to adapt to new type of problem domains The individual modeling notations, however, are based on less than 10 basic paradigms We will examine some of the basic paradigms Gus Requirements Engineering 5
Modeling Requirements Data Flow Diagrams Data Flow Diagrams (DFD) Provide graphical representation of a fundamental system structure and interfaces Do not show control flows Elements in a Data Flow Diagram: Data Flows Labeled arrows: to indicate information exchanged between two transformations Flow type: Continuous, on demand asynchronous etc. Data Transformations Bubbles: indicate processes/subsystems to depict internal entities Data Stores Horizontal Parallel lines: indicate Transactions, db External Entities Rectangles: indicates entities that interact with the system DFD must be accompanied by textual descriptions of data Flows, data Transformations and data Stores Data Dictionary defines data Stores and Flows Gus Requirements Engineering 6
Modeling Requirements Data Flow Diagrams Credit card holder Check details Transactions s Process transaction Print receipt Account system Printer Example Data Flow Diagram for ATM System Gus Requirements Engineering 7
Modeling Requirements Developing a Data Flow Diagram Start with a Context Diagram Show all external systems that interact with proposed system Process transaction Check details ATM System Credit card holder Account system Printer Fundamental Data Flow Diagram for ATM System Gus Requirements Engineering 8
Modeling Requirements Developing a Data Flow Diagram Next, progressively expand ( explode ) each bubble Detailed processes (bubbles), data stores and/or data flows Credit card holder (A) A Y C Accounts System (B) o Printer (C) B 1 2 C 3 4 X Z X 3.2 3.1 3.4 3.3 Z Explode 0 Explode 3 Gus Requirements Engineering 9
Developing a Data Flow Diagram Model for Ambulance Command & Control (AC&C) System Caller Handle Callers Current Incidents Handle ambulances Keep records Ambulance Ambulance State Model for Ambulance C&C System Records Gus Requirements Engineering 10
Developing a Data Flow Diagram Model for Ambulance Command & Control (AC&C) System Handle Callers Obtain Incident details Communicate with Caller Analyze incident Provide On-line advice Caller Handle ambulances Current Incidents Communicate with Ambulances Allocate ambulance Monitor Ambulance states Monitor incident Keep records Provide statistics Ambulance Ambulance State Detail Model for Ambulance C&C System Records Gus Requirements Engineering 11
Developing a Data Flow Diagram Functional structure of Ambulance Command & Control (AC&C) System Handle callers Communicate with caller Obtain incident details Analyze incident Provide on-line advice The obtain incident details function shallallowcenterstaff allow staff to obtain and record incident details from the caller C&C system Handle ambulances Allocate ambulance Communicate with ambulances Monitor ambulances The allocate ambulance function shall allow the controller to allocate an ambulance to an incident Keep records Monitor incidents Provide Statistics Gus Requirements Engineering 12
Modeling Requirements Use Cases A Use Case: Describes particular functionality of a system Modeling the interactions (dialog) that a user, external system or other entity (actor) will have with the system being developed Each use case describes possible scenarios of how the actor interacts with the system Use Cases are presented as Drawings of pertinent objects plus Brief textual description of how the function is performed For each scenario the use case identifies: All possible events System s response The collection of all use cases provides a complete description of the different ways of using the system by all possible entities Gus Requirements Engineering 13
Modeling Requirements Use Cases Pay fines <<include>> Check fines Patron Find item <<extend>> <<include>> Borrow item Return item <<extend>> Reserve item Recall item Library inventory Librariani Cancel reservation Example: Library Use Cases Can you Identify the actors? How about the use cases? Gus Requirements Engineering 14
Modeling Requirements Use Cases Actors: Patron (Human) Librarian (Human but different user) Library inventory (system/shelf) <<include>> Pay fines Check fines Base Case: Pay fines Find item Return item Reserve item Borrow item Patron Find item <<extend>> <<include>> Borrow item Return item Library inventory Subcase: Check fines Common to Base Cases: Pay fines and Borrow item Dashed arrows goes from Base Case to Subcase <<include>> Recall item (extension subcase) Adds functionality to base case Reserve item Dashed arrowed line points to Base case Borrow item (extension subcase) Adds functionality to base case Reserve item Dashed arrowed line points to Base case <<extend>> Librarian <<extend>> Reserve item Recall item Cancel reservation Library Use Cases Gus Requirements Engineering 15
Use Cases Shell Gas Station Lets consider a shell gas station that provides Three types of services: Refueling, Parking and Maintenance Bill to the customer for each service Develop the use cases for the system Gus Requirements Engineering 16
Use Cases Shell Gas Station Start with the fundamental use case diagram Refueling <<extend>> Customer Billing Services Parking Maintenance High-level view for billing But customer Performs refueling Parking, maintenance? Some customers will use credit card Next, Discover new aspects of the problem by asking questions Gus Requirements Engineering 17
Use Cases Shell Gas Station Add credit card payment option Refueling Customer Billing Services Parking High-level view for billing Some will pay with Visa? Credit card system Maintenance Gus Requirements Engineering 18
Use Cases Shell Gas Station Add manager; gas station offers Tune up services Refueling Customer Parking Manager But how does manager interacts with the system? Maintenance Tune up <<extend>> Next, Discover new aspects of the problem by asking questions Gus Requirements Engineering 19
Use Cases Shell Gas Station Managerial role is different from customer Accounting, inventory, orders parts for the services Printer system Accounting services Inventory Control Manager But how does manager interacts with the system? Fuel ordering system Parts ordering system Gus Requirements Engineering 20
Use Cases Shell Gas Station Collection of Use Cases for the various scenarios Printer system Accounting services Customer Billing Services Inventory Control Manager Parking Fuel Services Refueling Fuel ordering system Maintenance Services Parts ordering system Tune up Gus Requirements Engineering 21
Functional Requirements Unified Modeling Language (UML) Class Diagrams UML Represents systems in terms of objects and methods Objects (analogous to Entities) Organized in classes that have inheritance Each provides methods that perform actions on the object variables As objects executes they: Send messages to invoke each others method Acknowledge actions Transmit data Class Diagram is an ER that relates classes (entities) in a UML model Gus Requirements Engineering 22
UML Class Diagrams Patron * patron id name address fines checkfines( ) increasefines( () payfines( ) recallnotify( ) 0..1 0.. * Loan due date overdue fine calc due date( ) calc overdue fines( ) renew( ) recall( () Publication * call number title value depreciation loan period reserve loan period reserve fine rate recall period find(title): publication buy() lose() borrow() return() reserve() unreserve() decreasevalue() Class name Class attributes (simple variables) Set of Operations on attributes Book author Example UML Class Model of Library Problem Periodical editor volume number loan period fine rate * Article Gus Requirements Engineering author 23
UML Class Diagrams Notations Class-Scope Attribute (Underlined attributes) Attributes associated with the class rather than instances of the class Loan period, fine rate apply to all publications Librarian can modify loan duration for all books, all periodicals but not for individual books or individual periodicals Class-Scope Operations (Underlined operations) Operation performed by abstract class on a new instance or a whole collection of instances Association (Line between two entities) Indicates relationship between the classes entities Patron borrows a Publication Aggregate Association (line with clear diamond end) Class at the diamond end owns (includes instances) of class at the other end of the line Composition Association (line with black diamond) Instances of compound class are physically constructed from classes of component classes Periodicals is composed of Articles Generalization Association (Line with triangle on one end) Publication is a parent class of subclasses: Book and Periodical A subclass inherits all the parents class s attributes, operations and associations It is not necessary to draw a line between Patron and Book, because Book inherits this association from Publication Multiplicities Constraints on number of links between entities Number, range, unlimited numbers (*) Gus Requirements Engineering 24
Modeling Requirements Massage Sequence Charts (MSC) MSC provides graphical representations of Sequences of events exchanged between real-world entities Elements in MSC: Participating Entity Depicted as a vertical line Message Depicted as an arrow from the sending entity to receiving entity Actions Invoked operations or changes to variable values Depicted as labeled rectangles Gus Requirements Engineering 25
Massage Sequence Chart (MSC) Library Loan Request (Item available) Publication Loan Patron borrow (patron) publication, patron a b checkfines es c no fine d calc due date e Gus Requirements Engineering 26
MSC Operational Details a. Library loan request is sent to the Publication entity to be burrowed b. Publication creates a loan entity to manage the loan specific data c. Check if patron has a fine d. Patron does not have fines e. Calculate due date to return burrowed item Gus Requirements Engineering 27
Massage Sequence Chart (MSC) Library Loan Request (item checked out ~ reserve) Publication Loan Patron reserve (patron) recall a b return Recall notification (publication) delete Recall notice (publication) c d e f calc due date g Increase fine h Gus Requirements Engineering 28
Modeling Requirements Use Case Scenario & Message Sequence Chart Medical Device Nurse PDA Wireless Network Server Outside World ISP, PROVIDER Gus Requirements Engineering 29
Patient uses speech command to raise bed Use Case Scenario & MSC Commands PDA Server TV Monitor Device Pti Patient: t Bd Bedop Cmd-API CTL a Bed up b Bed -ID up c Patient Selects Option # Simulate Bed on TV + CTL Menu Display bed + Menu Options d e f g h Simulate Bed level i Display bed position j Wait 1 sec Send ctrl to raise bed k l Gus Requirements Engineering 30
Glossary of Terms This section provides a glossary of terms used in this document. It is not meant to be a glossary of all relevant terms used in the product. Acronym CCD GUI JVM MS NE NEI OA&M QA SSN Definition Control Command Definition Graphical User Interface Java Virtual Machine Microsoft Network Element Network Element Interface Operations Administration and Maintenance Quality Assurance Social Security Number Refers to customer (business) & technical jargons Gus Requirements Engineering 31
Functional Requirements Example: Case Study Case Study Case Study materials will be presented in class Gus Requirements Engineering 32