Vous êtes sur la page 1sur 26

Chapter 5:

Concepts

Analysis
and Principles

Contents
Software

Requirements Analysis
Requirement
Elicitation
for
Software
Analysis Principles

Software Requirements
Analysis
Requirements

analysis
as
a
bridges between requirements
engineering and software design.
Requirements analysis provides
the designer with a representation
of information, function, and
behavior that can be translated to
data, architectural, interface, and
component-level designs.
3

Software Requirements
Analysis
Requireme
nt
Engineerin
g
Requireme
nt
Analysis

Software
Design

Areas effort of RA
Software

requirements analysis
may be divided into five areas of
effort:

problem recognition
evaluation and synthesis
modeling
specification
review

Contents
Software

Requirements Analysis
Requirement
Elicitation for
Software
Analysis Principles

Requirement Elicitation for


Software
Before

requirements can be analyzed,


modeled, or specified they must be
gathered through an elicitation process.
A customer has a problem that may be
amenable
to
a
computer-based
solution.
A developer responds to the customer's
request for help.
Communication has begun, but the
communication can be indistinct.
7

Contents
Software

Requirements Analysis
Requirement
Elicitation for
Software

Initiating the Process


FAST
Quality Function Deployment
Use-Cases

Analysis

Principles
8

Initiating the Process


The

most commonly used requirements


elicitation technique is to conduct a
meeting or interview.
The analyst start by asking context-free
questions.
The set of questions which are the basic
understanding of the problem, the
people who want a solution, the nature
of the solution that is desired, and the
effectiveness of the first encounter
itself.
9

Context Free Questions1


The
questions
help
to
identify
all
stakeholders who will have interest in the
software to be built.
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful
solution?
Is there another source for the solution that you
need?
10

Context Free Question2


The questions enables the analyst to gain a
better understanding of the problem and the
customer to voice his or her perceptions
about a solution
How would you characterize "good" output that
would be generated by a successful solution?
What problem(s) will this solution address?
Can you show me (or describe) the environment in
which the solution will be used?
Will special performance issues or constraints
affect the way the solution is approached?
11

Context Free Questions3


The final set of questions focuses on the
effectiveness of the meeting.
Are you the right person to answer these
questions? Are your answers "official"?
Are my questions relevant to the problem that you
have?
Am I asking too many questions?
Can anyone else provide additional information?
Should I be asking you anything else?

12

Contents
Software

Requirements Analysis
Requirement
Elicitation for
Software

Initiating the Process


FAST
Quality Function Deployment
Use-Cases

Analysis

Principles
13

Facilitated Application
Specification Techniques
Too

often, customers and software


engineers have an unconscious us and
them mind-set.
History has shown that this approach
doesn't work very well.
Misunderstandings abound, important
information is omitted, and a successful
working
relationship
is
never
established.
FAST has been used to improve the
communication.
14

Basic Guidelines of FAST


Attendees

from both the development and


customer/user organizations are invited to
attend.
Rules for preparation and participation are
established.
Covered all important point.
A facilitator (can be a customer, a developer, or
an outsider) controls the meeting.
A definition mechanism is used such as: flip
charts, or wall stickers or an electronic bulletin
board, chat room or virtual forum.
Identify the problem, propose elements of the
solution, negotiate different approaches.
15

Contents
Software

Requirements Analysis
Requirement
Elicitation for
Software

Initiating the Process


FAST
Quality Function Deployment
Use-Cases

Analysis

Principles
16

Quality Function Deployment


Quality

Function Deployment (QFD) is a


quality management technique that
translates the needs of the customer
into technical requirements for software.
Originally developed in Japan and first
used at the Kobe Shipyard of Mitsubishi
Heavy Industries, Ltd., in the early
1970s.
QFD
concentrates
on
maximizing
customer satisfaction from the software
engineering process.
17

Types of Requirements
QFD

identifies
requirements:

three

types

of

Normal requirements. objectives and goals


are present, the customer is satisfied. E.g.,
normal requirements might be requested types of
graphical displays, specific system functions,
Expected requirements. Requirements are
implicit to the product or system. E.g., ease of
human/machine interaction, high reliability,

Exciting requirements.

These features go beyond


the customers expectations and prove to be very
satisfying when present. E.g., word processing software is
requested with standard features.

18

Contents
Software

Requirements Analysis
Requirement
Elicitation for
Software

Initiating the Process


FAST
Quality Function Deployment
Use-Cases

Analysis

Principles
19

Use-Cases
The

software engineer (analyst) can create a


set of scenarios that identify a thread of
usage for the system to be constructed. The
scenarios, often called use-cases.
To create a use-case, the analyst must first
identify the different types of people that
use the system or product.
Actors actually represent roles that people
play as the system operates.
Defined somewhat more formally, an actor is
anything that communicates with the
system.
20

Example of Use-Cases
Create

Use-Case Diagram of web


system of distance learning.
Web-system of distance learning
assumes there are two types of actor:
student and lecturer.
Student has facilities: Login, Get
Exercise, View the result of exam, View
Information.
Lecturer has facilities: Login, View
student score, Upload exercises/answers,
View information.
21

Use Cases Diagram


Get Exericise

View Student Score

Login
Student

Lecturer

View Information

View Result of Exam

Upload
Exercise/Answer

22

Contents
Software

Requirements Analysis
Requirement
Elicitation
for
Software

Initiating the Process


FAST
Quality Function Deployment
Use-Cases

Analysis

Principles
23

Analysis Principles
All

analysis methods are related by a set of


operational principles:

The information domain of a problem must be


represented and understood.
The functions that the software is to perform must
be defined.
The behavior of the software (as a consequence of
external events) must be represented.
The models that depict information, function, and
behavior must be partitioned in a manner that
uncovers detail in a layered (or hierarchical) fashion.
The analysis process should move from essential
information toward implementation detail.

24

Davis Analysis Principle


The

operational analysis principles, Davis


suggests a set of guiding principles for
requirements engineering:
Understand the problem before you begin to
create the analysis model.
Develop 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 of requirements.
Rank requirements.
Work to eliminate ambiguity.
25

Literatures
en.wikipedia.org
Basics

of Software Project Management

2004.
Ian Sommerville Software Engineering
6th Edition 2000.
Roger
S.
Pressman
Software
Engineering: a practitioners approach 5 th
Edition 2001.
Murali Chemuturi Delphi Techniques
for Software Estimate
http://www.chemuturi.com/Delphi%20Te
chnique%20for%20software%20estimatio

26

Vous aimerez peut-être aussi