1

SOFTWARE REQUIREMENT
ENGINEERING

Chapter - 3
 What are requirements?
2

 Requirements are statements that describe what a

system should do or how it should behave. They
define the functionality, limitations, and goals of a
system and serve as the foundation for design,
development, and testing.
 In simple terms: Requirements tell developers what to
build, not how to build it.
 What are requirements?
3

 Requirements are defined during the early stages of a system development as a

specification of what should be implemented or as a constraint of some kind on
the system. Something required, something wanted or
needed
 They may be: •Need- something you have to have
•Want -something you would like to have
 a user-level facility description,
 a detailed specification of expected system behaviour,
 a general system property,
 a specific constraint on the system,
 information on how to carry out some computation,
 a constraint on the development of the system.
 Product and Process Requirements
4

 Product parameters are requirements on software to be developed

 for example, “The software shall verify that a student meets all
prerequisites before he or she registers for a course.”.
 A process parameter is essentially a constraint on the
development of the software.
 for example, “The software shall be written in Ada.”.
 What is requirements engineering?
5

 Requirements engineering covers all of the activities involved in

discovering, documenting, and maintaining a set of requirements
for a computer-based system.

 The use of the term ‘engineering’ implies that systematic and

repeatable techniques should be used to ensure that system
requirements are complete, consistent, relevant, etc.
 Sub-disciplines of Software Requirements Engineering
6

 These sub-disciplines encompass all the activities involved with exploring,

evaluating, documenting, and confirming the requirements for a product
 What happens if the requirements are wrong?
7

 The system may be delivered late and cost more than originally
expected.
 The customer and end-users are not satisfied with the system. They
may not use its facilities or may even decide to scrap it altogether.
 The system may be unreliable in use with regular system errors and
crashes disrupting normal operation.
 If the system continues in use, the costs of maintaining and evolving
the system are very high.
 What happens if the requirements are wrong?
8

Building the Wrong Product: Example: A customer wanted a mobile app, but the team
delivered a desktop app.

Wasted Time and Resources: Developers, testers, and designers spend effort on features
or designs that will need to be redone or discarded.

Increased Costs: Fixing requirements-related issues late in the development process (or after
release) is far more expensive than fixing them early. According to studies, fixing a defect after
release can cost 100x more than during the requirements phase.

Project Delays: Teams may need to go back, rework parts of the design, code, and tests, which
disrupts schedules.

Frustrated Stakeholders: Users, clients, and management may lose trust in the development
team if expectations aren’t met.

Reduced Product Quality: Incorrect or incomplete requirements can lead to missing

 Why is requirements engineering difficult?
9

 Unclear or Evolving Requirements

Stakeholders may not know exactly what they need at the start.
 Communication Gaps
Developers, users, managers, and clients often use different language and have
different perspectives. Misunderstandings are common, especially when
technical and non-technical people try to communicate.
 Conflicting Requirements
Different stakeholders may have competing interests or priorities.
 Example: Marketing wants speed to market, while legal wants strict
compliance—these may conflict.
 Lack of Formal Techniques
 Many organizations rely on informal methods like plain text documents or
verbal agreements. This leads to ambiguity, missed requirements, and lack
of traceability.
 Why is requirements engineering difficult?
10

 Businesses operate in a rapidly changing environment so their

requirements for system support are constantly changing.
 Multiple stakeholders with different goals and priorities are
involved in the requirements engineering process.
 System stakeholders do not have clear ideas about the system
support that they need.
 Requirements are often influenced by political and organisational
factors that stakeholders will not admit to publicly.
 Establishing the Groundwork
11

 Establishing the Groundwork: refers to the initial phase where

the foundation for the entire requirements process is set.
 This stage ensures that all stakeholders have a shared
understanding of the project's goals, context, scope, and
constraints before gathering detailed requirements.

 Establishing the groundwork is the process of preparing the

environment, understanding the problem domain, identifying
stakeholders, and defining the scope and objectives for
requirements engineering.
 RE process inputs and outputs
12

Existing
systems
information

Stakeholder Agreed
needs requirements

Requirements System
Organisational engineering process
standards specification

System
Regulations models

