Requirements Elicitation

1
Requirements Elicitation

• Lecture 05
• Software Engineering and
• Project Management
• Instructed by Steven Choy on Oct 23, 2006

2
Where are we NOW?
Requirement Elicitation
Maintenance
Requirement Analysis
System Design
Object Design
Implementation (Coding)
Testing
Deployment
- not listed in textbook
3
What we will discuss today?

• The Requirement Process
• Requirement Elicitation (Chapter 4)
• Gather requirement from our users
• Requirement Analysis (Chapter 5)
• Analyze the requirement and build a model for the
  potential system
• (We will discuss it next lecture)

4
The Importance of Requirement Process

• The success of a software project depends largely
  on defining requirement.
• The requirement process should be intuitive for
  both developers and non-technical user/client.
• Requirement Elicitation Requirement Analysis

5
Software Development Activities
Requirement Elicitation
Requirement Analysis
System Design
Object Design
Implementation (Coding)
public class
Object/ Dynamic Model in application domain
Dynamic Model in solution domain
Use Case Model
Source Code
Sub-system
6
What does requirement elicitation consume and
produce?
Problem statement
Requirements elicitation
Nonfunctional requirements
Functional requirements
Analysis
7
More requirement concepts

• Completeness no scenarios are omitted
• Consistent no contradictory requirements
• Unambiguous the requirement specification cannot
  be interpreted in two mutually exclusive ways
• Correctness accurately reflects the clients
  requirements

8
More requirement concepts

• Realistic the system can be implemented within
  constraints
• Verifiable repeatable tests can be designed to
  demonstrate that the system fulfills the
  requirements
• Traceable if each requirement can be traced to
  the appropriate functions the system provides and
  vice versa

9
3 categories of requirement process

• Greenfield engineering the development start
  from scratch
• Reengineering based on existing system with the
  intention to replace it
• Interface engineering redesign the user
  interface of the existing system

10
Requirement Elicitation

• A process among users, clients and developers for
  defining the new system
• Elicit means to bring out or to draw out
• Requirement elicitation tries to
• bring out what the user already knows about the
  potential system (thats comparatively easy)
• draw out what the user doesnt know or think of
  about the system

11
What Youre trying to identify

• What system you are going to achieve
• Who will use the system? Who will operate the
  system?
• What are the constraints of the system?
• Whats the system environment?

12
How to Identify?

• Interview / Meeting
• Survey / Questionnaire
• Observation
• Review internal document / business plan
• Review software
• Domain Analysis
• Prototypes
• Weblog

13
Types of Requirement

• Functional Requirement
• What the features/functions it should support
• Describe the interaction between the user and the
  system without concerning the implementation
• Non-functional Requirement
• Refers to those requirements that are not
  directly related to the features of the system
• Some examples are
• Usability
• Reliability
• Performance
• Supportability

14
A Collaborative Process

• Requirement elicitation is a collaborative
  process that requires several groups to involve
• Users domain experts are more specialized in
  their domain and have a better idea of what the
  system behaves, but they are not the expert of
  software development
• Developers are technically competent to build
  software system, but they are not specialize in
  the user environment

15
Common Problems in Requirement Process

• Developers and Users are from different worlds.
• They speak different languages and express
  requirement in different view points.
• Users do not understand
• The technical jargon
• Why developers are always talking about jargon.
• Developers do not understand
• The user environment and business processes
• Why users know so little about technical jargon.

16
Use case model is designed to bridge the gap
between developers and users
17
Requirement Elicitation Activities

• Requirement elicitation involves several
  activities
• Define the initial problem statement
• Identifying functional requirements
• Identifying non-functional requirements
• Identifying actors
• Identifying scenarios
• Identifying use cases
• Refining use cases
• Identifying relationships among use cases

18
Problem Statement

• The problem statement, comes up by project
  manager client, describes the problem that the
  system addresses
• A common problem statement describes
• The current situation
• The functionalities supported
• The target environment the system would run on
• The deliverables expected by the client
• The acceptance criteria

