• View
• Edit
• History
• Print

Requirements Elicitation

A Software Engineering Lecture by Steven Choy

Lecture Overview: Requirements engineering is the foundation of all other software engineering activities. If we don't have a clear understanding of a client's requirements, we could develop a system on time and within budget, but the system does not possess the features the client needs. A small mistake made in the requirements activity is more costly than a mistake in other software engineering activities.

In this lecture, we will study the first part of requirement engineering, namely requirements elicitation. Requirements elicitation is about bringing out the requirements that originally reside in people's minds.

Reading: Chapter 4 of the textbook Requirements Elicitation

What you will learn

• The Requirement Process
• Requirement Elicitation (this lecture; Textbook Chapter 4)
  • Gather requirement from our users
• Requirement Analysis (next lecture; Textbook Chapter 5)
  • Analyze the requirement and build a model for the potential system

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

Where are we now?

What does requirement elicitation consume and produce?

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 client's requirements
• 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

Three 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

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 (that's comparatively easy)
  • draw out what the user doesn't know or think of about the system

What You're 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?
• What's the system environment?

How to Identify?

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

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

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

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.

Use case model is designed to bridge the gap between developers and users

Requirement Elicitation 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

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

Problem Statement Layout

• The Problem
  • What's the current situation?
  • What's 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

Examples

• 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

• 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

• 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

• 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 via 56k modem

• 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)

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?

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
• 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

Examples

Buy "iPod Nano" Scenario

ARENA: Identify Scenario

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

Examples

ARENA: High-level Use Case

BuyProduct Use Case

ARENA: Use Case

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

More examples of Use Case

Extra Resources for Probing Further

Thanks for Reading

If you would rather like to have this lecture note in printed format, please click the print action link in the top right corner.

If you find any problem in this lecture note, please feel free to tell Steven by steven@findaway.hk