1 Chapter 3: Requirements Engineering

 Requirements
 Requirements Engineering Process
 Requirements Management

Software Engineering - Le Vu Hao 8/2/2023

Requirements
2

Software Engineering - Le Vu Hao 8/2/2023

3 Requirements

 What are requirements?

 Functional and non-functional requirements
 Domain requirements
 The software requirements document

Software Engineering - Le Vu Hao 8/2/2023

4 What are requirements?

 The requirements for a system are the descriptions of what the system
should do - the services that it provides and the constraints on its operation.
 These requirements reflect the needs of customers for a system that serves
a certain purpose such as controlling a device, placing an order, or finding
information.
 The process of finding out, analyzing, documenting and checking these
services and constraints is called requirements engineering (RE)

Software Engineering - Le Vu Hao 8/2/2023

5 What are requirements?

 Two levels of requirements:

 User requirements (high-level abstract requirements) are statements, in a natural
language plus diagrams, of what services the system is expected to provide to
system users and the constraints under which it must operate.
 System requirements are more detailed descriptions of the software system’s
functions, services, and operational constraints.

Software Engineering - Le Vu Hao 8/2/2023

6 What are requirements?

Software Engineering - Le Vu Hao 8/2/2023

7 Functional and non-functional
requirements
 Functional requirements These are statements of services the system should
provide, how the system should react to particular inputs, and how the
system should behave in particular situations. In some cases, the functional
requirements may also explicitly state what the system should not do.
 Non-functional requirements These are constraints on the services or
functions offered by the system. They include timing constraints, constraints
on the development process, and constraints imposed by standards. Non-
functional requirements often apply to the system as a whole, rather than
individual system features or services.

Software Engineering - Le Vu Hao 8/2/2023

8 Examples of functional requirements

 Examples of functional requirements for the MHC-PMS system, used to

maintain information about patients receiving treatment for mental health
problems:
1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients who are
expected to attend appointments that day.
3. Each staff member using the system shall be uniquely identified by his or her
eight-digit employee number

Software Engineering - Le Vu Hao 8/2/2023

9 Non-functional requirements

 Not directly concerned with the specific services delivered by the system to
its users
 Relate to emergent system properties such as reliability, response time, and
store occupancy (e.g. constraints on the system implementation such as
the capabilities of I/O devices or the data representations used in
interfaces with other systems)
 Types of non-functional requirements: performance, security, or availability,
usually specify or constrain characteristics of the system as a whole

Software Engineering - Le Vu Hao 8/2/2023

10 Non-functional requirements

 The implementation of non-functional requirements may be diffused

throughout the system because:
1. Non-functional requirements may affect the overall architecture of a system
rather than the individual components. For example, to ensure that
performance requirements are met, you may have to organize the system to
minimize communications between components.
2. A single non-functional requirement, such as a security requirement, may
generate a number of related functional requirements that define new system
services that are required. In addition, it may also generate requirements that
restrict existing requirements.

Software Engineering - Le Vu Hao 8/2/2023

11 Types of non-functional requirements

Software Engineering - Le Vu Hao 8/2/2023

12 Metrics for specifying non-functional
requirements

Software Engineering - Le Vu Hao 8/2/2023

13 Domain requirements

 Domain requirements are derived from the application domain of the

system rather than from the specific needs of system users. They may be
new functional requirements in their own right, constrain existing functional
requirements, or set out how particular computations must be carried out.
 The problem with domain requirements is that software engineers may not
understand the characteristics of the domain in which the system operates.
They often cannot tell whether or not a domain requirement has been
missed out or conflicts with other requirements.

Software Engineering - Le Vu Hao 8/2/2023

14 Domain requirements example

Software Engineering - Le Vu Hao 8/2/2023

15 Domain requirements problems

 Understandability
 Requirements are expressed in the language of the application domain
 This is often not understood by software engineers developing the system (e.g.
consider the previous slide) would they understand the Physics/Engineering
 Implicitness
 Domain specialists understand the area so well that they do not think of making
the domain requirements explicit which leads to problems later if software
developer implements the requirements in the wrong way

Software Engineering - Le Vu Hao 8/2/2023

16 The software requirements document

 The software requirements document (sometimes called the software

requirements specification or SRS) is an official statement of what the
system developers should implement.
 It should include both the user requirements for a system and a detailed
specification of the system requirements.
 If there are a large number of requirements, the detailed system
requirements may be presented in a separate document.

Software Engineering - Le Vu Hao 8/2/2023

17 Users of requirements documents

Software Engineering - Le Vu Hao 8/2/2023

18 A requirements document structure

Software Engineering - Le Vu Hao 8/2/2023

19 A requirements document structure

Software Engineering - Le Vu Hao 8/2/2023

20 Ways to write SRS document

Software Engineering - Le Vu Hao 8/2/2023

Requirements
Engineering
21

Software Engineering - Le Vu Hao 8/2/2023

22 Requirements Engineering

 Understanding the requirements of a problem is among the most difficult

