Software Requirements Engineering

Chapter 3
Requirement Engineering Process

Chapter 4
Requirements Elicitation and Analysis
Objectives

• To describe the processes of requirements Engineering

• To describe the processes of requirements elicitation and
analysis.
• To introduce a number of requirements elicitation and
requirements analysis techniques.
• To discuss how prototypes may be used in the RE process.

2
Requirements Engineering Processes

3
 Five distinct steps of R.E process
• Feasibility study
• Requirements elicitation
• Requirements analysis
• Requirements specification
• System modeling
• Requirements validation &Verification
• Requirements management

4
5
Feasibility Study….
• Feasibility study leads to a decision:
• go ahead
• do not go ahead
• think again
• In research, feasibility study is often in the form of a proposal.
• A feasibility study decides whether not the proposed system is
worthwhile.
• It is a short focused study that checks
• If the system contributes to organizational objectives or not;
• If the system can be engineered using current technology and within
budget or not ;
• If the system can be integrated with other systems that are used or not;
• Feasibility Report….
• Based on information assessment (what is required),information
collection, Feasibility report writing will be carried over…..
6
 Requirements Elicitation
• Is the process through which the customer and developer discover,
review, articulate, and understand the users needs and constraints on
the software and development activities.
• RE is about discovering what requirements a system should be based
upon.
• This doesn’t involve just stakeholders what they want.
• It Requires a careful analysis of:
• The organization
• The application domain
• Organization process where the system will be used to determine what the
stakeholders need.
• It certainly seems simple enough to ask the customer, the users,
and others
• What the objectives of the system are….?
• What is to be accomplished…?
• How the system or product fits into the needs of the business and
• Finally, how the system or product is to be used on a day-to-day
basis…..? But it isn’t simple—it’s very hard. 7
Software Development Process:
Classify Requirements Elicitation

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation
cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Use Case
Model
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Expressed in
terms of

Use Case Application

Model Domain
Objects
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Expressed in Structured
terms of by

Use Case Application

Domain Sub-
Model
Objects systems
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Expressed in Structured Realized by

terms of by

Use Case Application Solution

Domain Sub-
Model Domain
Objects systems
Objects
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented by
Expressed in Structured Realized by
terms of by

class...
class...
class...
Use Case Application Solution
Domain Sub- Source
Model Domain
Objects systems Code
Objects
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented by
Expressed in Structured Realized by Verified
terms of by
By
class...
class... ?
class... ?
class....
Use Case Application Solution
Domain Sub- Source Test
Model Domain
Objects systems Code Cases
Objects
Cont.

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Cases
Objects
Components of requirements elicitation
• Application domain understanding :
• Application domain knowledge
is knowledge of the general area
where the system is applied.
• Example 1 : understand the Application Problem to
requirements for a cataloguing Domain be solved
system, you must have a general
knowledge of libraries and how Stakeholder
Business
libraries work. Needs and
constraints
context

• Example 2 : understand the

requirements for a railway
signaling system, you must have
a background knowledge about
the operation of railways and
the physical characteristics of
trains.
16
Components of requirements elicitation
• Problem understanding:
• The details of the specific customer
problem where the system will be
applied must be understood.
• Example 1 : for a cataloguing Application Problem to
system, you must understand how Domain be solved

a particular library categorizes its

Stakeholder
collection. Needs and
Business
context
constraints
• Example 2 : for a railway signaling
system, you must know the way in
which speed limits are applied to
particular track segments.
• During problem understanding,
you specialize and extend general
domain knowledge.
17
Components of requirements elicitation
• Business understanding: You
must understand how systems
interact and contribute to
overall business goals.
• Understanding the needs and Application Problem to
Domain be solved
constraints of system
stakeholders: Stakeholder
Business
• You must understand, in detail, Needs and
constraints
context

the specific needs of people

who require system support in
their work.

18
1.The good requirements elicitation process-Elicitation stages

• Objective setting: establish the overall organizational objectives:

determine why system may be necessary.
• Background of knowledge acquisition: gather and understand
more background information about the system.
19
The good requirements elicitation process-Elicitation stages

• Knowledge organization: organize, prioritize and collate the

large amount of data collected in the previous phases.
• Stakeholder requirements collection: involve system
stakeholders to discover their requirements.
20
Elicitation, analysis and negotiation: Yet another view on RE( spiral)

21
Process of Requirements Elicitation: Products of Requirements
Process

22
Requirements analysis and negotiation-Analysis checks

• Necessity checking:
• Sometimes requirements don’t contribute to the business goals of
the organization or to the specific problem to be addressed by the
system.
• Consistency and completeness checking:
• Cross-checking for consistency and completeness (no
contradictions, no services or constraints are missed out).
• Feasibility checking:
• the context of the budget and schedule.
23
Requirements negotiation

