WELCOME

Software Engineering[210253]

Mr. Shreyas. S. Shinde

Assistant Professor
Dept. Of Computer Engineering,
Sinhgad Institute of Technology, Lonavala
[email protected]
Cell. +91 8862046732
 Unit 2 - Software Requirements Engineering and Analysis

• Modeling: Requirements Engineering, Establishing the Groundwork, Identifying

Stakeholders, Recognizing Multiple Viewpoints, working toward Collaboration,
Asking the First Questions, Eliciting Requirements, Collaborative Requirements
Gathering, Usage Scenarios, Elicitation Work Products, Developing Use Cases,
Building the Requirements Model, Elements of the Requirements Model,
Negotiating Requirements, Validating Requirements.

• Suggested Free Open Source tools: StarUML, Modelio, SmartDraw.

7
 Requirements Engineering
• Definition: Description and Specifications of a
system
• The process of establishing the services that the
customer requires from a system and the constraints
under which it operates and is developed
• Requirements may be functional or non-functional
– Functional requirements describe system services
or functions
– Non-functional requirements is a constraint on the
system or on the development process
 What is a Requirement?

• It may range from a high-level abstract statement of a

service or of a system constraint to a detailed
mathematical functional specification
• This is unavoidable as requirements may serve a dual
function
– May be the basis for a bid for a contract - therefore
must be open to interpretation
– May be the basis for the contract itself - therefore must
be defined in detail
– Both these statements may be called requirements
 Types of requirements
• User requirements
– Statements in natural language (NL) plus diagrams of the
services the system provides and its operational constraints.
Written for customers
• System requirements
– A structured document setting out detailed descriptions of the
system services. Written as a contract between client and
contractor
• Software specification
– A detailed software description which can serve as a basis for
a design or implementation. Written for developers
 Requirements Targets
Client Managers

User Requirements System end-users

Contract managers
System architects

System end-users
System Client engineers
Requirements
System architects
Software developers

Software Client engineers

Specification
System architects
Software developers
 Requirements Types:

1. Functional requirements: services the system should

provide

2. Non-functional requirements: constraints on the services

of functions offered by the system. e.g. speed, time to
market

3. Domain requirements: related to the application domain

of the system (may be functional or non-functional
requirements)
 Functional requirements
• Functionality or services that the system is expected to provide.
• Functional requirements may also explicitly state what the
system shouldn’t do.
• Functional requirements should be written in a simple language,
so that it is easily understandable.
• Functional requirements specification should be:
– Complete: All services required by the user should be
defined
– Consistent: should not have contradictory definition (also
avoid ambiguity→ don’t leave room for different
interpretations)
– The examples of functional requirements are authentication,
business rules, audit tracking, certification requirements,
transaction corrections, etc.
 Non-Functional requirements

• Requirements that are not directly concerned with the

specific functions delivered by the system
• Typically relate to the system as a whole rather than the
individual system features
• Non-functional requirements are not related to the
software's functional aspect.
• Often could be deciding factor on the survival of the
system (e.g. reliability, cost, response time)
• Basic non-functional requirements are - usability,
reliability, security,storage,cost, flexibility, configuration,
performance, legal or regulatory requirements, etc.
Non-Functional requirements classifications:

Non-Functional
Requirements

Product requirements External requirements

•Efficiency •Interoperability
•Reliability Organizational requirements •Ethics
•Portability •Delivery •Legislative
•Usability •Implementation •Privacy
•Performance •Standards •Safety
•Space
 Functional Requirements Non Functional Requirements
A non-functional requirement defines the quality attribute
A functional requirement defines a system or its component.
of a software system.
It places constraints on “How should the software system
It specifies “What should the software system do?”
fulfill 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.
Helps you verify the functionality of the software. Helps you to verify the performance of the software.

Functional Testing like System, Integration, End to End, API Non-Functional Testing like Performance, Stress, Usability,
testing, etc are done. Security testing, etc are done.
Usually easy to define. Usually more difficult to define.

Example
Example
1) Emails should be sent with a latency of no greater than 12
1) Authentication of user whenever he/she logs into the
hours from such an activity.
system.
2) The processing of each request should be done within 10
2) System shutdown in case of a cyber attack.
seconds
3) A Verification email is sent to user whenever he/she
3) The site should load in 3 seconds when the number of
registers for the first time on some software system.
simultaneous users are > 10000
 Domain requirements
