Requirements Analysis -- Conceptual Modeling Class Notes

Requirements Engineering Activity Model Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Validated Requirements Specification Existing System Information Stakeholder Needs Organizational Standards Technical Standards Regulations Domain Information Goals Requirements Management

Requirements Analysis l The process of analyzing requirements to: Detect and resolve requirements problems Decompose (elaborate) requirements Discover system boundary and how system must interact with its environment Discover interactions and overlaps between requirements Gain a better understanding of the problem l Includes the following main activities: Requirements classification Conceptual modeling Requirements negotiation l Quality of analysis directly affects product quality More rigorous analysis leads to better software quality

Typical Requirements Problems l Ambiguous requirements l Conflicting requirements l Design dependent requirements l Infeasible requirements (technical, operational, economic) l Incomplete requirements l Inconsistent requirements l Non-singularized requirements l Non-testable requirements l Unnecessary requirements

Background on Modeling l Modeling is a proven and well-accepted engineering technique Architectural models (blueprints) in civil engineering Mathematical models for analysis of physical properties Effects of wind on buildings Bandwidth analysis Economic models “A model is a simplification of reality created in order to better understand the system being created” [Grady Booch]

Conceptual Modeling l Development of models to aid understanding of requirements A model is an abstract representation of system whose requirements are being analyzed Model can be used to answer questions about system Not concerned with initiating design of the solution l In nearly all cases, useful to start by building model of system boundary Crucial to understanding system’s context in its operational environment Crucial to identify system’s interfaces to external environment

Booch’s Four Principles of Modeling l Choice of models has profound influence on how problem is attacked and how solution is shaped Choose your models well l Every model may be expressed at different levels of precision l Best models are connected to reality l No single model is sufficient Every nontrivial system is best approached through a small set of nearly independent models

Advantages of Conceptual Modeling (1 of 2) l Facilitates reasoning about system in an organized and precise manner Allows reviewer’s to validate that modeler’s understanding is correct l Enhances communication between stakeholders and developers l Provides basis for predicting important system characteristics Development schedule Performance Processing sequence

Advantages of Conceptual Modeling (2 of 2) l Reduces amount of complexity that must be understood at one time Consider system from different viewpoints Consider different parts of system Understand interactions and relationships between different parts of system Create a composite model by relating viewpoints l Reduces risk by exposing requirements problems early in life-cycle

Requirements Specification Goal To provide a representation of the software for the customer’s review and approval Developed as a joint effort between the developer and the customer Serve as basis for review for both customer and developer Culmination of requirements analysis

Specification Principles Separate functionality from implementation Process-oriented systems specification language is required Specification must encompass the system of which the software is a component Specification must include the environment in which the system operates

Specification Principles (continued) System specification must be a cognitive model Specification must be operational System specification must be tolerant of incompleteness and augmentable Specification must be localized and loosely coupled

Software Requirements Specification (SRS) l Includes Requirements Definition & Specification l Principles: [Heninger 80] Should specify external system behavior Should specify implementation constraints Should by easy to change Should serve as reference tool for maintenance Should record forethought about system lifecycle Should characterize acceptable responses to undesired events

Software Requirements Specification (SRS) Introduction System Models  Information Model  Functional Model  Behavioral Model Functional Requirements Definition Non-functional Requirements Definition System Evolution Requirement Specification Validation Criteria Bibliography Appendix & Glossary

Requirements Analysis Many types of analysis methods Structured Analysis Object-Oriented Analysis Each method has techniques for representing Data Processing/Function Control/Behavior Each technique/notation is used to model one or more types for information

Analysis Methods l Viewpoint Oriented Analysis Stakeholders perspectives Conflict resolution l Method Based Analysis Data-flow based analysis methods Object-Oriented analysis methods

Analysis Models l Data processing model Data Flow Diagrams l Composition model Entity-Relationship Diagrams l Stimulus-response model State Transition Diagrams l Classification model Object Model l A reference point during product maintenance.

Classification of Specification Styles l Formal, informal and Semiformal Specifications l Operational and descriptive specifications Operational specifications: desired behavior Descriptive specifications: desired properties

