UNIT-II

Requirements Engineering: Tasks

Introduction to requirement engineering
 The process of collecting the software requirement from the client
then understand, evaluate and document it is called as requirement
engineering.
 Requirement engineering constructs a bridge for design and
construction.

Requirement engineering consists of seven different tasks as follow:

1. Inception(Beginning)
 Inception is a task where the requirement engineering asks a set of
questions to establish a software process.
 In this task, it understands the problem and evaluates with the proper
solution.
 It collaborates with the relationship between the customer and the
developer.
 The developer and customer decide the overall scope and the nature of
the question.

2. Elicitation(Extraction)
Elicitation means to find the requirements from anybody.
The requirements are difficult because the following problems occur in
elicitation.

Problem of scope: The customer give the unnecessary technical detail

rather than clarity of the overall system objective.

Problem of understanding: Poor understanding between the customer and

the developer regarding various aspect of the project like capability,
limitation of the computing environment.

Problem of volatility: In this problem, the requirements change from time

to time and it is difficult while developing the project.

1
 3. Elaboration(explanation)
 In this task, the information taken from user during inception and
elaboration and are expanded and refined in elaboration.
 Its main task is developing pure model of software using functions,
feature and constraints of a software.

4. Negotiation(Cooperation)
 In negotiation task, a software engineer decides the how will
the project be achieved with limited business resources.
 To create rough guesses of development and access the impact of the
requirement on the project cost and delivery time.

5. Specification
 In this task, the requirement engineer constructs a final work product.
 The work product is in the form of software requirement specification.
 In this task, formalize the requirement of the proposed software such
as informative, functional and behavioral.
 The requirement are formalize in both graphical and textual formats.

6. Validation
 The work product is built as an output of the requirement engineering
and that is accessed for the quality through a validation step.
 The formal technical reviews from the software engineer, customer
and other stakeholders helps for the primary requirements validation
mechanism.

7. Requirement management
 It is a set of activities that help the project team to identify, control
and track the requirements and changes can be made to the requirements at
any time of the ongoing project.
 These tasks start with the identification and assign a unique identifier
to each of the requirement.

 After finalizing the requirement traceability table is developed.

 The examples of traceability table are the features, sources,
dependencies, subsystems and interface of the requirement.
2
Initiating the Requirements Engineering Process
Requirements Engineering Process

Definition for Requirements Engineering Process

It is the process of discovering, analyzing, documenting and validating the

requirements of the system

Requirements engineering (RE) refers to the process of defining,

documenting, and maintaining requirements in the engineering design
process.
Requirement Engineering Process
It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

3
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change and
conformable to established standards.

Types of Feasibility:
1. Technical Feasibility - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer requirements
within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve
business problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the
necessary software can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements
are identified with the help of customers and existing systems processes, if
available.
Analysis of requirements starts with requirement elicitation. The
requirements are analyzed to identify inconsistencies, defects, omission, etc.
We describe requirements in terms of relationships and also resolve
conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.
o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system
requirements.

4
3. Software Requirement Specification:
The models used at this stage include ER diagrams, data flow diagrams
(DFDs), function decomposition diagrams (FDDs), data dictionaries, etc.
o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely
for modeling the requirements. DFD shows the flow of data through a
system. The system may be a company, an organization, a set of
procedures, a computer hardware system, a software system, or any
combination of the preceding. The DFD is also known as a data flow
graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirements
stage, the data dictionary should at least define customer data items, to
ensure that the customer and developers use the same definition and
terminologies.
o Entity-Relationship Diagrams: Another tool for requirement
specification is the entity-relationship diagram, often called an "E-R
diagram." It is a detailed logical representation of the data for the
organization and uses three main constructs i.e. data entities,
relationships, and their associated attributes.
5
 4. Software Requirement Validation:
After requirement specifications developed, the requirements discussed in
this document are validated.
Requirements can be the check against the following conditions -
o If they can practically implement
o If they are correct and as per the functionality and specially of
software
o If there are any ambiguities
o If they are full
o If they can describe
Requirements Validation Techniques
o Requirements reviews/inspections: systematic manual analysis of
the requirements.
o Prototyping: Using an executable model of the system to check
requirements.
o Test-case generation: Developing tests for requirements to check
testability.
o Automated consistency analysis: checking for the consistency of
structured requirements descriptions.

