analysis co cept s principles 2009

8/2/2019 Analysis Co Cept s Principles 2009

1/20

Analysis Concepts and Principles

These slides are based in part on those provided by the textbook publisher, the text book author, and Dr. RalphD. Meeker. They are copyright by various people including Roger S. Pressman & Associates, Inc., McGraw HillCompanies, Inc., Dr. Ralph D. Meeker and Dr. John Kevin Doyle.


2/20

What Problem Are We Trying to Solve?

The customer has only a vague idea of what is

required

The developer is willing to proceed with thevague idea on the assumption that well fill

in the details as we go along

The customer keeps changing requirements

The developer is ratcheted by these changes,

making errors in specifications anddevelopment

and so it goes


3/20

Software Requirements Analysis

Identify the customer and work together to

negotiate product-level requirements

Build an analysis model

focus on data

define function

represent behavior

Prototype areas of uncertainty

Develop a specification that will guide design

Conduct formal technical reviews


4/20

Requirements Gathering The most common technique to bridge the

communications gap between customer anddeveloper is via a preliminary meeting orinterview

One particular method used in this area is

FAST Facilitated Application SpecificationTechnique

The goal in FAST is to identify the problem,propose elements of the solution, negotiate

different approaches, and specify a preliminaryset of solution requirements in an atmospherewhich is conducive to accomplishing that goal


5/20

Requirements Gathering -- FAST

Meeting at neutral site Software engineers and customer participate

Rules for preparation agreed in advance

Rules for participation agreed in advance

Set a reasonably formal agenda

Facilitator controls the meeting; dont get mired

in technical detail

A definition mechanism is used (flipcharts,

easel sheets, post-its, chat room, )


6/20

Requirements Gathering -- FASTFacilitated Application Specification Techniques

SoftwareEngineering

Group

CustomerGroup


7/20

Use Cases A collection of scenarios that describe the thread of

usage of a system

Each scenario is described from the point-of-viewof an actor a person or device that interactswith the software in some way

Each scenario answers the following questions:

What are the main tasks or functions performed by theactor?

What system information will the actor acquire, produce orchange?

Will the actor inform the system about environmentalchanges?

What information does the actor require of the system? Does the actor wish to be informed about unexpected

changes?


8/20

Software Requirements Analysis

Identify the customer and work together to

negotiate product-level requirements

Build an analysis model

focus on data

define function

represent behavior

Prototype areas of uncertainty

Develop a specification that will guide design

Conduct formal technical reviews


9/20

The Analysis Process

the problemrequirements

elicitation

build aprototype

createanalysis

models

developSpecification Review


10/20

Analysis Principles -- Overview

Represent and understand (model) the

information domain Define (model) functions for the software

Model behavior of the software as aconsequence of external events

Models for information, function, and behaviormust be partitioned to uncover details in alayered or hierarchical fashion

Analysis process should move from essential

(logical) information toward implementation(physical) detail


11/20

Analysis Principles

Model the Information Domain

Define data objects

Represent data relationships

Represent data flow how do data and control

change as each moves through a system? Specify data content attributes


12/20

Analysis Principles

Model Function and Behavior Identify functions that transform data objects

Input

Processing

Output

Indicate different states of the system

Specify events that cause the system to change

state

Can define a state diagram (waiting,computing, printing, polling, etc.)

State changes are triggered by events


13/20

Analysis Principles

Partition the Models

Refine each model to represent lower levels ofabstraction

Refine data objects

Create a functional hierarchy Represent behavior at different levels of

detail

An iterative process


14/20

Analysis Principles

Essence vs. Implementation Begin by focusing on essence

Partition to represent implementation-related

content

Iterate between the two domains until acomplete specification has been developed

Hard in practice, but imperative!


15/20

Software Prototyping

Requirements analysis can be facilitated bybuilding a model of the software to be built

Used for customer and developer assessment

Sometimes, the prototype is the only meansthrough which requirements can be effectivelyderived


16/20

Software Prototyping Approaches

Closed-ended throwaway prototype

Open-ended evolutionary prototype

Consider prototype candidacy factors:

Is the application domain understood?

Can be problem be modeled?

Is the customer certain of basic systemrequirements?

Are requirements established/stable?

Are any requirements ambiguous? Are there contradictions in the requirements?


17/20


Approach SelectionQuestion Throwaway Evolutionary Additional

WorkIs the application domainunderstood?

Yes Yes No

Can the problem be modeled? Yes Yes NoIs the customer certain of

basic requirements?

Yes/No Yes/No No

Are requirements establishedand stable

No Yes Yes

Are any requirementsambiguous?

Yes No Yes

Are there contradictions in the

requirements?

Yes No Yes


18/20


Method and Tools Fourth Generation Techniques (4GTs)

Database and query languages

Program and application generators

Reusable Software Components Abstract Data Types (ADTs)

Programs

Modules

Formal Specification and PrototypingEnvironments


19/20

Requirements Specification

Outline


20/20

Requirements Specification

Formal Review Conducted by both software developer and

customer

Want to ensure specification is complete,consistent, and accurate

analysis co cept s principles 2009

Documents