Se6162 analysis concept and principles

1

IF-ITB/YW/Juli 2005SE6162 Software Analysis

Page 1

SE6162 Software Engineering

Yani WidyaniDepartemen Teknik Informatika

Institut Teknologi Bandung


Page 2

Analysis Concept and Principles

• Requirement analysis• Requirement elicitation• Analysis principles• Specification and specification review


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”


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


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)


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


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)


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 ofsolution requirements.


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


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.


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.


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


Page 13


• 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)


Page 14


• 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)


Page 15


• 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


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


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)


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


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.


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


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.

Technology

Se6162 analysis concept and principles