SCS 2204 Software Engineering

BITC Year 2, Semester 2

Department of Computer Science

By Dr. Beatrice Aguti
19th January 2022
 Lecture Four: Requirements Engineering
and UML Modelling
► Topics to cover;
► Introduce the concepts of requirements
► Requirements engineering processes
► Requirements elicitation and analysis
► Requirements validation
► Requirements change management
► Introduce the UML Modelling with Use Cases

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Engineering

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirement Engineering

► Requirements engineering is 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.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 The Requirement Engineering
Process
► The processes used for Requirements Engineering vary widely
depending on the application domain, the people involved and the
organisation developing the requirements.
► However, there are a number of generic activities common to all
Requirement Engineering Processes;
► Requirements elicitation
► Requirements analysis
► Requirements Specification
► Requirements Validation
► Requirements management

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Engineering Process

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Elicitation

► Requirements Elicitation / inception: ask a set of questions

that establish …
► 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 customer and the developer.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Elicitation – Cont’d
► Requirements Elicitation:
► It is the practice of obtaining the requirements of a system from users,
customers and other stakeholders. The practice is also sometimes referred to
as Requirement gathering.
► Requirements elicitation practice include the following:
► Interviews
► Questionnaires
► User observation
► Workshops
► Brain storming
► Use cases and prototyping

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Elicitation – Cont’d
► Problems of Requirement Elicitation
► Problems of scope: The boundary of system is ill-defined. Or
unnecessary details are provided.
► Problems of understanding: The users are not sure of what they
need, and don’t have full understanding of the problem domain.
► Problems of volatility: the requirements change overtime.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Guidelines of Requirements
Elicitation
► Assess the business and technical feasibility for the proposed system
► Identify the people who will help specify requirements.
► Define the technical environment (e.g. computing architecture, operating system,
telecommunication needs) into which the system or product will be placed
► Identify “domain constraints” (i.e. characteristics of the business environment
specific to the application domain) that limit the functionality or performance of
the system or product to build
► Define one or more requirements elicitation methods (e.g. interviews, team
meetings, etc.)
► Solicit participation from many people so that requirements are defined from
different point of views.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Eliciting Requirements - Inception

► Identify (key) stakeholders

► These are the people who will be involved in the negotiation
► “who else do you think I should talk to?”
► Recognize multiple points of view
► Work toward collaboration
► The first 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?
Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Eliciting Requirements
► Meetings are conducted and attended by both software engineers and customers
► Rules for preparation and participation are established
► An agenda is suggested
► 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
► The goal is
► to identify the problem
► propose elements of the solution
► negotiate different approaches, and
► specify a preliminary set of solution requirements

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Elicitation Work Products
► A statement of need, scope, and feasibility.
► A list of customers, users, and other stakeholders who participated in
requirements elicitation
► A description of the system’s technical environment (enterprise model
in system engineering).
► 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.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Analysis

► Requirements Analysis is about determining whether the

stated requirements are clear, complete, consistent and
unambiguous.
► Requirements Analysis also relates to stakeholder
identification.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Analysis – Cont’d
► Stakeholder Identification
► Stakeholders are people or organizations that have a valid interest in
the system. They may be affected by it directly or indirectly.
► Stake holders may include:
► Anyone who operates the system
► Anyone who benefits from the system
► Anyone involved in purchasing or procuring the system
► People opposed to the system (negative stakeholders)
► Organizations responsible for the system

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Analysis – Cont’d

