Lesson 3 :ANALYSIS MODELLING Lesson 3


Requirement Analysis :Requirement Analysis Requirements analysis is a software engineering task that bridges the gap between system level requirements and software design(figure 1.1) Requirements analysis provides the software designer with a representation of information , function and behavior that can be translated to data, architectural, interface, and component level designs. Finally the requirements specification provides the developer and the customer with the means to assess quality once the software is built. Software requirements analysis may be divided into five areas of effort: (1) Problem recognition (2)Evaluation and synthesis ,(3) Modeling, (4) Specification and (5) Review Initially, the analyst studies the System Specification(if one exists and the Software Project Plan . 2


Slide 3:During the evaluation and solution synthesis activity, the analyst creates models of the system in an effort to better understand data and control flow, functional processing, operational behavior, and information content. The model serves as a foundation for software design and as the basis for the creation of specifications for the software. Requirements Elicitation for Software Before requirements can be analyzed, modeled or specified they must be gathered through an elicitation process. Initiating the process The most commonly used requirements elicitation technique is to conduct a meeting or interview. Facilitated Application Specification Techniques 3


Identifying Objects and Operations :Identifying Objects and Operations Define “objects” by underling all nouns in the written statement of scope producer/consumers of data places where data are stored “composite” data item Define “operations” by double underling all active verbs processes relevant to the application data transformations Consider other “services” that will be required by the objects 4


Slide 5:Data Modeling and Entity Relationship(E-R) Diagramming 5


Slide 6:Why Data Modeling examines data objects independent of processing focuses attention on data domain creates a model at the customer’s level of abstraction indicates how data objects relate to one another 6


: What is a data Object? Object - something that is described by a set of attributes (data items) and that will be manipulated within the software (system). Each instance of an object (e.g., a book) can be identified uniquely( e.g., ISBN#) Each plays a necessary role in the system I.e., the system could not function without access to the instances of the object Each is described by the attributes that are themselves data items 7


Typical Objects :Typical Objects external entities( printer, user, sensor) things ( e.g., reports, displays, signals) occurrences or events ( e.g., interrupt, alarm) roles (e.g., manager, engineer, salesperson) organizational units (e.g., division, team) places (e.g., manufacturing floor) structures (e.g., employee record) 8


Data Objects and attributes :Data Objects and attributes A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object Object: automobile Attributes:make model body type price options code 9


What is a Relationship? :What is a Relationship? relationship- indicates “connectedness” ;a fact that must be remembered by the system and cannot or is not computed or derived mechanically. several instances of a relationship can exist objects can be related in many different ways 10


ERD Notation :ERD Notation Relationship Attribute (1,1) (0,m) Relationship (0,m) (1,1) Object1 Object 2 Object1 Object 2 One common form Another common form 11


Building an ERD :Level 1 - model all data objects (entities) and their “connections” to one another Level 2 - model all entities and relationships Level 3 - model all entities, relationships, and the attributes that provide further depth Building an ERD 12


The ERD : An example :The ERD : An example Customer places Standard task table Selected from Work tasks materials lists Consists of generate Request for service Work order (1,1) (1,i) (1,1) (1,m) (1,w) (1,1) (1,w) (1,n) (1,1) (1,1) 13


Creating a Flow Model :Creating a Flow Model 14


Slide 15:The Flow Model Every computer-based system is an information transform…. Computer based system input output 15


Flow Modeling Notation :Flow Modeling Notation external entity process data flow data store 16


Slide 17:External entity A producer or consumer of data Examples: a person, a device, a sensor Another example: a computer based system Data must always originate somewhere and must always be sent to something 17


Process :Process A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function 18


Data Flow :Data Flow Data flows through a system, beginning as input and be transformed into output. Compute triangle area base height area 19


Slide 20:Data Stores Data is often stored for later use Sensor # Report required Look up sensor data Sensor#, type, location, age Type, location, age Sensor number Sensor data 20


Data Flow Diagramming: Guidelines :Data Flow Diagramming: Guidelines all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with the context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic 21


Slide 22:Constructing a DFD review ERD to isolate data objects and grammatical parse to determine “operations” determine external entities (producers and consumers of data) create a level 0 DFD. 22


Level 0 DFD Example :Level 0 DFD Example user video source Digital video processor monitor NTSC video signal Processing request requested video signal 23


Slide 24:Constructing a DFD- II write a narrative describing the transform parse to determine next level transform “balance” the flow to maintain data flow continuity develop a level 1 DFD use a 1:5 (approx.) expansion ratio 24


The Data Flow Hierarchy :The Data Flow Hierarchy Level 1 p1 p5 p2 p3 p5 y x f e b d a a c b g Level 0 p 25


Slide 26:Flow Modeling Notes each bubble is refined until it does just one thing the expansion ratio decreases as the number of levels increase most systems require between 3 and 7 levels for an adequate flow model a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information) 26


DFDs: A look Ahead :DFDs: A look Ahead Maps Info Design Model Analysis Model 27


Behavioral Modeling and Process Specification :Behavioral Modeling and Process Specification 28


Behavioral Modeling :Behavioral Modeling Outside world Application events behavior 29


The States of a System :The States of a System State: a set of observable circumstances that characterizes the behavior of a system at a given time State transition: the movement from one state to another Event: an occurrence that causes the system to exhibit some predictable form of behavior Action- process that occurs as a consequence of making a transition 30


Behavioral Modeling :make a list of different states of the system(How does the system behave?) indicate how the system makes a transition from one state to another (How does the system change state?) indicate event indicate action draw a state transition diagram Behavioral Modeling 31


State Transition Diagram Notation :State Transition Diagram Notation 32 Event causing transaction Action that occurs new state state


State Transition Diagram :State Transition Diagram Jammed Invoke problem-diagnosis Invoke read-op-input Not jammed empty Invoke reload paper Invoke read-op-input Invoke manage-copying full Copies done Full and start Invoke read-op-input Making copies Reading operator commands Reloading paper Problem state 33


The Control model :The Control model the control flow diagram is superimposed on the DFD and shows events that control the processes noted in the DFD. control flows- events and control items- are noted by dashed arrows a vertical bar implies an input to or output from a control spec (CSPEC) - a separate specification that describes how control is handled. a dashed arrow entering a vertical bar is an input to the CSPEC a dashed arrow leaving a process implies a data condition a dashed arrow entering a process implies a control input read directly by the process control flows do not physically activate/deactivate the processes- this is done via the CSPEC 34


Control flow diagram :Control flow diagram 35 start beeper on/off empty jammed display panel enabled problem light full


Control Specification(CSPEC) :Control Specification(CSPEC) The CSPEC can be: state transition diagram(sequential spec) state transition table decision tables activation tables Combinatorial spec 36


Slide 37:Guidelines for Building a CSPEC list all sensors that are “read” by the software list all interrupt conditions list all “switches” that are actuated by the operator list all data conditions recalling the noun-verb parse that was applied to the software statement of scope, review all “control items” as possible CSPEC inputs/outputs describe the behavior of a system by identifying its states; identify how each state is reached and defines the transitions between states focus on possible omissions.. Avery common error in specifying control, e.g., ask ; “Is there any other way I can get to this state or exit from it?” 37


Process Specification (PSPEC) :Process Specification (PSPEC) narrative pseudocode(PDL) equations tables diagrams and/or charts PSPEC bubble 38


Slide 39:A Design Note 39 PSPEC One or more “components” in the software design


Slide 40:Creating Mini-Specs 40 Software specification


Slide 41:The Data Dictionary a quasi-formal grammar for describing the content of data that the software will process and create a notation for describing control data and the values that control data can take, e.g., “on”, or “off” a repository that also contains “where-used”/”how used” information a notation that can be represented manually, but is best developed using CASE tools 42


Slide 42:Building a Data Dictionary Name: the primary name of the corporate data item Aliases: other names for the data item Where used: data transforms (processes) that use the composite data item How used: the role of the data item (input, output, temporary storage,etc) Description: a notation for representing content (presented on the next slide) Format: specific information about data types, pre- set values(if known) 43


Slide 43:Data Dictionary Notation Notation Meaning = is composed of + and [ | ] either - or { }n n repetitions of (….) optional data *…text…* delimits a comment 44


Slide 44:Data Dictionary Example 45 Telephone number Integrated office phone system System output Build the requirements dictionary: Name: telephone number Aliases: phone number, number Where/how used: read-phone number(input) display- phone number(output) analyze - long distance calls(input) Description: telephone no =[local extension|outside no| 0] outside no= 9 + [service code|domestic no.] service code =[211|411|611|911] domestic number = ((0)) + area code ) + local number, area code Format: alphanumeric data


