Chapter 4

Gathering Requirements

© 2009 Pearson Education, Inc. Publishing as Prentice Hall

Chapter Topics
 Define requirements
 Requirements discovery
 Classifying requirements
 Techniques for eliciting requirements
 Managing requirements
 The case history of Walden Hospital, the
main source for examples in this book

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 2

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 3
Requirements Gathering
 The task of requirements gathering is to
collect and define all features that the
information system must have in order to
fulfill the objectives that the customer has
set.
 The reliability and the correctness of
requirements is dependent on their
sources, on the techniques that we employ
to elicit and verify them, and on their
effective management.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 4

Requirements Discovery

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 5

Requirements Discovery
 Requirements discovery identifies the
scope and the major objectives of the
system. Requirements gathering defines
what is needed to reach those objectives.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 6

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 7
Classifying Requirements
 Requirements fall into two broad categories:
functional (or behavioral) and non-functional.
Since both relate to the same product, they are
interrelated and affect each other:
 Functional Requirements
 Functional requirements specify the behavior of the system
and the constraints on that behavior.
 Non-Functional Requirements
 Non-functional requirements specify non-behavioral
properties of the system and the constraints on those
properties.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 8

Non-Functional Requirements
 Usability
 Reliability
 Performance
 Maintainability
 Security

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 9

Techniques for Eliciting Requirements
 Interviews
 Questionnaires
 Elicitation Workshops
 Field Trips and Observation
 Modeling
 Mock-Ups

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 10

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 11
Building Blocks of an Interview

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 12

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 13
Questionnaire As Elicitation Tool
 The building blocks of a questionnaire as
an elicitation tool are generally the same as
in interviews, but the flow is inflexible.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 14

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 15
Elicitation Workshops
 Elicitation workshops are the most powerful
but also the most expensive tool for
requirements elicitation.
 Elicitation workshops are commonly
referred to as Joint Application
Development (JAD) workshops.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 16

Workshops
 Planning the Workshop
 Select participants carefully and help them to
help the workshop.
 Conducting the Workshop
 Conductor of the workshop must encourage
free discussion of ideas without losing control
of its goal.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 17

Field Trips and Observation
 Field trips provide valuable requirements
where workflow is rich in action and
interaction.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 18

Modeling
 Models for elicitation and verification of
requirements must be understandable to
stakeholders.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 19

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 20
Mock-Ups
 Mock-ups are approximations of the
system’s user interface to elicit comments
and requirements.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 21

Sources and Authorities
 Sponsors
 Sponsors are those who launch the project and
decide its fate.
 Domain Experts
 Domain experts are those who are the most
knowledgeable about the areas of business
activity within the project scope.
 Stakeholders
 Stakeholders are those whose interests are
affected by the operation of the system.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 22

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 23
Sources and Authorities
 Users
 Users are those who directly interact with the
system.
 Reverse Engineering
 Legacy applications and existing documents are
rich sources of requirements and business
rules, but they must be rigorously evaluated
and verified.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 24

Managing Requirements
 Document and update requirements
 Document sources
 Separate requirements into distinct units
 Uniquely identify each requirement
 Verify requirements and document
verifications
 Prioritize requirements
 Classify requirements meaningfully

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 25

Case History: Walden Medical Center
We will use Walden’s
case history in the
following chapter
as our main example.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 26

The History of Walden Medical Center
 The Rise
 Walden Hospital reached its zenith in
1970’s, with more than 500 licensed
beds and departments in most areas of
hospital medicine.
 The Decline
 Towards the end of millennium, Walden
Hospital was no longer profitable.
 The Revival
 With the boom market of the late
1990’s, the private corporation which
owned Walden Hospital decided to herd
its capital towards the greener pastures
of Dotcoms and put the hospital on the
block.
© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 27
Inception of the Project
 The project has to address four broad,
separate but interrelated areas:
1. Business & Finance:
 Patient Care.
 Service Cuts.
 Charity. Bidding.
 Inventory.
 Drugs.
 HMOs
 Subscription Plan
 Web Services.
 Incentives.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 28

Inception of the Project
2. Organization & Staff
 Hierarchy.
 Alienation.
 Inertia.
3. Infrastructure
 Neglect.
 Inadequacy of IS.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 29

Inception of the Project
4. Medical
 Outsourcing.
 Obsolescence.
 Archives.
 Drug Inventory.
 Cost Predicament.
 Research (Lack of).
 Accreditations.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 30

Initial Requirements
 The consultant concluded that to achieve
the goals of the capital-improvement
project, an integrated, comprehensive
electronic information system is
indispensable.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 31

 Requirement True/False Comment
ID
001 The product shall replace all current  
legacy systems.
001 The product shall automate all clerical  
functions of patient management in an
integrated system.
003 The architecture of patient management  
subsystem must be compatible with the
architecture of future subsystems within
the enterprise-wide system.
004 Major functions of the system will be:  
Appointment to receive a medical
service.
Registration of the patient.
Recording of medical services.
Recording of costs incurred by the
medical service.
Patient billing
See the attached context diagram for
patient management.
005 …

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 32

Next: Domain Analysis
 While requirements identify the features of
the product, domain analysis places those
feature in the context of business domains.
 We will learn about problem space and the
solution space.
 We will also explore the distinctions
between requirements, problems, solutions
as methods, and solutions as products.

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 33

All rights reserved. No part of this publication may be reproduced, stored in a
retrieval system, or transmitted, in any form or by any means, electronic,
mechanical, photocopying, recording, or otherwise, without the prior written
permission of the publisher. Printed in the United States of America.

Copyright © 2009 Pearson Education, Inc.  

Publishing as Prentice Hall

© 2009 Pearson Education, Inc. Publishing as Prentice Hall 4- 34