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…

• Facilitated meetings

  (i.e., gather the stakeholders around a table for a formal discussion).

• Prototyping…

• Direct observation (a member of the development team)

  A member of the development team physically observes the current process in operation.

3.1 Interviews

• 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.

3.2 Prototyping

• 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.

• Representation frameworks:

  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

  • 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:

• Account
• Bank
• Account Holder
• Clearing House

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

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

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.

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

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.

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)

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

• 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.

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:

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.

— 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.

4.2.3 Quality Use Cases

Good use cases are

• Written in customer language
• Validatable
• Focused on a single goal
• Express requirements, not design

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.

Problems:

• 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.

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

• 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.

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:

• 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.

Model Building

The primary models of Object Oriented Analysis and Design are:

• domain model

• analysis model

• design model

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.

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.,

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.

• 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.

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.

• 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.)