• Requirements discussion:
• Requirements highlighted as problematical are discussed.
• The stakeholders involved present their views about the
requirements.
• Requirements prioritization:
• Identification of critical requirements.
• Requirements agreement:
• A compromised set of requirements are agreed.
• A changes to some of the requirements. 24
2. Elicitation techniques
• Specific techniques which may be used to collect knowledge
about system requirements.
• This knowledge must be structured:
• Partitioning - aggregating related knowledge.
• Abstraction - recognizing generalities.
• Projection - organizing according to perspective.
• Elicitation problems:
• Not enough time for elicitation.
• Insufficient preparation by engineers.
• Stakeholders are unconvinced of the need for a new
system.

25
Specific elicitation techniques

26
1. Review of Literature
• All documentation on data carriers (forms, records, report,
manuals etc.) are organized and evaluated as and when
available.
• Regarding the existing forms, the analyst needs to find out
• How they are filled out
• How useful they are to the user
• What changes need to be made
• How easy they are to read.
• Up to-date manuals saves information gathering time
• Search the literature through
• Professional reference & procedures , Manuals, books, Company
• studies, Government publications etc.
• Procedures, manuals and forms are useful sources for the analyst.
They describe the format and functions of the present system.
• For example
• A S/W Eng.. has to analyze the grade report and he has to find out how
the grades were calculated, similarly an analyst has to find out rules,
policies and procedures related to grade report.

27
2. Onsite observations / Direct observation
• It requires going to user area & may cause adverse reactions by the
user staff if not handled properly.
• It is time- consuming
• OBJECTIVE of on site observation is to get as close as possible to the
real system being studied, movement of people & work flow.
Alternative observation methods are
1. Natural : It occurs in the employee’s place of work.
2. Obtrusive : This observation takes place when the user knows that
he is being observed
3. Direct : Takes place when the analyst actually observes the subject
or system at work.
4. Structural :Here the observer looks for & records a specific action.
5. Contrived :It is set up by the observer in a place as laboratory.
6. Unobtrusive :This observation takes place secretly as behind one
way mirror.
7. Indirect :Here the analyst uses mechanical devices such as cameras
and video tapes to capture information
28
3. Questionnaire
• What is a Questionnaire?
• A set of Questions designed to generate the statistical
information from a specific demographic needed to
accomplish the research objectives

29
The Major Decisions in Questionnaire Design
• Content - What should be asked?
• Wording - How should each question be phrased?
• Sequence - In what order should the questions be
presented?
• Layout - What layout will best serve the research objectives
• FILTER question: that screens out respondents who are not qualified
to answer a second question.
• PIVOT question: a type of filter question that is used to determine
what version of a second question to ask.
• The most difficult step is specifying exactly what
information is to be collected from each respondent

30
Types of Questionnaires
• 1. Close ended questionnaires
• 2. Open Ended Questionnaires
• Closed Ended Questionnaire
• Here responses/ answers are presented as a set of
alternatives.
• Users must select / fill the appropriate alterative & the answer must
be selected from amongst exactly.
• Scoring takes less time when compared.
• There are five major varieties of closed questions. They
are.
• Fill in the Blanks
• Dichotomous (Yes / No type)
• Ranking Scale
• Multiple-Choice
• Rating Scale
31
Types of Questionnaires…
• Open Ended Questionnaire
• It requires no response direction or specific response
• Users can respond in their own words
• The answer is written in the space provided
• Scoring takes more time to analyze.
• These Questions are ideal in explanatory situations where the
new ideas and relationships are needed An open question is likely
to receive a long answer
• Example:
• If u had a choice, how would you have designed the present
information center?
• ____________________________________________________
____________________________________________________
______________________________________________

32
Types of Questionnaires…

33
 3. interview
• The requirements engineer or analyst discusses the
system with different stakeholders and builds up an
understanding of their requirements.
• Two Types of interview:
• Closed interviews: The requirements engineer looks
for answers to a pre-defined set of questions.
• Open interviews: There is no predefined agenda and
the requirements engineer discusses, in an open-
ended way, what stakeholders want from the system.

34
Contd..
• Structured (closed) interviews
• Stakeholders answer a predefined set of questions
• Easy to analyze (+)
• Well-formed questions generate well-formed answers (you have
to know your goals) (+)
• Knowledge about what and how to ask (-)
• Non-structured (open) interviews
• No predefined agenda
• Generating new ideas (experimental, brain storming) (+)
• sometimes hard to handle (dynamics of discussion) (-)
• In practice: mixed interview types are normal

