Software Engineering

Unit – II

Requirement Engineering and

Modelling

Dr. S. Manikandan
HOD-IT

1
 What is Requirements Engineering?

• The broad spectrum of tasks and techniques that lead

to an understanding of requirements is called
requirements engineering.
• Requirement Engineering is the process of defining,
documenting and maintaining the requirements. It is a
process of gathering and defining service provided by
the system.

2
 Seven Tasks of Requirements Engineering

1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements Management

3
 Software Requirements Specification (SRS)
Characteristics of SRS
• Correctness: User review is used to ensure the
correctness of requirements stated in the SRS.
• Completeness
• Consistency: Requirements in SRS are said to be
consistent if there are no conflicts between any set of
requirements.
• Unambiguousness: A SRS is said to be
unambiguous if all the requirements stated have only 1
interpretation.
• Ranking for importance and stability: There should
a criterion to classify the requirements as less or more
important or more specifically as desirable or
essential.
• Modifiability 4
• Verifiability
• Traceability: One should be able to trace a
requirement to design component and then to code
segment in the program.
• Design Independence: There should be an option to
choose from multiple design alternatives for the final
system.
• Testability: A SRS should be written in such a way
that it is easy to generate test cases and test plans
from the document.
• Understandable by the customer:
• Right level of abstraction: If the SRS is written for
the requirements phase, the details should be
explained explicitly.
5
 Establishing the Groundwork

• To discuss the steps required to establish the ground

work for an understanding of software requirements
– to get the project started in a way that will keep it
moving forward toward a successful solution.
1. Identifying stakeholders
2. Recognizing multiple viewpoints
3. Working toward collaboration
4. Asking the first questions
5. Non functional requirements
6. Traceability

6
Functional and Non-Functional Requirements

Functional Requirements:
These are the requirements that the end user specifically
demands as basic facilities that the system should
offer.
All these functionalities need to be necessarily
incorporated into the system as a part of the contract.
These are represented or stated in the form of input to be
given to the system, the operation performed and the
output expected.
They are basically the requirements stated by the user
which one can see directly in the final product, unlike
the non-functional requirements.

7
Non-functional requirements
These are basically the quality constraints that the
system must satisfy according to the project contract.
The priority or extent to which these factors are
implemented varies from one project to other. They
are also called non-behavioral requirements.
They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility 8
 Functional Requirements Non Functional Requirements

A non-functional requirement defines the quality attribute of a

A functional requirement defines a system or its component.
software system.

It places constraints on “How should the software system fulfill

It specifies “What should the software system do?”
the functional requirements?”

Non-functional requirement is specified by technical peoples

Functional requirement is specified by User.
e.g. Architect, Technical leaders and software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

9
 Eliciting Requirements
Requirements Elicitation also called Requirements
Gathering combines elements of problem solving,
elaboration, negotiation and specification.
Requirements elicitation Activities:
Requirements elicitation includes the subsequent
activities. Few of them are listed below –
• Knowledge of the overall area where the systems is
applied.
• The details of the precise customer problem where the
system are going to be applied must be understood.
• Interaction of system with external requirements.
• Detailed investigation of user needs.
• Define the constraints for system development.
10
Requirements elicitation Methods:
There are a number of requirements elicitation
methods. Few of them are listed below –
• Interviews – may be open ended or structured
• Brainstorming Sessions
• Facilitated Application Specification Technique
(FAST)
• Quality Function Deployment (QFD)
• Use Case Approach

11
 Facilitated Application Specification Technique
It’s objective is to bridge the expectation gap – difference
between what the developers think they are supposed to
build and what customers think they are going to get.
• A team oriented approach is developed for requirements
gathering.
Each attendee is asked to make a list of objects that are-
• Part of the environment that surrounds the system
• Produced by the system
• Used by the system
Each participant prepares his/her list, different lists are then
combined, redundant entries are eliminated, team is
divided into smaller sub-teams to develop mini-
specifications and finally a draft of specifications is written
down using all the inputs from the meeting.
12
 Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it
emphasizes on the requirements which are valuable to the
customer. 3 types of requirements are identified –
• Normal requirements –
In this the objective and goals of the proposed software are
discussed with the customer. Example – normal requirements for
a result management system may be entry of marks, calculation
of results, etc
• Expected requirements –
These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorized
access.
• Exciting requirements –
It includes features that are beyond customer’s expectations and
prove to be very satisfying when present. Example – when
unauthorized access is detected, it should backup and shutdown
13
all processes.
 Developing Use Case