19
Problem Statement Layout

• The Problem
• Whats the current situation?
• Whats the problem?
• How does the new system address the problem?
• Objectives
• Describe the objectives of the system
• Functional Requirements
• Describe the interaction between user and system
• Non-functional Requirements
• Target Environment

20
ARENA The Problem

• Many multi-player computer games include support
  for virtual communities
• Players can receive news about game upgrades, new
  game maps/characters
• Players can announce and organize matches
• Currently, each game company develops such
  virtual community support in each individual game
• Each company uses a different infrastructure,
  different concepts and provides different level
  of support
• This redundancy and inconsistency results in many
  disadvantages
• Learning curve for players, high maintenance cost
  for game companies
• Inconvenience for advertiser to sell
  advertisement
• No opportunity for cross-fertilization among
  different communities

Refer to Fig. 4-17 of textbook for full
description
21
ARENA Objectives

• The objectives of the project are to
• Provide an infrastructure for registering new
  games/players, organizing tournaments and keeping
  track of players scores
• Provide a framework for league owner to customize
  the number of matches
• Provide a framework for game developers for
  developing new games
• Provide an infrastructure for advertiser

Refer to Fig. 4-17 of textbook for full
description
22
ARENA Functional Requirement

• ARENA supports five types of users
• Operator define new games, tournament styles
  and manage users
• League owners define a new league, announce new
  tournament within a league, and declare winner
• Players register, apply for a league, play
  matches that are assigned to the player
• Spectators monitor any match in progress and
  check scores and statistics of past matches
• Advertiser upload advertisement, select
  advertisement scheme, check balance due and
  cancel advertisement

Refer to Fig. 4-17 of textbook for full
description
23
ARENA Non-functional Requirement

• Low operating cost
• Extensibility
• Scalability
• support kick-off of many parallel tournaments,
  each involving up to 64 players and several
  hundreds of simultaneous spectators
• Low-bandwidth network
• Players should be able to play matches viva 56k
  modem

Refer to Fig. 4-17 of textbook for full
description
24
ARENA Target Environment

• All users should be able to access any arena with
  a web browser supporting cookies, Javascript and
  Java applets.
• The system should be run on any Unix operating
  system (e.g. Linux, Mac OS X, Solaris)

Refer to Fig. 4-17 of textbook for full
description
25
Identifying Actor

• Recap Actors are external entities of the system
• Questions that helps you identify the potential
  actor
• Who are going to rely on the system to perform
  their work?
• Who is going to maintain and manage the system?
• What external system will the system interact
  with?

26
Identifying Scenarios

• Scenario is a concrete, focused, informal
  description of a single feature of the system
  from the viewpoint of a single actor
• Scenario is not use case. Scenario is just an
  instance of use case
• Scenario aids understanding of business event and
  communication between users

27
Identifying Scenarios

• When you need to develop a new system from
  scratch
• Interview with the users to learn about how they
  perform their work without the system
• Questions that help
• What are the tasks that the actor wants to
  perform?
• What information does the actor access? Who
  creates that data? Can it be modified?
• Which external changes does the actor need to
  inform the system?
• Which events does the system need to inform the
  actor about? Within what timeframe?
• When you have an old system to reference
• Examine the existing system
• Talk to the user and see how they use the
  existing system

28
Buy iPod Nano Scenario

• Scenario name BuyiPodNano
• Participating actors PeterCustomer
• Flow of events 1. Peter browses through product
  catalog and finds an iPod Nano.
• 2. He then adds the iPod into the shopping
  cart and proceeds to payment.
• 3. The system asks for Peters credit card
  shipping information.
• 4. Peter follows the instructions and type in
  the corresponding information.
• 5. The system checks the authorization on the
  credit card and confirms the sales,
  followed by a confirmation e-mail.

29
ARENA Identify Scenario

• Scenario name organizeChessTournament
• Participating actors aliceOperator,
  joeLeagueOwner, billSpectator, maryPlayer
