W86-T&M-I L5

Types of requirements

Functional requirements

  • What the system does

Non-Functional requirements

  • performance/reliability
  • interfaces
  • design constraints


Use Cases

Ivar Jacobson defines a "Use Case" as "a sequence of transactions performed by the system which yields a measurable result of value for a particular actor"

Use Cases describe "what" the system does

  • Use cases represent an external view of the system
  • Each use case focuses on describing how to achieve a goal or task
  • A complete set of Use Cases describe the scope of the system
    • Support functional requirements

 

Purpose of Use Cases

Use cases are a mature model to capture user (person or system) preferred interaction requirements and begin to establish some of the functional requirements before construction of a new system begins. Proponents prefer them to large, and regard them as an excellent technique for capturing the functional requirements of a system. Proponents cite these advantages:

  • Well written Use cases have proven to be easily understandable by business users, and thus to act as a bridge between them and software developers.
    • Use cases can put requirements in context, describing them in clear relationship to business tasks.
    • Use case diagrams help designers establish previously tacitly understood scope of the business area or the system under development.
    • Use cases do not need to be specified in a special language. They can be written in any style that suits the needs of the project.
    • Use cases can be translated into scenarios ("stories") and test cases which express the analyst's understanding of the business needs in a way that the business user can understand on their own terms.
    • Use cases prompt the consideration and discussion of alternative paths, thus capturing less frequent behavior and so improving system robustness.
  • Uniquely identified use cases can be traced back to business requirements or stakeholder needs.
  • Use case partitioning can be used to organize and structure the requirements model, permitting common behavior to be factored out.
  • Use cases can serve as a basis for the estimating, scheduling, and validating efforts.
  • Use cases are reusable within a project. A use case (like anything) can evolve at each iteration, from a method of capturing requirements, to development guidelines for programmers, to a test case and finally into user documentation.
  • Use cases make it easy to take a staged delivery approach to projects; they can be relatively easily added and removed from a software project as priorities change.
  • Use cases that represent interactions between a user and a system (others will represent interactions between systems) make it possible for user interface designers to become involved in the development process before, or in parallel with, software developers (although use cases are also said to discourage inappropriate premature design).
  • Test cases (user acceptance and functional) can be directly derived from use cases.

 

Use cases have limitations

  • Use case flows are not well suited to easily capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects).
  • Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
  • There is a learning curve involved in interpreting use cases correctly, for both end users and developers. As there are no fully standard definitions of use cases, each group must gradually evolve its own interpretation.
  • Proponents of Extreme Programming often consider use cases too needlessly document-centric, preferring to use the simpler approach of a user story.
  • Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize.
  • Use cases have received some interest as a starting point for test design. Some use case literature, however, states that use case pre and postconditions should apply to all scenarios of a use case (i.e., to all possible paths through a use case) which is limiting from a test design standpoint. If the postconditions of a use case are so general as to be valid for all possible use case scenarios, they are likely not to be useful as a basis for specifying expected behavior in test design. For example, the outputs and final state of a failed attempt to withdraw cash from an ATM are not the same as a successful withdrawal: if the postconditions reflect this, they too will differ; if the postconditions don’t reflect this, then they can’t be used to specify the expected behavior of tests. An alternate perspective on use case pre & postconditions more suitable for test design based on model-based specification.

 

Types

  • The business use case is described in technology free terminology which treats the business process as a black box and describes the business process that is used by its business actors (people or systems) to achieve their goals. The business use case will describe a process that provides value to the business actor, and it describes what the process does.
  •  The system use cases are normally described at the sub process level and specify the data input and the expected data response. The system use case will describe how the actor and the system interact.

Example

Name: Enroll in Seminar

Basic Course of Action:

·         Student inputs her name and student number

·         System verifies the student is eligible to enroll in seminars. If not eligible then the student is informed and use case ends.

·         System displays list of available seminars.

·         Student chooses a seminar or decides not to enroll at all.

·         System validates the student is eligible to enroll in the chosen seminar.  If not eligible, the student is asked to choose another.

·         System validates the seminar fits into the student’s schedule.

·         System calculates and displays fees

·         Student verifies the cost and either indicates she wants to enroll or not.

·         System enrolls the student in the seminar and bills them for it.

·         The system prints enrollment receipt.

 

 

Table of contents

Actors

There are 4 types of actors

  • Role
    • A person in the business environment. NOTE: Not a specific person. A Role that a person would take
  • Organization
    • An external organization which uses the system: Eg. Revenue Canada
  • System
    • An external system which uses the system: Eg. accounting system or legacy system
  • Device
    • An external device which interfaces with the system: Eg. Handheld scanner or door lock

In UML, Actors are shown as a stick man or a "stereotyped" class. The stereotype would be one of <<actor>> <<role>> <<device>> <<organization>> <<system>>



 

Use Case Diagram

Part of the goals of requirement analysis and system analysis are to define the boundaries of the system. The use case diagram helps to show the boundaries in a visual form.

Example drawn on board during lecture

 

Writing Use Cases

This is perhaps the most difficult part of understanding Use Cases. What constitutes a "good" Use case?

  • Describes what the system DOES
    • Does not describe what the system "must" do, "should" do or "could" do.
  • Does not describe HOW the system achieves it's goals
    • Describing HOW is part of design and scenarios are better suited for describing how things work
  • Does NOT describe the User Interface
    • Describes the logical interaction vs physical interaction
    • Eg: "User clicks the 'change password' link" - physical
    • "User indicates that he/she wishes to change his/her password" - logical

Examples provided later in lecture.

 

Identifying Use Cases

  • Identify the goals of each actor
    • What do the actors require from the system?
    • The actor arrives, interacts with the system, then leaves.
  • Review requirements
  • Identify tasks which the system must perform
  • Analyze the roles people fulfill within the business and the tasks they perform