Requirements Engineering

• Requirements engineering (RE) is the process of defining,

documenting, and maintaining requirements in the engineering
design process.
• It is common in systems engineering and software engineering.
• It is process of collecting the software requirements from the client
then understand, evaluate and document it.
• Requirement engineering constructs a bridge for design and
construction.
• The activities involved in requirements engineering vary depending on
the type of system being developed and the specific practices of the
organization(s) involved. These may include:
1. Requirements inception– Developers and customers meet, the latter
are inquired concerning their needs and wants regarding the software
product.
2. Requirements analysis and negotiation – Requirements are identified
and conflicts with customers are solved. Both written and graphical
tools are used as aids. (Examples of written analysis tools: use cases
and user stories. Examples of graphical tools: UML and LML).
3. System modelling – Some engineering fields require the product to be completely designed
and modelled before its construction or fabrication starts and, therefore, the design phase
must be performed in advance Many fields might derive models of the system with the
Lifecycle Modelling Language, whereas others, might use UML. Requirements specification –
Requirements are documented in a formal document called a Requirements Specification (RS),
which will become official only after validation. A RS can contain both written and graphical
(models) information if necessary. Example: Software requirements specification (SRS).
4. Requirements validation – Checking that the documented requirements and models are
consistent and meet the needs of the customer. Only if the final draft passes the validation
process, the RS becomes official.
5. Requirements management – Managing all the activities related to the requirements since
inception, supervising as the system is developed and, even until after it is put into use (e. g.,
changes, extensions, etc.)
Establishing ground work
• Groundwork(inception) consists of:
1. Identifying customers :determine who you want to get input from.
2. Recognizing viewpoints: Getting a variety of views is important to
determine who/what is the best options and input to contribute to
the project’s success.
3. Establishing collaboration among customers through conducting
conversations and questionnaires. it is important to work toward a
common goal and get people to work together to a common goal.
Eliciting requirements
• 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.
There are a number of requirements elicitation
methods. Few of them are listed below –
• Interviews: Objective of conducting an interview is to understand the customer’s
expectations from the software.
• Brainstorming Sessions: It is a group technique intended to generate lots of new
ideas providing a platform to share views
• Facilitated Application Specification Technique (FAST):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.
• Quality Function Deployment (QFD):translate the customer need into the technical
requirement for the software
• Use Case Approach: defining a list of actions or event steps or interactions between a
role (known in the Unified Modelling Language as an actor) and a system, to achieve
a goal.
Eliciting requirement steps are as follows:
1. Collaborative requirements gathering: Gathering the requirements by conducting the
meetings between developer and customer.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.
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.
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 is created as a result of
requirement elicitation. It depends on the size of the system or product
to be built.
• The work product consists of feasibility statement and scope of the
system.
• It also consists of a list of users participate in the requirement
elicitation.
Developing use cases
• In software and systems engineering, a use case is a list of actions or
event steps, typically defining the interactions between a role (known
in the Unified Modelling Language as an actor) and a system, to
achieve a goal.
• The actor can be a human, an external system, or time.
• Another way to look at it is a use case describes a way in which a real-
world actor interacts with the system.
•  System use cases can be written in both an informal manner and a
formal manner.
• A use case is a term that describes how a user uses a system to
accomplish a particular goal.
• Use cases define interactions between external actors and the system
to attain particular goals.
• There are three basic elements that make up a use case:
1. Actors: Actors are the type of users that interact with the system.
2. System: Use cases capture functional requirements that specify the
intended behaviour of the system.
3. Goals: Use cases are typically initiated by a user to fulfil goals
describing the activities and variants involved in attaining the goal.
Advantages of use case
• The list of goal names provides the shortest summary of what the
system will offer
• It gives an overview of the roles of each and every component in the
system. It will help us in defining the role of users, administrators etc.
• It helps us in extensively defining the user’s need and exploring it as
to how it will work.
• It provides solutions and answers to many questions that might pop
up if we start a project unplanned.
Planning a use case
• Use Case: What is the main objective of this use case. For eg. Adding a
software component, adding certain functionality etc.
• Primary Actor: Who will have the access to this use case. In the above
examples, administrators will have the access.
• Scope: Scope of the use case
• Level: At what level the implementation of the use case be.
• Flow: What will be the flow of the functionality that needs to be there.
More precisely, the work flow of the use case.
• Some other things that can be included in the use cases are:
• Preconditions
• Postconditions
• Brief course of action
• Time Period
The steps in designing use cases