► Stakeholder Interviews
► Interviews are a common technique used in requirement
analysis.
► This technique can serve as a means of obtaining the
highly focused knowledge from different stakeholders
perspectives.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Analysis – Types of
Requirements
► Customer Requirements:
► Operational distribution or deployment: Where will the system be used?
► Mission profile or scenario: How will the system accomplish its mission
objective?
► Performance and related parameters: What are the critical system parameters to
accomplish the mission?
► Utilization environments: how are the various system components to be used?
► Effectiveness requirements: How effective or efficient must the system be in
performing its mission?
► Operational life cycle: How long will the system be in use?
► Environment: what environments will the system be expected to operate in an
effective manner?

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Analysis – Types of
Requirements
► Architectural Requirements:
► A formal description and representation of a system, organized in a
way that support reasoning about the structure of the system which
comprises system components.
► The externally visible properties of those components, the
relationships and the behavior between them, and provides a plan
from which products can be procured and systems developed, that
will work together to implement the overall system.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Analysis – Types of
Requirements
► Functional Requirements:
► Defines functions of a software system or its components. They
may be calculations, technical details, data manipulation and
processing and other specific functionality that define “what a
system is supposed to accomplish?”
► They describe particular results of a system.
► Functional requirements are supported by Non-functional
requirements.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Analysis – Types of
Requirements
► Non-Functional Requirements:
► They are requirements that specify criteria that can be used to judge the
operation of a system, rather than specific behavior.
► Functional requirements define what the system is supposed to do,
whereas non-functional requirements define how a system is supposed to
be.
► Non-functional requirements can be divided into two main categories:
► Execution qualities, such as security and usability, which are
observable at runtime.
► Evolution qualities, such as testability, maintainability and scalability.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Specifications

► Requirements Specification is the direct result of a requirement analysis

and can refer to:
► Software Requirements Specification
► Hardware Requirements Specification
► Requirements Specification can be any one (or more) of the following:
► A written document
► A set of models - A formal mathematical
► A collection of user scenarios (use-cases)
► A prototype

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Software Requirements Specifications
(SRS)
► A Software Requirements Specification (SRS) – a
requirements specification for a software system:
► Is a complete description of the behavior of a system to be
developed. It includes a set of use cases that describe all the
interactions the users will have with the software. In addition to
use cases, the SRS also contains non-functional requirements
(such as performance requirements, quality standards, or design
constraints)

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 SRS
► A Software Requirements Specification (SRS)
► The software requirement specification document enlists all necessary
requirements for project development. To derive the requirements we need to
have clear and thorough understanding of the products to be developed.
► A general organization of an SRS is as follows:
► Introduction
► Purpose, Scope, Definitions, System Overview, References
► Overall Description
► Product Perspective, Product functions, User characteristics, constraints, assumptions and
dependencies.
► Specific Requirements
► External Interface requirements, functional requirements, performance requirements, design
constraints, logical database requirement, software system attributes.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Validation and
Verification
► Validation (& Verification), is the process of checking whether the
requirements, as identified, do not contradict the expectations about the system
of various stakeholders and do not contradict each other.
► It is Requirements Quality Control
► Validation is a review mechanism that looks for
► errors in content or interpretation
► areas where clarification may be required
► missing information
► inconsistencies (a major problem when large products or systems are engineered)
► conflicting or unrealistic (unachievable) requirements.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Validation Vs. Verification

► Validation: “Am I building the right product?” checking a work product

against higher-level work products or authorities that frame this
particular product.
► Requirements are validated by stakeholders

► Verification: “Am I building the product right?” checking a work product

against some standards and conditions imposed on this type of product
and the process of its development.
► Requirements are verified by the analysts mainly

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Change Management

► Requirements management is the process of managing