• Domain requirements are derived from the application domain of
the system rather than from the specific needs of the system users.

• May be new functional requirements, constrain existing

requirements or set out how particular computation must take
place.

• Example: tolerance level of landing gear on an aircraft (different

on dirt, asphalt, water), or what happens to fiber optics line in case
of sever weather during winter Olympics (Only domain-area
experts know)
Requirements Engineering Tasks: The software
requirements engineering process includes the following
steps of activities:
1.Inception
2.Elicitation
3.Elaboration
4.Negotiation
5.Specification
6.Validation
Inception:
This is the first phase of the requirements analysis process. This phase
gives an outline of how to get started on a project.
In the inception phase, all the basic questions are asked on how to go about
a task or the steps required to accomplish a task.
A basic understanding of the problem is gained and the nature of the
solution is addressed.
following criteria have to be addressed by the software engineers:
•Understanding of the problem.
•The people who want a solution.
•Nature of the solution.
•Communication and collaboration between the customer and developer.
2. Elicitation:
This is the second phase of the requirements analysis process. This phase
focuses on gathering the requirements from the stakeholders.
One should be careful in this phase, as the requirements are what establishes
the key purpose of a project.
The following problems can occur in the elicitation phase:
•Problem of Scope: The requirements given are of unnecessary detail, ill-
defined, or not possible to implement.
•Problem of Understanding: Not having a clear-cut understanding
between the developer and customer when putting out the requirements
needed.
•Problem of Volatility: Requirements changing over time can cause
difficulty in leading a project.
3. Elaboration: This is the third phase of the requirements analysis process. This
phase is the result of the inception and elicitation phase.
In the elaboration process, it takes the requirements that have been stated and
gathered in the first two phases and refines them.
The main task in this phase is to indulge in modeling activities and develop a
prototype that elaborates on the features and constraints using the necessary tools
and functions.
4. Negotiation: This is the fourth phase of the requirements analysis process. This
phase emphasizes discussion and exchanging conversation on what is needed and
what is to be eliminated. The following are discussed in the negotiation phase:
Availability of Resources.
Delivery Time.
Scope of requirements.
Project Cost.
Estimations on development.
5. Specification:
This is the fifth phase of the requirements analysis process. This phase specifies the
following:
Written document.
A set of models.
A collection of use cases.
A prototype.
The models used in this phase include ER (Entity Relationship) diagrams, DFD (Data Flow
Diagram), FDD (Function Decomposition Diagrams), and Data Dictionaries.
6. Validation:
This is the sixth phase of the requirements analysis process. This phase focuses on checking
for errors and debugging. In the validation phase, the developer scans the specification
document and checks for the following:
All the requirements have been stated and met correctly
Errors have been debugged and corrected.
Work product is built according to the standards.
 Groundwork For Understanding of Software Requirements
▪Requirements engineering is simply a matter of conducting meaningful
conversations with colleagues who are well-known members of the
team. But reality is often quite different.
▪Customer(s) or end users may be located in a different city or country,
may have only a vague(unclear) idea of what is required, may have
conflicting opinions about the system to be built, may have limited
technical knowledge, and may have limited time to interact with the
requirements engineer
▪Here are the steps required to establish the groundwork for an
understanding of software requirements—to get the project started in
away that will keep it moving forward toward a successful solution.
Identifying Stakeholders
Recognizing Multiple Viewpoints
Working toward Collaboration
Asking the First Questions
18
Groundwork For Understanding of Software Requirements

1.Identifying Stakeholders
• Sommerville and Sawyer [Som97] define a stakeholder as “anyone
who benefits in a direct or indirect way from the system which is
being developed.”
Ex : business operations managers, product managers, marketing
people, internal and external customers, end users, consultants,
product engineers, software engineers, support and maintenance
engineers, and others.
• Each stakeholder has a different view of the system, achieves
different benefits, and is open to different risks if the development
effort should fail. 19
 Groundwork For Understanding of Software Requirements

2. Recognizing Multiple Viewpoints