• instances
• Flow of events 1. Joe is a chess fan and
  volunteers to organize a tournament.
• 2. Alice registers Joe in the system as a
  league owner.
• 3. Joe defines a beginners league, in which
  any players can be joined. He
• also define
  the league to follow the knockout tournament
  style.
• 4. Joe schedules the first tournament in the
  league for 16 players.
• 5. Joe announces the tournament via web forum
  and e-mail.
• 6. Bill and Mary receive the e-mail
  notification.
• 7. Mary registers the game and 19 others apply
  too.
• 8. Joe schedules 16 players, rejecting 4 that
  apply the tournament. Each
• player got an electronic token to join
  the match.
• 9. Mary plays her first match and wins. She
  advances in the tournament.
• 10. Bill cant join the game but decides to
  watch Marys next match. He select the
  match and see the sequence of moves of each
  players. He also sees an advertisement
  banner at the bottom of his browser.
• 11. The tournament ends. The winner is
  declared and his league record is
  credited with all the points associated with the
  tournament.
• 12. Joe can choose to schedule more
  tournaments in the league.

30
Identifying Use Cases

• Generalization of scenarios
• Example BuyIpodNano can be generalized into
  BuyProduct use case
• Look for the verb phrase in the functional
  requirement will help you find out the use case
• Guideline on writing use case (Fig. 4-8)
• The name of a use case should be a verb phrase
  denoting what the actor is trying to accomplish
• Actors should be named with noun phrases
• Use case steps in the flow of events should be
  phrased in the active voice
• A use case does not need to describe the user
  interface

31
ARENA High-level Use Case
Fig. 4-21 of textbook
32
BuyProduct Use Case

• Use case name BuyProduct
• Participating actors Initiated by Customer
• Flow of events 1. The Customer browses through
  product catalog and select items into shopping
  cart.
• 2. The Customer performs a Checkout on the
  shopping cart.
• 3. The system responds with a blank form,
  requesting for customers shipping information.
• 4. The Customer fills the form with his/her
  address and proceeds.
• 5. The system responds with the full pricing
  information (including shipping cost) and a
  form for credit card information.
• 6. The customer fills in the credit card
  information and confirms the payment.
• 7. The system authorizes the payment.
• 8. The system presents an
  acknowledge and sends a confirmation to the
  customers e-mail address.
• Entry condition The Customer is logged into the
  online web store
• Exit condition The Customer has received an
  acknowledgement and confirmation email
• Quality The Customer is acknowledged within 10
  seconds.
• requirements

33
ARENA Identifying Use Case

• Use case name OrganizeTournament
• Participating actors Initiated by LeagueOwner
• Communicates with Advertiser, Player and
  Spectator
• Flow of events 1. The LeagueOwner creates a
  tournament, solicits sponsorships from
  advertisers, and announces the
  Tournament (include use case
  AnnounceTournament).
• 2. The Players apply for the Tournament
  (include use case ApplyForTournament)
• 3. The LeagueOwner processes the Player
  applications and assigns them to matches
  (include use case ProcessApplications).
• 4. The LeagueOwner kicks off the Tournament
  (include use case KickoffTournament)
• 5. The Players compete in the matches as
  scheduled and Spectators view the matches
  (include use case PlayMatch)
• 6. The LeagueOwner declares the winner and
  archives the Tournament (include use case
  ArchiveTournament)
• Entry condition The LeagueOwner is logged into
  ARENA
• Exit condition The LeagueOwner archived a new
  tournament in the ARENA and the winner has
  accumulated new points in the league OR
• The LeagueOwner cancelled the tournament and
  the players standing in the league is
  unchanged.

34
Refining Use Case

• With the high-level use case, you continue to
  refine them by providing details, including
• The elements that are manipulated by the system
• The low-level sequence of interactions between
  the actor and the system
• Exception handling as seen by actor
• Factoring out common use cases

35
Example Refined Use Case
36
ARENA Detailed Use Case
37

• Acknowledgement
• Part of the slides
• were originally authored
• by Simon Ng.