changing requirements during the requirements engineering
process and system development.
► New requirements emerge as a system is being developed
and after it has gone into use.
► You need to keep track of individual requirements and
maintain links between dependent requirements so that you
can assess the impact of requirements changes. You need to
establish a formal process for making change proposals and
linking these to system requirements.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Management:
Changing Requirements
► The business and technical environment of the system always changes
after installation.
► New hardware may be introduced, it may be necessary to interface
the system with other systems, business priorities may change (with
consequent changes in the system support required), and new
legislation and regulations may be introduced that the system must
necessarily abide by.
► The people who pay for a system and the users of that system are rarely
the same people.
► System customers impose requirements because of organizational
and budgetary constraints. These may conflict with end-user
requirements and, after delivery, new features may have to be added
for user support if the system is to meet its goals.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Management:
Changing Requirements
► Large systems usually have a diverse user community, with many users
having different requirements and priorities that may be conflicting or
contradictory.
► The final system requirements are inevitably a compromise between
them and, with experience, it is often discovered that the balance of
support given to different users has to be changed.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Evolution

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Management Planning
► Establishes the level of requirements management detail that is required.
► Requirements management decisions:
► identification Each requirement must be uniquely identified so that it can be
cross-referenced with other requirements.
► A change management process This is the set of activities that assess the impact and
cost of changes.
► Traceability policies These policies define the relationships between each requirement
and between the requirements and the system design that should be recorded.
► Tool support Tools that may be used range from specialist requirements management
systems to spreadsheets and simple database systems.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Change Management
► Deciding if a requirement’s change should be accepted
► Problem analysis and change specification
► During this stage, the problem or the change proposal is analyzed to check that it is valid. This
analysis is fed back to the change requestor who may respond with a more specific requirements
change proposal, or decide to withdraw the request.

► Change analysis and costing

► The effect of the proposed change is assessed using traceability information and general
knowledge of the system requirements. Once this analysis is completed, a decision is made
whether or not to proceed with the requirements change.

► Change implementation
► The requirements document and, where necessary, the system design and implementation, are
modified. Ideally, the document should be organized so that changes can be easily implemented.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Requirements Change Management
Process

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Building the Requirements Analysis
Model
► Elements of the analysis model
► Scenario-based elements
► Functional—processing narratives for software functions
► Use-case—descriptions of the interaction between an “actor” and the system
► Class-based elements
► Implied by scenarios
► Behavioral elements
► State diagram
► Flow-oriented elements
► Data flow diagram

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 UML

► Unified Modelling Language (UML) is a graphical language

for visualizing, specifying, constructing, and documenting
the artefacts of a software-intensive system.
► It offers a standard way to write a system’s blueprints,
including conceptual things such as business processes and
system functions as well as concrete things such as
programming language statements, database schemas, and
reusable software components.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 UML Diagrams

► Unified Modeling Language (UML)Diagrams

► UML is a modelling language mainly used for
► specification,
► visualization,
► development and
► documenting of software systems.
► But business professionals have adapted it as a powerful
business process modeling technique.
Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 UML Diagrams – Cont’d

► Unified Modeling Language (UML)Diagrams

► With 14 different UML diagram types it offers a flexible
and powerful way to visualize almost any business
process.
► They are typically used for modelling the detailed logic of
a business process.
► In many ways UML diagrams are the object-oriented
equivalent of flow charts.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 UML Diagrams – Cont’d

► Unified Modeling Language (UML)Diagrams

► The 14 diagrams of UML
1. Class Diagram
2. Component Diagram
3. Deployment Diagram
4. Object Diagram
5. Package Diagram
6. Profile Diagram
7. Composite Structure Diagram
Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Unified Modeling Language (UML)
Diagrams – Cont’d
► Unified Modeling Language (UML)Diagrams
► The 14 diagrams of UML
8. Use Case Diagram
9. Activity Diagram
10. State Machine Diagram
11. Sequence Diagram
12. Communication Diagram
13. Interaction Overview Diagram
14. Timing Diagram
Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 UML Class Diagram with Relationships

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Activity Diagrams with start, end, processes
and decision points

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 UML Activity Diagram of Admission,
Enrolment, and Registration Process

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Use Case Diagram Showing Actors and main
Processes

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Use Case Modelling with UML

► Use Cases:
► Is a collection of user scenarios that describe the
thread of usage of a system
► Each scenario is described from the point-of-view
of an “actor”—a person or device that interacts
with the software in some way

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Use Cases

► Use-cases are a kind of scenario that are included in the UML.