• Because many different stakeholders exist, the requirements of the
system will be explored from many different points of view.
• Each of these constituencies (voters) will contribute information to
the requirements engineering process. As information from
multiple viewpoints is collected, emerging requirements may be
inconsistent or may conflict with one another.
• You should categorize all stakeholder information (including
inconsistent and conflicting requirements) in a way that will allow
decision makers to choose an internally consistent set of
requirements for the system. 20
Groundwork For Understanding of Software Requirements

3. Working toward Collaboration

If five stakeholders are involved in a software project, you may
have
-five (or more) different opinions about
-The proper set of requirements, after that
-Customers (and other stakeholders) must collaborate among
themselves and with software engineering practitioners if a
successful system is to result.
The job of a requirements engineer is to identify areas of
commonality and areas of conflict or inconsistency.
21
Groundwork For Understanding of Software Requirements

4. Asking the First Questions

• first set of context-free questions focuses on the customer and other

stakeholders, the overall project goals and benefits. For example,

• you might ask:

• Who is behind the request for this work?

• Who will use the solution?

• What will be the economic benefit of a successful solution?

• Is there another source for the solution that you need?

• These questions help to identify all stakeholders who will have

interest in the software to be built.
22
 Eliciting Requirements

In order to encourage a collaborative, team-oriented approach to

requirements gathering, stakeholders work together to identify
the problem, propose elements of the solution, negotiate
different approaches and specify a preliminary set of solution
requirements

▪Collaborative Requirements Gathering

▪Quality Function Deployment
▪Usage Scenarios
▪Elicitation Work Products
25
 1.Collaborative Requirements Gathering
Many different approaches to collaborative requirements gathering have
been proposed. Each makes use of a slightly different scenario, but all
apply some variation on the following basic guidelines:
•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 of ideas.
•A “facilitator” (can be a customer, a developer, or an outsider) controls the
meeting.
•A “definition mechanism” (can be work sheets, flip charts, or wall stickers
or an electronic bulletin board, chat room, or virtual forum) is used. 26
 2. Quality Function Deployment

Quality function deployment (QFD) is a quality management

technique that translates the needs of the customer into
technical requirements for software.

QFD “concentrates on maximizing customer satisfaction from

the software engineering process”.

QFD identifies three types of requirements

1. Normal requirements
2. Expected requirements
3. Exciting requirements

30
 Quality Function Deployment cont..
1. Normal requirements :
▪ The objectives and goals that are stated for a product or system during
meetings with the customer.

▪ If these requirements are present, the customer is satisfied.

▪ Examples of normal requirements might be requested types of graphical

displays, specific system functions, and defined levels of performance.

2. Expected requirements :
▪ These requirements are understood to the product or system and may be so
fundamental that the customer does not openly state them.

▪ Their absence will be a cause for significant dissatisfaction.

▪ Examples of expected requirements are: ease of human/machine interaction,

overall operational correctness and reliability, and ease of software
installation.
31
 Quality Function Deployment cont..

3. Exciting requirements :

-These features go beyond the customer’s expectations and prove to be

very satisfying when present.

-For example, software for a new mobile phone comes with standard
features, but is coupled with a set of unexpected capabilities (e.g.,
multi touch screen, visual voice mail) that delight every user of the
product.

32
 3. Usage Scenarios

▪As requirements are gathered, an overall vision of system functions and

features begins to materialize.
▪However, it is difficult to move into more technical software
engineering activities until you understand how these functions and
features will be used by different classes of end users.
▪To accomplish this, developers and users can create a set of scenarios
that identify a thread of usage for the system to be constructed. The
scenarios, often called use cases, provide a description of how the
system will be used.

33
 4. Elicitation Work Products
The work products produced as a consequence of requirements elicitation will vary
depending on the size of the system or product to be built. For most systems, the
work products include :
• A statement of need and feasibility.
• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who participated
in requirements elicitation.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function)
• A set of usage scenarios
Each of these work products is reviewed by all people who have participated in
requirements elicitation.

34
 Developing Use Cases

“ A use case describes the system’s behavior under various

conditions as the system responds to a request from one of its
stakeholders . . .”
In essence, a use case tells a stylized story about how an end user
(playing one of a number of possible roles) interacts with the
system under a specific set of circumstances.
The story may be narrative text, an outline of tasks or interactions,
a template-based description, or a diagrammatic representation.
Regardless of its form, a use case depicts the software or system
from the end user’s point of view.
35
Use Case Diagram Notations
UML notations provide a visual language that enables software developers, designers, and other
stakeholders to communicate and document system designs, architectures, and behaviors in a
consistent and understandable manner.