tasks that face a software engineer.
 The broad spectrum of tasks and techniques that lead to an understanding
of requirements is called requirements engineering.
 Requirements engineering provides the appropriate mechanism for
understanding what the customer wants, analyzing need, assessing
feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the
requirements as they are transformed into an operational system. It
encompasses seven distinct tasks: inception, elicitation, elaboration,
negotiation, specification, validation, and management. These actions can
occur in parallel.

Software Engineering - Le Vu Hao 8/2/2023

23 Requirements Engineering

 Inception: At project inception,3 you establish a basic understanding of the

problem, the people who want a solution, the nature of the solution that is
desired, and the effectiveness of preliminary communication and
collaboration between the other stakeholders and the software team.

Software Engineering - Le Vu Hao 8/2/2023

24 Requirements Engineering

 Elicitation: ask the customer, the users, and others what the objectives for
the system or product are, what is to be accomplished, how the system or
product fits into the needs of the business, and finally, how the system or
product is to be used on a day-to-day basis.
 Problems that are encountered in Elicitation:
 Problems of scope. The boundary of the system is ill-defined or the
customers/users specify unnecessary technical detail that may confuse, rather
than clarify, overall system objectives
 Problems of understanding.
 Problems of volatility. The requirements change over time.

Software Engineering - Le Vu Hao 8/2/2023

25 Requirements Engineering

 Elaboration: This task focuses on developing a refined requirements model

that identifies various aspects of software function, behavior, and
information.
 Elaboration is a good thing, but you have to know when to stop. The key is
to describe the problem in a way that establishes a firm base for design. If
you work beyond that point, you’re doing design.

Software Engineering - Le Vu Hao 8/2/2023

26 Requirements Engineering

 Negotiation: It isn’t unusual for customers and users to ask for more than
can be achieved, given limited business resources. It’s also relatively
common for different customers or users to propose conflicting
requirements, arguing that their version is “essential for our special needs.”
 You have to reconcile these conflicts through a process of negotiation.
 There should be no winner and no loser in an effective negotiation. Both
sides win, because a “deal” that both can live with is solidified.

Software Engineering - Le Vu Hao 8/2/2023

27 Requirements Engineering

 Specification: A specification can be a written document, a set of

graphical models, a formal mathematical model, a collection of usage
scenarios, a prototype, or any combination of these.
 Validation: Requirements validation examines the specification5 to ensure
that all software requirements have been stated unambiguously; that
inconsistencies, omissions, and errors have been detected and corrected;
and that the work products conform to the standards established for the
process, the project, and the product.

Software Engineering - Le Vu Hao 8/2/2023

28 Requirements Engineering

 Requirements management: Requirements for computer-based systems

change, and the desire to change requirements persists throughout the life
of the system. Requirements management is a set of activities that help the
project team identify, control, and track requirements and changes to
requirements at any time as the project proceeds.

Software Engineering - Le Vu Hao 8/2/2023

29 Establishing the groundwork -
Inception
 Identifying Stakeholders:
 Anyone who benefits in a direct or indirect way from the system which is being
developed: 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 when
the system is successfully developed, and is open to different risks if the development
effort should fail.
 Ask questions:
 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?

Software Engineering - Le Vu Hao 8/2/2023

30 Establishing the groundwork -
Inception
 Recognizing Multiple Viewpoints:
 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.
 Ask questions:
 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?

Software Engineering - Le Vu Hao 8/2/2023

31 Establishing the groundwork -
Inception
 Working toward Collaboration:
 The job of a requirements engineer is to identify areas of commonality (i.e.,
requirements on which all stakeholders agree) and areas of conflict or
inconsistency (i.e., requirements that are desired by one stakeholder but conflict
with the needs of another stakeholder)
 In many cases, stakeholders collaborate by providing their view of requirements,
but a strong “project champion”(e.g., a business manager or a senior
technologist) may make the final decision about which requirements make the
cut.

Software Engineering - Le Vu Hao 8/2/2023

32 Establishing the groundwork -
Inception
 Questions focuses on the effectiveness of the communication:
 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?

Software Engineering - Le Vu Hao 8/2/2023

33 Eliciting requirements

 Collaborative Requirements Gathering:

 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.

Software Engineering - Le Vu Hao 8/2/2023

34 Eliciting requirements

 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 identifies three types of requirements:
 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.
 Expected requirements. These requirements are implicit to the product or system
and may be so fundamental that the customer does not explicitly state them.
Their absence will be a cause for significant dissatisfaction.
 Exciting requirements. These features go beyond the customer’s expectations
and prove to be very satisfying when present.

Software Engineering - Le Vu Hao 8/2/2023

35 Eliciting requirements

 Usage Scenarios:
 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.
 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.

Software Engineering - Le Vu Hao 8/2/2023

36 Eliciting requirements

 Elicitation Work Products:

 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) and the domain
constraints that apply to each.
 A set of usage scenarios that provide insight into the use of the system or product
under different operating conditions.
 Any prototypes developed to better define requirements.