• This technique combines text and pictures to provide a

better understanding of the requirements.
• The use cases describe the ‘what’, of a system and not
‘how’. Hence, they only give a functional view of the
system.
• A Use case tells a stylized story about how an end
user interacts with the system under a specific set of
circumstances.
The components of the use case design includes three
major things –
• Actor
• Use cases
• Use case diagram
14
• Actor –
It is the external agent that lies outside the system but
interacts with it in some way. An actor maybe a
person, machine etc. It is represented as a stick figure.
Actors can be primary actors or secondary actors.
– Primary actors – It requires assistance from the
system to achieve a goal.
– Secondary actor – It is an actor from which the
system needs assistance.
• Use cases –
They describe the sequence of interactions between
actors and the system. They capture who(actors) do
what(interaction) with the system. A complete set of
use cases specifies all possible ways to use the
system. 15
Use case diagram –
A use case diagram graphically represents what
happens when an actor interacts with a system. It
captures the functional aspect of the system.
– A stick figure is used to represent an actor.
– An oval is used to represent a use case.
– A line is used to represent a relationship between
an actor and a use case.

16
Use Case Diagram

17
 Requirements Model

• Requirements for a computer-based system can be

seen in many different ways. Some software people
argue that it’s worth using a number of different modes
of representation while others believe that it’s best to
select one mode of representation.
• The specific elements of the requirements model are
dedicated to the analysis modeling method that is to be
used.
• Elements of requirements model are
1. Scenario-based elements
2. Class-based elements
3. Behavioral elements

18
1. Scenario-based elements
Using a scenario-based approach, system is described
from user’s point of view. For example, basic use
cases and their corresponding use-case diagrams
evolve into more elaborate template-based use cases.
Figure 1(a) depicts a UML activity diagram for eliciting
requirements and representing them using use cases.
There are three levels of elaboration .

19
UML Activity Diagram for eliciting requirements

20
2. Class-based elements :
A collection of things that have similar attributes and
common behaviors i.e., objects are categorized into
classes. For example, a UML case diagram can be
used to depict a Sensor class for the SafeHome
security function. Note that diagram lists attributes of
sensors and operations that can be applied to modify
these attributes.
In addition to class diagrams, other analysis modeling
elements depict manner in which classes collaborate
with one another and relationships and interactions
between classes.

21
Class diagram for Sensor

22
3. Behavioral elements
Effect of behavior of computer-based system can be seen
on design that is chosen and implementation approach
that is applied. Modeling elements that depict behavior
must be provided by requirements model.
Method for representing behavior of a system by depicting
its states and events that cause system to change state is
state diagram. A state is an externally observable mode of
behavior. In addition, state diagram indicates actions
taken as a consequence of a particular event.

23
UML State Diagram notation

24
 Negotiating Requirements

• The successful negotiations aim for a “win-win”

outcome. That is, stakeholders, benefit from a system
or product that meets the majority of their needs, while
you benefit from working within realistic and
reasonable budgets and schedules.
Negotiation Activities are
• Identifying the major stakeholders in the system or
subsystem.
• Establishing the stakeholders’ “win conditions.”
• Negotiation of the win conditions of the stakeholders in
order to reconcile them into a set of win-win conditions
for all people involved.

25
 Validating Requirements

A review of the requirements model addresses the

following questions
• Is each requirement aligned with the overall system/product
objectives?
• Were all requirements expressed at the appropriate level of
abstraction? Do some criteria, in other words, give a level
of technical information that is inappropriate at this stage?
• Is the requirement truly necessary, or is it an optional
feature that may or may not be critical to the system’s
goal?
• Is each requirement well defined and unambiguous?
• Is each requirement attributed? Is there a source noted for
each requirement?
• Are there any requirements that conflict with others?
26
• Is each requirement attainable in the technical environment
in which the system or product will be housed?
• Is each requirement, once implemented, testable?
• Does the requirements model accurately represent the
information, functionality, and behaviour of the system to be
built?
• Has the requirements model been “partitioned” in such a
way that progressively more detailed information about the
system is exposed?
• Have requirements patterns been used to reduce the
complexity of the requirements model?
• Have all patterns been validated properly? Are all patterns in
accordance with the requirements of the customers?
27
Requirements Analysis

28
 Domain Analysis

Software Domain Analysis is the identification,

