Relationship to Textbook

• This lecture is partially based on material in Chapter 3 of the Jalote textbook

In this Lecture

• Use Cases
• Validation
• Metrics

Use Cases

• Use Cases are a text-based technique for specifying functional requirements via the use of scenarios
• Our book does an OK job of presenting this topic, but the best reference on Use Cases that I've found is
  • Writing Effective Use Cases by Alistair Cockburn. ISBN: 0-201-70225-8
• As a result, I'll be basing my material on Use Cases for this lecture on that book

Use Case Terminology

• Use Case Model
  • consists of actors and use cases
• Actors
  • entities which interact with a system
  • Actors are different from users
    • An actor represents a role that a user can play
    • Actors are classes; Users are instances
    • Actors are unlike other objects in that their behavior is non-deterministic
• Use Cases
  • An actor can carry out many different operations on the system
  • Each operation or task is a separate use case
  • Use cases participate in relationships with other use cases
    • They might use or include another use case
    • They might extend another use case
    • They might generalize or specialize another use case

Use Cases as Requirements

• The set of use case descriptions specifies the complete functional requirements of a system
• Things to remember
  • Use cases are requirements BUT they are not all of the requirements
    • Not good for specifying user interfaces, data formats, business rules, non-functional requirements
  • They are not easy to write!
    • But there are techniques to make your job easier
    • Analogy: A good story is easy to read, but writing a good story is hard!

More on Use Cases

• A use case captures a contract between the stakeholders of a system about its behavior
  • The use case is initiated by the primary actor; secondary actors may come into play while the use case is executing
  • Note: actors are not restricted to human beings, other computer systems may serve as secondary actors
• The primary actor is trying to achieve a goal
  • Many things may happen; the goal can be achieved (in more than one way) or the use case may fail (also, in more than one way)
  • A use case captures all of these possible scenarios
• Use Cases are primarily textual
  • We shall review a graphical notation for use cases; this notation is useful for specifying relationships between use cases and actors
  • It is inappropriate, however, for specifying the details of a use case
• Writing good use cases is thus a question of style; some writing styles are more effective than others

Parts of a Use Case

• A use case can be as simple as
  • a paragraph of informal text
• to
  • template-based forms that remind developers what information to include
• What to use depends on the ceremony level of the project
  • high ceremony projects will tend towards formal templates
  • mid ceremony projects will use forms with some or all of the recommended fields

Parts of a Use Case

Primary Actor	Goal in Context
Scope	Level
Stakeholders and Interests	Precondition
Minimal Guarantees	Success Guarantees
Trigger	Main Success Scenario
Extensions	Technology and Data Variations List
Priority	Releases
Response Time	Frequency of Use
Channel to Primary Actor	Secondary Actors
Channels to Secondary Actor	Open Issues

Highlights from Parts List

• Primary Actor
  • Actor that initiated use case
• Goal Level
  • Can be one of “very high summary”, “summary”, “user goal”, “sub-function”, and “too low”
  • Rule of Thumb
    • a user goal is one that can be completed in one sitting at a computer
    • a summary goal is one that cannot be completed in one sitting, and may require multiple people, organizations, and systems interacting to achieve the goal
• Main Success Scenario
  • How do we accomplish the goal successfully
• Extensions
  • How might the main success scenario be altered and
    1. still succeed, or,
    2. fail

Examples

Use Case Narratives

Use case narratives are used to motivate the existence of a use case. They are not use cases themselves!

User-Level Use Case

Summary-Level Use Case

Low-Ceremony Use Case

High-Ceremony Use Case

Graphical Notation

Actors and Goals

• Actors and Goals is a model Cockburn developed to help understand use cases; the model can help clarify how we think about and write use cases
• An actor has goals
  • To achieve a goal an actor has to take actions
  • Achieving a goal may require accomplishing sub-goals
  • Achieving sub-goals may require the support and collaboration of secondary actors
  • An action may call upon the responsibilities of a secondary actor; this sets up an interaction where the calling actor must wait for the secondary actor to achieve the goals associated with that responsibility

Actors and Goals Illustrated

The Writing Process

• Cockburn recommends the following process for writing use cases
  1. Name the system scope and boundaries
  2. Brainstorm and list the primary actors
  3. Brainstorm and exhaustively list user goals for the system
  4. Capture the outermost summary use cases to see who really cares
  5. Reconsider and revise the summary use cases. Add, subtract, or merge goals
• Then:
  1. Select one use case to expand
  2. Capture stakeholders and interests, preconditions, and guarantees
  3. Write the main success scenario
  4. Brainstorm and exhaustively list the extension conditions
  5. Write the extension-handling steps
• Loop until all functional requirements have been specified

Requirements Validation

• As we have mentioned, it is very important to detect errors made in the requirements phase as soon as possible
• Requirements engineering is a process that is prone to misunderstandings between clients and developers and this can lead to errors in the SRS
• The most common types of errors found in requirements specs are
  • Errors of Omission: A requirement on the system did not make it into the SRS
  • Inconsistency Errors: One requirement in the SRS contradicts another.
  • Incorrect Facts: An assertion in the SRS, stated as fact, turns out to be wrong
  • Errors of Ambiguity: A requirement in the SRS can be interpreted in multiple ways
• Jalote sites two studies on the errors in requirements specs.
  • The first looked at a data processing application and found over 250 errors in its SRS. Of these errors, 26% were omission errors, 38% were inconsistencies, 10% were incorrect facts, and 26% involved ambiguous requirements.
  • The second looked at a real-time flight control system known as A-7. Approximately 80 errors were found in its SRS. 23% of these errors were clerical in nature (i.e. typos), for the remainder, 32% were omission errors, 13% were inconsistencies, 49% were incorrect facts, and 5% involved ambiguous requirements.