Eliciting requirement steps are as follows:

1. Collaborative requirements gathering

 Gathering the requirements by conducting the meetings between
developer and customer.
 Fix the rules for preparation and participation.
 The main motive is to identify the problem, give the solutions for the
elements, negotiate the different approaches and specify the primary set of
solution requirements in an environment which is valuable for achieving
goal.

2. Quality Function Deployment (QFD)

 In this technique, translate the customer need into the technical
requirement for the software.
 QFD system designs a software according to the demands of the
customer.
6
 QFD consist of three types of requirement:

Normal requirements
 The objective and goal are stated for the system through the meetings
with the customer.
 For the customer satisfaction these requirements should be there.

Expected requirement
 These requirements are implicit.
 These are the basic requirement that not be clearly told by the
customer, but also the customer expect that requirement.

Exciting requirements
 These features are beyond the expectation of the customer.
 The developer adds some additional features or unexpected feature
into the software to make the customer more satisfied.
For example, the mobile phone with standard features, but the developer
adds few additional functionalities like voice searching, multi-touch screen
etc. then the customer more exited about that feature.

3. Usage scenarios
 Till the software team does not understand how the features and
function are used by the end users it is difficult to move technical activities.
 To achieve above problem the software team produces a set of
structure that identify the usage for the software.
 This structure is called as 'Use Cases'.

4. Elicitation work product

 The work product created as a result of requirement elicitation that is
depending on the size of the system or product to be built.
 The work product consists of a statement need, feasibility, statement
scope for the system.
 It also consists of a list of users participate in the requirement
elicitation.

7
 Building the Analysis Model -
 Analysis model operates as a link between the 'system description' and
the 'design model'.
 In the analysis model, information, functions and the behaviour of the
system is defined and these are translated into the architecture, interface
and component level design in the 'design modeling'.
Elements of the analysis model

1. Scenario based element

 This type of element represents the system user point of view.
 Scenario based elements are use case diagram, user stories.

2. Class based elements

 The object of this type of element manipulated by the system.
 It defines the object,attributes and relationship.
 The collaboration is occurring between the classes.
 Class based elements are the class diagram, collaboration diagram.

3. Behavioral elements
 Behavioral elements represent state of the system and how it is
changed by the external events.
 The behavioral elements are sequenced diagram, state diagram.

4. Flow oriented elements

 An information flows through a computer-based system it gets
transformed.
 It shows how the data objects are transformed while they flow
between the various system functions.
 The flow elements are data flow diagram, control flow diagram.

8
 Analysis Rules of Thumb
The rules of thumb that must be followed while creating the analysis model.

The rules are as follows:

 The model focuses on the requirements in the business domain. The
level of abstraction must be high i.e there is no need to give details.
 Every element in the model helps in understanding the software
requirement and focus on the information, function and behaviour of the
system.
 The consideration of infrastructure and nonfunctional model delayed
in the design.

Requirement Analysis
definition
Requirement Analysis, also known as Requirement Engineering, is the
process of defining user expectations for a new software being built or
modified.

9
The various steps of requirement analysis are shown in fig:

(i) Draw the context diagram: The context diagram is a simple model that
defines the boundaries and interfaces of the proposed systems with the
external world. It identifies the entities outside the proposed system that
interact with the system. The context diagram of student result management
system is given below:

10
 (ii) Development of a Prototype (optional): One effective way to find out
what the customer wants is to construct a prototype, something that looks
and preferably acts as part of the system they say they want.

The prototype should be built quickly and at a relatively low cost. Hence it
will always have limitations and would not be acceptable in the final
system. This is an optional activity.

(iii) Model the requirements: This process usually consists of various

graphical representations of the functions, data entities, external entities, and
the relationships between them. The graphical view may help to find
incorrect, inconsistent, missing, and superfluous requirements. Such models
include the Data Flow diagram, Entity-Relationship diagram, Data
Dictionaries, State-transition diagrams, etc.

(iv) Finalise the requirements: After modeling the requirements, we will

have a better understanding of the system behavior.

Data Modeling Concepts

Data modeling, sometimes also called information modeling, is the process
of visually representing what data the application or system will use, and how
it will flow. The resulting diagram or other visual representation is meant to
be designed in a way that is as easy to understand as possible.

Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering to
produce a conceptual data model of an information system. Diagrams
created using this ER-modeling method are called Entity-Relationship
Diagrams or ER diagrams or ERDs.