► Use cases identify the actors in an interaction and which describe the
interaction itself.
► A set of use cases should describe all possible interactions with the
system.
► UML sequence diagrams may be used to add detail to use-cases by
showing the sequence of event processing in the system.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Use Cases – Cont’d

► Each scenario answers the following questions:

► 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 extensions 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?

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Use Case: 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.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Use Case: Example of Collecting
Medical History
► Initial assumption: The patient has seen a medical receptionist who has created a record in
the system and collected the patient’s personal information (name, address, age, etc.). A
nurse is logged on to the system and is collecting medical history.
► Normal: The nurse searches for the patient by family name. If there is more than one
patient with the same surname, the given name (first name in English) and date of birth are
used to identify the patient.
► The nurse chooses the menu option to add medical history.
► The nurse then follows a series of prompts from the system to enter information about
consultations elsewhere on mental health problems (free text input), existing medical
conditions (nurse selects conditions from menu), medication currently taken (selected from
menu), allergies (free text), and home life (form).

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Use Case: Example of Collecting
Medical History
► What can go wrong: The patient’s record does not exist or cannot be found. The nurse should
create a new record and record personal information.
► Patient conditions or medication are not entered in the menu. The nurse should choose the ‘other’
option and enter free text describing the condition / medication.
► Patient cannot/will not provide information on medical history. The nurse should enter free text
recording the patient’s inability/unwillingness to provide information. The system should print
the standard exclusion form stating that the lack of information may mean that treatment will be
limited or delayed. This should be signed and handed to the patient.
► Other activities: Record may be consulted but not edited by other staff while information is
being entered.
► System state on completion: User is logged on. The patient record including medical history is
entered in the database, a record is added to the system log showing the start and end time of the
session and the nurse involved.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Use Case Diagram for Collecting
Medical History

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Assignment Three
th
Due Date: 19 February 2022
► Instructions
► Install either LUCIDCHART OR ARGOUML TOOLS.
► Get acquainted with these UML diagramming tools
► Read the Assignment Case Description on Slide 51. Also refer to the
Assignment posted via Google Classroom.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Assignment Case Description:
► You have been tasked to develop an APP for making Bookings and Reservations for Zoe Bus Company located in Kampala. The bus
company owns several buses and realizes several trips to different districts within the four regions of Uganda. Each bus is identified by its
number plate and a separately assigned bus number. The trips are based on a predefined schedule and stop at designated bus stations. Each
bus can have only one trip per day. Each bus includes a driver and one conductor. For long trips, the bus will have breaks at service and rest
areas. There are two types of trips, normal trips and express trips. Express trips do not stop at intermediate stations and get faster at the
destination. Seats can be reserved by customers on the website of the bus company or via the ZOE BUS COMPANY APP. The customer
has the option to directly pay for the seat through the website OR APP using either VISA CARD, MOBILE MONEY or CASH on the day
of BOARDING the Bus. In that case, the seat cannot be cancelled (neither by the customer nor by the bus company). If the customer has
not paid for the seat, the bus company can cancel the seat if the customer does not show up one hour before the trip. When the reservation is
cancelled, the seat will become free and can be sold to another customer. Both the customer and the company staff must authenticate
themselves for performing operations with the system, hence the system must register both the Customer and Staff.

► In reference to the case, perform a Requirements Engineering Procedure by addressing the questions listed below:

► List and justify functional and non-functional requirements that could be important for the above system.

► Identify actors and functions that will be included in the use case diagram.

► Draw a use case diagram for describing the functional requirements of the above system.

► Draw a Class Diagram that depicts the structure of the Bus Reservation System by showing the system’s classes, their attributes, and the
relationships among the classes.

► Use LUCIDCHART or ARGOUML to produce your use case diagram and class diagram.

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science
 Discussion / Questions

Dr. Beatrice Aguti Lecture Four: Requirements Engineering and UML Modelling © Semester 2 2022
SCS 2204 Software Engineering Department of Computer Science