Chapter Nine

Requirements Elicitation
 Introduction
 Unified process may be presented as a sequence of:
o Early design phase, which include requirements elicitation
(inception) and conceptual design (elaboration).
o building (construction) phase, which includes detailed design,
simulation and prototyping, as well as implementation and testing,
o Deployment (transition) of the achieved solution.
 The development of a system is not just done by taking a snapshot of
a scene (domain)
Cont..
 Two questions need to be answered:
o How can we identify the purpose of a system?
o Crucial is the definition of the system boundary: What is inside,
what is outside the system?
 These two questions are answered in the requirements
process(elicitation and analysis)
 The requirements process consists of two activities:
o Requirements Elicitation:
 Definition of the system in terms understood by the
customer (“Problem Description”) (“Requirements
specification”)
o Requirements Analysis:
 Technical specification of the system in terms understood by
the developer (“Problem Specification”) (Technical
specification, “Analysis model”)
Requirements Process

Problem Statement

Requirements
Elicitation Use Case
Diagrams

Non-functional Req. Functional Model

Sequence
Diagrams
Analysis

Class State
Diagrams Analysis Object Model Dynamic Model Diagrams

System Activity
Design Diagrams
Cont..
 Requires collaboration of people with different backgrounds
 Include all activities involved in discovering the requirements of a
system
 System developers and engineers work in close relationship with
customer and end-users to describe the problem statement and to
o Find out more about the problem to be solved
o To describe the functionality of the system
o Understand the application domain (“speak its language”)
o Hardware constraints, Deliverables expected by the client and
Delivery dates
o A set of acceptance criteria
 Cont..
 Not just a simple process about fishing for requirements, but a highly
complex process: B/C
o Customer rarely have a clear picture of their requirements
o Different people have conflicting requirements
 Bridging the gap between user and developer:
o Scenarios: Example of the use of the system in terms of a series of
interactions with between the user and the system
o Use cases: Abstraction that describes a class of scenarios
 During elicitation:
o Requirements, borders and external behavior of the system are defined
and
o Criteria of consumer satisfaction are set.
 Use cases are system boundaries identifying what the system should do.
o They capture subsystem functionality as seen from the point of view of
end user or domain expert and
o help to understand how the system should work.
Cont..
Software Lifecycle Activities
Requirements System Detailed Implemen-
Analysis Testing
Elicitation Design Design tation

Implemented by
Expressed in Structured Realized by
terms of Verified
by
By
class...
class... ?
class... class....?
Use Case Application Solution
Sub- Source Test
Model Domain Domain
systems Code Cases
Objects Objects
 Requirements elicitation concepts
 The idea of requirement elicitation is defining of the system in terms
understood by the customer (“Requirements specification”) and
identifying requirement validation criteria's.
 Requirement types:
o Functional requirements
 Describe interactions between the system and its environment
independent from the implementation
 Defined What a system is supposed to do
 Describe user tasks that the system needs to support
Cont..
 Nonfunctional requirements
o Aspects not directly related to functional behavior.
“The response time must be less than 1 second”
o define how a system is supposed to be
o Describe properties of the system or the domain
o Phrased as constraints or negative assertions
“All user inputs should be acknowledged within 1 second”
“A system crash should not result in data loss”.
Types of Nonfunctional Requirements
• Usability
• Reliability • Implementation
– Robustness • Interface
– Safety • Operation
• Performance • Packaging
– Response time • Legal
– Scalability – Licensing (GPL, LGPL)
– Throughput – Certification
– Availability – Regulation
• Supportability
– Flexibility Constraints or
– Maintainability Pseudo requirements

Quality requirements
why requirements elicitation is difficult?
 Problems of scope-The boundary of the system is ill-defined or the
customers/users specify unnecessary technical detail that may
confuse, rather than clarify, overall system objectives.
 Problems of understanding- The customers/users are not completely
sure of what is needed, have a poor understanding of the capabilities
and limitations of their computing environment, don’t have a full
understanding of the problem domain, have trouble communicating
needs to the system engineer, omit information that is believed to be
“obvious,” specify requirements that conflict with the needs of other
customers/users, or specify requirements that are ambiguous or
untestable.
 Problems of volatility- The requirements change over time.
Techniques to elicit Requirements
• Interviewing
– Conduct a series of interviews
• Ask about specific details
• Ask about the stakeholder’s vision for the future
• Ask if they have alternative ideas
• Ask for other sources of information
• Ask them to draw diagrams
• Questionnaires: Asking end user a list of pre-selected questions
• observation: Observing end users in their operational
environment
• Scenarios: Describe use of the system as a series of interactions
between a concrete end user and the system
• Use cases: Abstractions that describe a class of scenarios.
 Cont..
 Prototyping
o The simplest kind: paper prototype.
 a set of pictures of the system that are shown to users in