Verification of Specifications l Dynamic analysis l Static analysis l Formalism and verification Simulation Prototype l Verify all three aspects: Functional Consistency completeness

Data Flow Diagram: Specifying Functions of Information Systems l Features Describe systems as collections of functions that manipulate data Can be expressed by means of graphical notation Elements: Input device symbol Function symbol Data flowOutput device symbol Data store symbol

a + * + * b d c DFD Example (a + b) * ( c + a * d)

DFD limitations l The semantics of the symbol is specified only by the identifiers chosen by the user. l Control aspects are not defined by the model B D E C F A

DFD Limitations l The semantics of the symbol is specified only by the identifiers chosen by the user. l Control aspects are not defined by the model B D E C F A

DFD Limitations l The semantics of the symbol is specified only by the identifiers chosen by the user. l Control aspects are not defined by the model B D E C F A

Operational Specifications l Data Flow diagrams l UML Diagram for Specifying Behaviors Features Example Limitations l Finite State Machine: Describing Control Flow l Pretri Nets: Specifying Asynchronous Systems

Operational Specifications l Data Flow diagrams l UML Diagram for Specifying Behaviors l Finite State Machine: Describing Control Flow Definiation Features Example Limitations l Pretri Nets: Specifying Asynchronous Systems

Finite State Machines: Describing Control Flow l Definition A finite automata is a 5-tuple (Q, , , q 0, F), where 1.Q is a finite set called the states, 2.  is a finite set called the alphabet (inputs), 3.  : Q    Q is the transition function, 4. q 0  Q is the start state, and 5.F  Q is the set of accept states (final states).

Finite State Machines: Describing Control Flow l Features Formal notation Suitable for describing systems that can be in a finite set of states and that can go from one state into another as a consequence of some event, modeled by an input symbol. Widely used: specification of control systems, compilation, pattern matching, etc.

Finite State Machines: Describing Control Flow l Example On Off Push switch

Finite State Machines: Describing Control Flow l Example: Chemical plant On Off High-pressure alarm Restart High-temperature alarm

Normal Off Pressure Recovery Temperature Recovery Pressure signal Temperature signal Pressure signal Successful recovery Unsuccessful recovery Successful recovery Unsuccessful recovery Finite State Machines: Describing Control Flow l Example: Chemical plant

Finite State Machines: Describing Control Flow l Limitations Finite states: need assistance such as natural language or accompanied by action descriptions, like: Cooling_effort := k * (present_temperature – standard temperature) Can’t describe concurrent, asynchronous systems. P1 P2C1 C write produce read consume write read empty full

consume Produce consume Produce consume Produce write read write read FSM: Describing Control Flow l Example continued: the Cartesian Product of the component state sets:

Finite State Machines: Describing Control Flow l Limitations: The cardinality of the state space grows dramatically: if we have n subsystems, each with k i states, the resulting system has a cardinality of k 1 *k 2 *…K n FSM are essentially a synchronous model: at any time, a global state of the system must be defined and a single transition must occur.

Operational Specifications l Data Flow diagrams l UML Diagram for Specifying Behaviors l Finite State Machine: Describing Control Flow l Pretri Nets: Specifying Asynchronous Systems Definition Example Features Limitations

Petri Nets: Specifying Asynchronous System l Definition A Petri Net is a quadruple (P, T, F, W), where 1.P is the finite set of places; 2.T is a finite set of transitions; 3.P  T   ; 4.F  { P  T}  { T  P} is the flow relation; and 5.W: F  N – {0} is the weight function, which associates a nonzero natural value to each element of F. If no weight value is explicitly associated with a flow element, the default value 1 is assumed for the function

Petri Nets: Specifying Asynchronous System l Example: write produce p1 p2 Place Token Transition p2 is the input place of transition write p1 is the output place of transition write Produce is the enabled, so transition produce may fire

Petri Nets: Specifying Asynchronous System l Example: write produce p1 p2 Place Token Transition p2 is the input place of transition write p1 is the output place of transition write Produce is the enabled, so transition produce may fire 2

Petri Nets: Specifying Asynchronous System l Example: After produce fired write produce p1 p2 Place Token Transition p2 is the input place of transition write p1 is the output place of transition write Now, write is the enabled, so transition write may fire 2

