Analysis Concept & Principlekal@ittelkom.ac.id

OutlineRequirement AnalysisRule Of ThumbOperational PrincipleInformation DomainModeling PartitioningAnalysis Modeling

Requirements AnalysisSpecifies softwares operational characteristicsIndicates software's interface with other system elements Establishes constraints that software must meet

Requirements AnalysisRequirements analysis allows the software engineer (analyst or modeler in this context) to:elaborate on basic requirements established during earlier requirement engineering tasksbuild models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed.

A Bridge

Rules of ThumbThe model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system.Delay consideration of infrastructure and other non-functional models until design. Minimize coupling throughout the system. Be certain that the analysis model provides value to all stakeholders. Keep the model as simple as it can be.

Operational PrinciplesThe information domain of a problem must be represented and understood.The functions that the software is to perform must be defined.The behavior of the software must be represented.The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion.The analysis process should move from essential information toward implementation detail.

Information DomainThe information domain contains three different views of the data and controlinformation content and relationships (the data model), information flow, andinformation structure.

Information ContentRepresents the individual data and control objects that constitute some larger collection of information transformed by the software.Data and control objects can be related to other data and control objects. During the analysis of the information domain, the relationships should be defined.

Information FlowRepresents the manner in which data and control change as each moves through a system.

Information StructureRepresents the internal organization of various data and control items. Within the context of the structure, what information is related to other information? Is all information contained within a single structure or are distinct structures to be used? How does information in one information structure relate to information in another structure?

ModelingCreate functional models to gain a better understanding of the actual entity to be built. It must be capable of representing the information that software transforms, the functions (and sub-functions) that enable the transformation to occur, and the behavior of the system as the transformation is taking place.

Functional modelsSoftware transforms information, and in order to accomplish this, it must perform at least three generic functions: input, processing, and output. When functional models of an application are created, the software engineer focuses on problem specific functions. The functional model begins with a single context level model Over a series of iterations, more and more functional detail is provided, until a thorough delineation of all system functionality is represented.

Behavioral modelsMost software responds to events from the outside world.For example, software will remain in the wait state until:an internal clock indicates that some time interval has passed, an external event causes an interrupt, or an external system signals the software to act in some manner. A behavioral model creates a representation of the states of the software and the events that cause a software to change state.

Model Models created during requirements analysis serve a number of important roles:The model aids the analyst in understanding the information, function, and behavior of a system, thereby making the requirements analysis task easier and more systematic.The model becomes the focal point for review and, therefore, the key to a determination of completeness, consistency, and accuracy of the specifications.The model becomes the foundation for design, providing the designer with an essential representation of software that can be "mapped" into an implementation context.

PartitioningProblems are often too large and complex to be understood as a whole. In essence, partitioning decomposes a problem into its constituent parts. Conceptually, we establish a hierarchical representation of function or information and then partition the uppermost element by exposing increasing detail by moving vertically in the hierarchy, or functionally decomposing the problem by moving horizontally in the hierarchy

Horizontal Partitioning

Vertical Partitioning

Analysis ModelingThe analysis model must achieve three primary objectives: to describe what the customer requires, to establish a basis for the creation of a software design, and to define a set of requirements that can be validated once the software is built.

The structure of the analysis model

ReviewRequirement AnalysisRule Of ThumbOperational PrincipleInformation DomainModeling PartitioningAnalysis Modeling

*By applying these principles, the analyst approaches a problem systematically. Theinformation domain is examined so that function may be understood more completely.Models are used so that the characteristics of function and behavior can becommunicated in a compact fashion. Partitioning is applied to reduce complexity.Essential and implementation views of the software are necessary to accommodatethe logical constraints imposed by processing requirements and the physical constraintsimposed by other system elements.