Domain
information
Input/output description
Input or output Type Description
Existing system Input Information about the functionality of
13 information systems to be replaced or other systems
which interact with the system being
specified
Stakeholder needs Input Descriptions of what system stakeholders
need from the system to support their work
Organizational Input Standards used in an organization
standards regarding system development practice,
quality management, etc.
Regulations Input External regulations such as health
and safety regulations which apply to
Domain information Input the system.
General information about the application
domain of the system
 Requirements engineering processes
14

 The goal of RE Process is to create & maintain a system

requirements documents.
 Includes 4 High level RE Sub-processes:
 Feasibility study : usefulness to the business ;
 Elicitation and analysis : discovering and analyzing requirements;
 Specification: conversion of requirement into some standard form;
 Validation : check the requirements which defines the system that
the customer wants;
 The requirements engineering process
15
 1. Feasibility studies
16

 A feasibility study evaluates if a software project is

practical and viable.
 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 implemented using current technology, within given cost
and schedule constraints;
 If the system can be integrated with other systems that are already in place.
 1.Objectives of Feasibility Studies
17

 Assess technical, economic, legal, and other constraints.

 Identify potential risks and obstacles.
 Support informed decision-making.
 Prevent resource waste on unworkable projects.
 Types of Feasibility Studies
 Technical Feasibility
 Economic Feasibility
 Legal Feasibility
 Operational Feasibility
 Schedule Feasibility
 Organizational/Political Feasibility
 1.Feasibility studies
18

 Technical Feasibility: Can we build it with available

technology and skills?
 Assess tools, platforms, hardware, and development

expertise.
 Example: Is the team experienced in AI-based systems?

 Economic Feasibility: Is the project cost-effective?

 Analyze development costs vs expected benefits.
 Consider ROI, budget limits, and long-term savings.
 Legal Feasibility: Are there legal or regulatory issues?
 Check data privacy laws (e.g., GDPR), licenses, contracts.
 Operational Feasibility
 Will the system work within the organization?
 Assess user acceptance, business process impact, training
needs.
 1.Feasibility studies
19

 Schedule Feasibility
 Can we deliver the project on time?
 Evaluate timeline, deadlines, resource
availability.
 Include risk of delays and dependencies.
 Organizational/Political Feasibility
 Is there internal support for the project?
 Analyze company culture, stakeholder
alignment, and resistance to change.
 Example: Is upper management committed?
 1.Feasibility study implementation
20

 Feasibility study involves information assessment (what is required),

information collection and report writing.
 Questions for people in the organization for information assessment and
collection:
 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 report should make a recommendation about the

development to continue or not.

 2.Requirements elicitation and
21
analysis
2.1 Requirement Elicitation
Elicitation encompasses all of the activities involved with discovering requirements.
It involves interacting with stakeholders (such as clients, end-users, and developers) to
understand their needs, goals, and constraints for the system being developed.
The key actions are:
 Identifying the product’s expected user classes and other stakeholders.
 Understanding user tasks and goals and the business objectives with which those tasks
align.
 Learning about the environment in which the new product will be used.
 Working with individuals who represent each user class to understand their