write produce p1 p2 consume read c1 c2 read write 0 1 read write 2 PN: Specifying Asynchronous System l Example: producer and consumer

consume c1 c2 produce p1 p2 read write 0 1 read write 2 PN: Specifying Asynchronous System l Example continued: l producer and consumer: Now the system is at the state

consume c1 c2 produce p1 p2 read write 0 1 read write 2 PN: Specifying Asynchronous System l Example continued: l producer and consumer: Now the system is at the state

consume c1 c2 produce p1 p2 read write 0 1 read write 2 PN: Specifying Asynchronous System l Example continued: l producer and consumer: Now the system is at the state

Petri Nets: Specifying Asynchronous System l Features Good at describing concurrent and asynchronous system l Limitations Tokens are anonymous Can’t specify a selection policy Can’t resolve deadlock or starving…

Descriptive Specifications l Entity Relationship (ER) Diagrams l A semiformal notation l Logic Specification l Algebraic Specifications

Entity Relationship Diagrams STUDENT CLASS AGE SEX NAME ENROLLED_IN SUBJECT COURSE_ID MAX_ENROLLMENT Entities: a collection of items that share common properties Relations: A set of pairs, where a is an element of STUDENT and b is an element of CLASS Attribute:

Entity Relationship Diagrams Relation Attributes: A B R A B R A B R A B R A R B is one to one A R B is one to many A R B is many to one A R B is many to many

Unified Modeling Language l A general-purpose visual modeling language that is used to specify, visualize, construct and document the artifacts of a software system. l Static Structure (Descriptive) l Dynamic behavior (Operational)

Unified Modeling Language l Static Structure (Descriptive) Static view: class diagram User Case View Physical Views Implementation view Deployment view l Dynamic behavior (Operational) Interaction view Sequence diagram Collaboration diagram State machine view Activity view

Unified Modeling Language l Static Structure (Operational) Static View: class diagram User Case View Physical Views Implementation view Deployment view l Dynamic behavior (Descriptive) Interaction view Sequence diagram Collaboration diagram State machine view Activity view

Customer Name: String Phone: String Add(name,phone) Reservation Date: Date Subscription Series Series: integer Individual Reservation Ticket Available: Boolean Sell (c. Customer) Exchange() Show Name: String Performance Date: Date Time: TimeOfDay Seat: Sting 1 * 1* 1 1..* Class attributes class-scope operation association generalization multiplicities Class Diagram: qualifier

Kiosk buy tickets buy subscription make charges survey sales relationship Use case > Clerk Credit card service Supervisor system actor Use Case Diagram:

Unified Modeling Language l Static Structure (Operational) Static View: class diagram User Case View Physical Views Implementation view Deployment view l Dynamic behavior (Descriptive) Interaction view Sequence diagram Collaboration diagram State machine view Activity view

Kiosk box office credit card service message Request (count, performance) Show availability (seat-list) Select(seats) Demand payment(cost) Insert card(card number) Print tickets (performance, seats) Eject card charge(card number,cost)) authorized lifeline (active) Active object Sequence Diagram

Kiosk ticketseller message active object performanceGuide Db: performanceDB link multi object Db: performanceDB 2: db := findDB(performance) >db transient link passive object 1:request (count, performance)4: offer(seat-list)5:buy(seats)8:confirm (seats, cost) 3: seat-list := lock(count)  6: claim (seats)  7: unlock(seat-list)  Collaboration Diagram:

Initial state Available Locked Sold state transition Trigger event Assign to subscription Time out lock unlock exchange buy State chart Diagram

activity Pick show schedule show publicize show Buy scripts and music Hire artists Build sets Design lighting Make costumes Sell tickets rehearse Dress rehearsal perform Completion transition join fork Activity Diagram

Key Points l No ideal requirements analysis method l System models can be considerably enriched by combining different techniques l Data-flow model is based on the notion that systems can be modelled as a set of interacting functions l The object-oriented approach is based on the notion that systems can be modelled as a set of interacting objects l Formal methods are based on mathematical principles and are intended to achieve a high degree of confidence that a system will conform to its specifications