Eliciting Requirements

Steven J Zeil:

Last modified: Dec 21, 2019


Eliciting requirements is the process of determining what the customers actually need a proposed system to do and of documenting that information in a way that will allow us to write a more formal requirements document later.

In this lecture we survey some key concepts, problems, and actitivies associated with requirements elicitation, and then look at use cases, one of the most popular ways of documenting our understanding of those requirements.

1 Basic Principles of Requirements Analysis

Understanding the customer’s requirements for a software system

Problems of requirements analysis

2 Eliciting Requirements

The process of eliciting requirements is, fundamentally, an exercise in communication between developers and stakeholders.

3 Obtaining Requirements Information

Common sources are

3.1 Interviews

These interviews can be as much about learning how the current system works as about what is desired from the new system.

3.2 Prototyping

4 Organizing Requirements Information

4.1 Viewpoint Analysis

4.1.1 Types of viewpoint

Viewpoints are perspectives on the system, not “people who view it”.

Common viewpoints include

4.1.2 The VORD method

VORD: Viewpoint-Oriented Requirements Definition

Example: Checkbook balancing

Consider the design of software to balance a checkbook:

  • should accept transactions including

    • checks
    • deposits
    • withdrawals
    • interest accrued
    • service charges
  • Allow transactions to be confirmed from bank statement

  • should show current and confirmed balances

Viewpoint Identification

Plausible viewpoints are:

Services Provided

  • Account

    • apply transactions
  • Bank

    • create/close accounts
    • receive transactions
    • initiate transactions (charges)
  • Account holder

    • receive account statement
    • initiate transactions
    • examine register entries
    • get statement balance
    • get confirmed & unconfirmed register balances
    • confirm transactions from statement
  • Clearing House

    • receive checks

Viewpoint Documentation

For each viewpoint, we document the data and services that are visible form that viewpoint.

Reference: Bank

Attributes: name, location, accounts list

Events: end-of-month, transaction arrival


  • create/close accounts
  • receive transactions
  • initiate transactions (charges)


And we document the services

Reference: receive transaction (account debit)

Rationale: electronic funds transfer, may be signal from clearing house of a check received

Specification: The account balance is checked to determine if adequate. If so, confirmation of the transaction is sent, the account balance is reduced by the transaction amount, and the transaction noted in the account log. If not, the account kind is consulted for overdraft policy, and the policy routine found there is invoked.

Viewpoints: Bank, Clearing House

NF Reqts: Response of confirmation, rejection, or unable-to-process must be made within 30 seconds, with a mean response less than 0.1 seconds.

Viewpoints: Bank

4.2 Use Cases

Use cases have become popular as a means of organizing requirements.

A use case is a collection of scenarios.

4.2.1 Writing Use-Cases

  1. Start with a collection of scenarios
  2. Group by common user goals
  3. Define the actors
  4. Give brief descriptions of use cases
  5. Give a detailed description of the basic path
  6. Add alternative paths

Example: grading tests

Grading an Assessment

Actors: Scorer

Main Path

  1. The scorer begins with an assessment and a collection of response documents.

  2. For each item in the assessment, the scorer obtains the item’s rubric. Then for each response document, the scorer goes to the item response for that same item, grades the response using that rubric, and adds the resulting score and (if provided) feedback to the result document for that response document.

  3. When all items have been graded, then the scorer computes a total score for each results document.

  4. The scorer add the score from each result document to the grade book.

Alternative: Candidate by Candidate Scoring

2: For each candidate, the scorer goes through each of the items. For each item, the scorer obtains the item’s rubric, grades the item response using that rubric, adds the resulting score and (if provided) feedback to the result document for that response document.


Get Paid for Car Accident

Actors: Claimant, Accident victim making claim, Insurance Company, Company insuring Claimant, Agent, Insurance Company representative> processing claim

