Requirements

Engineering
The Problems with our
Requirements Practices

• We have trouble understanding the requirements that we

do acquire from the customer.
• We often record requirements in a disorganized manner.
• We spend far too little time verifying what we do record.
• We allow change to control us, rather than establishing
mechanisms to control change.
• Most importantly, we fail to establish a solid foundation
for the system or software that the user wants built.

2
Software Requirements

• It is the description of features and functionalities of the target

system.
• It is the description of what the system should do.
• Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering design
process.
• It is a four step process, which includes -
• 1. Feasibility Study
• 2. Requirement Gathering/Elicitation
• 3. Software Requirement Specification
• 4. Software Requirement Validation
Tool support for Requirements
Engineering
• Observation reports (user observation)
• Questionnaires (interviews, surveys and polls),
• Use cases
• User stories
• Requirement workshops
• Mind mapping
• Role-playing
• Prototyping
Impact of Wrong Requirements

• When requirements are wrong, systems are late,

unreliable and don’t meet customers needs.

• This results in enormous loss of time, revenue, market

share, and trust of customers.

6
Functional and non-functional
requirements

• Functional requirements
• Statements of services the system should provide, how the system should
react to particular inputs and how the system should behave in particular
situations.
• May state what the system should not do.

• Non-functional requirements
• Most non-functional requirements relate to the system
as a whole. They include constraints on timing and
performance, reliability, security, maintainability,
accuracy, the development process, standards, etc.

7
 A Solution: Requirements
Engineering

• Begins during the communication activity and continues into the modeling
activity
• Builds a bridge from the system requirements into software design and
construction
• Allows the requirements engineer:
• to examine the context of the software work to be performed
• the specific needs that design and construction must address
• the priorities that guide the order in which work is to be completed
• the information, function, and behavior that will have a profound impact on the resultant design

8
Requirements Engineering Tasks
• Seven distinct tasks are :
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 strive to define what the customer wants
• All serve to establish a solid foundation for the design and construction of
the software
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

10
 Inception Task
During inception, the requirements engineer asks a set of questions to establish…
• A basic understanding of the nature of problem and scope
• 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
• Break the ice and initiate the communication
The First Set of Questions

These questions focus on the customer, other

stakeholders, the overall goals, and the benefits

• Who is behind the request for this work?

• Who will use the solution?
• What will take the economic benefit of a successful
solution?
• Is there another source for the solution that you
need?

12
The Next Set of Questions

These questions enable the requirements engineer to gain

a better understanding of the problem and allow the
customer to voice his or her perceptions about a solution

• How would you characterize "good" output that would be generated

by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which
the solution will be used?
• Will special performance issues or constraints affect the way the
solution is approached?
13
The Final Set of Questions

These questions focus on the effectiveness of the

communication activity itself

• Are you the right person to answer these questions? Are

your answers "official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
14
 Requirements Elicitation

Requirements elicitation activity is performed by

• Determines the system requirements through
consultation with stakeholders, from system
documents, domain knowledge, and market
studies

• Requirements acquisition or requirements

discovery
• Elicitation collects reqs…after this activity ended the developer has
informal statement of reqs..
15
Elicitation Task

• Eliciting requirements is difficult because of :

• Problems of scope in identifying the boundaries of the
system or specifying too much technical detail rather than
overall system objectives
• 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).
• Problems of volatility because the requirements change
over time.
• Elicitation may be accomplished through two activities
• Collaborative requirements gathering
• Quality function deployment
16
Elicitation Work Products

The work products will vary depending on

the system, but should include one or more
of the following items
• 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 (organized by function) and the
domain constraints that apply to each.
• A set of preliminary usage scenarios (in the form of use
cases) that provide insight into the use of the system or
product under different operating conditions
• Any prototypes developed to better define requirements

19
 Elaboration Task

• During elaboration, the software engineer takes the information

obtained during inception and elicitation and begins to expand and
refine it( try to understand it in more depth)
• This task tries to develop a Refined Requirement Model
• Elaboration focuses on developing a refined technical model of software
functions, features, and constraints
• It is an analysis modeling task
• Use cases are developed (to describe how the end user is going to
interact with the system
• Domain classes are identified along with their attributes and
relationships
• State machine diagrams are used to capture the life of an object
• The end result is an analysis model that defines the functional, 20
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 22

satisfaction.
Specification Task (The process of writing down
the user and system requirements in a
requirements document)

• A specification is the final work product produced

by the requirements engineer. It is also known as
SRS document.

• It serves as the foundation for subsequent

software engineering activities.

• It describes the function and performance of a

computer-based system and the constraints that
will govern its development.

• It formalizes the informational, functional, and

behavioral requirements of the proposed software
in both a graphical and textual format.
23
Software Requirements
Specification (SRS)
• SRS is a description of a software system to be developed.
• • It lays out functional and non-functional requirements of the
software to be developed.
• • It may include a set of use cases that describe user interactions that
the software must provide to the user for perfect interaction.
Software Requirements
Specification (SRS)
• 1. Introduction
• 1.1 Purpose
• 1.2 Intended Audience
• 1.3 Scope
• 1.4 Definitions
• 1.5 References
• Overall Description
• 2.1 User Interfaces
• 2.2 System Interfaces
• 2.3 Constraints, assumptions and dependencies
• 2.4 User Characteristics
Software Requirements
Specification (SRS)
• System Features and Requirements
• 3.1 Functional Requirements
• 3.2 Use Cases
• 3.3 External Interface Requirements
• 3.4 Logical database requirement
• 3.5 Nonfunctional Requirements
• 4. Deliver for Approval
SRS Template-1 ….IEEE-830 standard
• 1. Introduction
• 1.1 Purpose
• 1.2 Document Conventions
• 1.3 Intended Audience and Reading Suggestions
• 1.4 Product Scope
• 1.5 References
• 2. Overall description
• 2.1 Product Perspective
• 2.2 Product Functions
• 2.3 User Classes and Characteristics
• 2.4 Operating Environment
• 2.5 Design and Implementation Constraints
• 2.6 Assumptions and dependencies
• 3. External Interface Requirements
• 3.1 User interfaces
• 3.2 Hardware interfaces
• 3.3 Software interfaces
27
• 3.4 Communications interfaces
• 4. System Features
• 4.x System Feature X
• 4.x.1 Description and Priority
• 4.x.2 Stimulus/Response Sequences & Information flows
• 4.x.3 Functional Requirements
• 5. Other Nonfunctional Requirements
• 5.1 Performance requirements
• 5.2 Safety requirements
• 5.3 Security Requirements
• 5.4 Software Quality Attributes
• 5.5 Business Rules
• 5.6 User Documentation
• 6. Other Requirements
• Appendix A: Glossary
• Appendix B: Analysis Models
• Appendix C: To-Be-Determined List
28
Validation Task

• Certifies that the requirements document is

an acceptable description of the system to be
implemented.

• The formal technical review serves as the

primary requirements validation mechanism.

• Checks a requirements document for:

• Completeness and consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements
29
Requirements Management Task

• Definition: “Requirements management is the

process of documenting, analyzing, tracing,
prioritizing and agreeing on requirements and then
controlling change and communicating to relevant
stakeholders.
• or
• The process of managing changes to the
requirements for a system.

• every requirement should have a unique

identification.
30