1 / 39

Requirements Modeling

Requirements Modeling. CIS 375 Bruce R. Maxim UM-Dearborn. H.I.P.O. Chart. 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.

devin
Télécharger la présentation

Requirements Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. H.I.P.O. Chart

  3. 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

  4. Hierarchical Data Structures

  5. 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.

  6. 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.

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

  8. 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

  9. 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

  10. 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

  11. 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

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

  13. Entity-Relationship Diagrams

  14. 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

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

  16. 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

  17. 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

  18. 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.

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

  20. 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

  21. 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

  22. 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

  23. 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

  24. DFD Refinement

  25. 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 Report Results Table2.CSV Printer - Command - PN data User

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

  27. tbl_Classification • DFD/CFD Level 2 - Validate Data Make tbl_createdWKConn 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) Print / Save Data Criteria: - dbs - strCriteria - strOrigPN Criteria: - dbs - strOrigPN Make tbl_createdT1 Table1 Delimited Text information T2 Field data Make tbl_createdT2 tbl_createdT2 Relevant T2 Record(s) Table2 Delimited Text information

  28. 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 Recreate tbl_createdT2 qry_Table2PrelimUnique Table2 Delimited Text information Table2 Query Results Relevant T2Record(s)

  29. 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

  30. State Transition Diagram

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

  32. 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

  33. Rules Condition 1 2 Actions 1 2 Decision Table

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

  35. Petri Nets • Sequential Process • F(StateA, Event1, Event2, Event3)  StateS • F(StateA, Event1, Event2, Event3)  (StateS1,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  Generating  Activity • Resulting Activity  Storage Device

More Related