Software Engineering - Le Vu Hao 8/2/2023

37 Developing Use Cases

 A use case depicts the software or system from the end user’s point of view.
 Steps:
 Define the set of “actors”: the different people (or devices) that use the system or
product within the context of the function and behavior that is to be described.
 Develop use cases: answer questions

Software Engineering - Le Vu Hao 8/2/2023

38 Developing Use Cases

 Questions that should be answered by a use case:

 Who is the primary actor, the secondary actor(s)?
 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What exceptions might be considered as the story is described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or change?
 Will the actor have to inform the system about changes in the external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?

Software Engineering - Le Vu Hao 8/2/2023

39 Developing Use Cases

Software Engineering - Le Vu Hao 8/2/2023

40 Developing Use Cases

Software Engineering - Le Vu Hao 8/2/2023

41 Developing Use Cases

Software Engineering - Le Vu Hao 8/2/2023

42 Developing Use Cases

Software Engineering - Le Vu Hao 8/2/2023

43 Developing Use Cases

UML use case diagram for SafeHome

home security function

Software Engineering - Le Vu Hao 8/2/2023

 UML activity diagrams for
44 eliciting requirements

Software Engineering - Le Vu Hao 8/2/2023

45 Building the requirements model

 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: Different modes of representation
force you to consider requirements from different viewpoints—an approach
that has a higher probability of uncovering omissions, inconsistencies, and
ambiguity. A set of generic elements:
 Scenario-based elements
 Class-based elements
 Behavioral elements
 Flow-oriented elements

Software Engineering - Le Vu Hao 8/2/2023

46 Scenario-based elements

 The system is described from the user’s point of view using a scenario-based
approach.
• Functional - processing narratives for software functions
• Use-case - descriptions of the interaction between an “actor” and the system

Software Engineering - Le Vu Hao 8/2/2023

47 Class-based elements

 Each usage scenario implies a set of objects that are manipulated as an

actor interacts with the system.
 These objects are categorized into classes - a collection of things that have
similar attributes and common behaviors.
 Class diagram for Sensor

Software Engineering - Le Vu Hao 8/2/2023

48 Class-based elements

 Each usage scenario implies a set of objects that are manipulated as an

actor interacts with the system.
 These objects are categorized into classes - a collection of things that have
similar attributes and common behaviors.
 Class diagram for Sensor

Software Engineering - Le Vu Hao 8/2/2023

49 Behavioral elements

 The state diagram is one method for representing the behavior of a system
by depicting its states and the events that cause the system to change
state.
 UML state diagram notation

Software Engineering - Le Vu Hao 8/2/2023

50 Flow-oriented elements

Information is transformed as it flows

through a computer-based system.
The system accepts input in a variety
of forms, applies functions to transform
it, and produces output in a variety of
forms
 .

Software Engineering - Le Vu Hao 8/2/2023

51 Analysis Patterns

These analysis patterns [Fow97]

suggest solutions (e.g., a class, a
function, a behavior) within the
application domain that can be
reused when modeling many
applications.

Software Engineering - Le Vu Hao 8/2/2023

52 Negotiating Requirements

 Identify the key stakeholders

 These are the people who will be involved in the negotiation
 Determine each of the stakeholders “win conditions”
 Win conditions are not always obvious
 Negotiate
 Work toward a set of requirements that lead to “win – win”

Software Engineering - Le Vu Hao 8/2/2023

53 Validating Requirements

 Is each requirement consistent with the overall objectives for the

system/product?
 Have all requirements been specified at the proper level of abstraction?
That is, do some requirements provide a level of technical detail that is
inappropriate at this stage?
 Is the requirement really necessary or does it represent an add-on feature
that may not be essential to the objective of the system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?

Software Engineering - Le Vu Hao 8/2/2023

54 Validating Requirements

 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?
 Has the requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system?
 Have requirements patterns been used to simplify the requirements model?
 Have all patterns been properly validated? Are all patterns consistent with
customer requirements?

Software Engineering - Le Vu Hao 8/2/2023

55 A SRS document example

 SRSExample-webapp.doc

Software Engineering - Le Vu Hao 8/2/2023

Requirements
management
56

Software Engineering - Le Vu Hao 8/2/2023

57 Why?

 The business and technical environment of the system always changes

after installation.
 The people who pay for a system and the users of that system are rarely the
same people.
 Large systems usually have a diverse user community, with many users
having different requirements and priorities that may be conflicting or
contradictory

Software Engineering - Le Vu Hao 8/2/2023

58 Requirements management planning

 Planning is an essential first stage in the requirements management

process.
 The planning stage establishes the level of requirements management
detail that is required.
 During the requirements management stage, you have to decide on:
 Requirements identification
 A change management process
 Traceability policies
 Tool support

Software Engineering - Le Vu Hao 8/2/2023

59 Requirements change management

Software Engineering - Le Vu Hao 8/2/2023

60 Requirement Management Tools

Software Engineering - Le Vu Hao 8/2/2023

61

Software Engineering - Le Vu Hao 8/2/2023