sequence to explain what would happen
o The most common: a mock-up of the system’s UI
 Written in a rapid prototyping language
 Does not normally perform any computations, access any
databases or interact with any other systems
 May prototype a particular aspect of the system
 Outcome of a poor requirements
elicitation process
 Developers are solving the wrong problem.
 This guarantees the failure of the whole project in general.
 Buyers and users can be dissatisfied; often happens if the
developers did not really listen to them, or if the developers
dominated the process.
 Dissatisfaction may result in less effective participation by the
buyers and users
 The dissatisfaction can continue to affect the project through
development and delivery of the software.
Cont..

 The developers may discover that they are missing important

information, resulting in additional meetings with the buyers
and users.
 The developers may make the wrong decisions or tradeoffs
because of a lack of understanding of the users’ needs.
 The result is cost and schedule overruns, and sometimes failed
or canceled projects.
Requirements elicitation activities
Requirements elicitation includes the following activities:
 Identifying actors -During this activity, developers identify the
different types of users the future system will support.
 Identifying scenarios - During this activity, developers observe
users and develop a set of detailed scenarios for typical
functionality provided by the future system.
o Scenarios are concrete examples of the future system in use.
o Developers use these scenarios to communicate with the user
and deepen their understanding of the application domain.
 Identifying use cases- Once developers and users agree on a set
of scenarios, developers derive from the scenarios a set of use
cases that completely represent the future system.
 Cont..
 Refining use cases- During this activity, developers ensure that the
requirements specification is complete by detailing each use case and
describing the behavior of the system in the presence of errors and
exceptional conditions.
 Identifying relationships among use cases- During this activity,
developers identify dependencies among use cases.
o They also consolidate the use case model by factoring out common
functionality.
o This ensures that the requirements specification is consistent.
 Identifying nonfunctional requirements- During this activity,
developers, users, and clients agree on aspects that are visible to the
user, but not directly related to functionality.
o These include constraints on the performance of the system, its
documentation, the resources it consumes, its security, and its
quality.
 Identifying Actors
 This serves both to define the boundaries of the system and to find
all the viewpoints from which the developers need to consider the
system.
 Actors are outside of the system boundary- they are external
Subsystems and objects are inside the system boundary- they are
internal
 To identify an actor, search in the problem statement for business
terms that represent roles in the system. For example, in the
statement "patients visit the doctor in the clinic for medical tests,"
"doctor" and "patients" are the business roles and can be easily
identified as actors in the system.
Cont..
Questions for identifying actors
 Which user groups are supported by the system to perform their
work?
 Which user groups execute the system’s main functions?
 Which user groups perform secondary functions, such as
maintenance and administration?
 With what external hardware or software system will the system
interact?
 Actors are role abstractions and do not necessarily directly map
to persons
Identifying Scenarios
 any scenarios may be generated from a single use case description
 A scenario is “a narrative description of what people do and
experience as they try to make use of computer systems and
applications” [Carroll, 1995]
 A scenario is a concrete, focused, informal description of a single
feature of the system from the viewpoint of a single actor.
 Case Study
For our case study, we will be the architects assigned the task of constructing the
design elements for a system that can be used to manage courses/classes for an
organization that specializes in providing training. Let us name the system that we
will be designing as the Courseware Management System. The organization offers a
variety of courses in a variety of areas such as learning management techniques and
understanding different software languages and technologies. Each course is made up
of a set of topics. Tutors in the organization are assigned courses to teach according to
the area that they specialize in and their availability. The organization publishes and
maintains a calendar of the different courses and the assigned tutors every year. There
is a group of course administrators in the organization who manage the courses
including course content, assign courses to tutors, and define the course schedule. The
training organization aims to use the Courseware Management System to get a better
control and visibility to the management of courses as also to streamline the process
of generating and managing the schedule of the different courses.
The organization allow regular and extension students to register for training course
online and to pay for courses by Credit Card, by Cash, by Check etc.
Now that we have our problem statement defined, we can proceed to the next step—
analyzing and elaborating on the requirements(requirement elicitation activities) and
then designing the Courseware Management System.
UML Case study—Courseware Management System

 We will now design the use case model for the Courseware Management
System case study.
 Analyze the problem statement to identify the potential actors and use
cases of the system. First, let us list the potential actors.
 A quick look at the problem statement shows up the following terms and
entities specific to the system:
o Courses and Topics that make up a course
o Tutors who teach courses
o Course administrators who mange the assignment of the
courses to tutors
o Calendar or Course Schedule is generated as a result of the
students
o Students who refer to the Course schedule or Calendar to
decide which courses they wish to take up for study
 Identifying Actors of the Courseware
Management System
 The entities that perform action will be the actors for the
Courseware Management System.
 From carefully study of the problem, the actors that we can