Components of an ER Diagrams
1. Entity
An entity can be a real-world object, either animate or inanimate, that can
be merely identifiable. An entity is denoted as a rectangle in an ER diagram.
For example, in a school database, students, teachers, classes, and courses

11
offered can be treated as entities. All these entities have some attributes or
properties that give them their identity.

Entity Set
An entity set is a collection of related types of entities. An entity set may
include entities with attribute sharing similar values. For example, a Student
set may contain all the students of a school; likewise, a Teacher set may
include all the teachers of a school from all faculties. Entity set need not be
disjoint.

2. Attributes
Entities are denoted utilizing their properties, known as attributes. All
attributes have values. For example, a student entity may have name, class,
and age as attributes.
There exists a domain or range of values that can be assigned to attributes.
For example, a student's name cannot be a numeric value. It has to be
alphabetic. A student's age cannot be negative, etc.

12
There are four types of Attributes:
1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute

1. Key attribute: Key is an attribute or collection of attributes that uniquely

identifies an entity among the entity set. For example, the roll_number of a
student makes him identifiable among students.

There are mainly three types of keys:

1. Super key: A set of attributes that collectively identifies an entity in
the entity set.
2. Candidate key: A minimal super key is known as a candidate key. An
entity set may have more than one candidate key.
3. Primary key: A primary key is one of the candidate keys chosen by
the database designer to uniquely identify the entity set.

2. Composite attribute: An attribute that is a combination of other

attributes is called a composite attribute. For example, In student entity, the
student address is a composite attribute as an address is composed of other
characteristics such as pin code, state, country.
13
3. Single-valued attribute: Single-valued attribute contain a single value.
For example, Social_Security_Number.

4. Multi-valued Attribute: If an attribute can have more than one value, it

is known as a multi-valued attribute. Multi-valued attributes are depicted by
the double ellipse. For example, a person can have more than one phone
number, email-address, etc.

5. Derived attribute: Derived attributes are the attribute that does not exist
in the physical database, but their values are derived from other attributes
present in the database. For example, age can be derived from date_of_birth.
In the ER diagram, Derived attributes are depicted by the dashed ellipse.

14
3. Relationships
The association among entities is known as relationship. Relationships are
represented by the diamond-shaped box. For example, an employee
works_at a department, a student enrolls in a course. Here, Works_at and
Enrolls are called relationships.

15
Relationship set
A set of relationships of a similar type is known as a relationship set. Like
entities, a relationship too can have attributes. These attributes are called
descriptive attributes.

Degree of a relationship set

The number of participating entities in a relationship describes the degree of
the relationship. The three most common relationships in E-R models are:
1. Unary (degree1)
2. Binary (degree2)
3. Ternary (degree3)

1. Unary relationship: This is also called recursive relationships. It is a

relationship between the instances of one entity type. For example, one
person is married to only one person.

2. Binary relationship: It is a relationship between the instances of two

entity types. For example, the Teacher teaches the subject.

16
3. Ternary relationship: It is a relationship amongst instances of three
entity types. In fig, the relationships "may have" provide the association of
three entities, i.e., TEACHER, STUDENT, and SUBJECT. All three entities
are many-to-many participants. There may be one or many participants in a
ternary relationship.
In general, "n" entities can be related by the same relationship and is known
as n-ary relationship.

Cardinality
Cardinality describes the number of entities in one entity set, which can be
associated with the number of entities of other sets via relationship set.

Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most
one entity of entity set B and vice versa. Let us assume that each student has
only one student ID, and each student ID is assigned to only one person. So,
the relationship will be one to one.

17
Using Sets, it can be represented as:

2. One to many: When a single instance of an entity is associated with

more than one instances of another entity then it is called one to many
relationships. For example, a client can place many orders; a order cannot
be placed by many customers.

Using Sets, it can be represented as:

3. Many to One: More than one entity from entity set A can be associated
with at most one entity of entity set B, however an entity from entity set B
can be associated with more than one entity from entity set A. For example -
many students can study in a single college, but a student cannot study in
many colleges at the same time.

18
Using Sets, it can be represented as:

4. Many to Many: One entity from A can be associated with more than one
entity from B and vice-versa. For example, the student can be assigned to
many projects, and a project can be assigned to many students.

Using Sets, it can be represented as:

19