Unit 2

Software Requirements Engineering

And analysis Modeling
Requirements Engineering

• Requirements engineering is the process of identifying, analyzing,

specifying, validating, and managing the needs and expectations of
stakeholders for a software system.
• Requirement Engineering is the process of defining, documenting and
maintaining the requirements.
• Requirements Engineering ensure that the software being developed
meets the needs and expectations of the stakeholders.
• Requirements Engineering also ensure that the software is developed
in a cost-effective and efficient manner
• Requirements Engineering can improve communication and
collaboration between the development team and stakeholders
Requirements Engineering Tasks
• Seven distinct tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements Management
• Some of these tasks may occur in parallel and all are adapted to the needs of the
project
• All are defined for what the customer wants
• All serve to establish a solid foundation for the design and construction of the software
Requirements Engineering Tasks
1. Inception Task
• During inception, the requirements engineer asks a set of questions to
establish…
A basic understanding of the problem
The people who want a solution
The nature of the solution that is desired
• The effectiveness of preliminary communication and collaboration
between the customer and the developer
• Through these questions, the requirements engineer needs to…
Identify the stakeholders
Recognize multiple viewpoints
Work toward collaboration
Initiate the communication
2. Elicitation Task
Elicitation (the process of getting or producing something,
especially information or a reaction)
Eliciting requirements is difficult because of
• Customer sometimes unable understand the scop of project.
• Problems of understanding what is wanted, what the problem domain
is, and what the computing environment can handle.
• Information that is believed to be "obvious" is often omitted
• Sometimes may have got some conflicting requirement.
• Problems of volatility because the requirements change over time.
To overcome these problems the requirement gathering must be done
very systematically.
3. Elaboration Task
• During elaboration, the software engineer takes the information
obtained during inception and elicitation and begins to expand and
refine it.
• Elaboration focuses on developing a refined technical model of
software functions, features, and constraints
• It is an analysis modeling task
• Use cases are developed
• Domain classes are identified along with their attributes and
relationships
• Describe user Scenario- trying to describe how end user going to
interact to system.
4. Negotiation Task
• During negotiation, the software engineer reconciles the conflicts
between what the customer wants and what can be achieved given
limited business resources.
• Requirements are ranked (i.e., prioritized) by the customers, users,
and other stakeholders.
• Risks associated with each requirement are identified and analyzed.
• Rough guesses of development effort are made and used to assess
the impact of each requirement on project cost and delivery time.
• Using an iterative approach, requirements are eliminated, combined
and/or modified so that each party achieves some measure of
satisfaction.
The Art of Negotiation
• Recognize that it is not competition
• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit
5. Specification Task
• Specification is normally in the form of a software requirements
specification (SRS)
• It serves as the foundation for subsequent software engineering activities.
• Specify requirement in various form Like –
Written Document
Graphical form
Mathematical model
User scenario case
prototype
• A specification is the final work product produced by the requirements
engineer
6. Validation Task
• During validation, the work products produced as a result of requirements
engineering are assessed for quality.
• The validation in which requirement specification is analyzed in order to
ensure that requirement are specified unambiguously.
• The validation examined to ensure that all software requirements have
been stated clearly.
• Inconsistencies and errors have been detected and corrected
• The formal technical review (FTR) serves as the primary requirements
validation mechanism, the review team validates the software requirement.
• The review Members include software engineers, customers, users, and
other stakeholders and so on.
7. Requirements Management
Task
• Requirement management is the process of managing changing
requirements during the requirement engineering process and system
development.
• During requirements management, the project team performs a set
of activities to identify, control, and track requirements and changes
to the requirements at any time as the project proceeds.
• Requirement identification process - Each requirement is assigned a
unique identifier.
• Change Management process - Process plan is followed, when
analyzing a requirement change.
• Traceability policies- The amount of information about requirement
relationship is mentioned.
Establishing the Groundwork
• To initiate requirement engineering process meaningful conversation
between customer and software engineers must be held.
• There are the various steps that are required to initiate the
requirement engineering .
• These step are:
1. Identification of Stakeholders
2. Recognizing multiple viewpoints
3. Working towards the collaboration
4. Questioning
1.Identification of Stakeholders

