1

Chapter 8Chapter 8 Building the Analysis Model Building the Analysis Model

(1)(1)

Analysis Concepts and Analysis Concepts and PrinciplesPrinciples

2

I know you believe you understood what you think I said, but I am not sure you realise that what you heard is not what I meant……”

3

SwReq_1: The item shall ...SwReq_1: The item shall ...SwReq_2: ...SwReq_2: ...……....SwReq_X: ...SwReq_X: ...

What is a Requirement ?What is a Requirement ?

Requirement:Requirement: contractual condition and/or capability (external customer(*))contractual condition and/or capability (external customer(*)) industrial constraint (system engineering group, marketing, ...)industrial constraint (system engineering group, marketing, ...) states WHAT the system/software item must do, not HOW it does it.states WHAT the system/software item must do, not HOW it does it.

Specification: a list of technical requirementsSpecification: a list of technical requirements

Requirement trace-ability, necessary to ensure development coherenceRequirement trace-ability, necessary to ensure development coherence

4

11

2233

Functional technical Functional technical requirementsrequirements

• Capabilities• Dynamic behaviour• Data manipulation

Non-functional technical Non-functional technical requirementsrequirements

• Operational security• Safety• Availability• Reliability• Maintainability• Ergonomics• Performance• Constraints

Non-technical requirementsNon-technical requirements• Contractual milestones• Required methods and

techniques

Types of RequirementsTypes of Requirements

5

How Must Be A Requirement ?How Must Be A Requirement ?

Easily IdentifiableEasily Identifiableby a well–determined name and a unique by a well–determined name and a unique

reference in the system.reference in the system.

UnambiguousUnambiguousOnly 1 possible interpretation is possibleOnly 1 possible interpretation is possible

TestableTestableA test case can be defined to test the A test case can be defined to test the

requirementrequirement

6

What is Software Requirements What is Software Requirements Analysis?Analysis?

The software requirements analysis is The software requirements analysis is to understand the specific to understand the specific requirements that must be achieved requirements that must be achieved to build high quality software.to build high quality software.

7

Software Requirements Software Requirements Analysis as a BridgeAnalysis as a Bridge

System Engineering

Software Requirements

Analysis

Software Design

8

Software Requirements Software Requirements AnalysisAnalysis

Requirements analysis is a software Requirements analysis is a software engineering task that bridges the gap engineering task that bridges the gap between system level requirements between system level requirements engineering and software design.engineering and software design.

Software requirements analysis may be Software requirements analysis may be divided into five areas of effort:divided into five areas of effort:Problem recognitionProblem recognition Evaluation and synthesisEvaluation and synthesisModelingModelingSpecificationSpecificationReviewReview

9

The Software requirements The Software requirements Analysis ProcessAnalysis Process

the problemthe problemrequirementsrequirements

elicitationelicitation

build abuild aprototypeprototype

createcreateanalysisanalysismodelsmodels

developSpecification ReviewReview

10

The Phases of Software The Phases of Software Requirements AnalysisRequirements Analysis

identify the “customer” and work together to identify the “customer” and work together to negotiate “product-level” requirementsnegotiate “product-level” requirements

build an analysis modelbuild an analysis model focus on datafocus on data define functiondefine function represent behaviorrepresent behavior

give out prototype areas of uncertaintygive out prototype areas of uncertainty develop a specification that will guide designdevelop a specification that will guide design conduct formal technical reviewsconduct formal technical reviews

11

What Are the Real Problems of What Are the Real Problems of Analysis?Analysis?the customer has only a vague idea of what is the customer has only a vague idea of what is

requiredrequired

the developer is willing to proceed with the the developer is willing to proceed with the "" vague idea" on the assumption that "we'll fill in vague idea" on the assumption that "we'll fill in the details as we go"the details as we go"

the customer keeps changing requirementsthe customer keeps changing requirements

the developer is "racheted" by these changes, the developer is "racheted" by these changes, making errors in specifications and development making errors in specifications and development

and so it goes ...and so it goes ...

12

Requirements Requirements GatheringGatheringFacilitated Application Specification TechniquesFacilitated Application Specification Techniques

SoftwareSoftwareEngineeringEngineering

GroupGroupCustomerCustomer

GroupGroup

13

FAST FAST GuidelinesGuidelines participants must attend entire meetingparticipants must attend entire meeting

all participants are equalall participants are equal preparation is as important as meetingpreparation is as important as meeting all pre-meeting documents are to be viewed as all pre-meeting documents are to be viewed as

“proposed”“proposed” off-site meeting location is preferredoff-site meeting location is preferred set an agenda and maintain itset an agenda and maintain it don’t get mired in technical detaildon’t get mired in technical detail

J. Wood & D. Silver

14

Quality Function Quality Function Deployment (QFD)Deployment (QFD)

QFD identifies three types of requirements:QFD identifies three types of requirements:Normal requirementsNormal requirements, must be met;, must be met; Expected requirementsExpected requirements, should be met;, should be met; Exciting requirementsExciting requirements, be care for;, be care for;

QFD has three activities:QFD has three activities: Function deploymentFunction deployment determines the “value” (as perceived determines the “value” (as perceived

by the customer) of each function required of the systemby the customer) of each function required of the system Information deploymentInformation deployment identifies data objects and events identifies data objects and events Task deploymentTask deployment examines the behavior of the system examines the behavior of the system

Value analysisValue analysis determines the relative priority determines the relative priority of requirementsof requirements

15

Use-Use-CasesCases The use-cases (scenarios) provide a description of The use-cases (scenarios) provide a description of

how the system will be used.how the system will be used. Each use-case is described from the point-of-view Each use-case 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 system or product in some waywith the system or product in some way