35
Interviews: Written vs. oral interviews, group vs. single
• Oral interviews:
• possibility to discussion (+)
• interviewer may influence interviewee (-)
• Written interviews
• problems in understanding (-)
• already transcribed, thus easy to analyze (+)
• Interviewing a single person:
• individual opinions (+)
• Interviewing a group of people: -
• Involvement of many perspectives
• Developer need experience to moderate (-)
• Sometimes single or silent opinions are not noticed (-)
• Independent Moderator can mediate between group 36
Interviewing Tips
• Interviewers should be open-minded, willing to listen to stakeholders and
should not have pre-conceived ideas about the requirements.
• During the interview
• behave professionally, you will receive the same attitude from your
interviewee.
• Take notes of all the necessary information.
• Don’t make the conversation too lengthy
• Do not prepare too many questions to ask.
• The interview paper and minutes are always useful for you and your
successor
• It’s important to open and close the interview carefully
• When opening the interview, try to do it in a trustful, respective way
with your good will.
• When closing the interview, you should recap the main points of the
interview, make arrangement for the following cooperation and
leave the issues open for discussion between both sides.
37
Interviewing …
• Advantages
• Rich collection of information
• Good for uncovering opinions, feelings, goals, as well as
hard facts
• Can probe in depth, & adapt follow up questions to what the
person tells you
• Disadvantages
• Large amount of qualitative data can be hard to analyze
• Hard to compare different respondents
• Interviewing is a difficult skill to master

38
4. Requirements reuse
• Reuse involves taking the requirements which have been
developed for one system and using them in a different
system.
• Requirements reuse saves time and effort as reused
requirements have already been analyzed and validated in
other systems.
• Currently, requirements reuse is an informal process but
more systematic reuse could lead to larger cost savings.

39
Reuse possibilities
• Where the requirement is concerned with providing
application domain information.
• Where the requirement is concerned with the style of
information presentation. Reuse leads to a consistency of
style across applications.
• Where the requirement reflects company policies such as
security policies.

40
4. Requirements analysis

• The goal of analysis is to discover problems, incompleteness

and inconsistencies in the elicited requirements. These are
then fed back to the stakeholders to resolve them through
the negotiation process.
• Analysis is inserted with elicitation as problems are
discovered when the requirements are elicited.

41
C and D Requirements

C Requirements-:
• Customer wants and needs;
• Expressed in language understood by the customer.
• Write C-requirements, review with customer, and update when
necessary.
• They are expressed using…..
• Use cases with a use case diagram. A use case specifies a
collection of scenarios.
• Data flow diagram explains the flow of data items across various
functions. Useful for explaining system functions.
• State transition diagram explains the change of system state in
response to one or more operations.

42
C and D Requirements

D Requirements
• For the developers; may be more formal.
• Obtain D-requirements from C-requirements and
customer.
• Write D-requirements; check to make sure that
there is no inconsistency between the C and the
D requirements.
• Organize the D-requirements. as Functional, Non
Functional
• Create sequence diagrams for use cases:
• Outline test plans
• Inspect
• Validate with customer & Release 43
The Requirements Model

44
45
What Is System Behavior?
• System behavior is how a system acts and reacts.
• It is the visible and testable activity of a system
• System behavior is captured by use cases.
• The most important aspect is to capture the dynamic behavior.
• Dynamic behavior means the behavior of the system when it is
running/operating.

46
What Is a Use-Case Model?
• A model that describes a system’s functional
requirements in terms of use cases
• Represents
– system’s intended functionality (use cases) and
– its environment (actors)

47
Purposes of use case diagrams
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors influencing the system.
• Show the interaction among the requirements are actors.
• When we are planning to draw a use case diagram, we should have
the following items identified.
• Functionalities to be represented as use case
• Actors
• Relationships among the use cases and actors.
• Use case diagrams are drawn to capture the functional requirements
of a system.

48
What Is an Actor?
• Actors are not part of the system. Actors are EXTERNAL.
• Actors represent roles a user of the system can play.
• An actor represents anything that interacts with the system
• They can represent a human, a machine, or another system.
• They can actively interchange information with the system.
• They can be a giver of information.
• They can be a passive recipient of information.
• Useful Questions in Finding Actors?
• Who will supply, use, or remove information?
• Who will use this functionality?
• Who is interested in a certain requirement?
• Where in the organization is the system used?
• What are the system’s external resources?
• What other systems will need to interact with this one?
49
What is an Use case.
• A use case is
– a sequence of actions a system
performs that yields an observable
result of value to a particular actor.
• Use Cases and Actors
• A use case model: a dialog between actors and the system.
• A use case is initiated by an actor to invoke a certain
functionality in the system.