• Stakeholder means anyone who gets benefited from the system in a

direct or indirect way when a system is getting developed
• Example: product engineer, software developer, customer, marketing
people

• Each stakeholder sees the system differently, gains different benefits

when the system is successfully developed and faces different risks if
the development effort fails.
2. Recognizing multiple
viewpoints
• Because there are so many different stakeholders, the system’s
requirements will be examined from various perspectives.
• Each of these stakeholders will contribute data to the requirements
engineering process.
• As information is gathered from multiple viewpoints, emerging
requirements may be inconsistent or contradictory.
• You should categories all stakeholder information so that decision-makers
can select an internally consistent set of system requirements for the
system.
• End user, Marketing People, Business Manager, Software developer,
Support engineer all these stakeholder contribute a lot in requirement
engineering process.
3. Working towards the collaboration

• If there are five stakeholders involved in a software project, there may

be five different opinions on the set of requirements.
• Customers must work together as well as with software engineering
practitioners to create a successful system.
• A requirements engineer’s job is to identify areas of attribute as well
as areas of conflict or inconsistency.
• Collaboration among the stakeholders and software engineers is
must.
4. Questioning
• The first set of questions asked is context-free and focuses on the
customer and other stakeholders, as well as the overall project goals
and benefits. You could ask
Who is the person or organization behind the request for this work?
Who will make use of the solution?
What is the economic value of a successful solution?
Is there a different source for the solution you require?
• These questions aid in identifying all stakeholders who will be
interested in the software being developed. Moreover, the questions
identify the benefit of successful implementation as well as potential
alternatives to custom software development.
• The following set of questions helps in gaining a better understanding
of the problem and allows the customer to express his or her
thoughts on a solution:

How would you characterize “good” output produced by a successful

solution?
To what problem(s) will this solution be applied?
Can you describe (or show me) the business environment in which
the solution will be used?
Will there be any special performance issues or constraints that will
influence how the solution is approached?
• The final set of questions is concerned with the effectiveness of the
communication activity itself.

Are you authentic person to respond to these questions?

Is your response “official”?
Are my queries relevant to the issue you’re dealing with?
Am I asking too many questions?
Is there any alternative source to getting answers of my questions?
Do you have any further questions?
• These questions will be initiating the communication required for
successful elicitation.
Eliciting Requirements
• Questioning is useful at inception of project but for detailed
requirement elicitation it is not sufficient.
• Ways in which elicitation done
1. Collaborative requirement gathering
2. Quality function deployment
3. Use Scenario
4. Elicitation work Product
1. Collaborative requirement gathering
• Meetings are conducted and attended by both software engineers and
other stakeholders
• Rules for preparation and participation are established
• An agenda is suggested that is formal enough to cover all important
points but informal enough to encourage the free flow ideas
• A “Facilitator ” controls the meeting (Facility Application Specification
Techniques(FAST)) approach is used.
• Example
Nowadays the market for video game is growing rapidly. We would
like to enter this market with more features , like attractive GUI, multiple
sound setting, realistic (3D) animation. This product is tentatively called
game fun, at the end of game, scores of each player should be displayed
• List of object
• List of services
• List of constraints
• Contains start & exit game option
• List of all functional keys with corresponding functionality
• Software provides interaction guidance, quick tour, sound control
• All players will play or interact through keys
• Software provides facility for change in the look of GUI
• Software displays scores of each player.
2. Quality function deployment
• Quality function deployment is a quality management techniques
which translates the needs of customer into technical requirements.

• Under Quality function deployment three types of requirement can

be defined –

1. Normal requirement
2. Expected requirement
3. Exciting requirement
3. Use Scenario

• During requirement gathering overall vision for systems functions &

features get developed.
• In order to understand how these function and features are used by
different classes of end users, developers and users create a set of
scenarios.
• This set identifies the usefulness of the system to be conducted. this
set is normally called use-cases.
• The use-cases provide a description of how the system will be used.
4. Elicitation work Product

