Chapter 5: Analysis Concepts and Principles

ContentsSoftware Requirements AnalysisRequirement Elicitation for

SoftwareAnalysis Principles

2

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

4

Requirement

Engineering Requireme

nt Analysis

Software Design

Areas effort of RASoftware requirements analysis

may be divided into five areas of effort:◦problem recognition◦evaluation and synthesis◦modeling◦specification ◦review

5

ContentsSoftware Requirements AnalysisRequirement Elicitation for

SoftwareAnalysis Principles

6

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

ContentsSoftware Requirements AnalysisRequirement Elicitation for

Software◦Initiating the Process◦FAST◦Quality Function Deployment◦Use-Cases

Analysis Principles

8

Initiating the ProcessThe 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

ContentsSoftware Requirements AnalysisRequirement 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

ContentsSoftware Requirements AnalysisRequirement 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 RequirementsQFD identifies three types of

requirements:◦ 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 customer’s expectations and prove to be very satisfying when present. E.g., word processing software is requested with standard features.

18

ContentsSoftware Requirements AnalysisRequirement 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

22

Get Exericise

Student

View Result of Exam

View Student Score

Upload Exercise/Answer

Login

Lecturer

View Information

ContentsSoftware Requirements AnalysisRequirement 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

Literaturesen.wikipedia.orgBasics of Software Project Management

– 2004.Ian Sommerville “Software

Engineering 6th Edition” – 2000.Roger S. Pressman “Software

Engineering: a practitioner’s approach 5th Edition” – 2001.

Murali Chemuturi “Delphi Techniques for Software Estimate” http://www.chemuturi.com/Delphi%20Technique%20for%20software%20estimation.pdf

26