REQUIREMENTS ENGINEERING - CBRE3103

Faculty of Information Technology & Multimedia Communication

MAY / 2023
ASSIGNMENT

CBRE3103
REQUIREMENTS ENGINEERING

MATRICULATION NO : 851202126273002
NAME : CHEONG JUN WAH
IDENTITY CARD NO. : 851202126273
TELEPHONE NO. : 0168291486
E-MAIL : tomcheong@oum.edu.my
LEARNING CENTRE : IPT Sandakan Learning Centre
 REQUIREMENTS ENGINEERING - CBRE3103

TABLE OF CONTENTS

Introduction Page 2

Question A Page 2
Question B Page 4
Question C Page 5
Question D Page 6
Question E Page 7
References Page 10

2
 REQUIREMENTS ENGINEERING - CBRE3103

INTRODUCTION

Requirements engineering is the process of understanding what a software system

should do. It involves gathering and documenting the needs of the system's stakeholders, and
then translating those needs into a set of requirements that can be used to develop the system.
Requirements engineering is an essential part of the software development process, as it
ensures that the system meets the needs of its users. Requirements engineering is a complex
and challenging task, but it is essential to the success of any software development project.
By taking the time to understand the requirements, developers can create systems that meet
the needs of their users and deliver value to the business.

Question A)
Requirements elicitation is the process of gathering and understanding the needs of the
stakeholders of a software system. It is an essential part of the software development process,
as it ensures that the system meets the needs of its users. The importance of requirements
elicitation can be summarized in the following points:

 It ensures that the system meets the needs of the users.

 It helps to avoid scope creep and budget overruns.
 It helps to improve the quality of the system.
 It helps to reduce the risk of project failure.

Three common techniques used for requirements elicitation are:

1. Interviews: This is a one-on-one conversation between the requirements engineer and

the stakeholder. It is a good way to gather detailed information about the stakeholder's
needs and expectations.

2. Workshops: This is a group discussion between the requirements engineer and the
stakeholders. It is a good way to get feedback from the stakeholders and to build
consensus on the requirements.

3
 REQUIREMENTS ENGINEERING - CBRE3103
3. Prototyping: This is the creation of a working model of the software system. It is a
good way to demonstrate the requirements to the stakeholders and to get their
feedback.

An example of when to use each technique:

1. Interviews: This technique is best used when you need to gather detailed information
from a single stakeholder. For example, you might use interviews to gather
information from a business analyst about the requirements for a new customer
relationship management system.

2. Workshops: This technique is best used when you need to get feedback from a group
of stakeholders. For example, you might use workshops to gather feedback from a
team of developers about the requirements for a new software application.

3. Prototyping: This technique is best used when you need to demonstrate the
requirements to a group of stakeholders. For example, you might use prototyping to
demonstrate the requirements for a new website to a group of marketing managers.

4
 REQUIREMENTS ENGINEERING - CBRE3103

Question B)

Requirements analysis is the process of understanding the needs of stakeholders and

translating them into a set of requirements that can be used to develop a system. It is a critical
part of the requirements engineering process and is often divided into two main phases:

1. Requirements elicitation: This is the process of gathering information about the needs
of stakeholders. This information can be collected through various methods such as
interviews, surveys and workshops.
2. Requirements Analysis: This is the process of analyzing the information gathered
during requirements elicitation and identifying the specific requirements that need to
be met. This involves identifying functional requirements that define what the system
should do and non-functional requirements that define how the system should behave.

The negotiation process is an important part of requirements analysis. This is because the
requirements of different stakeholders may conflict and it is important to reach agreement on
the final set of requirements. The negotiation process can be facilitated by a requirements
engineer who can help mediate the various stakeholders and reach a mutually acceptable
solution.

Figure 1 : The process of requirements elicitation and analysis — From Software

Engineering, 9th edition, Chapter 4, by Ian Sommerville

5
 REQUIREMENTS ENGINEERING - CBRE3103
The importance of the negotiation process in requirements analysis can be summarized as
follows:

1. It helps ensure that the final set of requirements meets the needs of all stakeholders.
2. It helps prevent conflicts and disagreements between stakeholders.
3. It helps ensure that the system is developed in a timely and cost-effective manner.