Following are some work products that get produced during requirement
elicitation.
• Statement for scope of the system.
• A statement of feasibility study perform in order to find need of the project.
• A list of customer, users and other stakeholders who participated in
requirement elicitation
• A List of requirements and domain constraints that apply to each
• A set of usage scenarios that provide insight into the use of the system or
product under different operating conditions
• The prototypes that may get developed for defining the requirements in
better manner.
Developing Use Case
• Use case are fundamental units of modelling language in which
functionalities are distinctly represented.
• Use case depicts the software from end user’s point of view.
• Use-case diagrams describe the high-level functions and scope of a
system.
• These diagrams also identify the interactions between the system and
its actors.
• First step – to identify Actors.
• After identifying the actors next step is to develop use cases .
Use case Notation
Following are the questions that should be answered by the use cases -
• What are the goals of the system?
• Who are the primary & secondary actors?
• What are the preconditions that should exist before the development
of the system?
• What are the mains functions that must be performed by the actor?
• What are those exceptions that must be considered by the system?
• What are the changes in the behavior of the actor?
• What are of system information to be produced by the actor?
• What kind of information is gained by the actor from the system?
• Will actor inform any change in the system to the external
environment?
• ATM
System
Building the Requirements
Model
• Requirement analysis is an intermediate phase between system
engineering and software design
• Requirement analysis produce a software specification.
How is requirement analysis helpful?
Analyst-
• The requirement analysis helps the ‘analyst’ to refine software
allocation.
• Using requirement analysis various models such as data model,
function model and behavioural model can be defined.
Designer –
After requirement analysis , the designer can design for data
architectural interface and component level design.

Developer –
• Using requirement analysis specification and design the software can
be developed.
What are requirement analysis
efforts?
• Problem recognition
The requirement analysis is done for the understanding the need of the
system. The scop of the software in context of the system must be understood.
• Evaluation
Following are the task that must be done in evaluation and synthesis
phase.
Define all externally observable data objects evaluate data flow.
Define software function
Understand the behavior of the system
Establish system interface characteristics
Uncover the design constrains
• Modelling
After evaluation and synthesis, using data, functional and
behavioural domains the data model, functional model and behavioural
model can be built.

• Specification
The requirement specification(SRS) must be build.

• Review
The requirement must be reviewed by project manager and must
be refined.
1. Overall Objectives

• The requirements model must achieve three primary objectives:

 To describe what the customer requires,
To establish a basis for the creation of a software design, and
 To define a set of valid requirements list.
• The analysis model bridges the gap between a system-level
description and design model.
• The system-level description that describes overall system or business
functionality as it is achieved by applying software, hardware, data,
human, and other system elements.
• Design model describes the software architecture, user interface and
component level structure.
2. Analysis Rules of Thumb
Arlow and Neustadt suggested some rule that should followed during the
creation of analysis model. These rule called analysis of thumb.
They are as follows:
• The model should focus on requirements that are visible within
the problem or business domain.
• The level of abstraction should be relatively high. “Don’t get
bogged down in details” that try to explain how the system will
work.
• Each element of the requirements model should add to an
overall understanding of software requirements and provide
insight into the information domain, function, and behavior of the
system.
• Minimize coupling throughout the system. Coupling is basically used
to represent the relationship between two objects by means of
functionalities.
• Keep the model as simple as it can be. Don’t create additional
diagrams when they add no new information. Don’t use complex
notational forms, when a simple list will do.
3. Domain Analysis:
• The analysis patterns often reoccur across many applications within a
specific business domain.
• If these patterns are defined and categorized in a manner that allows
you to recognize and apply them to solve common problems.
• The intent is to identify common problem solving elements that are
applicable to all applications within the domain.
• It is the responsibility of domain analyst to discover and define
reusable analysis patterns, analysis classes and related information.
• Domain analysis may be viewed as an umbrella activity for the
software process.
• This improves time-to market and reduces development costs.
• Also help in building the system or product very efficiently.
Elements of the Requirement
Model
• Following are the elements of analysis model –
1. Scenario Based element
2. Class based elements
3. Behavioral elements
4. Flow Model

Figure illustrates the elements of analysis model.

1. Scenario Based element
• The system is described from the user’s point of view using a
scenario-based approach.
• Scenario-based elements of the requirements model are often the
first part of the model that is developed.
• In analysis modelling, at the beginning, creation of scenarios in the
form of use case, activity diagrams and swimlane diagram occurs.
Use cases

