U-M CIS 375 - Requirements Modeling
Course Cis 375-
Pages 39

Unformatted text preview:

Requirements ModelingH.I.P.O. ChartH.I.P.O ChartHierarchical Data StructuresSlide 5Analysis Model ObjectivesStructured Analysis - 1Structured Analysis - 2Analysis Model Elements - 1Analysis Model Elements - 2Data Dictionary Entries - 1Data Dictionary Entries - 2Entity-Relationship DiagramsData Modeling Elements (ERD)Cardinality and Modality (ERD)Creating Entity-Relationship Diagrams - 1Creating Entity-Relationship Diagrams - 2Normalization RulesDataflow DiagramFunctional Modeling DFD - 1Functional Modeling DFD - 2Creating DFD - 1Creating DFD - 2DFD RefinementPowerPoint PresentationSlide 26Slide 27Slide 28Creating Control Flow DiagramsState Transition DiagramSTD ElementsBehavioral Modeling (STD)Decision TableSlide 34Event TablePetri NetsSADTSA – Activity DiagramSA – Data Diagram1Requirements ModelingCIS 375Bruce R. MaximUM-Dearborn2H.I.P.O. Chart3H.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 review4Hierarchical Data Structures5Hierarchical 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.6Analysis 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.7Structured 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.8Structured 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 text9Analysis 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 PSPEC10Analysis 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 CSPEC11Data 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 entity12Data Dictionary Entries - 2•Content description–notation for representing content•Supplementary information–other data type information, preset values, restrictions, limitations, etc.13Entity-Relationship Diagrams14Data 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 another15Cardinality 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 relationship16Creating 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 connection17Creating Entity-Relationship Diagrams - 2•Cardinality and modality are determined for an object-relationship pair•Attributes of each entity are defined•ERD is reviewed and refined18Normalization 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.19Dataflow DiagramRectangle = information producer or consumerOval = software element that transforms infoArrow = data iteminformation repository (not shown)20Functional 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 system21Functional 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 processing22Creating 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 names23Creating 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 language24DFD Refinement25DFD/CFD Level 0 - Part Number Analysis (PNA) SystemPART NUMBER ANALYSIS (PNA) ToolWKConnectors.XLSTable1.CSVTable2.CSVDisplay MonitorPrinterSpreadsheet InformationTable1 Delimited Text InformationTable2 Delimited Text


View Full Document

U-M CIS 375 - Requirements Modeling

Course: Cis 375-
Pages: 39
Download Requirements Modeling
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Requirements Modeling and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Requirements Modeling 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?