Slide 45:Writing the Software Specification 46 Everyone knew exactly what had to be done until someone wrote it down !


Slide 46:Specification Guidelines use a layer format that provides increasing detail as the “layers” deepen use consistent graphical notation and apply textual terms consistently(stay away from aliases) be sure to define all acronyms be sure to include a table of contents; ideally, include an index and /or a glossary write in simple, unambiguous style always put yourself in the reader’s position, “would I be able to understand this if it wasn’t intimately familiar with the system ?” 47


Slide 47:Specification Guidelines Be on the lookout for persuasive connectors, ask why? Keys:certainly, clearly, obviously, it follows that.. Watch out for vague terms Keys:some,sometimes,often,usually,ordinarily,most When lists are given, but not completed,be sure that all terms are understood. Keys:etc, and so forth, such as. Be sure stated ranges don’t contain unstated assumptions e.g. , Valid codes range from 10 to 100? Real?Hex? Beware of vague verbs such as handled, rejected, processed Beware of “passive voice “statements e.g.,The parameters are initialized. By what? Beware of “dangling” pronouns. e.g.,The I/O module communicated with the data validation module and its control flag is set. Whose control flag? 48


Slide 48:Requirement When a term is explicitly defined in one place, try substituting the definition for other occurrences of the term When a structure is described by words, draw a picture When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure When symbolic equations are used, try expressing their meaning in words When a calculation is specified, work at least two examples Look for statements that imply certainty, then ask for proof . Keys: always, every, all, none, never Search behind certainty statements- be sure restrictions or limitations are realistic 49