50
• guidelines to draw an efficient use case diagram
• The name of a use case is very important. The name should be
chosen in such a way so that it can identify the functionalities
performed.
• Give a suitable name for actors.
• Show relationships and dependencies clearly in the diagram.
• Do not try to include all types of relationships, as the main purpose
of the diagram is to identify the requirements.
• Use notes whenever required to clarify some important points.

51
E.g. diagram representing the order management system. Hence, if
we look into the diagram then we will find three use cases
(Order, SpecialOrder, NormalOrder) actor which is the customer.
The SpecialOrder and NormalOrder =>extended from Order use case.
System boundary, which is shown in the picture.
The actor Customer lies outside the system as it is an external user of
the system.

52
use-case diagram Rules

53
use-case diagram Rules

54
use-case diagram Rules

55
UML Class Diagram
▪ Class diagram is a static diagram. It represents the static
view of an application.
▪ Class diagram is not only used for visualizing, describing,
and documenting different aspects of a system but also for
constructing executable code of the software application.
▪ Class diagram describes the attributes and operations of a
class and also the constraints imposed on the system.
▪ The class diagrams are widely used in the modeling of
object oriented systems because they are the only UML
diagrams, which can be mapped directly with object-
oriented languages.

56
UML Class Diagram components
• The main symbols shown in class diagrams are:
• Class: A class represents the blueprint (template) of its
objects.
• Fields (Attributes, Variables or Constants)
• A field represents the state of the class and its instances.
• Behavior (Operations or Methods)
• A behavior represents an operation performed by the
class and its instances.
• Associations
• An association represents a relationship between two
classes.
• Generalizations
• A generalization groups classes into an inheritance
hierarchy.

57
Contd..
• The following points should be remembered while drawing a class
diagram −
• The name of the class diagram should be meaningful to
describe the aspect of the system.
• Each element and their relationships should be identified in
advance.
• Responsibility (attributes and methods) of each class should be
clearly identified
• For each class, minimum number of properties should be
specified, as unnecessary properties will make the diagram
complicated.
• Use notes whenever required to describe some aspect of the
diagram. At the end of the drawing it should be understandable
to the developer/coder.
• Finally, before making the final version, the diagram should be
drawn on plain paper and reworked as many times as possible
to make it correct.
58
Eg. Order Management
• First of all, Order and Customer are identified as the two
elements of the system.
• They have a one-to-many relationship because a customer
can have multiple orders.
• Order class is an abstract class and it has two concrete
classes (inheritance relationship) SpecialOrder and
NormalOrder.
• The two inherited classes have all the properties as the
Order class.
• In addition, they have additional functions like dispatch ()
and receive ().

59
Eg. Order Management

60
UML Representation of Classes
• A class is simply represented as a box with the name of the class inside.
• The diagram may also show the attributes and/or operations (fields and
behaviour).

• The complete signature of an operation is:

operationName(parameterName: parameterType …): returnType

• Examples:

Rectangle Rectangle Rectangle Rectangle Rectangle

getArea height height height: int
reSize width width width: int
getArea getArea(): int
reSize reSize(int,int)

61
▪ An association shows how classes are connected to each other:
– Symbols indicating multiplicity are shown at each end of the association.
*
Employee Company

* 1..*
Secretary Manager

Company BoardofDirectors

0..1 *
Office Employee

0, 3..8 *
Person BoardofDirectors

LEGEND
x..* (the range from x to many).
x..y (the range from x to y).
62
▪ Each association can be labelled, to make explicit
the nature of the association:

Association Association
Role Association Name Role
Class1 Class2

63
 * Works for →
Employee Company

* has 1..*
Secretary Manager

Company BoardofDirectors

0..1 isAllocated *
Office Employee

0, 3..8 isMember *
Person BoardofDirectors

64
Contd..

* Works for →
Employee Company

▪ Many-to-one
– A company has many employees.
– An employee can only work for one company.
• This system is not capable of processing information about more
than one company per employee.

– A company can have zero employees.

• E.g. a ‘shell’ company.

– It is not possible to be an employee unless you work for a company.

65
Contd..

* 1..*
Secretary Manager

▪ Many-to-many
– A secretary can work for many managers.
– A manager can have many secretaries.
– Secretaries can work in pools.
– Managers can have a group of secretaries.
– Some managers might have zero secretaries.
– It is not possible for a secretary to have zero managers.

66
Contd..

Company BoardofDirectors

▪ One-to-one

– For each company, there is exactly one board of directors.

– A board is the board of only one company.

– A company must always have a board.

– A board must always be of some company.

67
Contd..

0, 3..8 isBoardMember *
Person BoardofDirectors

▪ Many-to-many

– There can be zero people on a board of directors.

– There can be three to eight people on a board of directors.

– A person plays the role of a “board member”.

– A person can be a member of more than one board.

– A person can exist without being a member of any board.

68