• Identify the users of the system

• For each category of users, create a user profile. This includes all roles
played by the users relevant to the system.
• Identify significant goals associated with each role to support the system.
The system’s value proposition identifies the significant role.
• Create use cases for every goal associated with a use case template and
maintain the same abstraction level throughout the use case. Higher level
use case steps are treated as goals for the lower level.
• Structure the use cases
Building requirements model
• Requirements modelling in software engineering is essentially the
planning stage of a software application or system.
• A client approaches a software development team to create an
application or system from scratch or update an existing one.
Requirements modelling comprises two types
a)flow-oriented modelling, b)class-based modelling
• Each of these stages/patterns examines the same problem from a
different perspective.
Identifying the Requirements
• Requirements are the conditions that a proposed application must
meet in order to solve the business problem.
• The customer and the developer collaboratively work to form a
feasible set of requirements for the project.
• A functional requirement specifies something that the application or
system should do. This is defined as a behaviour of the system that
takes input and provides output. 
• Non-functional requirements,also called quality requirements,
describe how the system should function. Non-functional
requirements of a system include performance (e.g., response time),
maintainability and scalability etc.
Requirements Negotiation
• Unresolved conflicts reduce system acceptance
E.g., when only one of the contradictory requirements is implemented,
the other party is demotivated
Overall goal of negotiation
• Gain a common and agreed-upon understanding of the requirements
among all customers
• Resolving contradictory requirements .
• Negotiation needs to be done throughout the entire requirements
• engineering process (not as a single step at the end)
Requirement validation
• It’s a process of ensuring the specified requirements meet the
customer needs. It’s concerned with finding problems with the
requirements.
• These problems can lead to extensive rework costs when these they
are discovered in the later stages, or after the system is in service.
• The cost of fixing a requirements problem by making a system change
is usually much greater than repairing design or code errors. Because
a change to the requirements usually means the design and
implementation must also be changed, and re-tested.
During the requirements validation process, different types of checks should be carried out on
the requirements. These checks include:
• Validity checks: The functions proposed by stakeholders should be aligned with what the
system needs to perform. You may find later that there are additional or different functions
are required instead.
• Consistency checks: Requirements in the document shouldn’t conflict or different description
of the same function
• Completeness checks: The document should include all the requirements and constrains.
• Realism checks: Ensure the requirements can actually be implemented using the knowledge
of existing technology, the budget, schedule, etc.
• Verifiability: Requirements should be written so that they can be tested. This means you
should be able to write a set of tests that demonstrate that the system meets the specified
requirements.
Requirement validation techniques
1.Test case generation:
• Requirement mentioned in SRS document should be testable, the conducted tests reveal the
error present in the requirement. It is generally believed that if the test is difficult or impossible
to design than, this usually means that requirement will be difficult to implement and it should
be reconsidered.
2. Prototyping:
• In this validation techniques the prototype of the system is presented before the end-user or
customer, they experiment with the presented model and check if it meets their need. This
type of model is generally used to collect feedback about the requirement of the user.
3. Requirements Reviews:
• In this approach, the SRS is carefully reviewed by a group of people including people from both
the contractor organisations and the client side, the reviewer systematically analyses the
document to check error and ambiguity.
4. Automated Consistency Analysis:
• This approach is used for automatic detection of an error, such as non determinism,
missing cases, a type error, and circular definitions, in requirements specifications.
• The report of all inconsistencies is identified and corrective actions are taken.
5. Walk-through:
• A walkthrough does not have a formally defined procedure and does not require a
differentiated role assignment.
• Checking early whether the idea is feasible or not.
• Obtaining the opinions and suggestion of other people.
• Checking the approval of others and reaching an agreement.
Requirements Analysis
• Requirements Analysis is the process of defining the expectations of
the users for an application that is to be built or modified.
• It involves all the tasks that are conducted to identify the needs of
different stakeholders.
• Therefore requirements analysis means to analyze, document,
validate and manage software or system requirements.
• High-quality requirements are documented, actionable, measurable,
testable, traceable, helps to identify business opportunities, and are
defined to a facilitate system design.
Requirements Analysis Process