functionality needs and their quality expectations.
Requirements elicitation typically takes either a usage-centric (understanding and exploring
 2.Requirements elicitation and
22
analysis..
 Eliciting & understanding stakeholder requirement is difficult due to the
following reasons:
 Stakeholders don’t know what they really want except in most general.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have deferent requirements.
 Organizational & political factors may influence the system requirements.
 The requirements change during the analysis process.
 New stakeholders may emerge and the business environment change.
 2.Requirements elicitation and
23
analysis..
2.2 Requirement Analysis
understanding of each requirement & representing sets of requirements in multiple ways.


Following are the principal activities:



 Analysing the information received from users to distinguish their task goals from

functional requirements, quality expectations, business rules, suggested solutions,

and other information
 Decomposing high-level requirements into an appropriate level of detail

 Deriving functional requirements from other requirements information

 Understanding the relative importance of quality attributes

 Allocating requirements to software components defined in the system architecture

 Negotiating implementation priorities

 Identifying gaps in requirements or unnecessary requirements as they relate to the

defined scope
2.Requirements elicitation and analysis..

 The goal of analysis is to discover problems, incompleteness and

inconsistencies in the elicited requirements.
 These are then feedback to the stakeholders to resolve them
through the negotiation process.
 Analysis is inserted with elicitation as problems are discovered
when the requirements are elicited.
 A problem checklist may be used to support analysis.
 Each requirement may be assessed against the checklist.
 Requirements elicitation & analysis Process…
25
 Elicitation and analysis Process activities…
26

 Requirements discovery
 Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
 Requirements classification and organization
 Group related requirements and organizes them into coherent clusters.
 Prioritization and negotiation
 Prioritizing requirements & finding and resolving requirements conflicts.
 Requirements documentation
 Requirements are documented and input into the next round of the spiral.
 Requirements elicitation & analysis Process…
27

Requirements discovery
The process of gathering information about the proposed and existing
systems and distilling the user and system requirements from this information.
Sources of information include documentation, system stakeholders and the
specifications of similar systems.
Approaches & Techniques of requirements discovery are:
 Questioner
 Interviewing
 Document analysis
 Use-cases
 Requirements Specification
28

 Requirements specification involves representing and storing the collected

requirements knowledge in a persistent and well-organized fashion.
 The principal activity is:
 Translating the collected user needs into written requirements and
diagrams suitable for comprehension, review, and use by their
intended audiences.
 A complete Software Requirement Specifications should be:
 Clear, Correct, Consistent, Coherent, Comprehensible, Modifiable
Verifiable, Prioritized, Unambiguous, Traceable…
 Requirements validation…
29

 Confirms that you have the correct set of requirements

information that will enable developers to build a solution that
satisfies the business objectives
 Concerned with demonstrating that the requirements define the
system that the customer really wants.
 Requirements error costs are high so validation is very important
 Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementation error.
 Requirements validation…
30

Requirements checking
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?
 Requirements validation…
31

Requirements validation techniques (central activities):

Requirements reviews
 Systematic manual analysis of the requirements.
Prototyping
 Using an executable model of the system to check requirements.
Test-case generation
 Developing tests for requirements to check testability.
 If test is difficult or impossible to design for the requirement means it is
difficult to implement that requirement
 Requirements validation…
32

Requirements reviews
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.
 Requirements validation…
33

Review checks
 Verifiability: Is the requirement realistically testable?
 Comprehensibility: Is the requirement properly understood?
 Traceability: Is the origin of the requirement clearly stated?
 Adaptability: Can the requirement be changed without a large impact
on other requirements?
Requirements negotiation
 Disagreements about requirements are expected when a system has
many stakeholders.
 Conflicts are not ‘failures’ but reflect different stakeholder needs and
priorities.
 Requirements negotiation is the process of discussing requirements
conflicts and reaching a compromise that all stakeholders can agree
to.
 In planning a requirements engineering process, it is important to
leave enough time for negotiation.
Negotiation meetings

 An information stage where the nature of the problems associated with a

requirement is explained.
 A discussion stage where the stakeholders involved discuss how these
problems might be resolved.
 All stakeholders with an interest in the requirement should be given the
opportunity to comment.
 Priorities may be assigned to requirements at this stage.
 A resolution stage where actions concerning the requirement are agreed.
 These actions might be to delete the requirement, to suggest specific
modifications to the requirement or to elicit further information about the
requirement.
 Key points
 Requirements elicitation involves:
 Understanding the application domain
 The specific problem to be solved,
 The organisational needs and constraints and
 The specific facilities needed by system stakeholders.
 The processes of requirements elicitation, analysis and negotiation
are iterative, interleaved processes which must usually be repeated
several times.
 Requirements management
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;
 Different viewpoints have different requirements and these are
often contradictory.
 Requirements management…
38

Requirements change
The priority of requirements from different viewpoints changes during
the development process.
System customers may specify requirements from a business
perspective that conflict with end-user requirements.
The business and technical environment of the system changes during
its development.
 Emergent properties
39

 Emergent properties are properties of the system as a whole rather than

properties that can be derived from the properties of components of a
system.
 Emergent properties are a consequence of the relationships between
system components.
Some examples of emergent properties:
 Volume/the total space occupied
 Reliability
 Security
 Reparability

 Types of Software Requirements
40

Functional requirement
A functional requirement defines a function of a software system or its component.
A function is described as a set of inputs, the behaviour, and outputs.
Functional requirements may be calculations, technical details, data manipulation &
processing and other specific functionality that define what a system is supposed to
accomplish.
Functional requirements should be complete and consistent
Customers and developers usually focus all their attention on functional requirements
 Types of Software Requirements…
41

Non-Functional requirement
A requirement that specifies criteria that can be used to judge the operation of a system,
rather than specific behaviours.
Non-functional requirements are often called qualities of a system
Types:
Product requirements: Efficiency (performance & space) , Reliability, Portability
requirements
Organizational requirements (organizational policies and procedures): Delivery ,
Implementation , Standards requirements
External requirements (factors which are external to the system): Interoperability ,
legislative (Privacy & safety), Ethical requirements ..

 Software and System Requirements
42

 A software requirements specification (SRS) includes in-depth

descriptions of the software that will be developed.
 A system requirements specification (SyRS) collects information on the
requirements for a system.
 System requirements relate to the system as a whole. They may
relate to hardware, software, processes, documentation and so on.
 “Software” and “system” are sometimes used interchangeably as SRS.
 But, a software requirement specification provides greater detail than a
system requirements specification.
 For a Written Article Review
Assignment
43

•Title of the Review

•Citation of the Article

•Introduction

•Article Summary

•Critical Analysis
•Limitations or weaknesses.

•Theoretical or Conceptual Framework

•Implications

•Personal Reflection / Evaluation

•Conclusion

•References
 For Article Review For a
Presentation
44

•Title Slide
•Your name, article title, author(s), course name.

•Introduction
•Purpose of the Article

•Methodology

•Key Findings

•Critical Evaluation

•Theoretical Contributions
•Implications

•Your Reflection

•Conclusion

•Q&A Slide
 Building the Requirements Model in
Software Engineering
45

 Building the requirements model is

the process of capturing, organizing,
and representing the needs and
expectations of users and stakeholders
for a software system in a clear and
structured way. This model acts as a
blueprint that guides system design,
development, and testing.
 Purpose of the
46
Requirements Model
 Define what the system should do (not
how it should do it)
 Ensure a common understanding
between stakeholders and developers
 Serve as a basis for system design,
validation, and testing
 Help manage scope and reduce
misunderstandings
 Structured
47

 Structured methods are traditional, process-

driven techniques used in software
development. They focus on functions and
processes rather than objects. These methods
became popular in the 1970s and 1980s,
especially for large business applications.
 Key Characteristics:
 Emphasize top-down design

 Focus on functions and procedures

 Often used in waterfall model environments

 Use diagrams to represent system structure and data

flow
 Structured: Common
48
Modeling Tools
 Data Flow Diagrams (DFDs): Show
how data moves through the system.
 Structure Charts: Show the hierarchy
of program modules.
 Entity-Relationship Diagrams
(ERDs): Model data and relationships.
 Process Specifications (P-Specs):
Describe processes in detail.
 Structured
49

Advantages:
Clear structure for system decomposition

Useful for procedural programming

languages
Limitations:
Poor support for reuse and scalability

Difficult to manage complexity in large

systems
Not aligned with object-oriented

programming
 Object-Oriented
50

 Scenario-Based Requirements Modeling Methods.

 Class-Based Requirements.
 Object-Oriented (OO) methods model a system as a
collection of interacting objects that represent real-
world entities. These methods align closely with object-
oriented programming languages like Java, C++,
Python…..
 Key Characteristics:
 Focus on objects, classes, and inheritance
 Integrate data and behavior (methods)
 Promote reusability, modularity, and
encapsulation
 Common Modeling
51
Language:
 UML (Unified Modeling Language) – the industry
standard
 Class Diagrams
 Use Case Diagrams
 Sequence Diagrams
 State Diagrams
 Activity Diagrams
 Advantages:
 Excellent for complex and large systems
 Promotes maintainability and code reuse
 Aligns with modern programming practices
 Limitations:
 Can be more complex for small/simple applications
 Learning curve for non-technical stakeholders
 Cont…
52 Example: Problem statement
 Idea: A Library Management System should be
designed. Information on books, CDs, DVDs, Journals,
etc. can be stored and retrieved.
Functional Req.
 Possible Requirements:
 Searching by Title, Author, and/or ISDN should be possible

 User Interface should be web-based (accessible via WWW

Browser) Implementation req.

Performance req.

 At least 20 transactions per seconds should be possible

Availability req.

 All services should be available within 10 minutes

Security req.
 Users have no access to personal data of other users
 Requirements
53
Specifications
 Requirements Specification is the direct
result of a requirement analysis and can
refer to:
 Software Requirements Specification
 Hardware Requirements Specification

 A Software Requirements
Specification (SRS) –is a complete
description of the behavior of a system to
be developed.
 Cont’d…
54

 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)
 Requirements
