Requirements Modeling CIS 375 Bruce R Maxim UM-Dearborn

Requirements Modeling CIS 375 Bruce R. Maxim UM-Dearborn 1

H. I. P. O. Chart 2

H. I. P. O Chart • Hierarchical Input-Process-Output • Strength – Shows functional relationships • Weaknesses – Does not show non-functional requirements – No checking mechanism, except for customer review 3

Hierarchical Data Structures 4

Hierarchical Data Structures • How does it different from object hierarchy? – Looks at data, not methods. – No inputs/outputs. – Only shows declaration of records, could work for database model, but not for implementation. 5

Analysis Model Objectives • Describe what the customer requires. • Establish a basis for the creation of a software design. • Devise a set of requirements that can be validated once the software is built. 6

Structured Analysis - 1 • Analysis products must be highly maintainable, especially the software requirements specification. • Problems of size must be dealt with using an effective method of partitioning. • Graphics should be used whenever possible. • Differentiate between the logical (essential) and physical (implementation) considerations. 7

Structured Analysis - 2 • Find something to help with requirements partitioning and document the partitioning before specification. • Devise a way to track and evaluate user interfaces. • Devise tools that describe logic and policy better than narrative text 8

Analysis Model Elements - 1 • Data dictionary – contains the descriptions of all data objects consumed or produced by the software • Entity relationship diagram (ERD) – depicts relationships between data objects • Data flow diagram (DFD) – provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow – a function is represented in a DFD using a process specification or PSPEC 9

Analysis Model Elements - 2 • State transition diagram (STD) – indicates how the system behaves as a consequence of external events – states are used to represent behavior modes – arcs are labeled with the events triggering the transitions from one state to another – control information is contained in control specification or CSPEC 10

Data Dictionary Entries - 1 • Name – primary name for each data or control item, data store, or external entity • Alias – alternate names for each data object • Where-used/how-used – listing of processes that use the data or control item and how it is used • • input to process output from process as a store as an external entity 11

Data Dictionary Entries - 2 • Content description – notation for representing content • Supplementary information – other data type information, preset values, restrictions, limitations, etc. 12

Entity-Relationship Diagrams 13

Data Modeling Elements (ERD) • Data object – any person, organization, device, or software product that produces or consumes information • Attributes – name a data object instance, describe its characteristics, or make reference to another data object • Relationships – indicate the manner in which data objects are connected to one another 14

Cardinality and Modality (ERD) • Cardinality – in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1: 1, 1: N, M: N) • Modality – zero (0) for an optional object relationship – one (1) for a mandatory relationship 15

Creating Entity-Relationship Diagrams - 1 • Customer asked to list "things" that application addresses • These things evolve into input objects, output objects, and external entities • Analyst and customer define connections between the objects • One or more object-relationship pairs is created for each connection 16

Creating Entity-Relationship Diagrams - 2 • Cardinality and modality are determined for an object-relationship pair • Attributes of each entity are defined • ERD is reviewed and refined 17

Normalization Rules • Given instance of an object has one value for an attribute. • Attributes represent elementary items. • When more than one attribute is used to identify an object, make sure they describe the same "key". • All non-ID attributes represent the same characteristics of instance named by key. 18

Dataflow Diagram Rectangle = information producer or consumer Oval = software element that transforms info Arrow = data item information repository (not shown) 19

Functional Modeling DFD - 1 • Shows the relationships among – – external entities process or transforms data items data stores • DFD's cannot show procedural detail like conditionals or loops • DFD’s only show the flow of data through the software system 20

Functional Modeling DFD - 2 • Refinement from one DFD level to the next should follow approximately a 1: 5 ratio • This ratio will reduce as the refinement proceeds • To model real-time systems, structured analysis notation must be available for time continuous data and event processing 21

Creating DFD - 1 • Level 0 data flow diagram should depict the system as a single bubble • Primary input and output should be carefully noted • Refinement should begin by consolidating (for representation at the next level): – candidate processes – data objects – data stores to be represented at the next level • Label all arrows with meaningful names 22