• The requirements analysis process involves the following steps:

• Eliciting requirements
• Analyzing requirements
• Requirements modeling
• Review and retrospective
1- Eliciting requirements
• The process of gathering requirements by communicating with the
customers is known as eliciting requirements.

2- Analyzing requirements
• This step helps to determine the quality of the requirements. It
involves identifying whether the requirements are unclear,
incomplete, ambiguous, and contradictory. These issues resolved
before moving to the next step.
3- Requirements modeling
• In Requirements modeling, the requirements are usually documented
in different formats such as use cases, user stories, natural-language
documents, or process specification.

4- Review and retrospective

• This step is conducted to reflect on the previous iterations of
requirements gathering in a bid to make improvements in the process
going forward.
Requirements Analysis Techniques:
• There are different techniques used for business Requirements Analysis. Below is
a list of different Requirements Analysis Techniques:
• Business process modelling notation (BPMN)
• UML (Unified Modelling Language)
• Flowchart technique
• Data flow diagram
• Role Activity Diagrams (RAD)
• Gantt Charts
• IDEF (Integrated Definition for Function Modeling)
• Gap Analysis
1- Business process modeling notation (BPMN)
• This technique is similar to creating process flowcharts, although BPMN has its own
symbols and elements. Business process modeling and notation is used to create
graphs for the business process. These graphs simplify understanding the business
process. BPMN is widely popular as a process improvement methodology.
2- UML (Unified Modeling Language)
• UML consists of an integrated set of diagrams that are created to specify, visualize,
construct and document the artifacts of a software system. UML is a useful
technique while creating object-oriented software and working with the software
development process.  In UML, graphical notations are used to represent the
design of a software project.  UML also help in validating the architectural design of
the software.
3- Flowchart technique
• A flowchart depicts the sequential flow and control logic of a set of activities that are related.
Flowcharts are in different formats such as linear, cross-functional, and top-down. The flowchart can
represent system interactions, data flows, etc. Flow charts are easy to understand and can be used by
both the technical and non-technical team members. Flowchart technique helps in showcasing the
critical attributes of a process.

4- Data flow diagram

• This technique is used to visually represent systems and processes that are complex and difficult to
describe in text. Data flow diagrams represent the flow of information through a process or a system.
It also includes the data inputs and outputs, data stores, and the various subprocess through which
the data moves. DFD describes various entities and their relationships with the help of standardized
notations and symbols. By visualizing all the elements of the system it is easier to identify any
shortcomings. These shortcomings are then eliminated in a bid to create a robust solution.
5- Role Activity Diagrams (RAD)
• Role-activity diagram (RAD) is a role-oriented process model that represents role-activity
diagrams. Role activity diagrams are a high-level view that captures the dynamics and role
structure of an organization. Roles are used to grouping together activities into units of
responsibilities. Activities are the basic parts of a role. An activity may be either carried
out in isolation or it may require coordination with other activities within the role.

6- Gantt Charts
• Gantt charts used in project planning as they provide a visual representation of tasks that
are scheduled along with the timelines. The Gantt charts help to know what is scheduled
to be completed by which date. The start and end dates of all the tasks in the project can
be seen in a single view.
7- IDEF (Integrated Definition for Function Modeling)
• Integrated definition for function modeling (IDEFM) technique represents the
functions of a process and their relationships to child and parent systems with the
help of a box. It provides a blueprint to gain an understanding of an organization’s
system.
8- Gap Analysis
• Gap analysis is a technique which helps to analyze the gaps in performance of a
software application to determine whether the business requirements are met or
not. It also involves the steps that are to be taken to ensure that all the business
requirements are met successfully. Gap denotes the difference between the
present state and the target state. Gap analysis is also known as need analysis,
need assessment or need-gap analysis.
Requirement modelling strategies
• Attributes
• Please visit the link: https://slideplayer.com/slide/2477580/ for
further notes on requirement modelling strategies.