The document discusses the requirements engineering process, which includes establishing the services required of a system and the constraints on its operation. It involves tasks like requirements elicitation, analysis, specification, validation and management. These help understand what users want from the software and its business impact. The document outlines the various stages of requirements engineering like feasibility studies, elicitation, analysis, specification and validation. It also describes different types of requirements like functional, non-functional and their characteristics.

1. Unit III
Requirements
Engineering Process
1
V.Sutha Jebakumari, AP/CSE
Kamaraj College of Engineering and
Technology, Virudhunagar.
OCS551-Software engineering

2. 2
• Functional and non-functional requirements
• The software requirements document
• Requirements specification
• Requirements engineering processes
• Requirements elicitation and analysis
• Requirements validation
• Requirements management
Topics covered

3. 3
• The process of establishing what services are required and the
constraints on the system’s operation and development
• Requirements engineering help software engineers to better understand
the problem they will work to solve.
• It encompasses the set of tasks that lead to an understanding of what the
business impact of the software will be, what the customer wants and how
end-users will interact with the software.
Requirement Engineering Process
• Feasibility Study
• Requirements elicitation and analysis
• Requirements Specification
• Requirements Validation
The Requirement Engineering Process

4. 4
It may range from a high-level abstract statement of
a service or of a system constraint to a detailed
mathematical functional specification.
What is a Requirement?

5. 5
User requirements
• Statements in natural language 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’s functions, services and operational constraints.
• Defines what should be implemented so may be part of a contract
between client and contractor.
• Whom do you think these are written for?
• These are higher level than functional and non-functional
requirements.
Types of Requirements

6. 6

7. Notations for Requirements Specification

8. 8
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
Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards, etc.
Often apply to the system as a whole rather than individual features or
services.
Domain requirements
Constraints on the system from the domain of operation
Functional and Non-functional requirements

9. 9
• Describe functionality or system services.
• Depend on the type of software, expected users and the
type of system where the software is used.
• Functional user requirements may be high-level
statements of what the system should do.
• Functional system requirements should describe the
system services in detail.
Functional Requirements

10. 10
These define system properties and constraints
e.g. reliability, response time, maintainability, scalability,
portability, and storage requirements.
Constraints are I/O device capability, system representations, etc.
Non-functional requirements may be more critical than functional
requirements. If these are not met, the system may be useless.
Non-functional Requirements

11. 11
Types of Nonfunctional Requirements

12. 12
Metrics for specifying nonfunctional requirements

13. 13

14. 14
• A feasibility study decides whether or not the
proposed system is worthwhile
• A short focused study that checks
 If the system contributes to organizational objectives
 If the system can be engineered using current
technology and within budget
 If the system can be integrated with other systems
that are used
Feasibility studies

15. 15
• Based on information assessment (what is required),
information collection and report writing
• Questions for people in the organization
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed
system?
Feasibility study implementation

16. 16
• Sometimes called requirements elicitation or
requirements discovery
• 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
Elicitation and analysis

17. 17
• 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
• The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change
Problems of requirements analysis

18. 18
The requirements analysis process

19. 19
Process activities

20. Techniques for Requirements Elicitation
1.Viewpoints
2.Interviewing
3.Scenarios
4.Use cases

21. 21

22. Types of interviews
Formal or informal interviews with system stakeholders are part of
requirements engineering process
1. Closed Interviews- predefined set of questions
2. Open Interviews- No predefined agenda

23. 23

24. 24

25. 25
 Event scenarios may be used to
describe how a system responds
to the occurrence of some
particular event such as ‘start
transaction’

26. 26

27. 27

28. 28

29. 29
Lending use-case

30. 30
Library use-cases

31. 31
Catalogue management

32. 32

33. 33
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?

34. 34

35. 35
• 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

36. 36

37. 37
• Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development
• Requirements are inevitably incomplete and
inconsistent
• New requirements emerge during the process
as business needs change and a better
understanding of the system is developed

38. 38
• The priority of requirements from different
viewpoints changes during the
development process
• The business and technical environment
of the system changes during its
development

39. 39

40. 40
Enduring and volatile requirements

41. 41
Classification of requirements

42. 42
During the requirements engineering process,
we have to plan:
Requirements management planning

43. 43

44. 44

45. 45