1. 1
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 1
SE6162 Software Engineering
Yani Widyani
Departemen Teknik Informatika
Institut Teknologi Bandung
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 2
Analysis Concept and Principles
• Requirement analysis
• Requirement elicitation
• Analysis principles
• Specification and specification review
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 3
Requirement Analysis
“I know you believe you understand what
you think I said, but I am not sure that you
realize that what you heard is not what I
meant”
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 4
Requirement Analysis
• Software engineering task that bridges the gap between
system level requirements engineering and software
design.
• Provides software designer with a representation of
system information, function, and behavior that can
be translated to data, architectural, and component-level
designs.
• Five area of effort (phases):
– Problem recognition
– Evaluation and synthesis (focus is on what not how)
– Modeling
– Specification
– Review
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 5
Requirement Elicitation
• Most commonly technique used:
– Meeting
– Interview
• Initiating the Process
– Asking context-free question:
• Who is behind the request of this work
• Who will use the solution
• What will the economic benefit of a successful solution
• Is there another source for the solution that you need
– “He who asks a question is a fool for five minutes; he
who does not ask a question remains a fool forever”
(chinese proverb)
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 6
Req. Elicitation (2)
– Next set of questions to gain better understanding of customer’s
perceptions:
• How would you characterize “good” output
• What problem(s) will this solution address
• Can you show me the environment in which the solution will be used
• Will special performance issues or constraints affect the way the
solutions approached
– Final questions focused on the effectiveness of the meeting:
• Are you the right person to answer
• Are my questions relevant to the problem you have
• Am I asking too many questions
• Can anyone else provide additional information
• Should I be asking you anything else
These questions (and others) will help to “break the ice”…..

2. 2
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 7
Req. Elicitation (3)
• Do not only use the Q&A techniques
– Only for the first encounter
– Replace by the meeting that combines elements of:
• Problem solving
• Negotiation
• Specification
• Another techniques:
– FAST (Facilitated Application Specification Techniques)
– QFD (Quality Function Deployment)
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 8
Req. Elicitation (4)
• FAST
encourages the creation of a joint team of customers and
developers who work together
– Meeting held at neutral site, attended by both software engineers
and customers.
– Rules established for preparation and participation.
– Agenda suggested to cover important points and to allow for
brainstorming.
– Meeting controlled by facilitator (customer, developer, or
outsider).
– Definition mechanism (flip charts, stickers, electronic device, etc.)
is used.
– Goal is to identify problem, propose elements of solution,
negotiate different approaches, and specify a preliminary set of
solution requirements.
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 9
Req. Elicitation (5)
• QFD
– Translates customer needs into technical software requirements
– Identified three types of requirement:
• Normal requirements (must be present in product for customer to be satisfied)
• Expected requirements (things like ease of use or reliability of operation, that
customer assumes will be present in a professionally developed product
without having to request them explicitly)
• Exciting requirements (features that go beyond the customer's expectations
and prove to be very satisfying when they are present)
– In meeting with the customer:
• Function deployment is used to determine the value of each function required
for system
• Information deployment identifies data objects and events produced and
consumed by the system
• Task deployment examines the behavior of product within it environment
• Value analysis is used to determine the relative priority of requirements during
function, information, and task deployment
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 10
Req. Elicitation (6)
• As requirements are gathered, the software
engineer can create:
– Scenarios that describe how the product will be used in
specific situations called use-cases
– narratives that describe the role of an actor (user or
device) as interaction with the system occurs.
• Use-cases are designed from the actor's point of
view.
• Not all actors can be identified during the first
iteration of requirements elicitation, but it is
important to identify the primary actors before
developing the use-cases.
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 11
Analysis Principles
• Operational principles:
– The information domain of the problem must be
represented and understood.
– The functions that the software is to perform must be
defined.
– Software behavior must be represented.
– Models depicting information, function, and behavior
must be partitioned in a hierarchical manner that
uncovers detail.
– The analysis process should move from the essential
information toward implementation detail.
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 12
Analysis Principles (2)
• Guiding principles [DAV95a]:
– Understand the problem before you begin to create the
analysis model
– Develop a prototypes that enable a user to understand
how human-machine interaction will occur
– Record the origin of and the reason for every
requirement
– Use multiple views for requirements
– Rank requirements
– Work to eliminate ambiguity

3. 3
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 13
Analysis Principles (3)
• Information domain:
– Encompasses all data objects that contain numbers,
text, images, audio, or video.
– Information content or data model (shows the
relationships among the data and control objects that
make up the system)
– Information flow (represents the manner in which data
and control objects change as each moves through the
system)
– Information structure (representations of the internal
organizations of various data and control items)
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 14
Analysis Principles (4)
• Modeling:
– Data model (shows relationships among
system objects)
– Functional model (description of the functions
that enable the transformations of system
objects)
– Behavioral model (manner in which software
responds to events from the outside world)
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 15
Analysis Principles (5)
• Partitioning:
– Process that results in the elaboration of data,
function, or behavior.
– Horizontal partitioning is a breadth-first
decomposition of the system function,
behavior, or information, one level at a time.
– Vertical partitioning is a depth-first elaboration
of the system function, behavior, or
information, one subsytem at a time
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 16
Software Prototyping
• Selecting the prototyping approach:
– Throwaway prototyping (prototype only used
as a demonstration of product requirements)
– Evolutionary prototyping (prototype is refined
to build the finished system)
• Customer resources must be committed to
evaluation and refinement of the prototype.
• Customer must be capable of making
requirements decisions in a timely manner
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 17
Prototyping Methods and Tools
• Fourth generation techniques (4GT tools allow
software engineer to generate executable code
quickly)
• Reusable software components (assembling
prototype from a set of existing software
components)
• Formal specification and prototyping
environments (can interactively create executable
programs from software specification models)
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 18
Specification Principles
• Separate functionality from implementation.
• Develop a behavioral model that describes functional
responses to all system stimuli.
• Define the environment in which the system operates and
indicate how the collection of agents will interact with it.
• Create a cognitive model rather than an implementation
model.
• Recognize that the specification must be extensible and
tolerant of incompleteness.
• Establish the content and structure of a specification so
that it can be changed easily

4. 4
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 19
Specification Representation
• Representation format and content should
be relevant to the problem.
• Information contained within the
specification should be nested.
• Diagrams and other notational forms
should be restricted in number and
consistent in use.
• Representations should be revisable.
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 20
Specification Review
• Conducted by customer and software
developer.
• Once approved, the specification becomes
a contract for software development.
• The specification is difficult to test in a
meaningful way.
• Assessing the impact of specification
changes is hard to do
IF-ITB/YW/Juli 2005
SE6162 Software Analysis
Page 21
Structured Analysis (DeMarco)
• Analysis products must be highly maintainable, especially
the software requirements specification.
• Problems of size must be dealt with using an effective
method of partitioning.
• Graphics should be used whenever possible.
• Differentiate between the logical (essential) and physical
(implementation) considerations.
• Find something to help with requirements partitioning and
document the partitioning before specification.
• Devise a way to track and evaluate user interfaces.
• Devise tools that describe logic and policy better than
narrative text.