Requirements Modeling

Slides:



Advertisements
Similar presentations
Logical and Physical Design of an Information System
Advertisements

Alternative Approach to Systems Analysis Structured analysis
IFS310: Week 3 BIS310: Structured Analysis and Design 5/4/2015 Process Modeling and Data Flow Diagrams.
Chapters 7 & 9 System Scope
Analysis Concepts, Principles, and Modeling
Lecture 8- Analysis Modeling The Elements of Anaylsis Model The Elements of Anaylsis Model Data Modeling, Functional Modeling and Information Flow Data.
Chapter : Analysis Modeling
Chapter 4 Enterprise Modeling.
Chapter 4.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
SYSTEM ANALYSIS & DESIGN (DCT 2013)
Systems Analysis and Design 9th Edition
1 Lecture 4 Behaviour Modelling Requirement Specification Object-Oriented Paradigm.
Systems Analysis Requirements structuring Process Modeling Logic Modeling Data Modeling  Represents the contents and structure of the DFD’s data flows.
CS 425/625 Software Engineering System Models
Analysis Modeling Over view of today’s lesson T he analysis model is the first technical representation of a system. Analysis modeling uses a combination.
Analysis Modeling Instructor: Dr. Jerry Gao. Analysis Modeling Jerry Gao, Ph.D. Jan Elements of the analysis model - Data modeling - Functional.
Structuring System Requirements: Process Modeling
Physical design. Stage 6 - Physical Design Retrieve the target physical environment Create physical data design Create function component implementation.
Modeling the Processes and Logic
CS /47 Illinois Institute of Technology CS487 Software Engineering Requirements II- part B Instructor David Lash.
Chapter 4.
Cardinality and Modality (ERD)
Analysis Modeling Two primary methods today
CIS 375 Bruce R. Maxim UM-Dearborn
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Entity-Relationship Design
Chapter 6: The Traditional Approach to Requirements
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
staffs.ac.uk Process Model. staffs.ac.uk Contents Provide definitions Explain the components and representations Introduce a step.
Systems Analysis and Design in a Changing World, Fifth Edition
Chapter 6 The Traditional Approach to Requirements
Data flow diagrams.
Data and Process Modeling
Systems Analysis and Design in a Changing World, Fifth Edition
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
1 Chapter 14 Architectural Design. 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
Business Process Modeling
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Phase 2: Systems Analysis
Chapter 7 Structuring System Process Requirements
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Analysis Modeling. Function Modeling & Information Flow  Information is transformed as it flows through a computer-based system. The system accepts input.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
Chapter 4 enterprise modeling
Database Design – Lecture 4 Conceptual Data Modeling.
UML’s StateChart FSM, EFSM in UML Concurrent states Tool support.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
INTRODUCTION TO DATABASE DESIGN. Definitions Database Models: Conceptual, Logical, Physical Conceptual: “big picture” overview of data and relationships.
Information Access Mgt09/12/971 Entity-Relationship Design Information Level Design.
Software Engineering Lecture 11: System Analysis.
Systems Analysis and Design 8th Edition
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
Chapter 12 Analysis Modeling. Analysis Modeling ä Two primary methods today ä Structured Analysis ä Object-oriented analysis ä Some important considerations.
Lecture 91 Introduction to Data Analysis and Logic Specification Objectives l Draw an entity-relationship diagram, and explain the types of entity relationships.
Systems Analysis and Design 8th Edition
Software Analysis and Design Software Analysis Concepts and Principles Software Analysis Modeling Software Design Concepts and Principles Software Design.
CS223: Software Engineering
6 Systems Analysis and Design in a Changing World, Fourth Edition.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Modeling the Processes and Logic.
Course Instructor: Kashif I hsan 1. Chapter # 6 2.
System Design and Modeling
Chapter 8 Building the Analysis Model (2) Analysis Modeling
Data Dictionaries ER Diagram.
ANALYSIS MODELING.
Chapter 12 Analysis Modeling
Requirement Analysis using
Presentation transcript:

Requirements Modeling CIS 375 Bruce R. Maxim UM-Dearborn

H.I.P.O. Chart

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

Hierarchical Data Structures

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.

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.

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.

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

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

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

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

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

Entity-Relationship Diagrams

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

Cardinality and Modality (ERD) 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

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

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

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.

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

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

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

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

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

DFD Refinement

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

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

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

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

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

State Transition Diagram

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 , Ij)  Si

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

Decision Table   Rules Condition 1 2 Actions

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

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

Petri Nets Sequential Process F(StateA, Event1, Event2, Event3)  StateS F(StateA, Event1, Event2, Event3)  (StateS1,StateS2)

SADT Structured Analysis and Design Technique Phases: SA DT 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

SA – Activity Diagram Control  Inputs   Outputs  Mechanism

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