Software Engineering Requirements Elicitation Requirements ...
Software Engineering Requirements Elicitation Requirements ...
Software Engineering Requirements Elicitation Requirements ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Technische<br />
Universität<br />
Dresden<br />
<strong>Software</strong> <strong>Engineering</strong><br />
<strong>Requirements</strong> <strong>Elicitation</strong><br />
<strong>Requirements</strong> <strong>Elicitation</strong><br />
ABSTRACT: LEcture_<strong>Software</strong> <strong>Engineering</strong>_05<br />
o This lecture explains the major ideas of<br />
scenario-based requirements eleicitation.<br />
The elemnts scenarios are introduced.<br />
o Scenarios describe an example of system use.<br />
o A use case is an abstraction describing a class<br />
of scenarios.<br />
Dr.-Ing. habil. Karsten Menzel<br />
Privatdozent<br />
TU Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
[1] pages 97-100, 120f, 123<br />
[2]<br />
An Overview of<br />
<strong>Requirements</strong> <strong>Elicitation</strong><br />
LE_SE_0501<br />
8 transperencies<br />
[1] pages 106-119<br />
[3], [4], [5], [6]<br />
<strong>Requirements</strong> <strong>Elicitation</strong><br />
Activities (1)<br />
LE_SE_0503<br />
22 transperencies<br />
<strong>Requirements</strong> <strong>Elicitation</strong><br />
MODULE: LEcture_<strong>Software</strong> <strong>Engineering</strong>_05<br />
[1] pages 106-119<br />
[3], [4], [5], [6]<br />
<strong>Requirements</strong> <strong>Elicitation</strong><br />
Activities (2)<br />
LE_SE_0504<br />
9 transperencies<br />
[1] pages 101-105<br />
<strong>Requirements</strong><br />
<strong>Elicitation</strong> Concepts<br />
LE_SE_0502<br />
8 transperencies<br />
[1]pages 120-124, 126<br />
[2], [7], [8], [9]<br />
Managing <strong>Requirements</strong><br />
<strong>Elicitation</strong><br />
LE_SE_0505<br />
9 transperencies<br />
<strong>Requirements</strong> <strong>Elicitation</strong><br />
LITERATURE for module LE_SE_02<br />
[1] Bernd Bruegge, Allen H. Dutoit: „Object-Oriented <strong>Software</strong> <strong>Engineering</strong>“<br />
Prentice Hall, Upper Saddle River, NJ, 2000.<br />
[2] P. Johnson, “Human Computer Interaction: Psychology, Task Analysis<br />
and <strong>Software</strong> <strong>Engineering</strong>.”<br />
McGraw-Hill Int., London, 1992.<br />
[3] I. Jacobson, M. Christerson, P. Jonsson, & G. Overgaard, “Object-<br />
Oriented <strong>Software</strong> <strong>Engineering</strong>—A Use Case Driven Approach.”<br />
Addison-Wesley, Reading, MA, 1992.<br />
[4] I Jacobson, G. Booch, & J. Rumbaugh,<br />
“The Unified <strong>Software</strong> Development Process.”<br />
Addison-Wesley, Reading, MA, 1999.<br />
[5] R. Wirfs-Brock, B. Wilkerson, & Lauren Wiener,<br />
“Designing Object-Oriented <strong>Software</strong>.”<br />
Prentice Hall, Eaglewood Cliffs, NJ, 1990.<br />
[6] J. M. Carroll (ed.), “Scenario-Based Design: Envisioning Work and<br />
Technology in System Development.”<br />
Wiley, New York. 1995.<br />
[7] J. Nielsen & R. L. Mack (eds.), “Usability Inspection Methods.”<br />
Wiley, New York, 1994.<br />
[8] J. Nielsen, “Usability <strong>Engineering</strong>.” Academic, 1993.<br />
[9] J. Rubin, “Handbook of Usability Testing.”<br />
Wiley, New York, 1994.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
ABSTRACT<br />
An Overview of <strong>Requirements</strong><br />
<strong>Elicitation</strong><br />
o<br />
o<br />
This module provides an overview of<br />
requirements elicitation.<br />
It describes its relationship to other software<br />
development activities.<br />
LE_SE_0501<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
DEFINITIONS<br />
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
PURPOSE & WORK PRODUCTS<br />
o<br />
o<br />
o<br />
A requirement is:<br />
• a feature that the system must have or<br />
• a constraint that it must satisfy to be accepted by the<br />
client.<br />
<strong>Requirements</strong> engineering<br />
• aims at defining the requirements under construction.<br />
<strong>Requirements</strong> engineering activities are:<br />
• <strong>Requirements</strong> <strong>Elicitation</strong>:<br />
• results in specification of the system<br />
that the CLIENT understands<br />
• requires the collaboration of several participants<br />
with different backgrounds (challenging task!).<br />
• Analysis:<br />
results in an analysis model<br />
that the DVELOPERS can unambiguously interpret.<br />
o<br />
o<br />
o<br />
o<br />
<strong>Requirements</strong> elicitation and analysis<br />
• focus only on the user's view of the system<br />
<strong>Requirements</strong> elicitation<br />
• focuses on describing the purpose of the system.<br />
• The client, the developers, and the users<br />
identify a problem area and<br />
define a system that addresses the problem.<br />
The System Specification (Document)<br />
• serves as a contract between the client and the developers.<br />
• supports the communication with the client and users.<br />
• is written in natural language,<br />
• is structured and formalized during analysis<br />
to produce an analysis model.<br />
The analysis model<br />
• supports the communication among developers.<br />
• is usually expressed in a formal or semiformal notation,<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
<strong>Requirements</strong><br />
<strong>Elicitation</strong><br />
Analysis<br />
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
EXAMPLE<br />
system<br />
specification<br />
:Model<br />
analysis model<br />
:Model<br />
o<br />
o<br />
o<br />
o<br />
o<br />
o<br />
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
REQUIREMENTS ELICITATION ACTIVITIES<br />
Identifying ACTORS<br />
• Developers identify the different types of users.<br />
Identifying SCENARIOS<br />
• Developers observe users and<br />
develop a set of detailed scenarios<br />
for typical functionality provided by the future system.<br />
Identifying USE CASES<br />
• Developers derive from the scenarios a set of use cases<br />
that completely represent the future system.<br />
Refining USE CASES<br />
• Developers ensure that the system specification is complete<br />
by detailing each use case<br />
Identifying RELATIONSHIPS among use cases<br />
• Developers<br />
consolidate the use case model by eliminating redundancies.<br />
Identifying nonfunctional requirements.<br />
• Developers, users, and clients<br />
agree on aspects visible to the user<br />
but not directly related to functionality.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
MAIN TYPES OF METHODS for ELICITING INFORMATION<br />
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
KNOWLEDGE ANALYSIS of TASKS<br />
o<br />
Joint Application Design (JAD)<br />
• focuses on building consensus among developers,<br />
users, and clients<br />
• the system specificatio is jointly developed<br />
o<br />
The Knowledge Analysis (KAT)<br />
• is a task analysis method proposed by Johnson [2].<br />
• is an oo-analysis technique by representing<br />
the application domain in terms of objects and actions.<br />
o<br />
o<br />
Knowledge Analysis of Tasks (KAT)<br />
• focuses on eliciting information from users through<br />
observation<br />
Usability testing<br />
• focuses on validating the requirements elicitation<br />
model with the user through a variety of methods<br />
o<br />
Activities are:<br />
• collecting DATA from various sources<br />
(protocol analysis, procedures, textbooks, interviews)<br />
• analyzing DATA<br />
identifying individual elements involved in the task<br />
(objects, actions, procedures, goals, and subgoals)<br />
• constructing a model<br />
of the overall KNOWLEDGE.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
JOINT APPLICATION DESIGN<br />
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
JAD ACTIVITIES and WORK PRODUCTS<br />
Technische<br />
Universität<br />
Dresden<br />
o Joint Application Design (JAD):<br />
• is a requirements elicitation method<br />
• it was developed at IBM at the end of the 1970s.<br />
• the method is very effectife because the elicitation<br />
work is done in one single WORKSHOP session<br />
in which ALL STAKEHOLDERS participate.<br />
• the workshop session results in<br />
the final JAD document,<br />
o The final JAD document represents an agreement<br />
• between users, clients, and developers.<br />
o STAKEHOLDERS are participants:<br />
• with a vital interest in the success of the project,<br />
• can make substantial decisions,<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
o<br />
o<br />
o<br />
o<br />
o<br />
Project definition:<br />
• The JAD facilitator (JAD-F) interviews managers and clients<br />
to determine the objectives and the scope of the project.<br />
• Findings are collected in the Management Definition Guide.<br />
Research:<br />
• The JAD-F interviews present and future users,<br />
gathers domain information, and describes the work flows.<br />
• Results: Session Agenda and Preliminary Specification.<br />
Preparation:<br />
• The JAD-F prepares the session and creates a Working Document.<br />
Session:<br />
• The JAD-F guides the team in creating the system specification.<br />
• A JAD session lasts for 3-5 days.<br />
• The team defines and agrees on the work flow, the data elements,<br />
the screens, and the reports of the system.<br />
The FINAL JAD DOCUMENT:<br />
• is a complete sytem specification agreed on during the session.<br />
• is distributed to the session's participants for review.<br />
• The participants then meet for a 1- to 2-hour meeting<br />
to discuss the reviews and finalize the document.<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
An Overview of <strong>Requirements</strong> <strong>Elicitation</strong><br />
USABILITY TESTING<br />
Technische<br />
Universität<br />
Dresden<br />
o<br />
Usability testing<br />
• tests users’ understanding of the use case model.<br />
• finds problems with the system specification<br />
by letting users explore the system or parts of it.<br />
• is also concerned with user interface details, e.g.<br />
• the look and feel of the user interface,<br />
• the geometrical layout of the screens, and<br />
• the hardware<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts<br />
LE_SE_0502<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts<br />
ABSTRACT<br />
This module describes the main requirements<br />
elicitation concepts, such as:<br />
• Functional requirements,<br />
• Non-functional requirements,<br />
• Levels of description<br />
• Correctness, completeness, consistency,<br />
clarity, and realism<br />
o<br />
o<br />
o<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts<br />
TYPES OF REQUIREMENTS<br />
Functional requirements<br />
• describe the interactions between the system<br />
and its environment independent of its implementation.<br />
Nonfunctional requirements<br />
• describe user-visible aspects of the system<br />
which are not directly related with the functional behavior<br />
• include quantitative constraints<br />
(e.g. response time or accuracy)<br />
Pseudo requirements<br />
• are imposed by (e.g.) the client<br />
• restrict the implementation of the system.<br />
(e.g. implementation language or platform requirements)<br />
Process and documentation requirements<br />
• have usually no direct effect<br />
on the user’s view of the system.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen
o<br />
o<br />
o<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts<br />
USE CASES and DESCRIPTION LEVELS<br />
Work division.<br />
• work processes of the users relevant to the system<br />
are described.<br />
Application-specific system functions.<br />
• functions provided by the system are defined<br />
Work-specific system functions.<br />
• supporting functions of the system are described<br />
(file management functions, grouping functions,<br />
undo functions, etc.)<br />
Dialog.<br />
• interactions between the users and the user<br />
interface of the system are described in this set of<br />
use cases<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts<br />
REQUIREMENTS VALIDATION CRITERIA<br />
<strong>Requirements</strong><br />
• are continuously validated<br />
with the client and the user against the following criteria:<br />
o<br />
o<br />
o<br />
o<br />
o<br />
Is the specification CORRECT<br />
• Does it represent the client's view of the system ?<br />
(i.e., everything in the requirements model accurately represents<br />
an aspect of the system).<br />
Is the specification COMPLETE<br />
• Are all possible scenarios through the system described?<br />
The requirements model represents all aspects of the system;<br />
including exceptional behavior.<br />
Ii the system specification CONSISTENT<br />
• Does the system contradict itself?<br />
Is the system specification UNAMBIGUOUS<br />
• Does it exactly define one system ?<br />
(It is impossible to interpret the specification in different ways).<br />
Is the system REALISTIC<br />
• Can the system be implemented with constraints.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts (4)<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts (5)<br />
Correct—The model describes<br />
the reality of interest to the<br />
client, not another reality<br />
m: Model r: Reality<br />
r2: Reality<br />
Consistent—All concepts in the<br />
model correspond to<br />
phenomena of the same reality<br />
c1: Concept<br />
m: Model r1: Reality r2: Reality<br />
p1:<br />
Phenomenon<br />
Technische<br />
Universität<br />
Dresden<br />
Complete—Every<br />
phenomenon of interest is<br />
described in the model by a<br />
concept<br />
c1: Concept<br />
m: Model r: Reality<br />
c2: Concept<br />
p1:<br />
Phenomenon<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
p2:<br />
Phenomenon<br />
Unambiguous—All concepts in<br />
the model correspond to exactly<br />
one phenomenon<br />
Technische<br />
Universität<br />
Dresden<br />
c1: Concept<br />
c2: Concept<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
p2:<br />
Phenomenon<br />
m: Model r1: Reality r2: Reality<br />
p1:<br />
Phenomenon<br />
p2:<br />
Phenomenon<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts (6)<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts<br />
DESIRABLE PROPERTIES<br />
Realistic—The model describes<br />
a reality that can exist<br />
the Universe<br />
of Realizable Systems<br />
the Universe<br />
of Vaporware<br />
o<br />
VERIFIABLE:<br />
• The specification is verifiable if, once the system is built,<br />
a repeatable test can be designed to demonstrate that<br />
the system fulfills the requirement.<br />
m: Model r1: Reality r2: Reality<br />
o<br />
TRACEABLE:<br />
• A system specification is traceable, if each system<br />
function can be traced to its corresponding set of<br />
requirements.<br />
• Traceability is not a constraint on the content of the<br />
specification, but rather, on its organization.<br />
• Traceability facilitates the development of tests and the<br />
systematic validation of the design against the<br />
requirements.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen
<strong>Requirements</strong> <strong>Elicitation</strong> Concepts<br />
CATEGORIES of ELICITATION ACTIVITIES<br />
Technische<br />
Universität<br />
Dresden<br />
Technische<br />
Universität<br />
Dresden<br />
o In greenfield engineering<br />
• the development starts from scratch,<br />
• no prior system exists,<br />
• the requirements are extracted from users and the client.<br />
• the project is triggered by a user need or<br />
the creation of a new market.<br />
o A reengineering project<br />
• redesigns and reimplementats an existing system<br />
• is triggered by new technology or new information flow.<br />
• extracts the requirements from an existing system.<br />
o<br />
An interface engineering project<br />
• aims on redesigning the user interface of an existing<br />
system.<br />
• The legacy system is left untouched.<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
PART 1:<br />
LE_SE_0503<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
o<br />
o<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
ABSTRACT<br />
<strong>Requirements</strong> elicitation activities map a<br />
problem statement into a system specification.<br />
A system specification is represented as a set<br />
of actors, scenarios, and use cases.<br />
<strong>Requirements</strong> elicitation activities include:<br />
• identifying actors<br />
• identifying scenarios<br />
• identifying use cases<br />
• refining use cases<br />
• identifying relationships among use cases<br />
• identifying participating objects<br />
• identifying nonfunctional requirements<br />
o<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
PURPOSE<br />
<strong>Requirements</strong> elicitation serves both:<br />
• to define the BOUNDARIES of the system and<br />
• to find all the PERSPECTIVES from which the<br />
developers need to consider the system.<br />
NOTE:<br />
• In an existing organizational structure most actors<br />
usually exist before the requirements elicitation is<br />
performed:<br />
• Actors correspond to roles in the organization.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
IDENTIFYING ACTORS<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
IDENTIFYING SCENARIOS<br />
o<br />
o<br />
o<br />
o<br />
Actors represent external entities that interact with the<br />
system; either a human being or an external system.<br />
Questions for identifying actors are:<br />
• Which user groups are supported by the system?<br />
• Which user groups execute the system's main functions?<br />
• Which user groups perform secondary functions?<br />
(e.g. maintenance, or administration)<br />
• Will the system interact with any external hardware or<br />
software system?<br />
Furtermore, one needs to determine the functionality<br />
that is accessible to each actor.<br />
This information can be:<br />
• extracted using scenarios and<br />
• formalized by applying use cases.<br />
o<br />
o<br />
o<br />
SCENARIO:<br />
• “a narrative description of what people do and experience<br />
as they try to make use of computer systems and<br />
applications" [6].<br />
• is a concrete, focused, informal description<br />
of a single feature of the system<br />
from the viewpoint of a single actor.<br />
Traditional representations:<br />
• are centered around the system<br />
as opposed to the work that the system supports.<br />
• They focus on completeness, consistency, & accuracy.<br />
In contrast scenarios are open ended and informal.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
IDENTIFYING SCENARIOS<br />
Questions for identifying scenarios:<br />
o What are the TASKS<br />
that the actor wants the system to perform?<br />
o<br />
o<br />
o<br />
What INFORMATION does the actor access?<br />
• Who creates that data?<br />
• Can it be modified or removed? By whom?<br />
Which EXTERNAL CHANGES does the actor<br />
need to inform the system about?<br />
• How often?<br />
• When?<br />
Which EVENTS does the actor need<br />
to be informed by the system about?<br />
• With what latency?<br />
o<br />
o<br />
o<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
TYPES of SCENARIOS [see also 6]<br />
AS-IS SCENARIOS:<br />
• describe a current situation.<br />
• are validated for correctness and accuracy with the users.<br />
VISIONARY SCENARIOS:<br />
• describe a future system,<br />
• can be discovered as an inexpensive prototype,<br />
• They have two functions:<br />
• They are used as a design representation<br />
by developers and<br />
• They are used as a communication medium<br />
to elicit requirements from users.<br />
EVALUATION SCENARIOS:<br />
• describe user tasks<br />
against which the system is to be evaluated.<br />
TRAINING SCENARIOS:<br />
• are tutorials<br />
used for introducing new users to the system.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
SCENARIOS and USE CASES<br />
A USE CASE<br />
o specifies all possible scenarios<br />
for a given piece of functionality.<br />
(i.e. a scenario is an instance of a use case)<br />
o<br />
o<br />
o<br />
o<br />
is initiated by a specific actor.<br />
may interact with other actors after its initiation<br />
describes a series of related interactions that<br />
result from the initiation of the use case.<br />
represents a complete flow of events through<br />
the system.<br />
o<br />
o<br />
o<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
PURPOSE of USE CASES<br />
The cost of changing the system specification and<br />
modifying functionality increases.<br />
• as the design & implementation of the system starts.<br />
Scenarios and use cases aim at creating requirements<br />
and defining functionality<br />
• which are validated by the user<br />
as early as possible in the development cycle.<br />
Note that many use cases are<br />
• rewritten several times,<br />
• substantially refined, or<br />
• completely dropped.<br />
Most of the exploration work can be done effeciently<br />
by using scenarios and user interface mock-ups.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
IDENTIFYING USE CASES<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
IDENTIFYING RELATIONSHIPS<br />
o<br />
o<br />
o<br />
o<br />
USE SCENARIOS:<br />
• to communicate with users and to validate functionality.<br />
• First, refine a narrow vertical slice (i.e. one scenario)<br />
• to understand the user's preferred style of interaction.<br />
• Next, define a horizontal slice<br />
(i.e. many not-very-detailed scenarios)<br />
• to define the scope of the system.<br />
• Validate with the user.<br />
PRESENT ALTERNATIVES to the user<br />
• as opposed to extracting a single alternative from the user.<br />
DETAIL a BRAOD VERTICAL SLICE:<br />
• when the system’s scope and users’ preferences are clear.<br />
• Validate with the user.<br />
USE MOCK-UPs<br />
• as a visual support only.<br />
• User interface design should occur as a separate task<br />
once the functionality is sufficiently stable.<br />
o<br />
o<br />
o<br />
o<br />
RELATIONSHIPS<br />
• among actors and use cases<br />
enable the developers and users<br />
to reduce the complexity of the model and<br />
to increase its understandability.<br />
COMMUNICATION RELATIONSHIPS<br />
between actors and use cases<br />
• are used to describe the system in layers of functionality.<br />
EXTENDED RELATIONSHIPS<br />
• are used to separate exceptional & common<br />
flows of events.<br />
INCLUDE RELATIONSHIPS<br />
• are used to reduce redundancy among use cases.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
IDENTIFYING INCLUDE and EXTEND RELATIONSHIPS<br />
o<br />
o<br />
o<br />
o<br />
INCLUDE & EXTEND<br />
• are similar constructs [3]<br />
• the direction of the relationship distincts these constructs.<br />
INCLUDE RELATIONSHIP<br />
• the conditions under which the target use case is initiated<br />
are described in the initiating use case<br />
as an event in the flow of events.<br />
EXTEND RELATIONSHIP<br />
• the conditions under which the extension is initiated<br />
are described in the extension<br />
as an entry condition.<br />
How to identify extend and include relationships?<br />
• Use includes<br />
to describe behavior shared across several use cases.<br />
• Use extends<br />
for exceptional, optional, or seldom-occurring behavior.<br />
o<br />
o<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
IDENTIFYING OBJECTS<br />
When collaborating one major obstacle is<br />
• different terminology<br />
used by developers and users<br />
Misunderstandings result from the same terms<br />
• being used in different context and<br />
• with different meanings.<br />
Once use cases have been consolidated:<br />
DEVELOPERS:<br />
• identify the participating objects for each use case,<br />
(corresponding to the main concepts in the application<br />
domain)<br />
• define an object name,<br />
• describe objects unambiguously, and<br />
• collate objects into a glossary.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
o<br />
o<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
GLOSSARY<br />
The GLOSSARY:<br />
• is included in the system specification.<br />
• becomes later a part of the user manual.<br />
Developers keep this glossary up to date<br />
• as the system specification evolves.<br />
BENEFITS of the glossary:<br />
• Consistent definitions are available to developers,<br />
• a single term is used for each concept<br />
(instead of a developer term and a user term)<br />
• each term has a precise and clear official meaning.<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
IDENTIFYING ANALYSIS OBJECTS<br />
o Always use application domain terms!<br />
o Identify TERMS<br />
• that developers or users need to clarify<br />
in order to understand the use case<br />
o Identify NOUNS<br />
• recurring in the use cases (e.g. incident)<br />
o Identify REAL-WORLD ENTITIES<br />
• tracked by the system (e.g. Fieldofficer, Resource)<br />
o Identify REAL-WORLD PROCESSES<br />
• tracked by the system (e.g., EmergencyOperationsPlan)<br />
o Identify USE CASES (e.g. ReportEmergency)<br />
o Identify DATA SOURCES or SINKS (e.g. printer)<br />
o Identify INTERFACE ARTIFACTS (e.g. station)<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
CROSS-CHECKING USE CASES & PARTICIPATING OBJECTS<br />
o Which use cases create(d) this object?<br />
• In which use case(s) are the values of the object<br />
attributes entered into the system)?<br />
• Which actors can access this information?<br />
o Which use cases modify & destroy this object?<br />
• In which use cases is the information from the<br />
system edited or removed?<br />
• Which actor can initiate these use cases?<br />
o Is this object needed?<br />
• Is there at least one use case<br />
depending on this information?<br />
o<br />
o<br />
o<br />
o<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
NONFUNCTIONAL REQUIREMENTS (1)<br />
NONFUNCTIONAL REQUIREMENTS:<br />
• describe user-visible aspects of the system<br />
not directly related to the behavior of the system.<br />
User interface and human factors:<br />
• What kind of interface should the system provide?<br />
• What is the level of expertise of the users?<br />
Documentation:<br />
• What level of document is required?<br />
• Should only user documentation be provided?<br />
• Should there be technical documentation for maintainers?<br />
• Should the development process be documented?<br />
System modifications:<br />
• What is the anticipated scope of future changes?<br />
• Who will perform the changes?<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
NONFUNCTIONAL REQUIREMENTS (2)<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
NONFUNCTIONAL REQUIREMENTS (2)<br />
o<br />
o<br />
o<br />
o<br />
Physical environment:<br />
• Where will the system be deployed?<br />
• Are there external factors (such as weather conditions)<br />
that the system should withstand?<br />
Hardware considerations:<br />
• Are there hardware compatibility requirements?<br />
• Will the system interact with other hardware systems?<br />
Performance characteristics:<br />
• How responsive should the system be?<br />
• How many concurrent users should it support?<br />
• What is a typical or extreme load?<br />
Resource issues:<br />
• What are the constraints on the resources<br />
consumed by the system?<br />
o<br />
o<br />
o<br />
Error handling and extreme conditions:<br />
• How should the system handle exceptions?<br />
• Which exceptions should the system handle?<br />
• What is the worse environment in which the system is<br />
expected to perform?<br />
• Are there safety requirements on the system?<br />
Quality issues:<br />
• How reliable/available/robust should the system be?<br />
• What is the client's involvement in assessing the quality of<br />
the system or the development process?<br />
Security issues:<br />
• Should the system be protected against external<br />
intrusions or against malicious users?<br />
• To what level?<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities (8)<br />
Use case name<br />
ReportEmergency<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities<br />
PART 2: EXAMPLE<br />
LE_SE_0504<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Participating actor<br />
Entry condition<br />
Flow of events<br />
Exit condition<br />
Special<br />
requirements<br />
Technische<br />
Universität<br />
Dresden<br />
Initiated by FieldOfficerCommunicates with Dispatcher<br />
1. The FieldOfficer activates the "Report Emergency" function other<br />
terminal.<br />
2. FRIEND responds by presenting a form to the officer.<br />
3. The FieldOfficer fills the form, by selecting the emergency level,<br />
type, location, and brief description of the situation. The FieldOfficer<br />
also describes possible responses to the emergency situation.<br />
Once the form is completed, the FieldOfficer submits the form, at<br />
which point the Dispatcher is notified.<br />
4. The Dispatcher reviews the submitted information and creates an<br />
incident in the database by invoking the Openlncident use case. The<br />
Dispatcher selects a response and acknowledges the emergency<br />
report.<br />
5. The FieldOfficer receives the acknowledgment and the selected<br />
response<br />
The FieldOfficer's report is acknowledged within 30 seconds. The<br />
selected response arrives no later than 30 seconds after it is sent by the<br />
Dispatcher.<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities (12)<br />
<strong>Requirements</strong> <strong>Elicitation</strong> Activities (13)<br />
<br />
<br />
FieldOfficer<br />
Dispatcher<br />
OpenIncident<br />
FieldOfficer<br />
ConnectionDown<br />
ReportEmergency<br />
ReportEmergency<br />
AllocateResources<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen
<strong>Requirements</strong> <strong>Elicitation</strong> Activities (14)<br />
Technische<br />
Universität<br />
Dresden<br />
<br />
Managing <strong>Requirements</strong> <strong>Elicitation</strong><br />
OpenIncident<br />
<br />
ViewMap<br />
LE_SE_0505<br />
AllocateResources<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
o<br />
o<br />
o<br />
Managing <strong>Requirements</strong> <strong>Elicitation</strong><br />
ABSTRACT<br />
However, use case modeling by itself,<br />
does not constitute requirements elicitation.<br />
<strong>Requirements</strong> still need to be acquired from the<br />
users and must be converged onto an<br />
agreement with the client.<br />
This module revisits methods for eliciting<br />
information from users. It describes how to<br />
negotiate an agreement with the client and how<br />
to evelop the results of requirements elicitation.<br />
o<br />
o<br />
o<br />
Managing <strong>Requirements</strong> <strong>Elicitation</strong><br />
TASK ANALYSIS: HISTORY<br />
Initially, task analysis was not concerned with<br />
requirements or system design.<br />
• It was used to identify how people should be trained.<br />
Task analysis originated in the United States and the<br />
United Kingdom in the 1950s and 1960s [2].<br />
• United States (U.S.A.)<br />
• The military was primarily interested in task analysis<br />
to decrease the cost of training.<br />
• United Kingdom:<br />
• The Department of Trade and Industry developed (unified)<br />
methods to enable people to move across industries.<br />
More recently, task analysis has become important in the<br />
field of Human Computer Interaction (HCI):<br />
• for identifying and describing the user tasks<br />
that a system should support.<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
o<br />
o<br />
o<br />
o<br />
o<br />
Managing <strong>Requirements</strong> <strong>Elicitation</strong><br />
MANAGEMENT ACTIVITIES<br />
Identifying objects and actions:<br />
• Actions associated with objects are identified using similar<br />
techniques as object identification in object-oriented analysis.<br />
Identifying procedures:<br />
• A procedure is a set of actions, a precondition necessary to<br />
triggering the procedure, and a postcondition.<br />
• Actions may be partially ordered.<br />
Identifying goals and sub goals:<br />
• A goal is a state to be achieved for the task to be successful.<br />
• Subgoals are identified by decomposing goals.<br />
Identifying typicality and importance:<br />
• Each identified element is rated according to:<br />
• how frequently it is encountered and<br />
• whether it is necessary for accomplishing a goal.<br />
Constructing a model of the task:<br />
• The information gathered above is generalized<br />
to account for common features across tasks.<br />
o<br />
Managing <strong>Requirements</strong> <strong>Elicitation</strong> (4)<br />
Although task analysis and KAT are not<br />
requirements elicitation methods per se, they<br />
can greatly benefit the requirements elicitation<br />
activity:<br />
• During elicitation, they provide techniques for<br />
eliciting and describing application domain<br />
knowledge.<br />
• When defining the boundaries of a system, task<br />
models assist in determining which parts of the task<br />
should remain manual and which parts should be<br />
automated<br />
• When designing the interface of the system, task<br />
models serve as a source of inspiration for<br />
metaphors understandable by the user [7]<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen
Managing <strong>Requirements</strong> <strong>Elicitation</strong><br />
USABILITY TESTS<br />
Managing <strong>Requirements</strong> <strong>Elicitation</strong><br />
TYPES OF USABILITY TESTS<br />
Technische<br />
Universität<br />
Dresden<br />
o<br />
o<br />
USABILITY TESTS:<br />
• are based on experiments identifying deficiencies<br />
that developers fix iteratively [9].<br />
• are performed based on the classical approach for<br />
conducting a controlled experiment.<br />
Important differences:<br />
• classical experimental methods are designed to<br />
confirm or refute a hypothesis,<br />
• usability tests aim to obtain qualitative information on<br />
• how to fix usability problems and<br />
• how to improve the system.<br />
• Usability tests are performed less rigorously than<br />
classical experiements.<br />
• Nielsen [8] uses the term Discount Usability <strong>Engineering</strong><br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
o<br />
o<br />
o<br />
Scenario test:<br />
• several users are presented with a visionary scenario.<br />
• developers identify<br />
• how quickly users are able to understand the scenario,<br />
• how accurately it represents their model of work, and<br />
• how positively they react to the new system’s description.<br />
Prototype test:<br />
• several users are presented with a piece of software<br />
that practically implements the system.<br />
• A VERTICAL PROTOTYPE:<br />
implements a complete use case through the system<br />
• A HORIZONTAL PROTOTYPE<br />
An interface for most use cases (with less functionality).<br />
Product test:<br />
• similar to the prototype test, except that a functional<br />
version of the system is used in place of the prototype.<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Managing <strong>Requirements</strong> <strong>Elicitation</strong><br />
REQUIRMENTS ANALYSIS DOCUMENT (RAD)<br />
Managing <strong>Requirements</strong> <strong>Elicitation</strong><br />
REQUIRMENTS ANALYSIS DOCUMENT (RAD)<br />
The REQUIRMENTS ANALYSIS DOCUMENT.<br />
o DOCUMENTS the results of :<br />
• the requirements elicitation activity and<br />
• the analysis activity.<br />
o<br />
o<br />
o<br />
completely DESCRIBES the system in terms of:<br />
• functional and nonfunctional requirements<br />
SERVES as a contractual basis between<br />
• the client and the developers.<br />
ADDRESSES the following audience:<br />
• the client, the users,<br />
• the project management,<br />
• the system analysts and the system designers.<br />
The RAD shall contain the following chapters:<br />
o Introduction<br />
• Purpose, Scope, Objectives,<br />
• Definitions, References, Overview<br />
o Current system<br />
o Proposed system<br />
• Overview<br />
• Functional requirements<br />
• Nonfunctional requirements<br />
(User, Documentation, Hardware, Performance,<br />
Error handling, Quality issues, System modifications,<br />
Physical environment, Security issues, Resource issues)<br />
• Pseudo requirements<br />
• System models (Scenarios, Use case model, GUI’s)<br />
o Glossary<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen<br />
Technische<br />
Universität<br />
Dresden<br />
Institut für Bauinformatik<br />
Lehrgebiet Mehrdimensionale Informationssysteme im Bauwesen