Creating DFD - 2 • Information flow must be maintained from one level to level • Refine one bubble at a time • Write PSPEC for each bubble in the final DFD – "mini-spec" written using English or another natural language or a program design language 23

DFD Refinement 24

n DFD/CFD Level 0 - Part Number Analysis (PNA) System WKConnectors. XLS Spreadsh eet Informatio n CSV File Creation (WKConnectors. CSV) WKConnect ors Delimited Text Information Display Monitor Report Results Table 1. CSV Table 1 Delimited Text Information Table 2. CSV - Command - PN data PART NUMBER ANALYSIS (PNA) Tool Report Results File Report Results Printer User 25

n DFD/CFD Level 1 - Part Number Analysis (PNA) Tool WKConnectors Delimited Text information Report Results Validation Results Table 1 Delimited Text information Report Results Validate Data Process Report Print / Save Data Report Results Table 2 Delimited Text information - Command - PN data 26

n DFD/CFD Level 2 - Validate Data WKConnecto rs Delimited Text information tbl_Classification Make Relevant tbl_created. WKConnector Records - Command - PN data Make WKConn Category Reference ID Validation Results tbl_created. WKConn field data - Component Remarks - Category ID tbl_created. T 1 Field data Relevant T 1 Record(s) Table 1 Delimited Text information Analyze/Classify Data Criteria: - dbs - str. Criteria - str. Orig. PN Print / Save Data Criteria: - dbs - str. Orig. PN T 2 Field data Make tbl_created. T 1 tbl_created. T 2 Table 2 Delimited Text information Make tbl_created. T 2 Relevant T 2 Record(s) 27

n DFD/CFD Level 3 - Make tbl_created. T 1 Table 1 Delimited Text information Criteria: - dbs - str. Criteria - str. Orig. PN qry_Table 1 Unique. PN Recreate tbl_created. T 1 Table 1 Query Results Relevant T 1 Record(s) n DFD/CFD Level 3 - Make tbl_created. T 2 Criteria: - dbs - str. Orig. PN Table 2 Delimited Text information Recreate tbl_created. T 2 qry_Table 2 Prelim. Unique Table 2 Query Results Relevant T 2 Record(s) 28

Creating Control Flow Diagrams • Begin by stripping all the data flow arrows form the DFD • Events (solid arrows) and control items (dashed arrows) are added to the diagram • Create CSPEC for each bubble in final CFD – contains an STD (state transition diagram) that serves as a sequential specification of the bubble’s behavior 29

State Transition Diagram 30

STD Elements • • • Set of machine states S S 0 start state F S set of final state(s) I set of input symbols Transition function (Sj , Ij) Si 31

Behavioral Modeling (STD) • State transition diagrams represent the system states and events that trigger state transitions • STD's indicate actions (e. g. process activation) taken as a consequence of a particular event • A state is any observable mode of behavior • Control flow diagrams (CFD) can also be used for behavioral modeling 32

Decision Table Rules Condition 1 2 Actions 1 2 33

Condition N not numeric T F F F N <= 1 - T F F N legal - - T F N prime - - T F Action Print “N prime” X Print “N not prime” Print error message X X X Print “Good bye” Input new value for N Stop X X X 34

Event Table Mode Event 1 Event 2 Event 3 Event 4 Presentation Graphics Action 1 Action 8 O X Architecture Drawing X A 2 then A 3 A 5 & A 6 O Programming O A 4 A 1, A 2 & A 3 A 7 X = no action defined for event O = no state change and no action 35

Petri Nets • Sequential Process • F(State. A, Event 1, Event 2, Event 3) State. S • F(State. A, Event 1, Event 2, Event 3) (State. S 1, State. S 2) 36

SADT • Structured Analysis and Design Technique • Phases: – SA • Activity diagrams combined to for activity network • Data diagrams combined to form data network – DT • • Uses dataflow diagrams Data dictionary Pseudo algorithm representations for control information Relational tables to indicate data element relations 37

SA – Activity Diagram Control Outputs Inputs Mechanism 38

SA – Data Diagram Control Generating Resulting Activity Storage Device 39