WEEK 10

Requirements Engineering
1. Introduction
• Unit 3 Learning Outcome
Students evaluate the quality of information systems in an organization,
including its effects on all stakeholders inside and outside the organization.

• Week 10 Learning Objectives

· Understand importance of requirements and assign priorities to them.

• Prior Knowledge
Information System Design and Implementation.

2. Theory
• Requirements Engineering
This section contains excerpts from Pressman and Maxim (2015).
Understanding the requirements of a problem is among the most difficult
tasks that face a software engineer. When you first think about it,
developing a clear understanding of requirements doesn’t seem that hard.
After all, doesn’t the customer know what is required? Shouldn’t the end
users have a good understanding of the features and functions that will
provide benefit? Surprisingly, in many instances the answer to these
questions is “no.” And even if customers and end users are explicit in their
needs, those needs will change throughout the project.

Designing and building an elegant computer program that solves the wrong
problem serves no one’s needs. That’s why it’s important to understand
what the customer wants before you begin to design and build a computer-
based system. Requirements engineering establishes a solid base for design
and construction. Without it, the resulting software has a high probability of
not meeting customer’s needs.

1
Requirements engineering begins with inception (a task that defines the
scope and nature of the problem to be solved). It moves onward to
elicitation (a task that helps stakeholders define what is required), and then
elaboration (where basic requirements are re- fined and modified). As
stakeholders define the problem, negotiation occurs (what are the priorities,
what is essential, when is it required?) Finally, the problem is specified in
some manner and then reviewed or validated to ensure that your
understanding of the problem and the stakeholders’ understanding of the
problem coincide.

Requirements engineering encompasses seven distinct tasks: inception,

elicitation, elaboration, negotiation, specification, validation, and
management. It is important to note that some of these tasks occur in
parallel and all are adapted to the needs of the project.

Inception
In general, most projects begin when a business need is identified, or a
potential new market or service is discovered. Stakeholders from the
business community (e.g., business managers, marketing people, product
managers) define a business case for the idea, try to identify the breadth and
depth of the market, do a rough feasibility analysis, and identify a working
description of the project’s scope. All of this information is subject to
change, but it is sufficient to precipitate discussions with the software
engineering organization.

At project inception, 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.

Elicitation
It certainly seems simple enough—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,

2
and finally, how the system or product is to be used on a day-to-day basis.
But it isn’t simple— it’s very hard.

An important part of elicitation is to establish business goals. Your job is to

engage stakeholders and to encourage them to share their goals honestly.
Once the goals have been captured, a prioritization mechanism should be
established, and a design rationale for a potential architecture (that meets
stakeholder goals) can be created.

Elaboration
The information obtained from the customer during inception and elicitation
is expanded and refined during elaboration. This task focuses on developing
a refined requirements model that identifies various aspects of software
function, behavior, and information.

Elaboration is driven by the creation and refinement of user scenarios that

describe how the end user (and other actors) will interact with the system.
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.

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.

Customers, users, and other stakeholders are asked to rank requirements and
then discuss conflicts in priority. Using an iterative approach that prioritizes
requirements, assesses their cost and risk, and addresses internal conflicts,
requirements are eliminated, combined, and/or modified so that each party
achieves some measure of satisfaction.

3
Specification
In the context of computer-based systems (and software), the term
specification means different things to different people. 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.

Some suggest that a “standard template” should be developed and used for a
specification, arguing that this leads to requirements that are presented in a
consistent and therefore more understandable manner. However, it is
sometimes necessary to remain flexible when a specification is to be
developed. For large systems, a written document, combining natural
language descriptions and graphical models may be the best approach.
However, usage scenarios may be all that are required for smaller products
or systems that reside within well-understood technical environments.

Validation
The work products produced as a consequence of requirements engineering
are assessed for quality during a validation step. Requirements validation
examines the specification 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.

Glinz writes that quality requirements need to be represented in a manner

that delivers optimal value. This means assessing the risk of delivering a
system that fails to meet the stakeholders’ quality requirements and
attempting to mitigate this risk at minimum cost. The more critical the
quality requirement is, the greater the need to state it in quantifiable terms.
Less-critical quality requirements can be stated in general terms. In some
cases, a general quality requirement can be verified using a qualitative
technique (e.g., user survey or check list). In other situations, quality
requirements can be verified using a combination of qualitative and
quantitative assessment.

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

• Establishing the Groundwork