Inspections to the Rescue!

• How do we validate an SRS? Inspections!
• An inspection of an SRS should include the author of the requirements document, the client, a designer, and an end-user
• SRS inspections have been shown to discover a significant amount of requirements errors. In the A-7 project, 33% of the errors in the SRS were detected by inspections. An additional 45% of the errors in the SRS were then detected during the design phase, as the design documents were being created and validated

Metrics

• Metrics during the requirements analysis phase are a mixed bag due to the wide variation in the use of analysis techniques and the structure of SRSs by different organizations
• With respect to quality, Jalote suggests that two process-based metrics can provide insight into the requirements analysis phase
  • Number of Errors Found: This metric can be tracked after the first requirements review and then monitored after each subsequent review. If your process is under statistical control the numbers that you receive with this metric can help you assess if the SRS of your current project is of similar or better quality than specifications produced in the past
  • Change Request Frequency: This metric tracks how many requirements changes per week, month, iteration, etc. are submitted to your requirements change management process once your development project is in design and/or implementation. Such a metric can provide insight into the stability of the entire set of requirements and can aid a team in making better stability estimates in future projects
• Otherwise, the only other metric covered by Jalote with respect to requirements analysis is function points

Function Points

• A key problem after the creation of an SRS is estimating the development effort and schedule required to implement a system that will meet its requirements
• Recognizing that a primary factor that determines the cost and schedule of a project is its size, a metric known as function points was devised that attempts to predict a system's size based on the functionality documented in an SRS
  • Past efforts attempted to use the physical size of the SRS such as number of pages, number of paragraphs, to make this prediction but these metrics were found to be of little value due to the variability of the writing styles of software analysts
• The idea behind function points is that the functionality of a system is a good predictor of its size.
  • Since functionality is independent of writing styles, function points have a better chance of producing meaningful numbers
  • Note: it has since been shown that function points are accurate for data processing applications (aka information systems) and are used widely in that domain

Calculating Function Points

• Function Points are calculated on the basis of five different parameters across three levels of complexity
• The five parameters are
  • external input types: unique input type provided by the system's users
  • external output types: unique output types generated by the system
  • logical internal file types: a data structure used by the system internally to implement its functionality
  • external interface file types: files passed between the system and other applications
  • external inquiry types: input-output pair that is processed by the system in real-time
• Each individual instance of one of these types is then classified as either:
  • simple
  • average
  • complex
• Function points then provides a table of weights (see Table 3.3) for each parameter and complexity type
  

  Function Type	Simple	Average	Complex
  External Input	3	4	6
  External Output	4	5	7
  Logical Internal File	7	10	15
  External Interface File	5	7	10
  External Inquiry	3	4	6

• Once you have analyzed a specification for instances of the above parameters and you have classified each of the instances, you can calculate the unadjusted function point score using the following algorithm:
  

  for i in each parameter
      for j in each classification
          UFP = UFP + weight[i][j] * count[i][j]

• Example: Given an SRS that contains 3 simple external inputs, 2 complex external inputs, 1 average external output, 2 average logical internal files, and 2 complex external inquiries. The UFP score for this SRS would be:

  Item	Equation	Score
  3 simple external inputs	3 * 3	9
  2 complex external inputs	2 * 6	12
  1 average external output	1 * 5	5
  2 average logical internal files	2 * 10	20
  2 complex external inquiries	2 * 6	12
  Final UFP		58

• You then adjust this score, by taking into consideration 14 different environmental factors, classifying each factor on a scale of 0 (insignificant influence) to 5 (strong influence). Each of these classifications are added together to produce a number N, which is used to compute the complexity adjustment factor: CAF = 0.65 * 0.01N
  

  Environmental Factors
  data communications	distributed processing
  performance objectives	operation configuration load
  transaction rate	on-line data entry
  end user efficiency	on-line update
  complex processing logic	re-usability
  installation ease	operational ease
  multiple sites	desire to facilitate change

• Example: Assume we classified two of these factors as 5 and the rest as 1.
  N would equal 5 + 5 + 12 = 22. Given that, CAF would equal 0.65 * 0.01(22) = 0.143
• This number is then used to calculate the Delivered Function Points score: DFP = CAF * UFP
  • Example: Our Delivered Function Points would be 58 * 0.143 = 8.294
• At this point, you can use the results of previous studies that show that a single function point corresponds to 125 lines of C code or 50 lines of C++ or Java code to gain an estimate of the total size of a software project based on its SRS
  • Example: With a DFP of 8.294, we would then estimate that the program described by our SRS would be approximately 1037 lines of C code or 412 lines of C++ or Java code.

Problems with Function Points

• As mentioned, studies have shown that function points are an accurate metric for data processing applications
• But they are less accurate in other domains
• The key problem is, of course, analyst subjectivity
  • There is no guarantee that two analysts looking at the same specification will produce the same list of items for each of the five parameters with each instance classified in the same way
• However, proponents of function points argue that the subjectivity of an analyst can be reduced over time with experience...

Summary

• We have spent the last three lectures looking at a range of issues related to the software requirements phase of a software development project
  • Problem Context and Problem to be Solved
  • Shared Phenomena between Problem Domain and Machine
  • Analysis Techniques
    • Informal
    • Data Flow Modeling
    • Object-Oriented Modeling
    • Prototyping
  • SRS Characteristics
  • Requirements Validation
  • Metrics related to Software Requirements

Coming Up Next

• Lecture 12: Shared Objects and Mutual Exclusion