Steven J Zeil:
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
Developers working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints
May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders
Problems of requirements analysis
Stakeholders don’t know what they really want
(Is this a real problem, or snobbery on the part of software developers? For as often as I see this “problem” listed, I’m never really sure.)
Stakeholders express requirements in their own terms
- Different stakeholders may have conflicting requirements
- Organizational and political factors may influence the system requirements
- The requirements may change during the analysis process.
- New stakeholders may emerge
2 Eliciting Requirements
The process of eliciting requirements is, fundamentally, an exercise in communication between developers and stakeholders.
- Problem 1: Obtaining information
- Problem 2: Organizing the information obtained
3 Obtaining Requirements Information
Common sources are
Reading available documentation
Interviewing the stakeholders…
(i.e., gather the stakeholders around a table for a formal discussion).
Direct observation (a member of the development team)
A member of the development team physically observes the current process in operation.
Interviews may focus on general questions, e.g.,
“What do you do? ”What information do you need to do your job?“, ”What problems are you encountering with the current system?"
Or may seek to elicit scenarios
“Walk me through the process you follow when X happens.”
These interviews can be as much about learning how the current system works as about what is desired from the new system.
- That’s consistent with object-oriented approaches where a domain model is constructed of how the system works now, and that model is gradually evolved into an analysis model of how we would like it to work in the future,
- including the possible automation of processes currently done manually.
- OO practice assumes that the structure of the new system will mirror the structure of the old one to a significant degree, so effort spent modeling the current world is also effort towards modeling the new system.
- Building a quick mock-up of the eventual system
- May ranges from paper mockups of screens to beta-test code
- Providing or displaying the prototype to the stakeholders
It can be an effective method to
- Validate our understanding of the requirements
- Elicit discussion on things that we mis-understood or failed to consider at all.
4 Organizing Requirements Information
4.1 Viewpoint Analysis
- Stakeholders represent different ways of looking at a problem or problem viewpoints.
- This multi-perspective analysis is important as there may be no single correct way to analyze system requirements.
- By approaching requirements from multiple viewpoints, we can identify conflicting requirements among the stakeholders.
4.1.1 Types of viewpoint
Viewpoints are perspectives on the system, not “people who view it”.
Common viewpoints include
Data sources or sinks
Viewpoints responsible for producing or consuming data.
Viewpoints representing particular types of system model.
- May be compared to discover requirements that would be missed using a single representation.
Receivers of services:
Viewpoints external to the system that receive services from it.
- Particularly useful for interactive systems
4.1.2 The VORD method
VORD: Viewpoint-Oriented Requirements Definition
- Viewpoint identification
- Discover viewpoints which receive system services and identify the services provided to each viewpoint
- Viewpoint structuring
- Group related viewpoints into a hierarchy. Common services are provided at higher-levels in the hierarchy
- Viewpoint documentation
- Refine the description of the identified viewpoints and services
- Viewpoint-system mapping
- Transform the analysis to an object-oriented design
Example: Checkbook balancing
Consider the design of software to balance a checkbook:
should accept transactions including
- interest accrued
- service charges
Allow transactions to be confirmed from bank statement
- should show current and confirmed balances
Plausible viewpoints are:
- Account Holder
- Clearing House
- apply transactions
- create/close accounts
- receive transactions
- initiate transactions (charges)
- receive account statement
- initiate transactions
- examine register entries
- get statement balance
- get confirmed & unconfirmed register balances
- confirm transactions from statement
- receive checks
For each viewpoint, we document the data and services that are visible form that viewpoint.
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.
4.2 Use Cases
Use cases have become popular as a means of organizing requirements.
- Often includes in requirements documents
- Specific requirements are often linked back to a use case that explain or justifies them.
A use case is a collection of scenarios.
- It depicts a functionality of the system,
- typically beginning with some external input or action.
- It provides a step-by-step description of a main (success) scenario path.
- It includes extensions / alternative paths.
4.2.1 Writing Use-Cases
- Start with a collection of scenarios
- Group by common user goals
- Define the actors
- Give brief descriptions of use cases
- Give a detailed description of the basic path
- Add alternative paths
Example: grading tests
Grading an Assessment
The scorer begins with an assessment and a collection of response documents.
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.
When all items have been graded, then the scorer computes a total score for each results document.
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
- Claimant submits claim with substantiating data.
- Insurance Company verifies that Claimant owns a valid policy.
- Insurance Company assigns Agent to examine case.
- Agent verifies that all details are within policy guidelines.
- 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:
Overview – natural language description
Actors – list of external entities participating in the use case
Preconditions – list of conditions that must be true before this use case can be invoked.
Scenario(s): specified as a main path and a collection of alternative paths
Postconditions – list of conditions that are expected to be true upon completion of the use case
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
- Pre-conditions are generally omitted if trivial (always true)
- Exceptions can often be re-written as alternative paths
- Post-conditions are often omitted because he desired non-trivial conditions may only hold if the main path succeeeds.
Overview: A candidate attempts to take an assessment. The candidate might or might not finish the assessment within a single session.
Actors: candidate, proctor
- Assessment has been created
- Assessment has been provided to the proctor
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.
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.
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.
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
- Written in customer language
- Focused on a single goal
- Express requirements, not design
A poor use case
Register for Course
- Display a blank schedule.
- 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.
- Student clicks on a course.
- Update the lower window to show the times the course is available.
- Student clicks on a course time and then clicks on the “Add Course” button.
- Check if the Student has the necessary prerequisites and that the course offering is open.
- 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.”
- Mark the course offering as “enrolled” in the schedule.
- End do when the Student clicks on “Save Schedule.”
- Save the schedule and return to the main selection screen.
Too much user interface detail (design)
Too low level.
- Written more from system’s perspective than from customer’s
- Unclear pseudo-code-ish structure
- Poor grammar.
Register for Course
- Student requests a new schedule.
- The system prepares a blank schedule form and pulls in a list of open and available courses from the Course Catalog System.
- Student selects primary and alternate courses from the available offerings.
- 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.
- 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
- Reqts Definitions, and
- Reqts Specifications,
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”.
The records of elicited requirements information serve as references when we start writing the requirements documents.
The requirements documents serve as references when we start writing the design documents.
The design documents serve as references when we start writing the code.
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:
- Start with a model of how the world works now.
- Make just enough changes to that model to explain what we want to change (e.g., via new automation).
- Make just enough additional changes to account for necessary design “compromises”.
The result is, eventually, a design that had clear ties to the original model of the world before we started our project.
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.
The domain model describes the world in terms of objects interacting with one another via messages.
Not every project needs a domain model
e.g., If the team has done several projects already in this application domain, they may already share a common domain model.
(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.
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,…
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.
We should look to the real world to suggest how to decompose our system.
In this case, we have not decomposed it at all – just wrapped it up into a single black box.
All the hard decisions still need to be made.
And we have thrown out any insight we gained from building our domain model.
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.
… establish a boundary that tells us which of these classes and behaviors will
be a mixture of the two
The system, then, remains a collection of interacting objects rather than an unstructured black box.
- We may need to modify our class interfaces to reflect our new understanding, but we don’t need to discard them and start from scratch.
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.)