Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.
-
Upload
misael-burnison -
Category
Documents
-
view
214 -
download
0
Transcript of Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.
![Page 1: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/1.jpg)
Requirements ElicitationRequirements ElicitationLabs DiscussionLabs Discussion
p2p2T120B029T120B029
20020044 pavasario sem. pavasario sem.
![Page 2: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/2.jpg)
2
Agenda
• Requirements Elicitation– Introduction to concepts– Activities– Identifying actors, scenarios, and use
cases
• Project– Concept/Problem Definition Discussion
T120B029
![Page 3: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/3.jpg)
3
Software Development Activities
Application
Domain Objects
SubSystems
class...class...class...
Implementation
Domain Objects
SourceCode
Test Cases
?
Expressed in Terms Of
Structured By
Implemented
ByRealized By Verified By
SystemDesign
ObjectDesign
Implemen-tation
Testing
class....?
RequirementsElicitation
Use CaseModel
RequirementsAnalysis
T120B029
![Page 4: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/4.jpg)
4
Types of Projects• Greenfield Engineering
– Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client
• Re-engineering– Re-design and/or re-implementation of an existing
system using newer technology
• Interface Engineering– Provide the services of an existing system in a new
environment
T120B029
![Page 5: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/5.jpg)
5
Requirements Elicitation
• Challenging activity• Requires collaboration of people with
different backgrounds– User has application domain knowledge– Developer has implementation domain
knowledge
• Define the system– Easy to define (and then solve) the wrong
problem
T120B029
![Page 6: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/6.jpg)
6
T120B029
![Page 7: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/7.jpg)
7
Defining the System Boundary:
What do you see?
T120B029
![Page 8: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/8.jpg)
8
System Identification• Development of a system is not
just done by taking a snapshot of a scene (domain)
• Definition of the system boundary • What is inside, what is outside?
• How can we identify the purpose of a system?
T120B029
![Page 9: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/9.jpg)
9
Requirements Process
• Requirements Elicitation– Definition of the system in terms
understood by the customer
• Analysis– Technical specification of the system
in terms understood by the developer.
T120B029
![Page 10: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/10.jpg)
10
Products of Requirements Process
RequirementsElicitation
analysis model:Model
systemspecification
:Model
Analysis
T120B029
![Page 11: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/11.jpg)
11
System Specification vs Requirements Analysis
Model
• Both focus on the requirements from the user’s view of the system.
• System specification uses natural language (derived from problem statement)
• Requirements analysis model uses formal or semi-formal notation (e.g., UML)
T120B029
![Page 12: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/12.jpg)
12
Types of Requirements
• Functional requirements: Describe the interactions between the system and its environment independent from implementation– Internet users can browse Classics
catalog and place orders.
T120B029
![Page 13: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/13.jpg)
13
Types of Requirements
• Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. – The only form of payment
accepted is credit cards.– All orders are filled and shipped
from the corporate office.
T120B029
![Page 14: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/14.jpg)
14
Types of Requirements
• Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate– The OPFS systems will be placed in all
Classics Inc. retail stores. – This system will also include a Home
Shopping e-commerce system to enable customers to order Classics Inc. products from their homes or work.
T120B029
![Page 15: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/15.jpg)
15
Requirements Elicitation Activities
• Identify actors• Identify scenarios• Identify use cases• Identify relationships among use cases• Refine use cases• Identify nonfunctional requirements• Identify participating objects
T120B029
![Page 16: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/16.jpg)
16
Actors
• What’s an ACTOR?• Actors for an order processing and
fulfillment system ?• How do we identify them?• How does the choice of actors help us to
define the system boundary?• How does the system boundary help us
to identify the actors?
T120B029
![Page 17: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/17.jpg)
17
ToolsBridging the gap between user and
developer …– Scenario:
• Example of the use of the system in terms of a series of interactions between the user and the system
• Concrete / Real / Phenomenon
– Use case: • Abstraction that describes a class of
scenarios• Concept
T120B029
![Page 18: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/18.jpg)
18
Scenarios• “A narrative description of what people do and
experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995]
• A concrete, focused, informal description of a single feature of the system used by a single actor.
• Scenarios can have many different uses during the software lifecycle
T120B029
![Page 19: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/19.jpg)
19
Types of Scenarios• As-is scenario
– Used in describing a current situation. Usually used during re-engineering. The user describes the system.
• Visionary scenario– Used to describe a future system. Usually
described in greenfield engineering or reengineering.
– Can often not be done by the user or developer alone
T120B029
![Page 20: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/20.jpg)
20
Types of Scenarios
• Evaluation scenario– User tasks against which the system
is to be evaluated
• Training scenario– Step by step instructions designed to
guide a novice user through a system
T120B029
![Page 21: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/21.jpg)
21
How do we find scenarios?
• Don’t expect the client to be verbal if the system does not exist (greenfield engineering)
• Don’t wait for information even if the system exists
• Engage in a dialectic approach (evolutionary, incremental)– You help the client to formulate the requirements– The client helps you to understand the requirements– The requirements evolve while the scenarios are
being developed
T120B029
![Page 22: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/22.jpg)
22
Heuristics for finding Scenarios
• Ask yourself or the client the following questions:– What are the primary tasks that the system needs to
perform?– What data will the actor create, store, change, remove or
add in the system?– What external changes does the system need to know
about?– What changes or events will the actor of the system need
to be informed about?
T120B029
![Page 23: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/23.jpg)
23
Heuristics for finding Scenarios
• Insist on task observation if the system already exists (interface engineering or reengineering)– Ask to speak to the end user, not just
to the software contractor– Expect resistance and try to
overcome it
T120B029
![Page 24: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/24.jpg)
24
Example: Accident Management System
• What needs to be done to report a “Cat in a Tree” incident?
• What do you need to do if a person reports “Warehouse on Fire?”
• Who is involved in reporting an incident?• What do you need to do if the “Cat in the
Tree” turns into a “Grandma has fallen from the Ladder”?
• Can the system cope with a simultaneous incident report “Warehouse on Fire?”
T120B029
![Page 25: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/25.jpg)
25
Scenario Example: Warehouse on Fire
• Bob is driving down main street in his patrol car and notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from their car.
• Alice reports the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, she requests several paramedic units on the scene given that area appear to be relatively busy. She confirms her input and waits for an acknowledgment.
T120B029
![Page 26: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/26.jpg)
26
Scenario Example: Warehouse on Fire
(continued)
• John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice.
• Alice receives the acknowledgment and the ETA.
T120B029
![Page 27: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/27.jpg)
27
Observations about Warehouse on Fire
Scenario• Concrete scenario
– Describes a single instance of reporting a fire incident.
– Does not describe all possible situations in which a fire can be reported.
• Participating actors– Bob, Alice and John
T120B029
![Page 28: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/28.jpg)
28
Next goal, after the scenarios are formulated:
• Find a use case in the scenario that specifies all possible instances of how to report a fire– Example: “Report Emergency “ in the first paragraph of the
scenario is a candidate for a use case
• Describe this use case in more detail – Describe the entry condition – Describe the flow of events – Describe the exit condition – Describe exceptions– Describe special requirements (constraints, nonfunctional
requirements)
T120B029
![Page 29: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/29.jpg)
29
Example of steps in formulating a use case
• First name the use case– Use case name: ReportEmergency– Then find the actors– Generalize the concrete names (“Bob”) to
participating actors (“Field officer”)– Participating Actors:
• Field Officer (Bob and Alice in the Scenario)• Dispatcher (John in the Scenario)• ?
• Then concentrate on the flow of events– Use informal natural language
T120B029
![Page 30: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/30.jpg)
30
Example of steps in formulating a use case
• Formulate the Flow of Events :– The FieldOfficer activates the “Report Emergency” function
on her terminal. FRIEND responds by presenting a form to the officer.
– The FieldOfficer fills the form, ... The FieldOfficer also describes possible responses to the emergency situation. Once the form is completed, the FieldOfficer submits the form, …
– The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. The Dispatcher …
– The FieldOfficer receives the acknowledgment and the selected response.
T120B029
![Page 31: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/31.jpg)
31
Example of steps in formulating a use case
• Write down the exceptions:– The FieldOfficer is notified immediately if the connection
between her terminal and the central is lost.– The Dispatcher is notified immediately if the connection
between any logged in FieldOfficer and the central is lost.
• Identify and write down any special requirements:– The FieldOfficer’s report is acknowledged within 30
seconds. – The selected response arrives no later than 30 seconds
after it is sent by the Dispatcher.
T120B029
![Page 32: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/32.jpg)
32
How to Specify a Use Case (Summary)
• Name of Use Case• Actors
– Description of actors involved in use case• Entry condition
– Use a syntactic phrase such as “This use case starts when…”
• Flow of Events – Free form, informal natural language
• Exit condition – Start with “This use cases terminates when…”
• Exceptions – Describe what happens if things go wrong
• Special Requirements – List nonfunctional requirements and constraints
T120B029
![Page 33: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/33.jpg)
33
Use Case Model for Incident Management
ReportEmergency
FieldOfficer DispatcherOpenIncident
AllocateResources
T120B029
![Page 34: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/34.jpg)
34
Why use cases work• Utterly comprehensible by the user
– Use cases model a system from the users’ point of view (functional requirements)
• Define every possible event flow through the system• Description of interaction between objects
• Great tools to manage a project. Use cases can form basis for whole development process
– User manual– System design and object design– Implementation– Test specification– Client acceptance test
• An excellent basis for incremental & iterative development
T120B029
![Page 35: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/35.jpg)
35
Concept/Problem Definition “Meeting”
T120B029
![Page 36: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/36.jpg)
36
Agenda• List actors• Develop a list of scenarios• Detail some of the scenarios• Develop a list of use cases• Associate the actors and use cases
T120B029
![Page 37: Requirements Elicitation Labs Discussion p2 T120B029 2004 pavasario sem.](https://reader036.fdocuments.net/reader036/viewer/2022062712/56649c925503460f9494d8f5/html5/thumbnails/37.jpg)
37
Project Work• Team activities
– Get to know each others strengths– Set a weekly meeting time– Discuss communication– Work on use case diagram and
documentation
T120B029