Use case diagram for online Mobile Shopping

Activity Diagram

• An activity diagram focuses on condition of flow and the sequence in

which it happens.
• Activity diagram is basically a flowchart to represent the flow from
one activity to another activity.
• The activity can be described as an operation of the system.
Notation of an Activity diagram:
• Initial State: It depicts the initial stage or beginning
of the set of actions.

• Final State: It is the stage where all the control

flows and object flows end.

• Decision Box: It makes sure that the control flow

or object flow will follow only one path.

• Action Box: It represents the set of actions that

are to be performed.
• Forks:
The fork is used to represent that many activities
Can be parallelly carried out.

• Join: A join is one where two results of concurrent activities add and
form a single result.
Components of activity diagram
swimlane diagram
In swimlane diagram the activity
diagrams is partitioned
according to the class who is
responsible for carrying
out these activities.
2. Class based elements
• Class diagrams represents how to put various object together.
• These objects are categorized into classes.
• classes—a collection of things that have similar attributes and
common behaviors.
• A class diagram give overview of a system, in which various classes
and relationship among these classes is represented.
• For example:
In a class diagram manager, executive, salesperson can be
represented by a class employee.
Class Diagram for Shape
3. Behavioral elements
• The dynamic behaviour of the system can be represented by creating
the behavioural model of the system.
• Basically the behavioural model represent how software will respond
to external events.
• The state diagram and sequence diagram are used for representing
behaviour of system.
Sequence diagram for ATM system
4. Flow Model
• The Flow model is drowning by designing special kind of diagrams
called data flow diagrams and control flow diagrams.
• The data flow diagrams depicts the information flow and transform
that are applied on the data as it moves from input to output.
Components of Data Flow Diagram:
• Following are the components of the data flow diagram that are used
to represent source, destination, storage and flow of data.
1. Entities:
Entities include source and destination of the data. Entities are
represented by rectangle with their corresponding names.
Components of Data Flow Diagram:
2. Process:
• The tasks performed on the data is known as process. Process is
represented by circle. Somewhere round edge rectangles are also
used to represent process.
3. Data Storage:
• Data storage includes the database of the system. It is represented by
rectangle with both smaller sides missing or in other words within
two parallel lines.
4. Data Flow:
• The movement of data in the system is known as data flow. It is
represented with the help of arrow.
Data Flow Diagram Example
Negotiating the Requirements
• During the requirement engineering the inception, elicitation and
elaboration determine the customer requirements.
• But the requirement obtain by these task are not sufficient details.
• There is an important requirement engineering task named Negotiation.
• Negotiation means developer communicates with customer so that some
requirements specified by the customer can be negotiated or modified in
order to meet the budget and deadlines of the project.
Negotiations are Carried out for following two reasons:
• In order to develop project Plan
• By the negotiations, the real-world constraints are understood by both the
developer and the customer.
• If WIN-WIN situation is achieved after the negotiation then it is called
as best negotiation.
• The WIN-WIN situation means customer gets satisfied because his
measure needs going to get fulfilled and developer gets satisfied.
• The communication with customer is the most important activity for
the negotiation.
• Apart from this some important activities are-
 Identify the important stakeholders of the system
Determine the requirements that are the most important for the
customer.
Negotiate with the customer in order to achieve the WIN-WIN
condition.
Validating Requirements
• During validation, the work products produced as a result of
requirements engineering are assessed for quality.
• The specification is examined to ensure that all software
requirements have been stated clearly.
• inconsistencies and errors have been detected and corrected
• the work products conform to the standards established for the
process, the project, and the product
• The formal technical review serves as the primary requirements
validation mechanism.
• Members include software engineers, customers, users, and other
stakeholders
• Some important questions that are consider while validating the
requirements.
Is each requirement consistent with the overall objectives for the
system?
Are requirements abstract?
Does particular requirement really necessary?
Does each requirement achievable by software system?
Does requirement have some source?

• The requirement of the system have the accurate reflection of the

customer needs and they serve as the foundation for the software
design.