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
Stakeholders express requirements in their own terms
The process of eliciting requirements is, fundamentally, an exercise in communication between developers and stakeholders.
Common sources are
Reading available documentation
Interviewing the stakeholders…
Facilitated meetings
Prototyping…
Direct observation (a member of the development team)
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?"
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.
It can be an effective method to
Viewpoints are perspectives on the system, not “people who view it”.
Common viewpoints include
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 are perspectives on the system, not “people who view it”.
Common viewpoints include
Data sources or sinks
Viewpoints responsible for producing or consuming data.
Representation frameworks:
Viewpoints representing particular types of system model.
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.
Representation frameworks:
Viewpoints representing particular types of system model.
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.
Representation frameworks:
Viewpoints representing particular types of system model.
Receivers of services:
Viewpoints external to the system that receive services from it.
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.
Representation frameworks:
Viewpoints representing particular types of system model.
Receivers of services:
Viewpoints external to the system that receive services from it.
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
Services:
- create/close accounts
- receive transactions
- initiate transactions (charges)
Sub-VPs:
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
Use cases have become popular as a means of organizing requirements.
A use case is a collection of scenarios.
Example: grading tests
Grading an Assessment
Actors: Scorer
Main Path
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.
Example:
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.
Extensions
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.
(Adolph)
Lots of local variations:
Title
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
Example
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
Preconditions:
- Assessment has been created
- 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.
— Alternatives
Unavailable
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.
Good use cases are
A poor use case
Register for Course
A poor use case
Register for Course
- Display a blank schedule.
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.
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.
- Do
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.
- Do
- Student clicks on a course.
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.
- Do
- Student clicks on a course.
- Update the lower window to show the times the course is available.
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.
- Do
- 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.
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.
- Do
- 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.
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.
- Do
- 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.”
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.
- Do
- 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.
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.
- Do
- 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.”
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.
- Do
- 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.
Problems:
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.
- Do
- 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.
Problems:
Too much user interface detail (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.
- Do
- 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.
Problems:
Too much user interface detail (design)
Too low level.
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.
- Do
- 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.
Problems:
Too much user interface detail (design)
Too low level.
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.
- Do
- 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.
Problems:
Too much user interface detail (design)
Too low level.
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.
- Do
- 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.
Problems:
Too much user interface detail (design)
Too low level.
Improved Version
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.
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.
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.
Evolution
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:
domain model
analysis model
design model
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.
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.
E.g.,
Transaction |
---|
date number relatedAccount amount |
apply(toBalance) |
Checkbook |
---|
Account Balance list of Transactions |
add(Transaction) cancel(Transaction) balanceAgainst(Statement) |
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.
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.
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.
retain these classes
add more detail to our understanding of them, and …
The Boundary
… establish a boundary that tells us which of these classes and behaviors will
be automated
remain external
be a mixture of the two
The system, then, remains a collection of interacting objects rather than an unstructured black box.
(OOA is covered in more detail in CS330.)