This section contains excerpts from Pressman and Maxim (2015).
In an ideal setting, stakeholders and software engineers work together on the
same team. In such cases, requirements engineering is simply a matter of
conducting meaningful conversations with colleagues who are well-known
members of the team. But reality is often quite different.

Customer(s) or end users may be located in a different city or country, may

have only a vague idea of what is required, may have conflicting opinions
about the system to be built, may have limited technical knowledge, and may
have limited time to interact with the requirements engineer. None of these
things are desirable, but all are fairly common, and you are often forced to
work within the constraints imposed by this situation.

Identifying Stakeholders
Sommerville and Sawyer define a stakeholder as “anyone who benefits in a
direct or indirect way from the system which is being developed.” We have
already identified the usual suspects: 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.

At inception, you should create a list of people who will contribute input as
requirements are elicited. The initial list will grow as stakeholders are

5
contacted because every stakeholder will be asked: “Whom else do you think
I should talk to?”

Recognizing Multiple Viewpoints

Because many different stakeholders exist, the requirements of the system
will be explored from many different points of view. For example, the
marketing group is interested in functions and features that will excite the
potential market, making the new system easy to sell. Business managers are
interested in a feature set that can be built within budget and that will be
ready to meet defined market windows. End users may want features that are
familiar to them and that are easy to learn and use. Software engineers may
be concerned with functions that are invisible to nontechnical stakeholders
but that enable an infrastructure that supports more marketable functions and
features. Support engineers may focus on the maintainability of the software.

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.

There are several things that can make it hard to elicit requirements for
software that satisfies its users: project goals are unclear, stakeholders’
priorities differ, people have unspoken assumptions, stakeholders interpret
meanings differently, and requirements are stated in a way that makes them
difficult to verify. The goal of effective requirements engineering is to
eliminate or at least reduce these problems.

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). It is, of course, the latter
category that presents a challenge.

6
Collaboration does not necessarily mean that requirements are defined by
committee. 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.

Asking the First Questions

Questions asked at the inception of the project should be “context free”. The
first set of context-free questions focuses on the customer and other
stakeholders, the overall project goals and benefits. For example, you might
ask:
• 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?
These questions help to identify all stakeholders who interest in the software
will have to be built. In addition, the questions identify the measurable
benefit of a successful implementation and possible alternatives to custom
software development.
The next set of questions enables you to gain a better understanding of the
problem and allows 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?
The final set of questions focuses on the effectiveness of the communication
activity itself. Gause and Weinberg call these “meta-questions” and propose
the following (abbreviated) list:

7
• 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?
These questions (and others) will help to “break the ice” and initiate the
communication that is essential to successful elicitation. But a question-and-
answer meeting format is not an approach that has been overwhelmingly
successful. In fact, the Q&A session should be used for the first encounter
only and then replaced by a requirements elicitation format that combines
elements of problem solving, negotiation, and specification.

Nonfunctional Requirements
A nonfunctional requirement (NFR) can be described as a quality attribute, a
performance attribute, a security attribute, or a general constraint on a
system. These are often not easy for stakeholders to articulate. Chung
suggests that there is a lopsided emphasis on functionality of the software,
yet the software may not be useful or usable without the necessary non-
functional characteristics. Nonfunctional requirements are often listed
separately in a software requirements specification.

Traceability
Traceability is a software engineering term that refers to documented links
between software engineering work products (e.g., requirements and test
cases). A traceability matrix allows a requirements engineer to represent the
relationship between requirements and other software engineering work
products. Rows of the traceability matrix are labeled using requirement
names and columns can be labeled with the name of a software engineering
work product (e.g., a design element or a test case). A matrix cell is marked
to indicate the presence of a link between the two.

The traceability matrices can support a variety of engineering development

activities. They can provide continuity for developers as a project moves

8
 from one project phase to another, regardless of the process model being
used. Traceability matrices often can be used to ensure the engineering work
products have taken all requirements into account.

As the number of requirements and the number of work products grows, it

becomes increasingly difficult to keep the traceability matrix up to date.
Nonetheless, it is important to create some means for tracking the impact and
evolution of the product requirements

3. References
Pressman, R. S., & Maxim B. R. (2015). Software Engineering: A Practitioner’s
Approach (8th ed.). New York, United States of America: McGraw-Hill
Education.

4. Extra Material
• Business Analyst Training - Requirements Elicitation Techniques
https://youtu.be/kCJFBmAAvV4
https://youtu.be/fGyMt6tWCPs