Each use-case answers the following questions:Each use-case answers the following questions:What are the main tasks of functions performed by the actor?What are the main tasks of functions performed by the actor?What system information will the actor acquire, produce or What system information will the actor acquire, produce or

change?change?Will the actor inform the system about environmental changes?Will the actor inform the system about environmental changes?What information does the actor require of the system?What information does the actor require of the system?Does the actor wish to be informed about unexpected changesDoes the actor wish to be informed about unexpected changes

16

The Analysis The Analysis ModelModel

Data Model

BehavioralModel

FunctionalModel

17

Analysis Principle I: Analysis Principle I: Model the Data DomainModel the Data Domain

define data objectsdefine data objects describe data attributesdescribe data attributes establish data relationshipsestablish data relationships

18

Analysis Principle II: Analysis Principle II: Model FunctionModel Function

identify functions that transform data objectsidentify functions that transform data objects indicate how data flow through the systemindicate how data flow through the system represent producers and consumers of datarepresent producers and consumers of data

19

Analysis Principle III: Model Analysis Principle III: Model BehaviorBehavior

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 IV: Analysis Principle IV: Partition 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 levels of represent behavior at different levels of

detaildetail

21

Analysis Principle V: Analysis Principle V: EssenceEssence

begin by focusing on the begin by focusing on the essence of the problem essence of the problem without regard to without regard to implementation detailsimplementation details

22

Notes of Requirements Notes of Requirements AnalysisAnalysis

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

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

Record the origin and the reason for every Record the origin and the reason for every requirement. requirement.

Use multiple views of requirements. Use multiple views of requirements. Prioritize requirements. Prioritize requirements. Work to eliminate ambiguity. Work to eliminate ambiguity.

23

What is a What is a Specification ?Specification ?

Its main objective is to lay down the Its main objective is to lay down the foundations of the agreement to be foundations of the agreement to be ratified by the customer and the ratified by the customer and the manufacturermanufacturer

It consists in a list of technical It consists in a list of technical requirements which the requirements which the system/software must meetsystem/software must meet

It ensures, as far as possible, the It ensures, as far as possible, the feasibility of the system / software.feasibility of the system / software.

24

The Objective of Specification is to The Objective of Specification is to Analysis and UnderstandAnalysis and Understand

FirstStep

SpecificationDocument(s)

IterativeSteps

FinalStep

Reports

25

The Objective of Specification is to The Objective of Specification is to CommunicateCommunicate

ORGANISATION

DEVELOPER

CUSTOMER

DIFFERENT POINTS OF VIEW:DIFFERENT POSSIBLE

INTERPRETATION

26

The Objective of Specification is The Objective of Specification is to to Ensure the FeasibilityEnsure the Feasibility

Logical feasibility:Logical feasibility:The availability of all required information The availability of all required information

must be guaranteed,must be guaranteed,The complements required to ensure such The complements required to ensure such

availability must be identified.availability must be identified. Technical feasibility:Technical feasibility:

Complementary studiesComplementary studiesPrototypesPrototypesMock-upMock-up

Economic feasibilityEconomic feasibilityRespect cost & delayRespect cost & delay

27

The Objective of Specification is The Objective of Specification is to to Ensure Traceability of Ensure Traceability of

RequirementsRequirementsA major specification goal:A major specification goal:

System RequirementsSystem Requirements versusversus Software RequirementsSoftware RequirementsSoftware RequirementsSoftware Requirements versusversus Software DesignSoftware DesignSoftware RequirementsSoftware Requirements versusversus Software QualificationSoftware Qualification

SOFTWARESYSTEM SwReq_01 SwReq_02 ….. SwReq_xy

SystReq_01 XSystReq_02 X XSystReq_03

…… X XSystReq_nm X

…..

28

The Objective of Specification is The Objective of Specification is to to Prepare the DesignPrepare the Design

Requirements Analysis & Specification

Architectural Design

Detailed Design

Implementation

Integration

Validation Qualification

Unit Test

SpecificationDocument(WHAT?)

DesignDocument

(HOW?)

29

FromSpecified Requirements

ToTest Cases

The Objective of Specification is to The Objective of Specification is to Qualify the Software ProductQualify the Software Product

SpecificationDocument(s)

QualificationDocumentsSTP - STD

30

The Objective of Specification is The Objective of Specification is to to Organise & Manage the Organise & Manage the

DevelopmentDevelopment

Consolidation of the costConsolidation of the cost Specification enables refining of initial Specification enables refining of initial

estimations: estimations: size, costs, lead timessize, costs, lead times..

Definition of incrementsDefinition of increments Where the incremental developmentWhere the incremental development

approach is adopted.approach is adopted.

31

Specification Specification PrinciplesPrinciples

1. 1. Separate functionality from implementation.Separate functionality from implementation.

2. Develop a model of the desired behaviour of a 2. Develop a model of the desired behaviour of a system.system.

3. Establish the context of software operates.3. Establish the context of software operates.

4. Define the environment of system operates.4. Define the environment of system operates.

5. Create a cognitive model.5. Create a cognitive model.

6. Recognize that “the specification must be 6. Recognize that “the specification must be tolerant of incompleteness and augment-able.”tolerant of incompleteness and augment-able.”

7. Establish the content and structure of a 7. Establish the content and structure of a specification.specification.

32

Software ContextSoftware Context

System

Sub-system

Softwareitem

Softwareitem

Hardwareitem

Softwareitem

Softwareitem

Hardwareitem

InterfaceSpecification

Sub-system

33

The Steps of Creating a The Steps of Creating a SpecificationSpecification

The steps of creating a specification of The steps of creating a specification of requirements:requirements:RepresentationRepresentation The Software Requirements SpecificationThe Software Requirements SpecificationSpecification ReviewSpecification Review