analysis and specification of common requirements
from a specific domain, typically for reuse on
multiple projects with that application domain

29
Requirements Modeling Approaches

30
 Scenario Based Modeling

• It represents the system from the user’s point of view

• It produces a text oriented representation call a “use
case”
• The Use case can be supplemented with a number of
different UML diagrams that overlay a more procedural
view of the interaction
• The requirements modeling with UML begins with the
creation of scenarios in the form of use cases, activity
diagrams and swimlane diagrams.

31
Scenario Based Modeling

32
33
34
 Class Based Modeling
• Class-based modeling identifies classes, attributes and
relationships that the system will use.
• In the airline application example, the traveler/user and the
boarding pass represent classes. The traveler's first and last
name, and travel document type represent attributes,
characteristics that describe the traveler class. The
relationship between traveler and boarding pass classes is
that the traveler must enter these details into the application
in order to get the boarding pass, and that the boarding
pass contains this information along with other details like
the flight departure gate, seat number etc.
• Class based modeling represents the object. The system
manipulates the operations.
• The elements of the class based model consist of classes
and object, attributes, operations, class – responsibility -
collaborator (CRS) models. 35
 Classes
• Classes are determined using underlining each noun or
noun clause and enter it into the simple table.
Classes are found in following forms:
• External entities: The system, people or the device
• Things: The reports, displays, letter, signal are the part of
the information domain or the problem.
• Occurrences or events: A property transfer or the
completion of a series or robot movements occurs in the
context of the system operation.
• Roles: manager, engineer, salesperson
• Organizational units: The division, group, team
• Places: The manufacturing floor or loading dock
• Structures: The sensors, computers are defined a class of
objects or related classes of objects. 36
Attributes
• Attributes are the set of data objects that are defining a
complete class within the context of the problem.
• For example, 'employee' is a class and it consists of name,
Id, department, designation and salary of the employee are
the attributes.
Operations
• The operations define the behavior of an object.
• The operations are characterized into following types:
• The operations manipulate the data like adding, modifying,
deleting and displaying etc.
• The operations perform a computation.
• The operation monitors the objects for the occurrence of
controlling an event 37
 CRS Modeling

• The CRS stands for Class-Responsibility-Collaborator.

• It provides a simple method for identifying and
organizing the classes that are applicable to the
system or product requirement.
• Class is an object-oriented class name. It consists of
information about sub classes and super class
• Responsibilities are the attributes and operations that
are related to the class.
• Collaborations are identified and determined when a
class can achieve each responsibility of it. If the class
cannot identify itself, then it needs to interact with
another class.

38
39
40
41
 Data Flow Diagram

• A Data Flow Diagram (DFD) is a traditional visual

representation of the information flows within a system.
A neat and clear DFD can depict the right amount of
the system requirement graphically. It can be manual,
automated, or a combination of both.
• In Software engineering DFD(data flow diagram) can
be drawn to represent the system of different levels of
abstraction. Higher-level DFDs are partitioned into low
levels-hacking more information and functional
elements. Levels in DFD are numbered 0, 1, 2 or
beyond. Here, we will see mainly 3 levels in the data
flow diagram, which are: 0-level DFD, 1-level DFD, and
2-level DFD.

42
43
44
45
 Part – A Questions
• Tell about class based modeling
• What is Requirement Engineering and Software
Requirement Engineering?
• Identify goals of elicitation phase
• Tell about analysis patterns of requirement Engineering.
• Outline the role of use cases in UML.
• Illustrate ‘dependency’ relationship of class diagrams.
• List out characteristics of Software requirement
specification.
• Differentiate between functional and non-functional
requirements.
• Draw the Use case diagram for College registration
system.
• Illustrate the DFD diagram. 46
 Part – B Questions

• Explain in detail about establishing the groundwork for

an understanding of software requirements
• Illustrate about eliciting requirements with necessary
example.
• Explain in detail about Negotiating requirements and
Validating requirements
• Develop about requirements analysis in detail with
suitable example.
• Outline about scenario-based modeling with example
• Discuss about class based modeling with suitable
example

47
• Discuss in detail about Requirement elicitation
methods.
• Explain about seven tasks of requirement engineering.
• Construct short notes about the elements of
requirement analysis with necessary diagram.
• Develop about class based modeling in detail with
suitable necessary diagram.
• Outline about different diagrams which supports
scenario-based modeling
• Discuss about Data Flow Diagram along with suitable
example

48