You are on page 1of 39

Requirements Modeling

CIS 375
Bruce R. Maxim

H.I.P.O. Chart


H.I.P.O Chart
• Hierarchical Input-Process-Output
• Strength
– Shows functional relationships

• Weaknesses
– Does not show non-functional
– No checking mechanism, except for
customer review

Hierarchical Data Structures 4 .

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

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

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

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

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 .Analysis Model Elements .

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 store.Data Dictionary Entries .1 • Name – primary name for each data or control item.

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

Entity-Relationship Diagrams 13 .

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

1:N. M:N) • Modality – zero (0) for an optional object relationship – one (1) for a mandatory relationship 15 .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.

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 .1 • Customer asked to list "things" that application addresses • These things evolve into input objects.

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

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

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

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.Functional Modeling DFD . structured analysis notation must be available for time continuous data and event processing 21 .

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 .Creating DFD .

DFD Refinement 24 .

CSV . DFD/CFD Level 0 .Part Number Analysis (PNA) System WKConnectors.XLS Spreadsheet Information CSV File Creation (WKConnectors.Command .CSV) Display Monitor WKConnectors Delimited Text Information Report Results Table1.PN data Printer User 25 .CSV Table1 Delimited Text Information Table2 Delimited Text Information PART NUMBER ANALYSIS (PNA) Tool Report Results File Report Results Table2.

Part Number Analysis (PNA) Tool WKConnectors Delimited Text information Report Results Validation Results Table1 Delimited Text information Report Results Validate Data Process Report Print / Save Data Report Results Table2 Delimited Text information .Command . DFD/CFD Level 1 .PN data 26 .

Category ID tbl_createdT1 T1 Field data Relevant T1 Record(s) Table1 Delimited Text information Analyze/Classify Data Print / Save Data Criteria: . DFD/CFD Level 2 .strCriteria .Component Remarks .strOrigPN Criteria: .PN data Relevant WKConnector Records Make WKConn Category Reference ID Validation Results tbl_createdWKConn WKConn field data .Validate Data tbl_Classification WKConnectors Delimited Text information Make tbl_createdWKConn .dbs .strOrigPN T2 Field data Make tbl_createdT1 tbl_createdT2 Table2 Delimited Text information Make tbl_createdT2 Relevant T2 Record(s) 27 .Command .dbs .

Make tbl_createdT2 Criteria: .dbs .strOrigPN Table2 Delimited Text information Recreate tbl_createdT2 qry_Table2PrelimUnique Table2 Query Results Relevant T2Record(s) 28 . DFD/CFD Level 3 .dbs .Make tbl_createdT1 Table1 Delimited Text information Criteria: .strOrigPN qry_Table1UniquePN Recreate tbl_createdT1 Table1 Query Results Relevant T1 Record(s)  DFD/CFD Level 3 .strCriteria .

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 .

Ij)  Si 31 .STD Elements • • • • • Set of machine states S S0  start state F  S set of final state(s) I set of input symbols Transition function  (Sj .

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 X X X 34 .

Event Table Mode Event1 Event2 Event3 Event4 Presentation Graphics Action 1 Action8 O X Architecture Drawing X A2 then A3 A5 & A6 O Programming O A4 A1. A2 & A3 A7 X = no action defined for event O = no state change and no action 35 .

Event3)  StateS • F(StateA. Event1. Event1. Event2.Petri Nets • Sequential Process • F(StateA. Event3)  (StateS1. Event2.StateS2) 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  Inputs   Outputs  Mechanism 38 .

SA – Data Diagram Control  Resulting Generating  Activity Activity  Storage Device 39 .