55
Specifications
 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.
 Requirements Validation and
56
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 Vs.
57
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
 System models
58

 Different models may be produced during

the requirements analysis activity.
 Requirements analysis may involve
three structuring activities which result
in these different models
 Partitioning. Identifies the structural (part-of)
relationships between entities/objects/units
 Abstraction. Identifies generalities among
entities
 Projection. Identifies different ways of looking at
a problem
 Cont’d…
59

The System/analysis model is composed of three

individual models:
1. Functional model , represented by use cases and scenarios
2. Analysis object model , represented by class and object
diagrams
3. Dynamic model , represented by state chart and sequence
diagrams.
 Requirements Elicitation activities to
60
do System models
1. Identifying actors. During this activity,
developers identify the different types of users the
future system will support.
2. Identifying scenarios. During this activity,
developers observe users and develop a set of
detailed scenarios for typical functionality provided
by the future system.
-- scenarios are concrete examples illustrating a single
case.
3. Identifying use cases: developers derive from the
scenarios a set of use cases that completely
represent the future system.
-- use cases are abstractions describing all possible cases.
 Cont…
61

4. Refining use cases: developers ensure that the system

specification is complete, by detailing each use case
and describing the behavior of the system in the
presence of errors and exceptional conditions.
5. Identifying relationships among use cases:
developers consolidate the use case model by
eliminating redundancies. This ensures that the
system specification is consistent.
6. Identifying nonfunctional requirements: developers,
users, and clients agree on aspects that are visible to the
user but not directly related to functionality.
These include constraints on the performance of the system, its
documentation, the resources it consumes, its security, and its
quality.
 Scenarios