identify are:
o Tutors
o Course administrators
o Students
Identifying Use Cases of the Courseware
Management System
 Next, let us identify the potential business processes in the
Courseware Management System.
 The primary business flows in the system are:
o Manage courses
o Manage course assignments
 We can further divide the above two business flows into sub flows:
  So, within the "Manage courses" use case, we can identify the
following sub processes:
o View courses
o Manage topics for a course
o Manage course information
Cont..
 the use cases that we have identified within the "Manage course
assignment" use case are:
o View course calendar
o View tutors
o Manage tutor information
o Assign courses to tutors
Cont..
The final list of use cases for the courseware management system will
now be:
o View courses
o Manage topics for a course
o Manage course information
o View course calendar
o View tutors
o Manage tutor information
o Assign courses to tutors
o REGISTER ONLINE
o PAYMENT
 Writing a Use Case Specification
 A use case diagram, as we have seen, is a visual depiction of the
different scenarios of interaction between an actor and a use case.
 The usefulness of use case diagrams is more as a tool of
communication between the requirements capture team and the user
group.
 The next step after finalizing of use case diagrams is to document
the business functionality into clear-cut and detailed use case
specifications.
 Because use cases are used as an input to the other project phases
such as design, development, and testing, we need to ensure that the
visual depiction of the business requirements is translated into clear
and well-defined requirements in the form of use case specifications.
 Elaborate use case specifications are used as an input for design and
development and for writing test cases (unit, system, and regression
tests, as the case may be).
Cont..
 A use case specification document should enable us to easily
document the business flow.
 Information that you document in a use case specification
includes what actors are involved, the steps that the use case
performs, business rules, and so forth.
 A use case specification document should cover the following
areas(use case specification document contents):
 Use Case Name: Give a short, descriptive name to the use case
 Actors: List the actors that interact and participate in this use
case.
 Description: Give a short informal description
 Trigger: Describe the event that initiates the activity
 Cont..
 Pre-conditions: Pre-conditions that need to be satisfied for the use
case to perform. 
 Post-conditions: Define the different states in which you expect
the system to be in, after the use case executes. 
 Basic Flow: List the basic events that will occur when this use case
is executed.
o Include all the primary activities that the use case will perform.
 Alternative flows: Any subsidiary events that can occur in the use
case should be listed separately.
o Each such event should be completed in itself to be listed as an
alternative flow.
o A use case can have as many alternative flows as required.
o But remember, if there are too many alternative flows, you need
to revisit your use case design to make it simpler and, if
required, break the use case into smaller discrete units. 
Cont..
 Special Requirements: Business rules for the basic and
alternative flows should be listed as special requirements in the
use case narration.
o These business rules will also be used for writing test cases.
Both success and failure scenarios should be described here. 
Use case relationships: For complex systems, it is recommended
that you document the relationships between use cases.
o If this use case extends from other use cases or includes the
functionality of other use cases, these relationships should be
listed here.
 Use Case Templates – Simple Column Form
Linear sequences (main and alternatives)
1. A User inserts a card in the Card reader slot.
1.1 The Card is not valid.
1.1.1. The System ejects the Card.
2. The system asks for a personal identification number (PIN).
3. The User enters a PIN.
4. The System checks that the user identification is valid.
4.1 The User identification is not valid.
4.1.1 The System ejects the Card.
5. The System asks the user to chose an operation
Use Case Description Example 1
Use Case Description Example 2
Name: Enroll in University
Identifier: UC 19
Goal: Enroll applicant in the university
Preconditions:
o The Registrar is logged into the system.
o The Applicant has already undergone initial checks to verify that
they are eligible to enroll.
Post-conditions:
o The Applicant will be enrolled in the university as a student if
they are eligible.
Cont..
Main Flow:
1. An applicant wants to enroll in the university.
2. The applicant hands a filled out copy of form UI13 University
Application Form to the registrar.
3. The registrar visually inspects the forms.
4. The registrar determines that the forms have been filled out
properly.
5. The registrar selects to Create New Student.
6. The system displays the Create Student Screen.
7. The registrar inputs the name, address, and phone number of
the applicant.
[Extension Point: XPCheck]
Cont..
8. The system determines that the applicant does not already
exist within the system.
9. The system determines that the applicant is on the eligible
applicants list.
10. The system adds the applicant to its records.
11. The registrar enrolls the student in courses via use case UC
17 Enroll in
Course.
12. The system prepares a bill for the applicant enrollment fees.
Alternate Flows:
4.a The forms have not been adequately filled…
Cont..
Name: Perform Security Check
Identifier: UC 34
At Extension Point XPCheck:
1. The registrar asks for security check results about applicant.
2. The system asks RCMP Security System for applicant security
check results.
3. The RCMP Security System responds that applicant has been
cleared.
3.a The Security System responds that applicant has not been
cleared