Main Success Scenario

  1. Claimant submits claim with substantiating data.
  2. Insurance Company verifies that Claimant owns a valid policy.
  3. Insurance Company assigns Agent to examine case.
  4. Agent verifies that all details are within policy guidelines.
  5. Insurance Company pays Claimant.


1a. Submitted data is incomplete:

1a1. Insurance Company requests missing information. 1a2. Claimant supplies missing information.

2a. Claimant does not own a valid policy:

2a1. Insurance Company declines claim, notifies Claimant, records all this, and terminates proceedings.

3a. No Agents are available at this time:

3a1. (What does the Insurance Company do here?)

4a. Accident violates basic policy guidelines:

4a1. Insurance Company declines claim, notifies Claimant, records all this, and terminates proceedings.

4b. Accident violates some minor policy guidelines :

4b1. Insurance Company begins negotiation with Claimant as to degree of payment to be made.


4.2.2 Components of a use case

Lots of local variations:

  1. Title

  2. Overview – natural language description

  3. Actors – list of external entities participating in the use case

  4. Preconditions – list of conditions that must be true before this use case can be invoked.

  5. Scenario(s): specified as a main path and a collection of alternative paths

  6. Postconditions – list of conditions that are expected to be true upon completion of the use case

  7. Exceptions – List of failure conditions associated with the scenarios, and the appropriate system responses

Of these, #1 and #5 are essential and universal.

#4, #6, & #7 are often empty


Attempt Assessment

Overview: A candidate attempts to take an assessment. The candidate might or might not finish the assessment within a single session.

Actors: candidate, proctor


  1. Assessment has been created
  2. Assessment has been provided to the proctor

Main Path:

1: A candidate indicates to a proctor their desire to take an assessment. (This may involve simply showing up at a previously-schedule time and place when the assessment is going to be available.)

2: The proctor provides the candidate with a copy of the assessment and an empty response document.

3: The proctor authorizes the start of the assessment session.

4: The candidate reads the assessment, and repeatedly selects items from it. For each selected item, the candidate creates a response, adding it to the response document.

5: The proctor ends the assessment session after time has expired.

6: The candidate returns the response document to the proctor.



2: The proctor determines that the candidate is not eligible to take the assessment at this time (the assessment is not available or the candidate has not fulfilled assessment requirements such as being enrolled in the course).

The use case terminates immediately.

Variant Assessments

2A: Proctor randomly selects one of multiple available variants of the assessment.

2B: The proctor gives that selected assessment and an empty response document to the candidate.

In-line answers

2: The response document and the assessment copy are a single document.

Candidate provided response document

2: The candidate brings blank sheets of paper or blue books to serve as the response document.

Candidate finishes early

5: The candidate indicates that he/she is finished prior to the end of the allotted time. The proctor ends the assessment session.

Suspended session

5: The candidate asks to suspend the session, with the intention of completing the assessment at a later date. The proctor determines from the assessment properties that this is acceptable.

6: The proctor collects the candidate’s response document and copy of the assessment.

4.2.3 Quality Use Cases

Good use cases are

A poor use case

Register for Course

  1. Display a blank schedule.
  2. Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule.
  3. Do
  4. Student clicks on a course.
  5. Update the lower window to show the times the course is available.
  6. Student clicks on a course time and then clicks on the “Add Course” button.
  7. Check if the Student has the necessary prerequisites and that the course offering is open.
  8. If the course is open and the Student has the necessary prerequisites, add the Student to the course. Display the updated schedule showing the new course. If no, put up a message, “You are missing the prerequisites. Choose another course.”
  9. Mark the course offering as “enrolled” in the schedule.
  10. End do when the Student clicks on “Save Schedule.”
  11. Save the schedule and return to the main selection screen.


Improved Version

Register for Course

  1. Student requests a new schedule.
  2. The system prepares a blank schedule form and pulls in a list of open and available courses from the Course Catalog System.
  3. Student selects primary and alternate courses from the available offerings.
  4. For each course, the system verifies that the Student has the necessary prerequisites and adds the Student to the course, marking the Student as “enrolled” in that course in the schedule.
  5. When the Student indicates the schedule is complete, the system saves the schedule.