Question C)
Functional requirements are specific functions that software must have in order to
fulfill its desired goal or purpose. It defines all the necessary behaviors that a product must
have in order to satisfy a given requirement of one or more stakeholders. Functional
requirements are usually expressed as inputs, outputs and processes to be performed. They
are also used to specify what the application is supposed to do without specifying how to do
it. Examples of functional requirements include user authentication, data processing rules,
calculations, data storage, security features, and access control mechanisms. It is very
important all functional requirements must be designed carefully, taking into account
usability, scalability, and maintainability. Here are a number of challenges that can be faced
while defining functional requirements. These challenges include:

1. Unclear or incomplete requirements: The users may not be able to clearly articulate
their requirements, or they may not be aware of all of their requirements. This can
make it difficult to define the functional requirements.
2. Changing requirements: The requirements may change during the course of the
project. This can be due to changes in the business environment, changes in the user
needs, or changes in the technology. It is important to be able to adapt the functional
requirements to these changes.
3. Technical constraints: The functional requirements may be constrained by technical
limitations. For example, the system may not be able to do something that the users
want it to do because it is not technically possible.

Possible solutions to challenges in defining functional requirements. These solutions include:

1. Actively involve the users in the requirements definition process: The users
should be actively involved in the requirements definition process. This will help to
ensure that the requirements are accurate and complete.

6
 REQUIREMENTS ENGINEERING - CBRE3103
2. Use a variety of techniques to gather requirements: A variety of techniques can be
used to gather requirements, such as interviews, surveys, and workshops. This will
help to ensure that all of the requirements are captured.
3. Document the requirements: The requirements should be documented in a clear and
concise manner. This will help to ensure that the requirements are understood by all
stakeholders.
4. Review the requirements regularly: The requirements should be reviewed regularly
to ensure that they are still accurate and complete. This will help to identify any
changes in the requirements and to adapt the requirements accordingly.
Question D)
Use case diagrams are a powerful tool for requirements analysis. They provide a way to
visualize the interactions between a system and its users, and to capture the system's
functionality in a clear and concise way. Use case diagrams are important for several reasons.
First, they help to ensure that all of the system's requirements are captured. By
identifying the different actors that will interact with the system, and the different use cases
that those actors will perform, a use case diagram can help to ensure that no important
functionality is overlooked.

Second, use case diagrams can help to improve communication among stakeholders.
By providing a visual representation of the system's functionality, use case diagrams can help
to ensure that everyone involved in the project has a shared understanding of what the system
should do. This can be especially important in projects where there are multiple stakeholders
with different perspectives.

Finally, use case diagrams can help to facilitate the design and implementation of the
system. By identifying the different use cases, the system's designers can ensure that the
system is capable of supporting all of the required functionality.

Understanding system functionality: Use case diagrams can help to visualize the
different ways in which a system can be used. This can be helpful for understanding the
system's overall functionality, as well as the specific features that are available to different
users. For example, a use case diagram for an online banking system might show how a
customer can log in to their account, view their balance, transfer money, and pay bills.
Facilitating communication among stakeholders: Use case diagrams can provide a
common language for stakeholders to discuss the system's functionality. This can help to
7
 REQUIREMENTS ENGINEERING - CBRE3103
ensure that everyone involved in the project has a shared understanding of what the system
should do. For example, a use case diagram can be used to show how a customer interacts
with the online banking system, and how the system responds to those interactions. This can
help to ensure that the customer, the system developers, and the project manager all have a
clear understanding of how the system should work.
Documenting requirements: Use case diagrams can be used to document the system's
requirements. This can be helpful for tracking changes to the requirements, as well as for
communicating the requirements to other stakeholders. For example, a use case diagram can
be used to list the different use cases that the system should support, as well as the inputs,
outputs, and preconditions for each use case.
In summary, use case diagrams are an important tool for requirements analysis. They
can help to ensure that all of the system's requirements are captured, improve communication
among stakeholders, and facilitate the design and implementation of the system. Overall, use
case diagrams are a valuable tool for requirements analysis. They can help to ensure that all
of the system's requirements are captured, improve communication among stakeholders, and
facilitate the design and implementation of the system.

