Chapter 3:

Requirement Elicitation
What are requirements?
 Software requirements are the descriptions of the system
services (essential & desired) and constraints (on System
operation and software development process).
 Requirements are statements of what the system must do,
how it must behave, the properties it must exhibit, the
qualities it must possess, and the constraints that the
system and its development must satisfy. The Institute of
Electrical and Electronics Engineers (IEEE) defines a
requirement as
 a condition or capability needed by a user to solve a
problem or achieve an objective

2
 …Continued
 Requirement:
A statement that identifies a product or process operational,
functional, or design characteristic or constraint, which is
unambiguous, testable or measurable, and necessary for
product or process acceptability (by consumers or internal
quality assurance guidelines).

3
Requirements might describe:
• A user-level facility (e.g., the word processor must include a spell
checking and correction command)
• A very general system property (e.g., the system must ensure that
personal information is never made available without authorization)
• How to carry out some computation (e.g., the overall mark is computed
by adding the student's exam, project & coursework marks based on the
following formula. Total = [2 * exam + 3*(project + coursework)]/5
• constraint on the development of the system (e.g. The system must be
developed using java) Etc..

• [Davis 1990a, Faulk 1997a]. "The inability to produce complete,

correct, and unambiguous software requirements is still considered the
major cause of software failure today" .

4
What are requirements?...
 Requirements should always be statement of what a system
should do rather than a statement of how it should do it.
 However, sometimes it is necessary for the requirement
documents to include information about the design of the
system. Because:
 Readers are often practical engineers – they can relate it to
implementation descriptions
 The system may be one of several systems in an environment - to
be compatible with its environment specifying implementation
issues are important
 The specifiers are often experts in the application domain where
the system is to be used. The requirements may be descriptions of
how to carry out a computation using application domain

5
 …Continued
 The most common reasons for project failures are not technical and Table
1.1 identifies the main reasons why projects fail. The data is drawn from
surveys conducted by the Standish Group in 1995 and 1996.
 Incomplete requirements 13.1%
 Lack of user involvement 12.4%
 Lack of resources 10.6%
 Unrealistic expectations 9.9%
 Lack of executive support 9.3%
 Changing requirements/specifications 8.7%
 Lack of planning 8.1%
 Didn’t need it any longer 7.5%

 Hence giving emphasis to requirements is crucial in any system dev’t.

6
Requirement Engineering
 The term “requirements engineering” is often too
narrowly equated with requirements analysis, which is just
one of the activities within the wider discipline. The
emphasis on engineering is useful for two main reasons:
 Dealing with requirements is an essential part of every
engineering endeavor. Indeed, requirements engineering is a
subset of systems engineering in general, not just software
engineering.
 The term subsumes the wide variety of other titles given to
activities relating to requirements, such as requirements
analysis and the two terms used for key process areas:
requirements management and requirements development
(CarnegieMellon 2006).
7
 …Continued
 Requirements Engineering(RE) provides the basic agreement between
end-users and developers on what the software should do. It is a clear
statement on the scope and boundaries of the system to be analyzed and
studied. It gives stakeholders an opportunity to define their requirements
understandable to the development team
 RE “involves all life-cycle activities devoted to identification of user
requirements, analysis of the requirements to derive additional
requirements, documentation of the requirements as a specification, and
validation of the documented requirements against user needs, as well
as processes that support these activities” (DoD 1991).
 A branch of SWE concerned with the real-world goals for, functions of,
and constraints on software systems and also concerned with the
relationship of these factors to precise specifications of software
behavior (Zave 1997).

8
 …Continued
 The subset of systems engineering concerned with
discovering, developing, tracing, analyzing, qualifying,
communicating and managing requirements that define the
system at successive levels of abstraction.

 Requirements engineering is complex because of the three

roles involved in producing even a single requirement: the
requestor (referred to as the "user" in the IEEE definition), the
developer (who will design and implement the system), and
the author (who will document the requirements).

9
 …Continued
 Typically, the requestor understands the problem to be solved
by the system but not how to develop a system.
 The developer understands the tools and techniques required
to construct and maintain a system but not the problem to be
solved by that system.
 The author needs to create a statement that communicates
unambiguously to the developer what the requestor desires.
Hence, requirements address a fundamental communications
problem.
 RE according to Laplante (2007) is "a sub discipline of
systems engineering and SW engineering that is concerned
with determining the goals, functions, and constraints of
HW&SW systems.
10
Why Requirement Engineering?
 Despite new and effective software engineering techniques,
software systems
 Are delivered late and over budget
 Do not do what really users want
 Are prone to failure

 Some key aspects of successful software development are

 User input and involvement
 Effective management and support
 Resources
 Clearly defined, complete requirements
 Numerous software engineering studies show this repeatedly
 40-60% of all defects found in software projects can be traced back to
poor requirements.
11
Stakeholders: The Who of RE
 System Stakeholders are people or organizations who will
be affected by the system and who have direct or indirect
influence on the system requirements.
 In order to develop a good requirement document, it is
imperative to involve all kinds of user in the requirement
engineering process.
 You need to identify the stakeholders in a system and
discover their requirements.
 If you don’t do, you may find that they insist on changes
during the system development or after it has been
delivered for use.

12
 …Continued
 Stakeholders tend to state requirements in very
general and vague terms
 different stakeholders have different
requirements – sometimes even conflicting.
 It is increasingly recognized that stakeholders are
not limited to the organization employing the
analyst. Other stakeholders will include:
 anyone who operates the system (normal and
maintenance operators) .

13
 …Continued
 anyone who benefits from the system (functional,
political, financial and social beneficiaries)
 Anyone involved in purchasing or procuring the system. In a
mass-market product organization, product management,
marketing and sometimes sales act as surrogate consumers
(mass-market customers) to guide development of the product
 Organizations which regulate aspects of the system (financial,
safety, and other regulators).
 People or organizations opposed to the system (negative
stakeholders; see also Misuse case)
 Those organizations who integrate horizontally with the
organization for whom the analyst is designing the system.

14
Example
 For an automated railway signaling system (a system used to
control railway traffic safely) possible stakeholders are
 Train company operators responsible for running the
system
 Train crew
 Railway managers
 Passengers
 Equipment installation and maintenance engineers
 Safety certification authorities

15
Stakeholders…
 There are three main categories of stakeholders:
 the acquirers of the software product
 the suppliers of the software product and
 other stakeholders.
 The acquirer type stakeholders can be divided into two
major groups.
 customers who request, purchase, and/or pay for the software
product in order to meet their business objectives.
 users, also called end-users, who actually use the product
directly or use the product indirectly by receiving reports,
outputs, or other information generated by the product.

16
 …Continued
 The suppliers of the software product include individuals
and teams that are
 are part of the organization that develops the software product
or
 are part of the organizations that distribute the software product
or
 are involved in other product delivery methods (for example,
outsourcing).
 System analysts, designers, developers etc are some examples
among suppliers
 Suppliers who pay for the development of the product are
called client.

17
 Stakeholders: Example
Assume ASU has signed an agreement with a software company called ABC for
the automation of the Procurement and property Administration which
encompasses subsystems like property Administration n subsystem, Contract
Administration subsystem, Planning subsystem and the like.

 Identify all stakeholders for the system mentioned.

 ASU, ASU managers, Students, Instructor and other Admin staff officials,
the company ABC, etc.
 If the University sells the system to other universities so as to get
reimbursed for what it has spent, who is the client, the customer
and the user?
 Client: ASU
 Customers: Other Universities
 Users: Anyone using the system

18
Question
 ATM stakeholders?????

19
ATM stakeholders
 Bank customers
 Representatives of other banks
 Bank managers
 Counter staff
 Database administrators
 Security managers
 Marketing department
 Hardware and software maintenance engineers
 Banking regulators

20
Question
 Stakeholders in the MHC-PMS??????

21
Stakeholders in the MHC-PMS
 Patients whose information is recorded in the system.
 Doctors who are responsible for assessing and treating
patients.
 Nurses who coordinate the consultations with doctors and
administer some treatments.
 Medical receptionists who manage patients’ appointments.
 IT staff who are responsible for installing and maintaining
the system.
 A medical ethics manager who must ensure that the
system meets current ethical guidelines for patient care.

22
 …Continued
 Health care managers who obtain management
information from the system.

 Medical records staff who are responsible for ensuring

that system information can be maintained and preserved,
and that record keeping procedures have been properly
implemented.

23
How Requirements engineering
Requirement engineering includes two main activities;
Requirement Elicitation: Definition of the system understood
by the customer/client.(problem definition)
Requirement Analysis: Specification of the system
understood by the developers(Problem specification).

24
 …Continued
 Scenarios and use cases provide tools for bridging the gap
between users and developers.

 A scenario describes an example of system use in terms of a

series of interactions between the user and the system.
 Scenarios are stories which explain how a system might be
used.

 A use case is an abstraction that describes a class of scenarios.

25
 …Continued
 Basically, we focus on scenario-based requirements
elicitation.
 Developers elicit requirements by observing and interviewing
users and also use document analysis.

 Developers first represent the user’s current work processes

as as-is scenarios and then develop visionary scenarios
describing the functionality provided by the future system.

 The client and users validate the system description by

reviewing the scenarios and by testing small prototypes
provided by the developers.
26
 …Continued
 Requirements elicitation is about communication among
developers, clients, and users for defining a new system.

 Failure to communicate and understand each others’

domain results in a system difficult to use or that simply
fails to support user’s work.

 Errors during requirement elicitation include missing

system functionality, incorrectly specified functionality,
misleading or unusable user interfaces, and obsolete(out
of date) functionality.
27
 …Continued
 Developers construct a model of the application domain by
observing users in their environment (e.g., task analysis).

 Developers select a representation that is understandable by

clients and users (e.g., scenarios and use cases).

 Developers validate the application domain model by

constructing simple prototypes of the user interface and
collecting feedback from potential users (e.g., rapid
prototyping, usability testing).

28
 An Overview of Requirements Elicitation
 Requirement's elicitation is the practice of collecting the
requirements of a system from users, customers and other
stakeholders.
 sometimes referred to as "requirement
gathering".
 You can’t build a system if you don’t know what it should
do.

 Many developers in this stage may not want to spend

more time in requirement gathering. Instead, they want to
jump directly to programming.

 Requirements elicitation focuses on describing the purpose

29
 …Continued
 The client, developers, and users identify a problem area and
define a system that addresses the problem.

 Such a definition is called a system specification and serves as

a contract between the client and the developers.

 The system specification is structured and formalized during

analysis to produce an analysis model.

 The system specification is written in natural language, whereas

analysis model is expressed in a formal or semiformal notation.

30
 …Continued
 The system specification supports communication with the
client and users.

 The analysis model supports the communication among

developers.

 They are both models of the system which attempt to

accurately represent the external aspects of the system.

 Requirement's elicitation and analysis focus only on the

user’s view of the system.
31
 …Continued
 Requirement's elicitation includes the following activities.
 Identifying actors: developers identify the different types
of users.
 Identifying scenarios: developers observe users and
develop a set of detailed scenarios for typical
functionality provided by the system.
 Scenarios are concrete examples of the future system
in use.
 Developers use these scenarios to communicate with
the user and deepen their understanding of the
application domain.
32
 …Continued
 Identifying use cases: developers derive set of use cases
from scenarios that completely represent the system.
• Developers determine the scope of the system.

 Refining use cases: developers ensure that the system

specification is complete, by detailing each use case and
describing the behavior of the system in the presence of
errors and exceptional conditions.

33
 …Continued
 Identifying relationships among usecases: developers
consolidate the use case model by eliminating redundancies.
This ensures that the system specification is consistent.

 Identifying nonfunctional requirements: developers, users,

and clients agree on aspects that are visible to the user but
not directly related to functionality.

 These include constraints on the performance of the system,

its documentation, the resources it consumes, its security,
and its quality.

34
 …Continued
 During requirements elicitation,
 developers access many different sources of information,
including
 client-supplied documents about the application domain,
 manuals and technical documentation of legacy systems
that the future system will replace, and,
 most important, the users and clients themselves.

 Developers interact the most with users and clients

during requirements elicitation.
35
 …Continued
 We focus on three methods for eliciting information and making
decisions with users and clients:
 Joint Application Design (JAD) focuses on building consensus
(general agreement) among developers, users, and clients by
jointly developing the system specification.

 Knowledge Analysis of Tasks (KAT) focuses on eliciting

information from users through observation.

 Usability testing focuses on validating the requirements

elicitation model with the user through a variety of methods.
36
 Requirements elicitation concepts
 The main requirements elicitation concepts
 Functional requirements
 Nonfunctional and pseudo requirements
 Levels of descriptions
 Correctness, completeness, consistency, clarity, and
realism
 Verifiability and traceability

37
 Functional requirements
 Describe the interactions between the system and its
environment independent of its implementation.
 The environment includes the user and any other external
system with which system interacts.

38
Nonfunctional and pseudo requirements
Nonfunctional requirements
 Describe user-visible aspects of the system that are not
directly related with the functional behavior of the system.
 Nonfunctional requirements include quantitative
constraints, such as response time, or accuracy.

39
 …Continued
 Pseudo requirements are requirements imposed by the client
that restrict the implementation of the system.
 Typical pseudo requirements are the implementation language
and platform on which the system is to be implemented.

 The developer constructs a model describing the reality as

seen from a user’s point of view.

 Modeling consists of identifying and classifying real-world

phenomena (e.g., aspects of the system under construction)
into concepts.

40
 …Continued

 A System is a collection of real world Phenomena.

 A model is a collection of concepts that describes the system
of real world phenomena.
 Many models can represent different aspects of the same
system.
 An unambiguous model corresponds to only one system.
41
 …Continued
 This UML class diagram representing the relationships
between models and reality.
 In this diagram, a model is said to be correct if each concept
in the model corresponds to a relevant phenomenon.

 The model is complete if all relevant phenomena are

represented by at least one concept.

 The model is consistent if all concepts represent phenomena

of same reality (i.e., if a model is inconsistent, it must
represent aspects of two different realities, there is no
contradicting requirements.)
42
 …Continued
Levels of description
 Requirements describe a system and its interaction with
surrounding environment, such as the users, their work
processes, and other systems.

 Most requirements analysis methods have focused on

describing the system.

 In general, there are four levels of description, which can

uniformly be described with use cases. The four levels
description from most-general to most-specific are :

43
 …Continued
 Work division: focus on defining the boundaries between the
users and the system.
 Application-specific system functions: describes functions that
system provides that are related to application domain.

 Work-specific system functions: describe supporting functions

of system that are not directly related with application domain.
These include file management, grouping, undo functions, and
so on.

 Dialog: describes interactions between the users and user

interface of system. The focus is on designing resolving control
flow and layout issues. 44
Correctness, completeness, consistency,
clarity, and realism
 Requirements are continuously validated with client and user.

 Validation is a critical step in the development process, given

that both client and developer are dependent on system
specification.

 Requirement validation involves checking if the specification

is correct, complete, consistent, unambiguous, and realistic.

45
 …Continued
 A specification is correct if it represents the client’s view
of the system (i.e., everything in requirements model
accurately represents an aspect of system).

 It is complete if all possible scenarios through system are

described, including exceptional behavior (i.e., all aspects
of system are represented in requirements model).

 The system specification is consistent if it does not contradict

itself.

46
 …Continued
 The system specification is unambiguous if exactly one system
is defined (i.e., it is not possible to interpret the specification
two or more different ways).

 Finally, it is realistic if the system can be implemented within

constraints.

 The correctness and completeness of a system specification are

often difficult to establish, especially before the system exists.

47
 Verifiability and traceability
 Two more desirable properties of a system specification:
verifiable and traceable.
 The specification is verifiable if, once system is built, a
repeatable test can be designed to demonstrate that the
system fulfills requirement.
 The following requirements are additional examples of non
verifiable requirements:
 The product shall have a good user interface (good is not
defined).
 The product shall be error free (requires large amount of
resources to establish).
 The product shall respond to the user with 1 second for most
cases (“most cases” is not defined).
48
 …Continued
 A system specification is traceable if each system function can
be traced to its corresponding set of requirements.

 Traceability is not a constraint on the content of the

specification, but rather, on its organization.

 Traceability facilitates the development of tests and the

systematic validation of design against requirements.

49
 Requirements elicitation activities
 Is used to map a problem statement into a system specification
 That represent as a set of actors, scenarios, and use cases
(Modeling with UML).

 Requirements elicitation activities include:

 identifying actors
 identifying scenarios
 identifying use cases
 refining use cases
 identifying relationships among use cases
 identifying participating objects
 identifying nonfunctional requirements
50
 Identifying actors
 Actors represent external entities that interact with the system.
 An actor can be human or an external system.
 Actors define classes of functionality
 Actors are role abstractions and do not necessarily directly map
to persons.
 The first step of requirements elicitation is the identification of
actors.
 This serves to define boundaries of system and to find all the
perspectives from which developers need to consider system.

51
 …Continued
Questions for identifying actors
 To determine who are the actors, the following questions are helpful
1. Who uses the system?
2. Who gets/provides information from/to system?
3. Who operates the system?
4. Who starts up, uses and shuts down the system?
5. who installs, maintains the system?
6. What other systems interacts with the system?
7. Does any thing happen automatically at present time?
8. Who will supply, use, remove information from the system?
9. Where does the system get information?

52
 Identifying scenarios  
 A scenario is “a narrative description of what people do and
experience as they try to make use of computer systems and
applications”

 A scenario is a concrete, focused, informal description of a

single feature of the system from view point of a single actor.

 A scenario-based approach enhance requirements elicitation

by providing a tool that is readily understandable to users and
clients.
 Scenarios can have many different uses during requirements
elicitation and during other activities of the life cycle.
53
 …Continued
Types of scenarios
 As-is scenarios describe a current situation. During re-
engineering, for example, the current system is understood
by observing users and describing their actions as
scenarios. These scenarios can then be validated for
correctness and accuracy with users.

 Visionary scenarios: describe a future system, either re-

engineered or designed from scratch. Used as a design
representation by developers to refine idea of the future
system and as communication medium to elicit requirements
from users.
54
…Continued
 Evaluation scenarios: describe user tasks for evaluating the
system (acceptance criteria). The collaborative development
of evaluation scenarios by users and developers also
improves the definition of functionality tested by these
scenarios.

 Training scenarios: tutorials used for introducing new users

to system. These are step by step instructions designed to
hand-hold user through common tasks.
 In requirements elicitation, developers and users write and
refine a series of scenarios in order to gain understanding of
the system. Initially, each scenario may be high level and
incomplete. 55
 …Continued
Questions for identifying scenarios
 The following questions can be used for identifying scenarios.
 What are the tasks that the actor wants the system to perform?
 What information does the actor access? Who creates that data?
Can it be modified or removed? By whom?
 Which external changes does the actor need to inform the system
about? How often? When?
 Which events does the actor need to be informed by the system
about? With what latency?

56
 …Continued
 Developers use existing documents about the application
domain to answer questions:
 user manuals of previous systems, procedure manuals,
company standards, user notes, user and client interviews.

 The emphasis of scenario identification is for developers to

understand the application domain and to define right
system.

 Once developers identified and described actors and

scenarios, developers formalize scenarios into use cases.

57
 Identifying use cases
 A scenario is an instance of a use case, that is, a use case
specifies all possible scenarios for a given piece of
functionality.
 A use case is initiated by an actor.

 After its initiation, a use case may interact with other actors
as well.

 A use case represents a complete flow of events through

system that means, it describes a series of related
interactions that result from the initiation of the use case.

58
 …Continued
Questions for identifying Use Cases
 The following questions can be used for identifying
scenarios.
1. What are functions that the users in this role wants a system
to accomplish?
2. To fulfil this role what do users need to be able to do?
3. What are the main tasks of users in this role?
4. What are the operations that create, read/search,
update/modify, delete/remove the information?
5. What do users in this role need to be informed by the
system?
6. What do users in this role need to inform the system? 59
 Refining use cases
 The use of scenarios and use cases to define the functionality
of system aims at creating requirements that are validated by
user early in the development.

 As design and implementation of system starts, the cost of

changing the system specification and adding new unforeseen
functionality increases.

 Many use cases are rewritten several times, others are refined,
and yet others completely dropped.
 In order to save time, a lot of the exploration work can be done
using scenarios and user interface mock-ups.
60
 …Continued
 Heuristics for writing scenarios and use cases
 Use scenarios to communicate with users and to validate
functionality.
 First, refine a narrow vertical slice (i.e., one scenario) to
understand the user’s preferred style of interaction.
 Next, define a horizontal slice (i.e., many not-very-detailed
scenarios) to define the scope of the system. Validate with
the user.
 Use mock-ups as a visual support only; user interface
design should occur as a separate task once the
functionality is sufficiently stable.
 Present the user with multiple alternatives (as opposed to
extracting a single alternative from the user).
61
 …Continued
 The focus of this activity is on completeness and correctness.
 Developers identify functionality not covered by scenarios
and document it with new use cases.
 Developers describe rarely occurring cases and exception
handling as seen by the actors.
 If actors require an on-line help support system, developers
describe it with use cases during this activity.
 Once the system specification becomes stable, traceability
and redundancy issues can be addressed by consolidating
and reorganizing the actors and use cases.

62
Identifying relationships among actors
and use cases
 Relationships among actors and use cases enable
developers and users to reduce the complexity of the
model and increase its understandability.
 We use communication relationships between actors and
use cases to describe the system in layers of functionality.
 We use extend relationships to separate exceptional and
common flows of events.
 We use include relationships to reduce redundancy
among use cases.

63
 …Continued
 Communication relationships between actors and use cases
 Represent the flow of information during the use case.
 The actor who initiates the use case should be
distinguished from the other actors with whom the use case
communicates.
 Thus, access control (i.e., which actor has access to which
class functionality) can be represented at this level.
 The relationships between actors and use cases are
identified when use cases are identified.
 Extend relationships between use cases
 A use case extends another use case if the extended use
case may include the behavior of the extension under
certain conditions. 64
 …Continued
 Include relationships between use cases
 Redundancies among use cases can be factored out
using include relationships.
 Factoring out shared behavior from use cases has
many benefits, including shorter descriptions and
fewer redundancies.
 Behavior should only be factored out into a separate
use case if it is shared across two or more use cases.
 Excessive fragmentation of the system specification
across a large number of use cases makes the
specification confusing to users and clients.
65
 …Continued
 Extend versus include relationships
 Include and extend are similar constructs, and initially it may
not be clear to the developer when to use each construct .
 The main distinction between these constructs is the direction of
the relationship.
 Include relationship, the conditions under which the target use
case is initiated are described in the initiating use case, as an
event in the flow of events.
 Extend relationship, the conditions under which the extension is
initiated are described in the extension as an entry condition.
 Heuristics for extend and include relationships
 Use extends for exceptional, optional, or seldom-occurring
behavior.
 Use include for behavior that is shared across two or more use 66
 …Continued
 The purpose of adding include and extend relationships is to
reduce or remove redundancies from the use case model,
thus eliminating inconsistencies.

Identifying initial analysis objects

 One of the first obstacles developers and users encounter
when collaborating is differing terminology.
 Misunderstandings result from the same terms being used in
different context and with different meanings.

67
 …Continued
 Once use cases have been consolidated, developers identify
the participating objects for each use case.
 The participating objects correspond to the main concepts in
the application domain. Developers identify, name, and
describe them unambiguously and collate them into a
glossary(contain sys spec).
 Developers keep this glossary up to date as the system
specification evolves.
 The benefits of glossary are:
 New developers are exposed to a consistent set of
definitions,
 A single term is used for each concept (instead of a
developer term and a user term), and 68
 …Continued
 The identification of participating objects results in the
initial analysis model.
 The identification of participating objects during
requirements elicitation only constitute a first step
toward complete analysis model.
 The complete analysis model is usually not used as
means of communication between users and developers,
as users are often unfamiliar with object-oriented
concepts.
 However, the description of the objects (i.e., the
definitions of terms in glossary) and their attributes are
visible to the users and reviewed. 69
 …Continued
 Heuristics for identifying initial analysis objects
 Terms that developers or users need to clarify in
order to understand the use case
 recurring nouns in the use cases (e.g., Incident)
 real-world entities that the system needs to keep
track of
 real-world processes that the system needs to keep
track of use cases
 data sources or sinks
 interface artifacts, always use application domain
terms. 70
 …Continued
 During requirements elicitation, participating objects
are generated for each use case.
 If two use cases refer to the same concept, the
corresponding object should be the same.

 If two objects share the same name and do not

correspond to the same concept, one or both concepts
are renamed to acknowledge and emphasize their
difference.

 This consolidation eliminates any ambiguity in the

terminology used. 71
 …Continued
 Heuristics for cross-checking use cases and
participating objects
 Which use cases create this object (i.e., during which
use cases are values of object attributes entered in
system)? Which actors can access this information?
 Which use cases modify and destroy this object (i.e.,
which use cases edit or remove this information from
system)? Which actor can initiate these use cases?
 Is this object needed (i.e., is there at least one use case
that depends on this information?)

72
 …Continued
Identifying nonfunctional requirements
 Nonfunctional requirements describe user-visible aspects of the
system that are not directly related to the functional behavior of
the system.
 Nonfunctional requirements span a number of issues, from user
interface look and feel to response time requirements to security
issues.
 Nonfunctional requirements are defined at the same time as
functional requirements are, because they have as much impact on
the development and cost of the system.
 Performance(access time, response time, minimum requirement of
RAM & HD amount to operate, easiness to use etc. of the
system.), Security, Portability, Accuracy, Availability, Reliability,
Efficiency, Maintainability of the system 73
 …Continued
 Nonfunctional requirements can be elicited by investigating the
following issues.
 User interface and human factors: What kind of interface
should the system provide? What is the level of expertise of the
users?
 Documentation: What level of document is required? Should
only user documentation be provided? Should there be
technical documentation for maintainers? Should the
development process be documented?
 Hardware considerations: Are there hardware compatibility
requirements? Will the system interact with other hardware
systems?
 Performance characteristics: How responsive should the
system be? How many concurrent users should it support?
What is a typical or extreme load? 74
 …Continued
 Error handling and extreme conditions: How or which
exceptions should the system handle? Are there safety
requirements on the system?
 Quality issues: How reliable/available/robust should the system
be? What is the client’s involvement in assessing the quality of the
system or the development process?
 System modifications: What is the anticipated scope of future
changes? Who will perform the changes?
 Physical environment: Where will the system be deployed? Are
there external factors such as weather conditions that the system
should withstand?
 Security issues: Should the system be protected against external
intrusions or against malicious users? To what level?
 Resource issues: What are constraints on resources consumed by
75
system?
Managing requirements elicitation
 Use case modeling does not constitute requirements
elicitation.
 Even after they become expert use case modelers, developers
still need to elicit requirements from the users and converge
onto an agreement with the client.
 Methods for eliciting information from the users and
negotiating an agreement with a client
 eliciting requirements from users: Knowledge Analysis of
Tasks (KAT)
 negotiating a specification with clients: Joint Application
Design (JAD)
 validating requirements: usability testing
 documenting requirements elicitation 76
 …Continued
3.4.1. Eliciting information from users: Knowledge Analysis of Tasks
 Recently, task analysis has become important in the field of Human
Computer Interaction (HCI) for identifying and describing the user
tasks that a system should support.
 Task analysis is based on the assumption that it is inefficient to ask
users to describe what they do and how they do it. Users usually
do not think explicitly about the sequence of tasks that are required
to accomplish their work as they have often repeated these tasks
many times.
 Consequently, task analysis uses observation as an alternative to
build an initial task model.
 This initial task model is then refined by asking the users why they
accomplish a task a certain way.
77
 …Continued
 The Knowledge Analysis of Tasks (KAT)
 It is concerned with collecting data from a variety of sources (e.g.,
textbooks, interviews), analyzing these data to identify individual
elements involved in the task (e.g., objects, actions, procedures,
goals, and subgoals), and constructing a model of the overall
knowledge used by people accomplishing the task of interest.
 KAT is an object-oriented analysis technique which represents the
application domain in terms of objects and actions.
 KAT can be summarized by the five following steps:
 Identifying objects and actions: associated with object
identification, such as analyzing textbooks, manuals, rule
books, reports, interviewing and observing the task performer.

78
 …Continued
 Identifying procedures: A procedure is a set of actions, a
precondition necessary to triggering procedure, and a
postcondition.
 Identifying goals and subgoals: A goal is a state to be achieved
for task to be successful. Goals are identified through interview
during performance of a task or afterward. Subgoals are
identified by decomposing goals.
 Identifying typicality and importance: Each identified element
is rated according to how frequently it is encountered and
whether it is necessary for accomplishing a goal.
 Constructing a model of task: The information gathered above
is generalized to common features across tasks. Corresponding
goals, procedures, and objects are related using a textual
notation or a graph. 79
 …Continued
 Negotiating specifications with clients: Joint Application
Design(JAD)
 JAD is a requirements method developed at IBM at the end of
1970s.
 Its effectiveness lies in that requirements elicitation work is
done in one single workshop session in which all stakeholders
participate.
 Users, clients, developers, and a trained session leader sit
together in one room to present their viewpoint, listen to other
viewpoints, negotiate, and agree on a mutually acceptable
solution.
 The outcome of the workshop, final JAD document, is a
complete system specification document that includes
80
definitions of data elements, work flows, and interface screens.
 …Continued
 The final document is jointly developed by the
stakeholders, it represents an agreement between users,
clients, and developers, and thus minimizes requirements
changes later in development process.
 JAD is composed of five activities
 Project definition: JAD facilitator interviews managers
and clients to determine objectives and scope of the
project.
 The findings from interviews are collected in
Management Definition Guide. JAD facilitator forms a
team composed of users, clients, and developers. All
stakeholders are represented, and the participants are81
 …Continued
 Research: JAD facilitator interviews present and
future users, gathers domain information, and describes
work flows.
 The JAD facilitator also starts a list of issues that will
need to be addressed during the session.
 The primary results of research activity are a Session
Agenda and a Preliminary Specification listing work
flow and system information.
 Preparation: JAD facilitator prepares session, creates
a Working Document, first draft of the final document,
an agenda for the session, and any number of overhead
slides or flip charts representing information gathered82
 …Continued
 Session: JAD facilitator guides the team in creating system
specification. A JAD session lasts for 3–5 days. The team
defines and agrees on work flow, data elements, screens, and
reports of the system. All decisions are documented by a
scribe filling JAD forms.
 Final document: JAD facilitator prepares the Final
Document, revising the working document to include all
decisions made during the session.
 The Final Document represents a complete specification of
system agreed on during the session, distributed to the
session’s participants for review. The participants then meet
for a 1-to 2-hour meeting to discuss the reviews and finalize
the document. 83
 …Continued
3.4.2. Validating requirements: Usability testing
 Usability testing
 Tests user’s understanding of use case model.
 Finds problems with system specification by letting user
explore the system or only part of the system (e.g., the user
interface).
 Concerned with user interface details, such as look and
feel of the user interface, geometrical layout of screens,
and hardware.
 Based on experiments identifying deficiencies that
developers fix iteratively.
 Developers formulate a test objective, which they test by 84
 …Continued
 Developers study values of parameters to identify
significant cause-and-effect relationships.
 Usability tests focus on usability parameters,
such as
 the ease to learn the system,
 the time to accomplish a task, or
 the rate of errors a user makes when
accomplishing a task.
 The goal of usability tests is to obtain qualitative
information on how to fix usability problems and
85
improve the system.
 …Continued
 Nielsen uses the term “discount usability engineering” to
indicate that a few usability tests are better than none at
all.
 Three types of usability tests:
 Scenario test: Users are presented with a visionary
scenario of system.
 Developers identify how quickly users are able to
understand scenario, how accurately it represents their
model of work, and how positively they react to the
description of new system.
 A scenario test allows rapid and frequent feedback from
the user.
86
 Scenario tests are cheap to realize and to repeat but user
 …Continued
 Prototype test: Users are presented with a piece
of software that practically implements the
system.
 Prototype tests provide a realistic view of the
system to the user and can be instrumented to
collect detailed data but are expensive to build
and modify.
 Product test: Similar to prototype test except
that a functional version of system is used in
place of the prototype.
 A product test can only be conducted once most 87
 …Continued
 In all three types of tests, basic elements of usability
testing include
 Development of test objectives
 Use of a representative sample of end users
 Use of the system in the actual or simulated work
environment
 Involvement of end users
 Controlled, extensive interrogation, and probing of the
users by person performing the usability test
 Collection and analysis of quantitative and qualitative
results
 Recommendations on how to improve system 88
 …Continued
 Typical test objectives in a usability test address
 comparison of two user interaction styles,
 identification of the best and the worst features in a scenario or
a prototype,
 the main stumbling blocks,
 identification of useful features for novice and expert users,
 when is help needed, and
 what type of training information is required.
 One of the main problems of usability tests is with enrolling
participants(selecting real end users)
 The end users do not have time.
 The end users dislike being studied.

89
 …Continued
3.4.3. Documenting requirements elicitation
 The results of the requirements elicitation and the analysis activity
are documented in the Requirements Analysis Document (RAD).
 This document completely describes the system in terms of
functional and nonfunctional requirements and serves as a
contractual basis between client and developers.
 The audience for the RAD includes the client, the users, the
project management, the system analysts, and the system
designers.
 The first part of the document, including use cases and
nonfunctional requirements, is written during requirements
elicitation.
 The formalization of the specification in terms of object models is
written during analysis. 90
…Continued

91
 …Continued
 Introduction: Its purpose is to provide a brief overview of
function of the system and the reasons for its development, its
scope, and references to the development context (e.g., related
problem statement, references to existing systems, feasibility
studies). The introduction also includes the objectives and success
criteria of the project.
 Current system: describes the current state of affairs.
 Describes functionality and problems of the current system.
Describes how the tasks supported by the new system are
accomplished now.
 Proposed system: documents requirements elicitation and
analysis model of the new system. It is divided into five
subsections:
92
 Overview: presents a functional overview of the system.
 …Continued
 Functional requirements: describes high-level system
functionality.
 Nonfunctional requirements: describes user-level requirements
not directly related to functionality. This includes performance,
security, modifiability, error handling, hardware platform, and
physical environment.
 Pseudorequirements: describes design and implementation
constraints imposed by the client. This includes the specification of
the deployment platform, implementation language, or DBMS
 System models: describes scenarios, use cases, object model, and
dynamic models describing the system.
 Contains complete functional system specification, including
mock-ups and navigational charts illustrating user interface of the
system. This section is written during Analysis activity.
93
 …Continued
 The RAD should be written after the use case model is
stable, that is, when the number of modifications to the
requirements is minimal.
 The RAD, however, is updated throughout the
development process when specification problems are
discovered or when the scope of the system is changed.
 The RAD, once published, is baselined and put under
configuration management.
 The revision history section of the RAD will provide a
history of changes as a list of the author responsible for
the change, the date of change, and a brief description
of the change. 94
.

Thank You!

95