REQUIREMENT
ANALYSIS:SCENARIO-BASED
METHODS
PRESENTED BY
HIRA MANZOOR & MAIRAFeroz
Maira FEROZ
REQUIREMENT ANALYSIS
Requirements analysis results In
• the specification of software’s operational characteristics,
• indicates software’s interface with other system elements, and
• establishes constraints that software must meet.
Requirements analysis allows you (regardless of whether you’re called a software
engineer, an analyst, or a modeler) to elaborate on basic requirements established
during the inception, elicitation, and negotiation tasks that are part of
requirements engineering
• ELEMENTS OF REQUIREMENT ANALYSIS
The requirements modeling action results in one or more of the following
types/ELEMENYS of models:
• Scenario-based models of requirements from the point of view of various
system “actors”
• Data models that depict the information domain for the problem
• Class-oriented models that represent object-oriented classes (attributes and
operations) and class collaboration
• Flow-oriented models that represent the functional elements of the system and
how they transform data
• Behavioral models that depict how the software behaves as a consequence of
external “events”
• OVERALL OBJECTIVE AND PHILOSOPHY
The requirements model must achieve three
primary objectives:
• to describe what the customer requires,
• to establish a basis for the creation of a
software design, and
• to define a set of requirements that can be
validated once the software is built.
The analysis model bridges the gap between
a system-level description and a software.
• ANALYSIS RULE OF THUMB
Arlow and Neustadt rules of thumb FOR creating the analysis model:
• The model should focus on requirements that are visible within the problem or
business domain the level of abstraction should be relatively high.
• Each element of the requirements model should add to an overall understanding of
software requirements
• Delay consideration of infrastructure and other nonfunctional models until design.
• Minimize coupling throughout the system.
• Be certain that the requirements model provides value to all stakeholders
• Keep the model as simple as it can be
• DOMAIN ANALYSIS
Fire smith describes domain analysis in the following way:
Software domain analysis is the identification, analysis, and specification of common
requirements from a specific application domain, typically for reuse on multiple
projects within that application domain. Object-oriented domain analysis is the
identification, analysis, and specification of common, reusable capabilities within a
specific application domain, in terms of common objects, classes, subassemblies, and
frameworks.
Figure illustrates key inputs and outputs for the domain analysis process
• GOALS OF DOMAIN ANALYSIS
The goal of domain analysis is :
• To find or create those analysis classes and/or analysis patterns MAY be reused
• Domain analysis IS an umbrella activity for the software process.
• The role of a domain analyst is similar to the role of a master toolsmith in a
heavy manufacturing environment.
• The job of the toolsmith is to design and build tools that may be used by many
people doing similar but not necessarily the same jobs.
• REQUIREMENT MODELING APPROACHES
• One view of requirements modeling, called structured analysis, considers data
and the processes that transform the data as separate entities. Data objects are
modeled in a way that defines their attributes and relationships. Processes that
manipulate data objects are modeled in a manner that shows how they transform
data
• A second approach to analysis modeling, called object-oriented analysis, focuses
on the definition of classes and the manner in which they collaborate with one
another to effect customer requirements.
Each element of the requirements model presents
the problem from a different point of view.
• Scenario-based elements depict how the user
interacts with the system and the specific
sequence of activities that occur as the software
is used.
• Class-based elements model the objects that the
system will manipulate the relationships (some
hierarchical) between the objects, and the
collaborations that occur between the classes
• Behavioral elements depict how external events
change the state of the system or the classes
that reside within it.
• Flow-oriented elements represent the system as
an information transform, depicting how data
objects are transformed as they flow through
various system functions.
