Chapter Summary

(See related pages)

The analysis model is the first technical representation of a system. Analysis modeling uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way. uilding analysis models helps ma!e it easier to uncover requirement inconsistencies and omissions. Two types of analysis modeling are commonly used" structured analysis and ob#ect$oriented analysis. Scenario$ based modeling represents the system from the user%s point of view. &low$oriented modeling shows how data are transformed inside the system by processing functions. 'lass$based modeling defines ob#ects, attributes, and relationships. ehavioral modeling uses state transition diagrams to show the impact of events on the system states. Analysis wor! products must be reviewed for completeness, correctness, and consistency. Analysis (odel )uidelines Analysis products must be highly maintainable, especially the software requirements specification. *roblems of si+e must be dealt with using an effective method of partitioning. )raphics should be used whenever possible. ,ifferentiate between the logical (essential) and physical (implementation) considerations. &ind something to help with requirements partitioning and document the partitioning before specification. ,evise a way to trac! and evaluate user interfaces. ,evise tools that describe logic and policy better than narrative text. Analysis (odel -b#ectives ,escribe what the customer requires. .stablish a basis for the creation of a software design. ,evise a set of requirements that can be validated once the software is built. Analysis (odel /ules of Thumb The model should focus on requirements that are visible within the problem or business domain and be written as a relatively high level of abstraction. .ach element of the analysis model should add to the understanding of the requirements and provide insight into the information domain, function, and behavior of the system. ,elay consideration of infrastructure and non$functional models until design. (inimi+e coupling throughout the system. e certain the analysis model provides value to all sta!eholders. 0eep the model as simple as possible. ,omain Analysis Activities ,efine the domain to be investigated 'ategori+e the items extracted from the domain 'ollect a representative sample of applications in the domain Analy+e each application in the sample o 1dentify candidate reusable ob#ects o 1ndicate reasons the ob#ects may be reused o ,efine adaptations of the ob#ects that may be reused o .stimate percentage of applications in the domain that might ma!e reuse of the ob#ects o 1dentify ob#ects by name and use configuration management techniques to control them ,evelop an analysis model for the ob#ects Structured Analysis (odel .lements ,ata dictionary $ contains the descriptions of all data ob#ects consumed or produced by the software .ntity relationship diagram (./,) $ depicts relationships between data ob#ects ,ata flow diagram (,&,) $ provides an indication of how data are transformed as they move through the system2 also depicts functions that transform the data flow (a function is represented in a ,&, using a process specification or *S*.') State diagram (S,) $ 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 'S*.')