View
3
Download
0
Category
Preview:
Citation preview
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
MTAT.03.094
Software Engineering
Lecture 02:
Requirements Engineering
– Part 1
Dietmar Pfahl
email: dietmar.pfahl@ut.ee Fall 2013
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Schedule of Lectures
Week 01: Introduction to SE
Week 02: Requirements Engineering I
Week 03: Requirements Engineering II
Week 04: Analysis
Week 05: Development Infrastructure I
Week 06: Development Infrastructure II
Week 07: Architecture and Design
Week 08: Refactoring
Week 09: Measurement
Week 10: Agile/Lean Methods
Week 11: Verification and Validation I
(incl. SW Quality)
Week 12: Verification and Validation II
Week 13: Process Improvement
Week 14: Course wrap-up, review and
exam preparation
Week 15: no lecture
Week 16: no lecture
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Software Engineering Management
Consistent application of engineering principles and methods to the development of software (intensive) systems
Engineering: Application of systematic (i.e., predictable, repeatable, scalable) procedures - with well-defined goals (e.g., quality, functionality/scope, cost, time) - with well-defined/structured products, processes, and organization Adherence to existing body of knowledge Observation of constraints (standards, time/cost/quality requirements, etc.) Development and use of models
Planning – deciding what is to be done Organizing – making arrangements Staffing – selecting the right people for the job Directing – giving instructions Monitoring – checking on progress Controlling – taking action to remedy hold-ups Innovating – finding solutions when problems emerge Representing – liaising with clients, users, developers and other stakeholders
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Process Taxonomy H. Dieter Rombach, Martin Verlage,
Directions in Software Process Research,
Advances in Computers, Volume 41,
Marvin V. Zelkowitz (Ed.), Pages 1-63,
Academic Press, Boston, MA, 1995.
A Process … … defines Who does What, When
and How to reach a specific goal. In software engineering the goal is
to build a software product or to enhance an existing one
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Rational Unified Process (RUP)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Structure of Lecture 02
• The Nature of Requirements Engineering (RE)
• The Nature of Requirements
• The Process of RE
• Project Planning based on Requirements
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Goal of this Lecture:
To give answers to the following questions …
What is ‘Requirements
Engineering’?
Why is RE important?
Why is RE difficult?
Who is involved in RE?
What are ‘Requirements’?
What types of requirements exist?
What levels of requirements exist?
What process steps are involved in
RE?
How to get started with RE?
How to elicit requirements?
How to represent/document
requirements?
How to use requirements for
project planning?
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Acknowledgements
Textbooks:
• Ian Sommerville: Software Engineering, 9th edition, 2010 (http://www.softwareengineering-9.com/)
• Ivan Marsic: Software Engineering, 2012 (http://www.ece.rutgers.edu/~marsic/books/SE/book-SE_marsic.pdf)
• Sören Lauesen: Software Requirements - Styles and Techniques, Pearson Education, 2002
Lectures on RE:
• Prof. Björn Regnell, Lund University, Sweden
• Prof. Steve Easterbrook, University of Toronto, Canada
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Structure of Lecture 02
• The Nature of Requirements Engineering (RE)
• The Nature of Requirements
• The Process of RE
• Project Planning based on Requirements
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Definition: Requirements Engineering
• RE is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
RE means to ...
... dig up, understand, write down, check, prioritize, select, follow up on ...
... the functions and properties of (software) products
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Definition: Requirements Engineering
Requirements Engineering (RE) is a set of activities concerned with identifying and
communicating 1. the purpose of a software-intensive system, and
2. the contexts in which it will be used.
Hence, RE acts as the bridge between 1. the real world needs of users, customers, and
other constituencies affected by a software system, and
2. the capabilities and opportunities afforded by software-intensive technologies
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Definition: Requirements Engineering
Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software-
intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs
of users, customers, and other constituencies affected by a software
system, and the capabilities and opportunities afforded by software-
intensive technologies
Not a phase or stage!
Communication is as important as the analysis
Quality means fitness-for-purpose. Cannot say anything about quality unless you understand the
purpose
Designers need to know how and where
the system will be used
Requirements are partly about what
is needed…
…and partly about what is possible
Need to identify all the stakeholders - not just the customer and user
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
The Goal of RE
What the Customer
wants
What the Customer
needs
What the Software
does
Application Domain
(User Requirements)
System Domain
(System Requirements)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Why is RE important?
The Role of Requirements (Specification)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Economic Consequences of RE Problems
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
RE is difficult, because …
• It typically involves many stakeholders.
• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms (might be imprecise, ambiguous).
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• New stakeholders may emerge and the business environment change.
• The requirements change during the analysis process.
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example: Imprecise Requirement
• Requirement: ‘A user of the Library Information System (LIS) shall be able to search the recent publications lists for all libraries.’
• Consider the term ‘search … for all’:
• User intention: search for a publication across all recent publications lists in all libraries;
• Developer interpretation: search for a publication in an individual recent publications list. User first chooses library then searches list.
• Imprecise (ambiguous) requirements may be interpreted in different ways by developers and users.
?
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example: Conflicting Requirements
• A performance requirement may indicate that
• a core system must be updated in real time
but
• the size and scope of the system (as defined by other requirements) may preclude this.
Updating such a large system may not be possible in real time.
• Need to apply conflict resolution procedures ( negotiation with stakeholders)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
RE is difficult, because …
… software value-chains are getting more and more complex
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Project setting shapes how RE is done
In-house: intern development for own use
Product development: development for open (mass) market ( marked-driven development)
Time & materials based: compensation based on time/effort and material costs
Components-off-the-shelf: acquisition of generic (shelved) software (components)
Tender: bidding for a contract by a third party
Procurement of customer-specific development
Procurement of COTS development
Contract development: contract-based development with fixed or variable price
Sub-contracting: sub-contracted third-party development with fixed or variable price
Unknown: pre-study required to determine project type
Hybrid: combination of any of the above
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Customer – Supplier Relationship
Who has the power?
Who has the knowledge?
Who takes the biggest risk?
Who takes the biggest profit?
In the short term?
In the long run?
Mutual benefit?
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Stakeholders in SE
External:
• Customers
• Those who pay for the software
• Users
• Those who use the software
Internal:
• Software Developers
• Development (Project) Managers
• Product Managers
• ...
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example of a Real World Situation (Mobile Phones)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Structure of Lecture 02
• The Nature of Requirements Engineering (RE)
• The Nature of Requirements
• The Process of RE
• Project Planning based on Requirements
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Definition: Requirements
• Requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process. (Sommerville, 2010)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Definition: Requirements
According to IEEE standard, a requirement is:
(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
(3) A documented representation of a condition or capability as in (1) or (2).
IEEE = Institute of Electrical and Electronics Engineers (USA)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Types of Requirements
• User versus System Requirements
• Functional versus Non-Functional (Quality) Requirements
• Domain Requirements
• Business Rules or other Information that put constraints on User/System Requirements
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
User vs. System Requirements
User requirements
• Statements in natural language plus diagrams of the services the system provides and its operational constraints.
• Written for customers.
System requirements
• A structured document setting out detailed descriptions of the system’s functions, services and operational constraints.
• Defines what should be implemented and thus may be part of a contract between client and contractor.
Application Domain
System/Product to be developed
Requirements Spec
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Functional vs. Non-Functional Requirements
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
What non-functional (=quality) requirements do you expect from a compiler?
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
SW Product Quality -> ISO 9126
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example – Performance Requirements
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example – Usability Requirements
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
SW Product Quality -> ISO 9126 (cont’d)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
From Goal to Design
• Requirements can be formulated at various levels:
Underlying purpose, business, goals, expectated/intended improvements Context, how user and system-to-be-developed collaborate in order to achieve the goals Externally visible functions and properties of the system Precise description of data, functions, user-interfaces, etc.
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Domain vs. Product Level
Example:
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Domain vs. Product Level
A variant of the previous example
Note: Product and domain boundaries may vary depending on what the system-to-be-developed (product) will contain.
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Structure of Lecture 02
• The Nature of Requirements Engineering (RE)
• The Nature of Requirements
• The Process of RE
• Project Planning based on Requirements
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
RE Activities
• Requirements gathering (a.k.a. “Requirements elicitation”)
• Interacting with stakeholders to discover their requirements: what is to be accomplished, how the system will fit into the needs of the business, and how the system will be used on a day-to-day basis
• Requirements analysis
• Refining, classifying/clustering, structuring, prioritizing, and modifying the gathered requirements
• Requirements specification
• Documenting the (system) requirements in a semiformal or formal manner to ensure clarity, consistency, and completeness
• Requirements validation
• Checking the requirements
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
RE Activities: Iteration & Concurrency
Model
Model
Mo
de
l Mo
de
l
Initial information Scope Constraints
Requirements traced back
to their source
+ Requirements Management
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Where do we start? Identify the problem
what is the objective of the project?
the “vision” of those who are pushing for it?
e.g., “Meeting scheduling is too costly right now”
Scope the problem
given the vision, how much do we tackle?
e.g. “Build a system that schedules meetings”, …or…
e.g. “Build a system that maintains people’s calendars” …or…
Identify solution scenarios
given the problem, what is the appropriate business process for solving it?
e.g. “Anyone who wants to schedule a meeting goes to the secretary, gives details and the secretary handles the rest”, …or…
Scope the solution
Given a business process, what parts should be automated, and how?
e.g. “Computer takes in scheduling request details, outputs a solution” …or…
e.g. “Solution arrived at interactively by secretary and computer” …or…
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example: Home Access Control
Objective:
Design an electronic system for:
• Home access control
• Locks and lighting operation
• Intrusion detection and warning
System
Lock Photosensor Switch
Light bulb
Alarm bell
1
2
3
4
5
X
Y
1
2
3
4
5
X
Y
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Requirements Elicitation
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Difficulties of Elicitation
Thin spread of domain knowledge
The knowledge might be distributed across many sources
It is rarely available in an explicit form (I.e. not written down)
There will be conflicts between knowledge from different sources
Remember the principle of complementarity!
Tacit knowledge (The “say-do” problem)
People find it hard to describe knowledge they regularly use
Limited Observability
The problem owners might be too busy coping with the current system
Presence of an observer may change the problem
E.g. Probe Effect; Hawthorne Effect
Bias
People may not be free to tell you what you need to know
People may not want to tell you what you need to know
The outcome will affect them, so they may try to influence you (hidden agendas)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example
• Loan approval department in a large bank
• The analyst is trying to elicit the rules and procedures for approving a loan
• Why this might be difficult:
• Implicit knowledge:
• There is no document in which the rules for approving loans are written down
• Conflicting information: • Different bank staff have different ideas about what the rules are
• Say-do problem: • The loan approval process described to you by the loan approval officers is quite different from
your observations of what they actually do
• Probe effect: • The loan approval process used by the officers while you are observing is different from the one
they normally use
• Bias: • The loan approval officers fear that your job is to computerize their jobs out of existence, so they
are deliberately emphasizing the need for case-by-case discretion (to convince you it has to be done by a human!)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Elicitation Techniques Traditional techniques
Introspection
Reading existing documents
Analyzing hard data
Interviews
Open-ended
Structured
Surveys / Questionnaires
Meetings
Collaborative techniques
Focus Groups
Brainstorming
JAD/RAD workshops
Prototyping
Participatory Design
Contextual (social) approaches
Ethnographic techniques
Participant Observation
Ethnomethodology
Discourse Analysis
Conversation Analysis
Speech Act Analysis
Sociotechnical Methods
Soft Systems Analysis
Cognitive techniques
Task analysis
Protocol analysis
Knowledge Acquisition Techniques
Card Sorting
Laddering
Repertory Grids
Proximity Scaling Techniques
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Collecting Information
Identify the “problem”/”opportunity”
• Which problem needs to be solved?
• identify problem Boundaries
• Where is the problem?
• understand the Context/Problem Domain
• Whose problem is it?
• identify Stakeholders
• Why does it need solving?
• identify the stakeholders’ Goals
• How does the problem manifest itself?
• collect some Scenarios
• When does it need solving?
• identify Development Constraints
• What might prevent us solving it?
• identify Feasibility and Risk
W6H
The journalist’s technique: What? Where? Who? Why? When? How? (Which?)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Representation Styles
• Natural language (plus supporting tables and graphs)
• Structured natural language / Scenarios
• e.g., use case descriptions, user stories, CRC cards, ...
• Semi-formal notations
• e.g., UML diagrams (use case diagrams, class diagrams, state charts, sequence charts, etc.)
• Formal notations (with formal semantics)
• e.g., abstract model-based (Z, VDM, Larch, B, ...) or algebraic (Clear, OBJ, ACT-ONE, ...)
Not covered in this course
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example NL Requirements
Identifier Priority Requirement
REQ1 5
The system shall keep the door locked at all times, unless commanded otherwise by authorized user. When
the lock is disarmed, a countdown shall be initiated at the end of which the lock shall be automatically
armed (if still disarmed).
REQ2 2 The system shall lock the door when commanded by pressing a dedicated button.
REQ3 5 The system shall, given a valid key code, unlock the door and activate other devices.
REQ4 4
The system should allow mistakes while entering the key code. However, to resist “dictionary attacks,” the
number of allowed failed attempts shall be small, say three, after which the system will block and the alarm
bell shall be sounded.
REQ5 2 The system shall maintain a history log of all attempted accesses for later review.
REQ6 2 The system should allow adding new authorized persons at runtime or removing existing ones.
REQ7 2 The system shall allow configuring the preferences for device activation when the user provides a valid key
code, as well as when a burglary attempt is detected.
REQ8 1
The system should allow searching the history log by specifying one or more of these parameters: the time
frame, the actor role, the door location, or the event type (unlock, lock, power failure, etc.). This function
shall be available over the Web by pointing a browser to a specified URL.
REQ9 1 The system should allow filing inquiries about “suspicious” accesses. This function shall be available over
the Web.
’shall’: mandatory (?)
’should’: optional (?)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example NL Requirements
Identifier Priority Requirement
REQ1 5
The system shall keep the door locked at all times, unless commanded otherwise by authorized user. When
the lock is disarmed, a countdown shall be initiated at the end of which the lock shall be automatically
armed (if still disarmed).
REQ2 2 The system shall lock the door when commanded by pressing a dedicated button.
REQ3 5 The system shall, given a valid key code, unlock the door and activate other devices.
REQ4 4
The system should allow mistakes while entering the key code. However, to resist “dictionary attacks,” the
number of allowed failed attempts shall be small, say three, after which the system will block and the alarm
bell shall be sounded.
REQ5 2 The system shall maintain a history log of all attempted accesses for later review.
REQ6 2 The system should allow adding new authorized persons at runtime or removing existing ones.
REQ7 2 The system shall allow configuring the preferences for device activation when the user provides a valid key
code, as well as when a burglary attempt is detected.
REQ8 1
The system should allow searching the history log by specifying one or more of these parameters: the time
frame, the actor role, the door location, or the event type (unlock, lock, power failure, etc.). This function
shall be available over the Web by pointing a browser to a specified URL.
REQ9 1 The system should allow filing inquiries about “suspicious” accesses. This function shall be available over
the Web.
’Compound’ REQ: How test it?
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
87
User Stories
As a tenant, I can unlock the doors to enter my apartment.
user-role (benefactor)
capability business-value
• Similar to NL requirements, but focus on the user benefits, instead on system characteristics (alone).
• Unfortunately, third element (business-value) is often ommitted
• Preferred tool in agile methods.
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
NL Requirements vs. User Stories
Traditional requirement – “shall” statements:
• “The system shall provide a user configurable interface for all user and system manager functions”
• “The user interface shall be configurable in the areas of:
• Screen layout
• Font
• Background and text color
Corresponding “User Story”:
• “As a system user or system manager, …
• … I want to be able to configure the user interface for screen layout, font, background color, and text color, …
• … so that I can use the system in the most efficient manner”
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Example User Stories
Identifier User Story
ST-1 As an authorized person (tenant or landlord), I can keep the doors locked at all times.
ST-2 As an authorized person (tenant or landlord), I can lock the doors on demand.
ST-3 As an authorized person (tenant or landlord), I want the lock be automatically locked after a defined period of time.
ST-4 As an authorized person (tenant or landlord), I can unlock the doors. (Test: Allow a small number of mistakes, say three.)
ST-5 As a landlord, I can at runtime manage authorized persons.
ST-6 As an authorized person (tenant or landlord), I can view past accesses.
ST-7 As a tenant, I can configure the preferences for activation of various devices.
ST-8 As a tenant, I can file complaint about “suspicious” accesses.
Note: ’Why’ part is missing in the examples above.
REQ1
REQ2
REQ3
REQ4
...
etc.
REQ8
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Use Cases
• For Functional Requirements Analysis and Specification
• A use case is a 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, listing a specific sequence of actions and interactions between the actors and the system
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Types of Actors
• Initiating actor (also called primary actor or “user”): initiates the use case to realize a goal
• Participating actor (also called secondary actor): participates in the use case but does not initiate it:
• 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)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Identifying Actors
• Ask the following questions:
• Who will be a primary user of the system? (primary actor)
• Who will need support from the system to do her daily tasks?
• Who will maintain, administrate, keep the system working? (secondary actor)
• Which hardware devices does the system need?
• With which other systems does the system need to interact with?
• Who or what has an interest in the results that the system produces ?
• Look for:
• the users who directly use the system
• also others who need services from the system
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Finding Use Cases
• For each actor, ask the following questions:
• Which functions does the actor require from the system?
• What does the actor need to do?
• Does the actor need to read, create, destroy, modify, or store some kinds of information in the system?
• Does the actor have to be notified about events in the system?
• Does the actor need to notify the system about something?
• What do those events require in terms of system functionality?
• Could the actor’s daily work be simplified or made more efficient through new functions provided by the system?
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Deriving Use Cases from System Requirements
REQ1: Keep door locked and auto-lock REQ2: Lock when “LOCK” pressed REQ3: Unlock when valid key provided REQ4: Allow mistakes but prevent dictionary attacks REQ5: Maintain a history log REQ6: Adding/removing users at runtime REQ7: Configuring the device activation preferences REQ8: Inspecting the access history REQ9: Filing inquiries
( Actors are often given, if working from user stories instead of ‘shall/should’-statements.)
1
2
3
4
5
X
Y
1
2
3
4
5
X
Y
Actor Actor’s Goal (what the actor intends to accomplish) Use Case Name
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)
Landlord To create a new user account and allow access to home. AddUser (UC-3)
Landlord To retire an existing user account and disable access. RemoveUser (UC-4)
Tenant To find out who accessed the home in a given interval of time and potentially file complaints.
InspectAccessHistory (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 identified]
To auto-lock the door if it is left unlocked for a given interval of time.
AutoLock (UC-2)
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Use Case Diagram: Device Control UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login
«participate»
«initiate + participate»
«participate»
«participate»
«participate»
«participate»
First tier use cases Second tier use casessystem
boundary
communication
«include»
use case
«initiate»
«initiate»
Timer
LightSwitch
LockDevice
«initiate
»Tenant
Landlord
actor
«initiate»
UC1: Unlock
UC2: Lock
UC7: AuthenticateUser
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Use Case Diagrams and Descriptions
Use Case Description:
Name of Use Case
Actors associated with Use Case
Pre-conditions
Post-conditions
Normal Flow of Events (Basic Scenario)
Alternative Flow of Events (Alternative Scenarios)
…
Use-Case Descriptions
...
Use Case Model
Actors
Use Cases
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Schema for Detailed Use Cases Use Case UC-#: Name / Identifier [verb phrase]
Related Requirements: List of the requirements that are addressed by this use case
Initiating Actor: Actor who initiates interaction with the system to accomplish a goal
Actor’s Goal: Informal description of the initiating actor’s goal
Participating Actors: Actors that will help achieve the goal or need to know about the outcome
Preconditions: What is assumed about the state of the system before the interaction starts
Postconditions: What are the results after the goal is achieved or abandoned; i.e., what must be true about the system at the time the execution of this use case is completed
Flow of Events for Main Success Scenario:
1. The initiating actor delivers an action or stimulus to the system (the arrow indicates the direction of interaction, to- or from the system)
2. The system’s reaction or response to the stimulus; the system can also send a message to a participating actor, if any
3. …
Flow of Events for Extensions (Alternate Scenarios): What could go wrong? List the exceptions to the routine and describe how they are handled
1a. For example, actor enters invalid data
2a. For example, power outage, network failure, or requested data unavailable
…
The arrows on the left indicate the direction of interaction: Actor’s action; System’s reaction
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Use Case 1: Unlock
Use Case UC-1: Unlock
Related Requirem’ts:
REQ1, REQ3, REQ4, and REQ5
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To disarm the lock and enter, and get space lighted up automatically.
Participating Actors: LockDevice, LightSwitch, Timer
Preconditions: • The set of valid keys stored in the system database is non-empty.
• The system displays the menu of available functions; at the door keypad the menu choices are “Lock” and “Unlock.”
Postconditions: The auto-lock timer has started countdown from autoLockInterval.
Flow of Events for Main Success Scenario: 1. Tenant/Landlord arrives at the door and selects the menu item “Unlock” 2. include::AuthenticateUser (UC-7)
3. System (a) signals to the Tenant/Landlord the lock status, e.g., “disarmed,” (b) signals to LockDevice to disarm the lock, and (c) signals to LightSwitch to turn the light on
4. System signals to the Timer to start the auto-lock timer countdown
5. Tenant/Landlord opens the door, enters the home [and shuts the door and locks]
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Subroutine «include» Use Case Use Case UC-7: AuthenticateUser (sub-use case)
Related Requirements:
REQ3, REQ4
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To be positively identified by the system (at the door interface).
Participating Actors:
AlarmBell, Police
Preconditions: • The set of valid keys stored in the system database is non-empty.
• The counter of authentication attempts equals zero.
Postconditions: None worth mentioning.
Flow of Events for Main Success Scenario: 1. System prompts the actor for identification, e.g., alphanumeric key
2. Tenant/Landlord supplies a valid identification key
3. System (a) verifies that the key is valid, and (b) signals to the actor the key validity
Flow of Events for Extensions (Alternate Scenarios):
2a. Tenant/Landlord enters an invalid identification key
1. System (a) detects error, (b) marks a failed attempt, and (c) signals to the actor
1a. System (a) detects that the count of failed attempts exceeds the maximum allowed number, (b) signals to sound AlarmBell, and (c) notifies the Police actor of a possible break-in
2. Tenant/Landlord supplies a valid identification key
3. Same as in Step 3 above
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Structure of Lecture 02
• The Nature of Requirements Engineering (RE)
• The Nature of Requirements
• The Process of RE
• Project Planning based on Requirements
• Will be continued next week
MTAT.03.094 / Lecture 02 / © Dietmar Pfahl 2013
Next Lecture
• Date/Time:
• Friday, 20-Sep, 10:15-12:00
• Topic:
• Requirements Engineering II
• For you to do:
• Have a look at (some of) the recommended literature
• Form project teams and familiarise with your team
members
• MOST IMPORTANTLY: Get started with lab task 1!
Recommended