Question E)
On this question I will use a case study to describes the use case modeling process for
an ATM system. The ATM system is designed to allow customers to perform a variety of
banking transactions, such as withdrawing cash, depositing cash, transferring funds, checking
their account balance, and changing their PIN. The case study begins by describing the
problem that the ATM system is designed to solve, as well as the system requirements. It then
presents the use case diagrams, actors, and scenarios that were created to model the
functionality of the system. The case study also discusses how other types of UML diagrams
can be used in conjunction with use case diagrams to provide a more detailed view of system
behavior and interactions. By the end of the case study, readers will have a clear
understanding of the use case modeling process and how it can be applied to real-world
systems such as an ATM system. Refer to figure below.

8
 REQUIREMENTS ENGINEERING - CBRE3103

Source: www.cybermedian.com/use-case-modeling-for-an-atm-system-a-comprehensive-
guide-and-case-study

Use case:
Descriptions Customer withdraw cash from ATM Machine
Primary Actors Customer
Pre-conditions 1. The customer has inserted their ATM card into the machine.
2. The customer has entered their correct PIN.
Post-conditions 1. The system displays the main menu
Main success scenario 1. The customer will insert their ATM card into the ATM
machine.
2. The system prompts the customer to key in their numeric
password which is the PIN numbers.
3. The customer then enters their PIN numbers.
4. The system verifies the PIN numbers.
5. The customer presses the “Withdraw Cash” option on the
screen
6. The system prompts the customer to enter the amount of
money they wish to be withdraw.
7. The customer enters the amount of money.
9
 REQUIREMENTS ENGINEERING - CBRE3103
8. The ATM system dispenses the cash.
9. The customer removes their ATM card from the ATM
machine and takes the cash.

10
 REQUIREMENTS ENGINEERING - CBRE3103
Alternative Scenario 1a. Insufficient Funds

1. The ATM verifies that the customer has insufficient funds in

their account to cover the withdrawal amount.
2. The ATM displays an error message informing the customer
that they do not have sufficient funds to complete the
transaction.
3. The ATM prompts the customer to either enter a smaller
withdrawal amount or cancel the transaction.
4. The customer either enters a smaller withdrawal amount or
cancels the transaction.

2a. Invalid Amount

1. The customer enters an invalid withdrawal amount, such as a

negative number or a value that exceeds their daily
withdrawal limit.
2. The ATM displays an error message informing the customer
that the amount entered is invalid.
3. The ATM prompts the customer to enter a valid withdrawal
amount.
4. The customer enters a valid withdrawal amount.

3a. Card Retained

1. The ATM fails to dispense the cash due to a hardware or

software error.
2. The ATM displays an error message informing the customer
that their card has been retained.
3. The ATM prompts the customer to contact their bank or
customer service for assistance.
4. The customer contacts their bank or customer service to
retrieve their card.

11
 REQUIREMENTS ENGINEERING - CBRE3103

REFERENCES
Citation for Question A.
Isha. “Importance of Requirement Elicitation in Software Development Projects.” A4PNA
Infotech. 2 Dec. 2020
https://www.aapnainfotech.com/requirement-elicitation-software-development/

Citation for Question B.

Elgabry, Omar. "Requirements Engineering - Elicitation & Analysis (Part 2)." Medium, 1
Jan. 2022, https://medium.com/omarelgabrys-blog/requirements-engineering-elicitation-
analysis-part-2-a02db801f135

Citation for Question C.

“What Are Functional Requirements? A Comprehensive Guide with Examples.” nTask, 2
May 2023, www.ntaskmanager.com/blog/what-are-functional-requirements/

Citation for Question D.

15-6840 Paper by Dhiraj Kumar-Role of Use Cases in System Analysis and Development:
How Effective It Is Today?
https://www.umsl.edu/~sauterv/analysis/termpapers/f11/kumar/usecase.html

Citation for Question E.

12
 REQUIREMENTS ENGINEERING - CBRE3103
“Use Case Modeling for an ATM System: A Comprehensive Guide and Case Study.”
Cybermedian, 2 Mar. 2023, www.cybermedian.com/use-case-modeling-for-an-atm-
system-a-comprehensive-guide-and-case-study/

13