Scribd
Upload
3 views

Lecture-4-Requirements Development Management (1)

The document outlines the key components of Software Requirements Engineering, focusing on the processes of requirements development and management. It covers subdisciplines such as requirements elicitation, analysis, specification, validation, and management, emphasizing the importance of clear communication and stakeholder involvement. Additionally, it identifies common reasons for poor requirements, including insufficient user involvement and ambiguous requirements.

Uploaded by

hamdasiddiqui123
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
3 views

Lecture-4-Requirements Development Management (1)

The document outlines the key components of Software Requirements Engineering, focusing on the processes of requirements development and management. It covers subdisciplines such as requirements elicitation, analysis, specification, validation, and management, emphasizing the importance of clear communication and stakeholder involvement. Additionally, it identifies common reasons for poor requirements, including insufficient user involvement and ambiguous requirements.

Uploaded by

hamdasiddiqui123
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 13

Software

Requirements
Engineering

CSS-2122 (3-0)
BS (Software Engineering)
Lecture-4

Lecture-4
Previous Lecture Outline

• Software Requirements & System Engineering


• System Requirements
• Role of System Requirements
• Types of System Requirements
Case study

• XYZ Retail, a large retail chain, plans to expand its business


by launching an e-commerce platform to complement its
physical stores. The platform will allow customers to browse
products, make purchases online, and manage their orders.
The project involves gathering both system and software
requirements to ensure the platform meets business
objectives and provides a seamless user experience.
• Gather requirement as Requirement Engineer and Developer
Lecture Outline

• Requirements Development & Management


• Subdisciplines of software requirements engineering
• Requirements Elicitation, Requirements Analysis
• Requirements Specification
• Requirements Validation
• Requirements management
• The boundary between requirements development and requirements management
• Reasons for bad requirements
Requirements Development & Management
 Confusion about requirements terminology extends even
to what to call the whole discipline.

 Some authors call the entire domain requirements


engineering (our preference).

 Others refer to it all as requirements management.

 Still others refer to these activities as a subset of the broad


domain of business analysis.

 It is useful to split requirements engineering into


requirements development and requirements
management
Subdisciplines of software requirements engineering

 We subdivide requirements development into elicitation, analysis,


specification, and validation
 These subdisciplines encompass all the activities involved with
exploring, evaluating, documenting, and confirming the requirements for
a product.
Requirements Elicitation
 Elicitation encompasses all of the activities involved with
discovering requirements, such as interviews, workshops,
document analysis, prototyping, and others. The key actions
are:

 Identifying the product’s expected user classes and


other stakeholders.

 Understanding user tasks and goals and the business


objectives with which those tasks align.

 Learning about the environment in which the new


product will be used.

 Working with individuals who represent each user class to


Requirements Analysis
Analyzing requirements involves reaching a richer and more precise
understanding of each requirement and representing sets of
requirements in multiple ways.
Following are the principal activities:
 Analyzing the information received from users to distinguish their task
goals from functional requirements, quality expectations, business rules,
suggested solutions, and other information
 Decomposing high-level requirements into an appropriate level of
detail
 Deriving functional requirements from other requirements information
 Understanding the relative importance of quality attributes
 Allocating requirements to software components defined in the system
architecture
 Negotiating implementation priorities
Requirements Specification

Requirements specification involves representing and


storing the collected requirements knowledge in a persistent
and well-organized fashion.

The principal activity is:

 Translating the collected user needs into written


requirements

 Constructing diagrams suitable for comprehension, review,


and use by their intended audiences.
Requirements Validation
Requirements validation confirms that you have the correct
set of requirements information that will enable developers
to build a solution that satisfies the business objectives.

The central activities are:

 Reviewing the documented requirements to correct any


problems before the development group accepts them.

 Developing acceptance tests and criteria to confirm that


a product based on the requirements would meet customer
needs and achieve the business objectives.
Requirements management
Requirements management activities include the
following:
 Defining the requirements baseline, a snapshot in time that
represents an agreed-upon, reviewed, and approved set of functional
and nonfunctional requirements, often for a specific product release or
development iteration
 Evaluating the impact of proposed requirements changes and
incorporating approved changes into the project in a controlled way
 Keeping project plans current with the requirements as they
evolve
 Negotiating new commitments based on the estimated impact of
requirements changes
 Defining the relationships and dependencies that exist between
requirements
The boundary between requirements development and requirements
management
Reasons for bad requirements
 Insufficient user involvement

 Inaccurate planning

 Creeping user requirements

 Ambiguous requirements

 Gold plating

 Overlooked stakeholders

 Inexperienced software engineer

You might also like