Lecture - Visual Requirements Models.pdf

INFO8655 Requirements Modelling and Visualization Couse Visual Requirements Models Conestoga College  Topics § Data flow diagrams (DFDs) § Process flow diagrams such as swimlane diagrams § State-transition di...

INFO8655 Requirements Modelling and Visualization Couse Visual Requirements Models Conestoga College  Topics § Data flow diagrams (DFDs) § Process flow diagrams such as swimlane diagrams § State-transition diagrams (STDs) and state tables § Dialog maps § Decision tables and decision trees Event-response tables  Visual Requirements Models § Visual requirements models can help identify missing, extraneous, and inconsistent requirements. § These models are useful for elaborating and exploring the requirements, as well as for designing software solutions. § Whether you are using them for analysis or for design depends on the timing and the intent of the modeling. § Used for requirements analysis, these diagrams let you model the problem domain or create conceptual representations of the new system. § They depict the logical aspects of the problem domain’s data components, transactions and transformations, real- world objects, and changes in system state. § You can base the models on the textual requirements to represent them from different perspectives, or you can derive functional requirements from high-level models that are based on user input. § During design, models represent how you intend to implement the system: the actual database to create, the object classes to instantiate, and the code modules to develop. § Because analysis and design diagrams use the same notations, clearly identify each one you draw as being an analysis model (the concepts) or a design model (what you intend to build).  Data Flow Diagram (DFD) § The data flow diagram is the basic tool of structured analysis. § A DFD identifies the transformational processes of a system, the collections (stores) of data or physical materials that the system manipulates, and the flows of data or material between processes, stores, and the outside world. § Data flow modeling takes a functional decomposition approach to systems analysis, breaking complex problems into progressive levels of detail. § This works well for transaction-processing systems and other function-intensive applications. T § hrough the addition of control flow elements, the DFD technique has been extended to permit modeling of real-time systems. Karl Wiegers, Joy Beatty. (2013) Software Requirements (3rd Edition) Partial level 0 data flow diagram for the Chemical Tracking System. Karl Wiegers, Joy Beatty. (2013) Software Requirements (3rd Edition) Conventions for Drawing Data Flow Diagram § Processes communicate through data stores, not by direct flows from one process to another. Similarly, data cannot flow directly from one store to another or directly between external entities and data stores; it must pass through a process bubble. § Don’t attempt to imply the processing sequence using the DFD. § Name each process as a concise action: verb plus object (such as “generate reports”). Use names that are meaningful to the customers and pertinent to the business or problem domain. § Number the processes uniquely and hierarchically. On the level 0 diagram, number each process with an integer. If you create a child DFD for process 3, number the processes in that child diagram 3.1, 3.2, and so on. § Don’t show more than 8 to 10 processes on a single diagram or it will be difficult to draw, change, and understand. If you have more processes, introduce another layer of abstraction by grouping related processes into a higher-level process. § Bubbles with flows that are only coming in or only going out are suspect. The processing that a DFD bubble represents normally requires both input and output flows.  Swimlane Diagram § Swimlane diagram Swimlane diagrams provide a way to represent the steps involved in a business process or the operations of a proposed software system. § They are a variation of flowcharts, subdivided into visual subcomponents called lanes. The lanes can represent different systems or actors that execute the steps in the process. § Swimlane diagrams are most commonly used to show business processes, workflows, or system and user interactions. They are similar to UML activity diagrams. § Swimlane diagrams are sometimes called cross-functional diagrams. § Swimlane diagrams can show what happens inside the process bubbles from DFDs. They help tie together the functional requirements that enable users to perform specific tasks. They can also be used to perform detailed analysis to identify the requirements that support each process step  Elements of a Swimlane Diagram § Process steps, shown as rectangles. § Transitions between process steps, shown as arrows connecting pairs of rectangles. § Decisions, shown as diamonds with multiple branches leaving each diamond. The decision choices are shown as text labels on each arrow leaving a diamond. § Swimlanes to subdivide the process, shown as horizontal or vertical lines on the page. The lanes are most commonly roles, departments, or systems. They show who or what is executing the steps in a given lane. Partial swimlane diagram for a process in the Chemical Tracking System.  State-Transition Diagram The state-transition diagram (STD) shows the possible transitions between states visually. An example is a highway intersection that incorporates vehicle sensors, protected turn lanes, and pedestrian crosswalk buttons and signals. § State-transition diagram involves a combination of functional behavior, data manipulation, and state changes. § Real-time systems and process control applications can exist in one of a limited number of states at any given time. § A state change can take place only when well-defined criteria are satisfied, such as receiving a specific input stimulus under certain conditions. § Many information systems deal with business objects—sales orders, invoices, inventory items, and the like—with life cycles that involve a series of possible states, or statuses. § Describing a set of complex state changes in natural language creates a high probability of overlooking a permitted state change or including a disallowed change. § Depending on how an SRS is organized, requirements that pertain to the state-driven behavior might be sprinkled throughout it. This makes it difficult to reach an overall understanding of the system’s behavior.  Elements of State-Transition Diagram The STD contains three types of elements: 1. Possible system states, shown as rectangles. Some notations use circles to represent the state. Either circles or rectangles work fine; just be consistent in what you choose to use. 2. Allowed state changes or transitions, shown as arrows connecting pairs of rectangles. 3. Events or conditions that cause each transition to take place, shown as text labels on each transition arrow. The label might identify both the event and the corresponding system response.  This STD shows that an individual request can take on one of the following seven possible states: In Preparation. The Requester is creating a new request, having initiated that function from some other part of the system. Postponed. The Requester saved a partial request for future completion without either submitting the request to the system or canceling the request operation. Accepted. The Requester submitted a completed chemical request and the system accepted it for processing. Placed. The request must be satisfied by an outside vendor and a buyer has placed an order with the vendor. Fulfilled. The request has been satisfied, either by the delivery of a chemical container from the chemical stockroom to the Requester or by receipt of a chemical from a vendor. Back-ordered. The vendor didn’t have the chemical available and notified the buyer that it was back- ordered for future delivery. Canceled. The Requester canceled an accepted request before it was fulfilled, or the buyer canceled a A partial state-transition diagram for a chemical request in the Chemical vendor order before it was fulfilled or while it was Tracking System. back-ordered.  Dialog Map § The dialog map represents a user interface design at a high level of abstraction. § It shows the dialog elements in the system and the navigation links among them, but it doesn’t show the detailed screen designs. § A user interface can be regarded as a series of state changes. Only one dialog element (such as a menu, workspace, dialog box, line prompt, or touch screen display) is available at any given time for user input. § The user can navigate to certain other dialog elements based on the action he takes at the active input location. § The number of possible navigation pathways can be large in a complex system, but the number is finite and the options are usually known. § A dialog map is really just a user interface modeled in the form of a state-transition diagram describe a similar technique called a navigation map, which includes a richer set of notations for representing different types of interaction elements and context transitions. § A user interface flow is similar to a dialog map but shows the navigation paths between user interface screens in a swimlane diagram format.  Trigger Condition Just as in ordinary state-transition diagrams, the dialog map shows each dialog element as a state (rectangle) and each allowed navigation option as a transition (arrow). The condition that triggers user interface navigation is shown as a text label on the transition arrow. There are several types of trigger conditions: § A user action, such as pressing a function key, clicking on a hyperlink, or making a gesture on a touch screen. § A data value, such as an invalid user input value that triggers an error message display § A system condition, such as detecting that a printer is out of paper § Some combination of these, such as typing a menu option number and pressing the Enter key A partial dialog map for the “Request a Chemical” use case from the Chemical Tracking System.  Decision Tables and Decision Trees § Decision tables and decision trees are two alternative techniques for representing what the system should do when complex logic and decisions come into play. § A decision table lists the various values for all the factors that influence the behavior and indicates the expected system action in response to each combination of factors. § The factors can be shown either as statements with possible conditions of true and false, as questions with possible answers of yes and no, or as questions with more than two possible values.  This figure shows the decision table for the logic that governs whether the Chemical Tracking System should accept or reject each request for a new chemical. Four factors influence this decision: 1. Whether the user who is creating the request is authorized to request chemicals 2. Whether the chemical is available either in the chemical stockroom or from a vendor 3. Whether the chemical is on the list of Sample decision table for the Chemical Tracking System hazardous chemicals that require special training in safe handling 4. Whether the user who is creating the request has been trained in handling this type of hazardous chemical § This figure shows a decision tree that represents this same logic. § The five boxes indicate the five possible outcomes of either accepting or rejecting the chemical request. § Both decision tables and decision trees are useful ways to document requirements (or business rules) to avoid overlooking any combinations of conditions. § Even a complex decision table or tree is easier to read than a mass of repetitious textual requirements.  Event Response Table Another way to approach user requirements is to identify the external events to which the system must respond. An event is some change or activity that takes place in the user’s environment that stimulates a response from the software system. An event-response table (also called an event table or an event list) itemizes all such events and the behavior the system is expected to exhibit in reaction to each event. Classes of System Events There are three classes of system events: Business event. A business event is an action by a human user that stimulates a dialog with the software, as when the user initiates a use case. The event- response sequences correspond to the steps in a use case or swimlane diagram. Signal event. A signal event is registered when the system receives a control signal, data reading, or interrupt from an external hardware device or another software system, such as when a switch closes, a voltage changes, another application requests a service, or a user swipes his finger on a tablet’s screen. Temporal event. A temporal event is time-triggered, as when the computer’s clock reaches a specified time (say, to launch an automatic data export operation at midnight) or when a preset duration has passed since a previous event (as in a system that logs the temperature read by a sensor every 10 seconds).  Other Information to Include Other information you might want to add to an event-response table includes: § The event frequency (how many times the event takes place in a given time period, or a limit to how many times it can occur). § Data elements that are needed to process the event. § The state of the system after the event responses are executed. Partial event-response table for an automobile windshield-wiper system