62
 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;

 What can go wrong and how this is handled

 Information about other concurrent activities;

 A description of the state when the scenario

finishes.
 Example 1:
Scenario for collecting medical history in
MHC-PMS
63
 Scenario for collecting medical history
in MHC-PMS
64
 Use cases
65
 A scenario-based technique in UML which identify
the actors in an interaction and which describe
the interaction itself.

 Used also to clarify the system boundaries.

 A set of use cases should describe all possible

interactions with the system.

 Sequence diagrams show the interactions and

event processing inside a use case.
 Actors
66
 Actor can be human or external system (out side the system)
 Actor can be:
 Primary actor: initiates a use case.
 Secondary actor: can participate in the use case.

External system actors Input device actors

 Types of Actors
67
 Initiating actor (also called primary actor
or simply “user”): initiates the use case to
achieve a goal
 Participating actor (also called secondary
actor): participates in the use case but does
not initiate it. Subtypes of participating
actors:
 Supporting actor: helps the system-to-be to
complete the use case
 Offstage actor: passively participates in the use
case, i.e., neither initiates nor helps complete the
use case, but may be notified about some aspect
of it (e.g., for keeping records)
 Cont’d…
68
Use case diagram
Derived from use-case study scenarios. It is

an overview of use cases, actors, and their

communication relationships to demonstrate
how the system reacts to requests from
external users. It is used to capture system
requirements.
Sequence diagram
Describes time sequence of messages
passed among objects in a timeline
 Use case Diagram
69
 Sequence Diagram
70
 Cont’d…
71

Collaboration Diagram
Describes the sequence of message passing among

objects in the system. Equivalent to sequence diagram ,

except that it focuses on the object/s role.
Each communication link is associated with a sequence

order number plus the passed messages.

Class Diagram
Class diagrams can be derived from use-case
diagrams or from text analysis of the given problem
domain.
A class diagram is generated by system analysts and

designers and will be iteratively refined in the subsequent

phases during the software development life cycle.
 Collaboration diagram
72
 Class Diagram
73
 Cont’d…
74

Activity Diagram
Outline of activities— data and control flow

among related objects. An activity is an action

