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
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
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?