AnalysisConcepts and Principle

Requirements AnalysisRequirements Analysis

Five ActivitiesFive Activities Problem recognitionProblem recognition Evaluation and synthesisEvaluation and synthesis ModelingModeling SpecificationSpecification ReviewReview

Problem RecognitionProblem Recognition

Some problems to overcomeSome problems to overcome Understanding what the customer really wantsUnderstanding what the customer really wants Getting inside the customers requirementsGetting inside the customers requirements ““us-them” paradigm rather than “we”us-them” paradigm rather than “we” Federal Acquisition Regulations (FARs)Federal Acquisition Regulations (FARs)

Require customer to prepare specificationsRequire customer to prepare specifications Limit discussion between customer and supplier Limit discussion between customer and supplier

during bidding process.during bidding process.

Techniques for Requirements AcquisitionTechniques for Requirements Acquisition

Facilitated Application Specification Techniques (FAST)Facilitated Application Specification Techniques (FAST) Meeting (often at neutral site)Meeting (often at neutral site) Establish meeting rulesEstablish meeting rules Agenda to cover important pointsAgenda to cover important points a "facilitator" (can be a customer, a developer, or an outsider) controls the a "facilitator" (can be a customer, a developer, or an outsider) controls the

meetingmeeting a "definition mechanism" (can be work sheets, flip charts, or wall stickers a "definition mechanism" (can be work sheets, flip charts, or wall stickers

or an electronic bulletin board, chat room or virtual forum) is usedor an electronic bulletin board, chat room or virtual forum) is used the goal is the goal is

to identify the problemto identify the problem propose elements of the solutionpropose elements of the solution negotiate different approaches, andnegotiate different approaches, and specify a preliminary set of solution requirementsspecify a preliminary set of solution requirements

Techniques for Requirements AcquisitionTechniques for Requirements Acquisition

Facilitated Application Specification Facilitated Application Specification Techniques (FAST)Techniques (FAST) Refinement with subgroupsRefinement with subgroups

Techniques for Requirements AcquisitionTechniques for Requirements Acquisition

Quality Function DeploymentQuality Function Deployment Normal RequirementsNormal Requirements

What will make customer happyWhat will make customer happy

Expected RequirementsExpected Requirements Unstated requirements that are so “obvious” that Unstated requirements that are so “obvious” that

they need not be statedthey need not be stated

UnexpectedUnexpected RequirementsRequirements Enhancements beyond customer requirementsEnhancements beyond customer requirements

Quality Function DeploymentQuality Function Deployment

Function deploymentFunction deployment determines the “value” (as determines the “value” (as perceived by the customer) of each function perceived by the customer) of each function required of the systemrequired of the system

Information deploymentInformation deployment identifies data objects identifies data objects and eventsand events (tied to functions) (tied to functions)

Task deploymentTask deployment examines the behavior of the examines the behavior of the systemsystem

Value analysisValue analysis determines the relative priority of determines the relative priority of requirementsrequirements

Elicitation Work ProductsElicitation Work Products

a statement of need and feasibility.a statement of need and feasibility. a bounded statement of scope for the system or product.a bounded statement of scope for the system or product. a list of customers, users, and other stakeholders who a list of customers, users, and other stakeholders who

participated in requirements elicitation participated in requirements elicitation a description of the system’s technical environment.a description of the system’s technical environment. a list of requirements (preferably organized by function) a list of requirements (preferably organized by function)

and the domain constraints that apply to each.and the domain constraints that apply to each. a set of usage scenarios that provide insight into the use of a set of usage scenarios that provide insight into the use of

the system or product under different operating conditions.the system or product under different operating conditions. any prototypesany prototypes developed to better define requirementsdeveloped to better define requirements.

Use-CasesUse-Cases

A collection of user scenarios that describe the thread of usage of a systemA collection of user scenarios that describe the thread of usage of a system Each scenario is described from the point-of-view of an “actor”—a person or Each scenario is described from the point-of-view of an “actor”—a person or

device that interacts with the software in some waydevice that interacts with the software in some way Each scenario answers the following questions:Each scenario answers the following questions:

Who is the primary actor, the secondary actor (s)?Who is the primary actor, the secondary actor (s)? What are the actor’s goals?What are the actor’s goals? What preconditions should exist before the story begins?What preconditions should exist before the story begins? What main tasks or functions are performed by the actor?What main tasks or functions are performed by the actor? What extensions might be considered as the story is described?What extensions might be considered as the story is described? What variations in the actor’s interaction are possible?What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change?What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external Will the actor have to inform the system about changes in the external

environment?environment? What information does the actor desire from the system?What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?Does the actor wish to be informed about unexpected changes?

Use-Case DiagramUse-Case Diagram

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors

Analysis PrinciplesAnalysis Principles

Basic princBasic princiiplesples Represent and understand information domainRepresent and understand information domain Define functions that must be performedDefine functions that must be performed Represent behavior of software (to external Represent behavior of software (to external

events)events) Partition information, function and behavior Partition information, function and behavior

models hierarchicallymodels hierarchically Move from essential information to Move from essential information to

implementation detailimplementation detail

Guiding PrinciplesGuiding Principles

Understand problem before analysisUnderstand problem before analysis Develop prototypes for HCIDevelop prototypes for HCI Record Record origin and reason origin and reason for every requirementfor every requirement Develop multiple views of each requirementDevelop multiple views of each requirement

Data, functional and behavioral modelsData, functional and behavioral models Determine priorities of requirementsDetermine priorities of requirements Eliminate ambiguityEliminate ambiguity (by conducting formal technical (by conducting formal technical

reviews)reviews)

