Requirement engineering involves several key tasks: inception to establish project scope, elicitation to determine user needs, elaboration to refine requirements, negotiation to resolve conflicts, validation to verify requirements, and management of changing requirements. Effective elicitation uses techniques like interviews, scenarios, and ethnography to understand stakeholders and identify general, expected, and unexpected requirements while addressing problems of scope, understanding, volatility, and communication barriers. Requirements are further developed through analysis, modeling, prioritization, and specification documentation. Regular reviews validate that requirements define the desired system.

1. Chapter 7
Requirement Engineering
1
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Software Engineering 9/e
By Ian Sommerville
Introduction to Software Engineering

2. Content to complete
Requirement Engineering Task
• Inception
• Elicitation
• Elaboration
• Negotiation
• Validation
• Requirement Management
2

3. Inception
How does a software project get started?
•Is there another source for the solution?
•Stakeholders from the business community define a
business case for the idea, try to identify the breadth and
depth of the market, do analysis and identify description of
the project’s scope.
•You establish a basic understanding of the problem the
people who want a solution, nature of solution,
collaboration b/w the other stakeholders and S/W team
3

4. Requirement Elicitation
•Sometimes called requirements elicitation or requirements
discovery ,requirement capture and requirement acquisition.
•Involves technical staff working with customers to find out
about the application domain, the services that the system
should provide and the system’s operational constraints.
•May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These are
called stakeholders.

5. Problems of Elicitation
Problem of Scope:
–The boundary of the system is ill-defined.
–Customers / users specify unnecessary technical detail that may confuse
rather than clarify objectives.
Understanding:
-Stakeholders don’t know what they really want.
-Stakeholders express requirements in their own terms.
-Different stakeholders may have conflicting requirements.
-Organizational and political factors may influence the system requirements.
-Customers are not completely sure of what is needed?.
-Customers have a poor understanding of the capabilities and limitations of
the computing environment

6. Problems of Elicitation
Volatility:
The requirements change during the analysis process. New
stakeholders may emerge and the business environment
change. requirements change over time

7. Elicitation Techniques
Various elicitation techniques are used to identify the
problem, determine its solution, and identify different
approaches for the solution
–Interviews
–Scenarios
–Ethnography
–Quality Function Deployment (QFD)
•General requirements
•Expected requirements
•Unexpected requirements

8. Interviewing
•In formal or informal interviewing, the RE team puts
questions to stakeholders about the system that they use and
the system to be developed.
•There are two types of interview
–Closed interviews where a pre-defined set of questions are
answered.
–Open interviews where there is no pre-defined agenda and
a range of issues are explored with stakeholders.

9. 9
Effective interviewers
•Interviewers should be open-minded, willing to listen to
stakeholders and should not have pre-conceived ideas about the
requirements.
•They should prompt the interviewee with a question or a
proposal and should not simply expect them to respond to a
question such as ‘what do you want’.

10. Scenarios
•Scenarios are real-life examples of how a system can be
used.
•They should include
–A description of the starting situation;
–A description of the normal flow of events;
–A description of what can go wrong;
–Information about other concurrent activities;
–A description of the state when the scenario finishes.

11. Ethnography
•A social scientists spends a considerable time observing
and analyzing how people actually work.
•People do not have to explain or articulate their work.
•Social and organizational factors of importance may be
observed.
•Ethnographic studies have shown that work is usually
richer and more complex than suggested by simple system
models.

12. Elaboration
•Is to refine the information obtained from the
customer during inception and elicitation.
•Is an ANALYSIS MODELING actions
–Focus on developing a refined technical model of
software functions, features, and constraints,
behavior and information.
–Determine how end user will interact the system.

13. Negotiation
•Understand stakeholders
•Resolve Conflicts so that each party achieves some
measures of satisfaction.
•Resolve Risks
•categorizes and organizes requirements
•explores each requirement in relation to others
•examines requirements for consistency
, omissions, and ambiguity
•ranks requirements based on the needs of the users

14. Specification
•The term specification means different things to different people
•A specification can be a Written document
•Graphical model
•Formal mathematical model
•Collection of usage scenarios
•Prototype
•Follow Standard Template
•Final work product
• •Foundation for subsequent SE activities

15. 15
Requirements validation
•Concerned with demonstrating that the requirements define
the system that the customer really wants.
•Requirements error costs are high so validation is very
important
–Fixing a requirements error after delivery may cost up to
100 times the cost of fixing an implementation error.

16. Requirements checking
•Validity. Does the system provide the functions which best
support the customer’s needs?
•Consistency. Are there any requirements conflicts?
•Completeness. Are all functions required by the customer
included?
•Realism. Can the requirements be implemented given
available budget and technology
•Verifiability. Can the requirements be checked?
.

17. 17
Requirements reviews
Regular reviews should be held while the
requirements definition is being formulated.
Both client and contractor staff should be
involved in reviews.
Reviews may be formal (with completed
documents) or informal. Good communications
between developers, customers and users can
resolve problems at an early stage.

18. 18
Review checks
Verifiability: Is the requirement realistically testable?
Comprehensibility: Is the requirement properly
understood?
Traceability: Is the origin of the requirement clearly
stated?
Adaptability: Can the requirement be changed without a
large impact on other requirements?

19. Requirements management
Requirements management is the process of managing changing
requirements during the requirements engineering process and
system development.
Requirement management is a set of activities that help the
project team to identify, control and track requirements and
changes to requirements at any time as the project proceed.
Requirements are unavoidably incomplete and inconsistent
–New requirements emerge during the process as business needs
change and a better understanding of the system is developed;
–Different viewpoints have different requirements and these are
often contradictory.