for a system operation or a business process,
such as those outlined in the use-case
diagram.

It also covers decision points and threads of

complex operation processes. It describes how
activities are orchestrated to achieve the
required functionality.
 Activity Diagram
75
 Cont’d…
76
State chart diagram
Describes the life cycle of objects using a finite

state of machine.
The diagram consists of states and the transitions

between states. Transitions are usually caused by

external stimuli or events. They can also represent
internal moves by the object.
Component diagram
It describes all components in a system, their

interrelationships, interactions, and the interface of

the system. It is an outline of the composition
structure of components or modules
 State Diagram
77
 Component Diagram
78
 Cont’d...
79

Deployment Diagram
Describes system hardware, software, and

network connections for distributed

computing.

It covers server configuration and network

connections between server nodes in real-
world setting.
 Deployment Diagram
80
 Use Cases
81

 Used for Functional Requirements Analysis

and Specification.

 A use case is a step-by-step description of

how a user will use the system-to-be to
accomplish business goals.
 Detailed use cases are usually written as usage
scenarios or scripts, showing an envisioned
sequence of actions and interactions between
the external actors and the system-to-be.
 Cont’d…
82
 Deriving Use Cases from System
Requirements
83
REQ1: Keep door locked and auto-lock
1
REQ2: Lock when “LOCK” pressed 2
REQ3: Unlock when valid key provided 3
4
REQ4: Allow mistakes but prevent dictionary attacks 5
REQ5: Maintain a history log X
Y
REQ6: Adding/removing users at runtime
REQ7: Configuring the device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries

Actor’s Goal (what the actor intends to

Actor Use Case Name
accomplish)
Landlord To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Landlord To lock the door & shut the lights (sometimes?). Lock (UC-2)
To create a new user account and allow access to
Landlord AddUser (UC-3)
home.
Landlord To retire an existing user account and disable access. RemoveUser (UC-4)
To find out who accessed the home in a given interval InspectAccessHistory
Tenant
of time and potentially file complaints. (UC-5)
Tenant To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Tenant To lock the door & shut the lights (sometimes?). Lock (UC-2)
Tenant To configure the device activation preferences. SetDevicePrefs (UC-6)
LockDevice To control the physical lock mechanism. UC-1, UC-2
LightSwitch To control the lightbulb. UC-1, UC-2
[to be To auto-lock the door if it is left unlocked for a given
AutoLock (UC-2)
identified] interval of time.

( Actors already given if working from user stories instead of system requirements )
 Use Case Diagram: Device
Control UC1: Unlock
84 UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

system
boundary First tier use cases Second tier use cases

actor lude
» UC7: AuthenticateUser
«inc
«participate»
«initiate» »
UC1: Unlock t ic i pate
« par
«in
it «particip LockDevice
iat ate»
e»
Tenant
ate»
e» «particip
it iat
«i n
«pa LightSwitch
rtici
«initiate» UC2: Lock pate
»
«initiate + participate»
communication use case
Landlord Timer
 Use Case Diagram: Account
Management
85
UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

Account Management Subsystem

«initiate»
UC3: AddUser
« in
«ini clu
tiate de
» »
Landlord
e» UC4: RemoveUser «inclu
pat de»
ti ci
par
« e» UC8: Login
nc lud
«i
te»
«initia UC5: InspectAccessHistory »
ude
cl
«initi « in
ate»

Tenant UC6: SetDevicePrefs

 GUI for UC6: Set Device
86
Pref’s
Device Preferences
File Configure Help

Activate for valid key Activate for burglary attempt

Lights Air-
Air-conditioning Alarm bell Send SMS
Music Heating Police …

Apply Close

( NOTE: Lock device is mandatory, not an option )

 Use Case Generalizations
87
UC1: Unlock
UC2: Lock
 More abstract representations can be UC3: AddUser
UC4: RemoveUser

derived from particular representations UC5: InspectAccessHistory

UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

UC9: ManageUsers
Authorized Person

UC3: AddUser UC4: RemoveUser

Tenant Landlord

Actor Generalization Use Case Generalization

 Login Use Case?
88

BAD: GOOD:

Login
«inc
lude
AddUser »
AddUser
Login
Landlord
SetDevicePrefs Landlord SetDevicePrefs lu de»
«inc
89

Thank You!!
?