Information DomainInformation Domain

Software processes dataSoftware processes data Payroll processingPayroll processing Computing control signals for radar systemComputing control signals for radar system

Software also processes Software also processes eventsevents Timer went off -- time to calculate a controlTimer went off -- time to calculate a control Sensor turned on -- indicates intruderSensor turned on -- indicates intruder Heart rate monitor exceeded threshold -- Heart rate monitor exceeded threshold --

indicates fibrillation.indicates fibrillation.

Information DomainInformation Domain

Three views of informationThree views of information Information contentInformation content Information flowInformation flow Information structureInformation structure

Process ModelsProcess Models Functional -- possibly show block diagramsFunctional -- possibly show block diagrams Behavioral -- define states and transitionsBehavioral -- define states and transitions

Try to show models diagrammatically Try to show models diagrammatically

PartitioningPartitioning

State DiagramState Diagram

Figure 7.6 Preliminary UML state diagram for a photocopier

Initialization

system status=“not ready” display msg = “please wait” display status = blinking

entry/ switch machine on do: run diagnostics do: initiate all subsystems

turn copier “on“

subsystems ready system status=“Ready”

display msg = “enter cmd” display status = steady

entry/ subsystems ready do: poll user input panel do: read user input do: interpret user input

Readingcommands

system status=“Copying” display msg= “copy count =” display message=#copies display status= steady

entry/ start copies do: manage copying do: monitor paper tray do: monitor paper flow

Making copies

start copies

system status=“Jammed” display msg= “paper jam” display message=location display status= blinking

entry/ paper jammed do: determine location do: provide corrective msg. do: interrupt making copies

problem diagnosis

paper jammed

system status=“load paper” display msg= “load paper” display status= blinking

entry/ paper empty do: lower paper tray do: monitor fill switch do: raise paper tray

load paper

paper tray empty

not jammed

paper full

turn copier “off”

not jammed

copies complete

PrototypingPrototyping

Highly desirableHighly desirable Clarify requirementsClarify requirements Identify missing requirementsIdentify missing requirements Help define user interfacesHelp define user interfaces

Types of prototypesTypes of prototypes ThrowawayThrowaway Evolutionary -- a potential problem is that Evolutionary -- a potential problem is that

intended throwaways become evolutionaryintended throwaways become evolutionary

PrototypingPrototyping

Important questions underlying prototypingImportant questions underlying prototyping Customer commitment -- must be involvedCustomer commitment -- must be involved

Must commit resources for evaluationMust commit resources for evaluation Must be capable of making requirements decisions Must be capable of making requirements decisions

in timely mannerin timely manner

PrototypingPrototyping

Methods and toolsMethods and tools Fourth Generation Techniques -- program Fourth Generation Techniques -- program

application generatorsapplication generators Reusable Software Components -- build from Reusable Software Components -- build from

existing componentsexisting components Formal Specification and Prototyping Formal Specification and Prototyping

EnvironmentsEnvironments Translate specifications into codeTranslate specifications into code

SpecificationsSpecifications

Separate Function from ImplementationSeparate Function from Implementation Develop ModelDevelop Model Define EnvironmentDefine Environment Define how software interacts with environ.Define how software interacts with environ. Create Cognitive model -- how world sees itCreate Cognitive model -- how world sees it Recognize specs as imperfectRecognize specs as imperfect Flexibility -- be amenable to changeFlexibility -- be amenable to change

RepresentationRepresentation

Format and content relevant to problemFormat and content relevant to problem Information should be nestedInformation should be nested

Multiple layers or levelsMultiple layers or levels Diagrams should be consistent in useDiagrams should be consistent in use Representations should be revisableRepresentations should be revisable

Requirements Specifications DocumentationRequirements Specifications Documentation

Specifications ReviewSpecifications Review

Macroscopic LevelMacroscopic Level View from the topView from the top Goals met ?Goals met ? Alternatives explored ?Alternatives explored ? Customer satisfied ?Customer satisfied ?

SpecificsSpecifics Avoid persuasive, intimidating connectorsAvoid persuasive, intimidating connectors Ambiguous wordsAmbiguous words Vague languageVague language Watch for unstated assumptionsWatch for unstated assumptions

Validating Requirements-IValidating Requirements-I

Is each requirement consistent with the overall objective Is each requirement consistent with the overall objective for the system/product?for the system/product?

Have all requirements been specified at the proper level of Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?of technical detail that is inappropriate at this stage?

Is the requirement really necessary or does it represent an Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of add-on feature that may not be essential to the objective of the system?the system?

Is each requirement bounded and unambiguous?Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a Does each requirement have attribution? That is, is a

source (generally, a specific individual) noted for each source (generally, a specific individual) noted for each requirement? requirement?

Do any requirements conflict with other requirementsDo any requirements conflict with other requirements

Validating Requirements-IIValidating Requirements-II

Is each requirement achievable in the technical Is each requirement achievable in the technical environment that will house the system or product?environment that will house the system or product?

Is each requirement testable, once implemented?Is each requirement testable, once implemented? Does the requirements model properly reflect the Does the requirements model properly reflect the

information, function and behavior of the system to be information, function and behavior of the system to be built.built.

Has the requirements model been “partitioned” in a way Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about that exposes progressively more detailed information about the system.the system.

Have requirements patterns been used to simplify the Have requirements patterns been used to simplify the requirements model. Have all patterns been properly requirements model. Have all patterns been properly validated? Are all patterns consistent with customer validated? Are all patterns consistent with customer requirements?requirements?