1

Chapter 11Chapter 11Analysis Concepts and Analysis Concepts and

PrinciplesPrinciples

2

Requirements Requirements AnalysisAnalysis

3

Requirements Requirements AnalysisAnalysis

Result in the Result in the specificationspecification of of software’s operational characteristicssoftware’s operational characteristics

Indicate software’s Indicate software’s interfaceinterface with with other system elementsother system elements

Establish Establish constraintsconstraints that software that software must meetmust meet

4

Requirements Requirements AnalysisAnalysis

Analyst – to refine the software Analyst – to refine the software allocation and allocation and build modelsbuild models of the of the data, functional, and behavioral data, functional, and behavioral domains that will be treated by domains that will be treated by software. software.

Designer – provide a representation of Designer – provide a representation of information, function, and behavior information, function, and behavior that can be that can be translatedtranslated to data, to data, architectural, interface, and architectural, interface, and component-level designs.component-level designs.

Developer and customer – to assess Developer and customer – to assess qualityquality once software is built. once software is built.

5

Requirements Requirements AnalysisAnalysis

Five areas of effortFive areas of effort•Problem recognitionProblem recognition• Evaluation and solution synthesis Evaluation and solution synthesis •ModelingModeling•SpecificationSpecification•ReviewReview

6

The Analysis The Analysis ProcessProcess

the problemthe problem1.1.

requirementsrequirementselicitationelicitation

3.3.build abuild a

prototypeprototype

2.2.createcreate

analysisanalysismodelsmodels

4.develop

Specification

5.5.ReviewReview

10

Facilitated Application Facilitated Application Specification Specification

Techniques (FAST)Techniques (FAST)A A meetingmeeting is conducted at a neutral site is conducted at a neutral site and attended by both software and attended by both software engineers and customers.engineers and customers.

RulesRules for preparation and participation for preparation and participation are established.are established.

An An agendaagenda is suggested that is formal is suggested that is formal enough to cover all important points but enough to cover all important points but informal enough to encourage the free informal enough to encourage the free flow of ideas.flow of ideas.

A “A “facilitatorfacilitator” controls the meeting.” controls the meeting.A “A “definition mechanismdefinition mechanism” is used” is used……..

11

Quantity Function Quantity Function DeploymentDeployment

(QFD)(QFD)QFD is a quality management QFD is a quality management

technique that translates the technique that translates the needs needs of the customerof the customer into into technical technical requirementsrequirements for software. for software.

Three types of requirementsThree types of requirements•Normal requirementNormal requirement• Expected requirementExpected requirement• Exciting requirement Exciting requirement

12

Use-Use-CasesCases A collection of scenarios that describe the thread A collection of scenarios that describe the thread

of usage of a systemof usage of a system Each scenario is described from the point-of-view Each scenario is described from the point-of-view

of an “actor”—a person or device that interacts of an “actor”—a person or device that interacts with the software in some waywith the software in some way

Each scenario answers the following questions:Each scenario answers the following questions:• What are the main tasks of functions performed What are the main tasks of functions performed

by the actor?by the actor?• What system information will the actor acquire, What system information will the actor acquire,

produce or change?produce or change?• Will the actor inform the system about Will the actor inform the system about

environmental changes?environmental changes?• What information does the actor require of the What information does the actor require of the

system?system?• Does the actor wish to be informed about Does the actor wish to be informed about

unexpected changesunexpected changes

13

2. Analysis 2. Analysis ModelModel

Data Model

BehavioralModel

FunctionalModel

14

Analysis Analysis PrinciplesPrinciples

1.1. The The information domaininformation domain of a problem of a problem must be represented and understood.must be represented and understood.

2.2. The The functionsfunctions that the software is to that the software is to perform must be defined.perform must be defined.

3.3. The The behaviorbehavior of the software must be of the software must be represented.represented.

4.4. The The modelsmodels that depict information, that depict information, function, and behavior must be function, and behavior must be partitionedpartitioned in a manner that uncovers in a manner that uncovers detail in a layered fashion.detail in a layered fashion.