Actors
Actors are external entities that interact with the system. These can include users, other systems, or
hardware devices.

Use Cases
Use cases are like scenes in the play. They represent specific things your system can do. In the online
shopping system, examples of use cases could be “Place Order,” “Track Delivery,” or “Update
Product Information”. Use cases are represented by ovals.

System Boundary
The system boundary is a visual representation of the scope or limits of the system you are modeling.
It defines what is inside the system and what is outside.
 Example : Safe Home

We define four actors: homeowner (a user),

setup manager (likely the same person as homeowner, but playing a
different role),
sensors (devices attached to the system), and the monitoring and
response subsystem (the central station that monitors the SafeHome
home security function).
38
The homeowner actor interacts with the home
security function in a number of different ways
using either the alarm control panel or a PC:
•Enters a password to allow all other interactions.
•Inquires about the status of a security zone.
•Inquires about the status of a sensor.
•Presses the panic button in an emergency.
•Activates/deactivates the security system.
39
▪The basic use case presents a high-level story that describes the interaction
between the actor and the system.

▪The following template for detailed descriptions of use cases:

Use case: InitiateMonitoring

Primary actor: Homeowner

Goal in context : To set the system to monitor sensors when the home owner leaves the
house or remains inside.

System has been programmed for a password and to recognize various

Preconditions:
sensors.
The homeowner decides to “set” the system, i.e., to turn on the alarm
Trigger:
functions.

1. Homeowner: observes control panel

2. Homeowner: enters password
Scenario: 3. Homeowner: selects “stay” or “away”
4. Homeowner: observes read alarm light to indicate that SafeHome has been
armed 35
Exceptions:

2.1 Control panel is not ready: homeowner checks all sensors to

determine which are open; closes them.
Password is incorrect (control panel beeps once): homeowner re
enters correct password.
Password not recognized: monitoring and response subsystem must
be contacted to reprogram password.
Stay is selected: control panel beeps twice and a stay light is lit;
perimeter sensors are activated.
Away is selected: control panel beeps three times and an away light
is lit; all sensors are activated.
36
 Building the Requirements Model
Introduction:
The intent of the analysis model is to provide a description of the required informational,
functional, and behavioral domains for a computer-based system.
➢Elements of the Requirements Model :
•There are many different ways to look at the requirements for a computer-
based system. Some software people argue that it’s best to select one mode of
representation (e.g. the use case)
1.Scenario-based elements.
2.Class-based elements
3.Behavioral elements
4.Flow-oriented elements

45
 Negotiating Requirements

• In reality, you may have to enter into a negotiation with one or more
stakeholders.
• In most cases, stakeholders are asked to balance functionality, performance,
and other product or system characteristics against cost and time-to-market.
• The intent of this negotiation is to develop a project plan that meets
stakeholder needs while at the same time reflecting the real-world constraints
(e.g., time, people, budget) that have been placed on the software team.
• The best negotiations strive for a “win-win” result. That is, stakeholders win
by getting the system or product that satisfies the majority of their needs
and you (as a member of the software team) win by working to realistic and
achievable budgets and deadlines.
58
 Validating Requirements

Introduction:
As each element of the requirements model is created, it is examined for
inconsistency, omissions, and ambiguity.
The requirements represented by the model are prioritized by the
stakeholders and grouped within requirements packages that will be
implemented as software increments.

A review of the requirements model addresses the following questions:

•Is each requirement consistent with the overall objectives for the
system/product?

•Have all requirements been specified at the proper level of abstraction?

•Is the requirement really necessary or does it represent an add-on feature

that may not be essential to the objective of the system?
60
• Is each requirement bounded and unambiguous?

• Does each requirement have attribution? That is, is a source (generally,

a specific individual) noted for each requirement?

• Do any requirements conflict with other requirements?

• Is each requirement achievable in the technical environment that will

house the system or product?

• Is each requirement testable, once implemented?

• Does the requirements model properly reflect the information,

• function, and behavior of the system to be built?

61
Thank you