4.2.4 Use Cases and Requirements

We will shortly see that common requirements documents are

the latter being more detailed and formal.

Use cases fall somewhere between the two, and are often used as a mechanism for gathering the additional details needed to write the specifications.

4.3 Object-Oriented Analysis

The Object-Oriented philosophy can be summarized as:

  • Every program is really a simulation.

  • The quality of a program’s design is proportional to the faithfulness with which the structures and interactions in the program mirror those in the real world.

In pre-OO, Waterfall and similar processes, at the end of each phase, we set aside the prior set of documentation and sit with blank sheets of paper to begin the next phase “fresh”.

But each new step is, in essence, a fresh start.

There’s a certain wisdom in this. There’s a real danger in making design decisions when writing early requirements, or in having people reading the requirements think that you made a design decision when choosing notations or writing explanations as part of the requirements.

A fresh start helps remind designers that they have the freedom, if not the obligation, to consider alternatives.


But the OO view is very different. If we buy into the OO philosophy, then we take a more evolutionary process.

OOA is largely viewed as a model-building activity:

The result is, eventually, a design that had clear ties to the original model of the world before we started our project.

Model Building

The primary models of Object Oriented Analysis and Design are:

4.3.1 Domain Models


A domain model is a model of the application domain as it currently exists, before we began our new development project. The point of the domain model is to be sure the development team understands the world that the system will work in.

(Fortunately, most companies work in a small number of application domains. If they hired you last month to develop software for analyzing seismic data for petroleum engineering, they are unlikely to ask you to develop a compiler or a word processor next month.)

In that case, the team may already have a good understanding of the domain.

Even if a document describing the domain model is desired, domain models tend to be highly reusable since the world around our software systems usually changes fairly slowly.

Interacting Objects

All OOA models are based on the concept of objects interacting with one another by the exchange of messages (function calls).


Hence, even if we are modeling a physical object or a human being, we write our models in terms of classes with an interface of attributes and operations.


Balance list of Transactions

4.3.2 Analysis Models

An analysis model is a model of how the world will interact with the software system that we envision. As such, it is our statement of just what the system will do when it is working.


There is a real temptation to simply assume that the automated system will simply squat in the middle of the world, interacting with all the real world objects, sort of like this:

Or if you prefer,…

It’s Magic!


Poof! We have an analysis model!

Not wrong, per se, but it’s certainly not helpful.

Such an approach is fundamentally at odds with the OO philosophy, though.

In essence we have not done any analysis at all here. This “model” isn’t wrong, per se, but it’s certainly not helpful. We’ve basically thrown away everything we’ve learned in the domain model about how objects really interact. We’re treating the new program as a simple box, with no knowledge of its internal structure, Essentially, we’ve just deferred all the hard questions to the upcoming design.

Evolving the Analysis Model

What we really hope for is an evolution from our domain model to our analysis model. The OO philosophy tells us that the classes and interactions of our domain model …


… should carry over into our analysis.

In essence, we hope to retain these classes, add more detail to our understanding of them, and to establish a boundary that tells us which of these classes and behaviors will be automated, which will remain entirely unautomated, and which will have some portion automated while other parts remain external.

The Boundary


… establish a boundary that tells us which of these classes and behaviors will

The system, then, remains a collection of interacting objects rather than an unstructured black box.

There’s a definite overlap in the purpose of a requirements document and of an analysis model. Some will regard the analysis model as a kind of requirements specification. In some projects, though, a requirements document will still be required as something for customers or management to sign off on. But the analysis model is the basis from which the eventual requirements document is derived.

The evolutionary approach will carry forward, in an OO-style project, from requirements into design. When building the design model, we will start with the classes (and their APIs/interfaces) and make merely the changes we deem necessary for an effective design.

(OOA is covered in more detail in CS330.)