5.5. The analysis The analysis processprocess should move should move from essential information toward from essential information toward implementation detail.implementation detail.

15

Analysis Guiding Analysis Guiding PrinciplePrinciple

Understand the problem Understand the problem before you before you begin to create the analysis modelbegin to create the analysis model..

Develop prototypes Develop prototypes that enable a user that enable a user to understand how human/machine to understand how human/machine interaction will occur.interaction will occur.

Record the origin Record the origin of andof and the reason the reason for for ever requirement.ever requirement.

Use multiple views Use multiple views of requirementsof requirements.. Rank Rank requirements.requirements. Work to eliminate ambiguity.Work to eliminate ambiguity.

Davis

16

Analysis Principle IAnalysis Principle IModel the Data DomainModel the Data Domain

define data objectsdefine data objectsdescribe data attributesdescribe data attributesestablish data relationshipsestablish data relationships

17

18

Analysis Principle IIAnalysis Principle IIModel FunctionModel Function

identify functions that identify functions that transform data objectstransform data objects

indicate how data flow through indicate how data flow through the systemthe system

represent producers and represent producers and consumers of dataconsumers of data

19

Analysis Principle IIIAnalysis Principle IIIModel BehaviorModel Behavior

indicate different indicate different statesstates of the of the systemsystem

specify specify eventsevents that cause the that cause the system to change statesystem to change state

20

Analysis Principle IVAnalysis Principle IVPartition the ModelsPartition the Models

refine each model to represent refine each model to represent lower levels of abstractionlower levels of abstraction• refine data objectsrefine data objects• create a functional hierarchycreate a functional hierarchy• represent behavior at different represent behavior at different

levels of detaillevels of detail

21

PartitioniPartitioningng

Horizontally moving – decomposing Horizontally moving – decomposing problemproblem

Vertically moving – increasing detailVertically moving – increasing detail

22

23

Analysis Principle VAnalysis Principle VEssence & Implementation Essence & Implementation

ViewsViews

Essential view – the functions Essential view – the functions and informationand information

Implementation view – real Implementation view – real world manifestation of world manifestation of processing function and processing function and information structuresinformation structures

24

3. Software 3. Software PrototypingPrototyping Candidacy factorsCandidacy factors

• Application areaApplication area• Application complexityApplication complexity• Customer characteristicsCustomer characteristics• Project characteristicsProject characteristics

TypesTypes• close-ended (throwaway prototyping)close-ended (throwaway prototyping)• open-ended (evolutionary open-ended (evolutionary

prototyping)prototyping) MethodsMethods

• Fourth generation techniquesFourth generation techniques• Reusable software componentsReusable software components• Formal specification and prototyping Formal specification and prototyping

environmentsenvironments

25

26

4. Software Requirements 4. Software Requirements SpecificationSpecification

27

Specification Specification PrinciplesPrinciples

Separate functionality from implementationSeparate functionality from implementation Develop a desired behavior model of a Develop a desired behavior model of a

systemsystem Establish the contextEstablish the context Define the environmentDefine the environment Create a cognitive modelCreate a cognitive model Recognize incompleteness and augmentableRecognize incompleteness and augmentable Establish a changeable content and structure Establish a changeable content and structure

28

RepresentatRepresentationion

Representation format and content Representation format and content should be relevant to the problem.should be relevant to the problem.

Information contained within the Information contained within the specification should be nested.specification should be nested.

Diagrams and other notational forms Diagrams and other notational forms should be restricted in number and should be restricted in number and consistent in use.consistent in use.

Representations should be revisable.Representations should be revisable.

29

5. Specification 5. Specification ReviewReview

Ensure complete, consistent, and accurateEnsure complete, consistent, and accurate Not only broad descriptions, but wordedNot only broad descriptions, but worded ContractContract Change – increase costChange – increase cost Difficult to test – inconsistency and Difficult to test – inconsistency and

omissionsomissions