UNDERSTANDING REQUIREMENTS

Understanding Requirements

Contents

§  Understanding Use case

§  Understanding Functional Specification

§  Difference between FS and Use case

Understanding Use Cases

Contents

§  What is a Use Case?

§  What does a Use Case Contain?

§  Why a Use Case?

§  Structure of a Use Case

§  Use Case Examples

What is a Use Case?

§  Use case is an effective way to document system functionality from a user’s perspective, a perspective that provides both software teams and their customers a common understanding of the expected behavior of the system to build.

§  Use cases are the starting point of object-oriented design, where use case diagrams represent a high level picture of the system functionality.

§  Use cases are an intuitive way of documenting functional system requirements. Because use cases encompass functional requirements, they should be included in the management of all system requirements.

What does a Use Case Contain?

§  Each use case contains  a set of steps that describes the dialog between the actor who typically initiates the use case, and the system accomplishing the functionality described in the use case.

§  This set of steps is often referred to as the flow of events of the use case. Typical use cases have a single basic flow of events, several alternate flow of events and several exceptional flow of events.

§  The basic flow is an expected user interaction with the system while the alternate flows talk about flows other than normal flows and exceptional flows talk about how the system should handle unusual events.

§  These flow of events of a use case puts functional requirements in a context that customers can relate to more easily than traditional formal requirements specification.  This helps customers validate that their needs will be addressed by the system.

§  The flow of events of a use case are written in natural languages. This informality increases the understanding of what the system shall do for both the technical people building the system, and the not-so-technical people using the system.

§  Thus, Use cases effectively address the challenge of communicating requirements to audiences of varying technical levels.

Why a Use Case?

§  Development teams work out their design tasks from the use cases.

§  Use cases provide all and only black-box behavioral requirements that the design must meet. The requirements are to name everything that the system must do without usurping any freedom the designers should have.

§  Use cases serve as handy scenarios when designing the program. They serve well with all design techniques, showing when the design is complete and handling all situations.

§  The use cases shout out the names of the objects / entities involved. Consider the use case phrase

§     System produces an invoice, fills the invoice line items with their costs, adds tax and shipping costs, and produces the total. The invoice footer states terms of delivery.

§   

§      It does not take a great leap of imagination to see Invoice, Invoice Footer with the attributes cost, tax, shipping and footer. These are not necessarily the final design items, but they certainly are a good business objects starter set. They tighten and refine the design.

Structure of a Use Case

§  Use Case Title

Ø   The title of the module / functionality dealt in the use case

§  Brief Description

Ø   Summary of the functionality explained in the use case

§  Pre-Conditions

Ø   Events that should precede the use case

§  Start Conditions (Trigger)

Ø   Conditions that initiate the use case

§  Actors

Ø   Primary : Actor who is primarily dealing with the system

Ø   Secondary : Actor who is benefiting from the system. Could also be another system with which there is an exchange of data

§  Post Conditions

Ø   Events that follow the use case

§  Logical View

Ø   Use case Diagram

Ø   Pictorial representation of the use case

§  Flow of Events

Ø   Basic Flow : Expected user interaction with the system

Ø   Alternate Flows : Flows other than normal flows

Ø   Exception Flows : Flows that handle unusual events / error conditions

Ø   Sub Flows : Flows which are referred to in several other flows (basic / alternate)

§  Data

Ø   Input

Ø   Output

§  Subordinates

Ø   Use cases that are invoked from the current use case

§  Super Ordinates

Ø   Use case that triggers the current use case

§  Business Rules

Ø   They are specialized form of logic that express a constraint about the way the system behaves

§  Special Requirements

Ø   Non-Functional requirements that need specific attention

§  Extension Points

Ø   Lists any use cases that are extended from this one

§  Business User Comments

Ø   Requirements from business point of view

§  Assumptions

Ø   Assumptions with which the use case was written.

§  Issues

Ø   Problems in the use case that need clarification.

§  Revision History

Ø   List of all changes that the use case has undergone from the time of creation. Contains the date, issue description and the author.

•    Use Case Examples

§  Simple Use Case

    Example : Add Student

§  Average Use Case

    Example : Search for an Agent

§  Complex Use Case

    Example : Point of Sale

Understanding Functional Specifications

Contents

§  What is a Functional Specification / What does it Contain?

§  Why a FS?

§  Structure of a FS

§  FS Examples

What is a FS / What does it contain?

§  A Functional specification is a formal description of the requirements of a software

§  It is used as a blueprint for implementing the program.

§  It states what the proposed system is to do keeping in mind the design and to ensure that a realistic system is specified.

§  It clearly defines the UI, functional interfaces, and data requirements of the application.

§  It also defines the external interfaces, performance goals, and other assumptions / constraints that bind the approach to the solution.

Why FS?

§  It provides a ready reference for the entire project team

§  Aligns large and disparate teams to a single goal.

§  Provides technical guidance on how the different modules of a particular application can to be designed and integrated with each other.

§  Ensures that the front end (UI, application controls),  the middle tier (code) and the back end (DB) – fit exactly to provide the required functionality.

§  Drives internal scheduling and external communication.

Structure of a FS

§  FS Title

Ø   The title of the module / functionality dealt in the FS.

§  Introduction

Ø   Summary of the functionality explained in the FS.

§  Scope

Ø   In Scope   

v   Functionality that the FS deals with.

Ø   Out of Scope

v   Functionality and risks that the FS does not cover

§  Dependencies

Ø   Any dependency that this FS has on another FS or external factors. It can also include the pre-conditions for this FS to function.

§  Assumptions

Ø   Assumptions with which the FS was written.

§  Process Flow

Ø   The details of the functionality. This section gives the implementation details.

§  Prototype

Ø Details about the UI of the application are described along with screen shots of the prototype.

§  Terminology

Ø Contains all words or phrases having a special meaning for this project with a clear definition.

§  Security

Ø Security related details. Example : Application level, database security are described.

§  Numbers and User Community

Ø Number of users to use the system, how often, expected number of transactions (per minute / hour / day), peak usage times and so on.

Ø Identification of who the system is aimed at.

§  Existing System

Ø An explanation of the system that may be getting replaced. The problems faced with this system and their root causes.

§  External Interfaces

Ø The external interfaces with which the system interacts.

§  Use Case Model

Ø Any use case models that this FS is referring to.

§  Administration Functions

Ø Provides the details of how the system is to be administered. Separate functions for an administrator if any. Details of any security built in to stop others using administrative functions .

§  Error Handling

Ø States how errors should be handled. The different types of errors along with the reasons for the classification is given.

§  Platforms

Ø The reference platform or platforms plus appropriate operating system versions that are supported.

§  Internationalization

Ø Details about any Internationalization. Whether it is to be included now or in the future.

§  Performance

Ø Performance requirements i.e. Capacity, Response times and so on.

§  Portability, Expandability

Ø Any requirement to port developments to other platforms and the likely expansion requirements.

§  Customization

Ø If the user is to be allowed to customize the system, what is he going to be provided.

§  Support and Maintenance

Ø Any functions to be included to make maintenance and support easier, for example, internal monitoring of traffic flows and so on.

§  Configuration Management

Ø Details about how the various software versions would be managed.

§  Documentation

Ø List of documents that will be produced.

§  Issues

Ø Problems in the FS that need clarification

§  Schedule

Ø The schedule for the development and test.

§  Traceability Matrix

Ø Gives the traceability between this document and reference documents used like Design documents, Business requirements documents and so on.

§  Revision History/Approvals

Ø List of all changes that the FS has undergone. Contains date, change description and the author. The Approval section contains the details about the approver of this document and the approval status.

Difference between FS and Use Cases

The high level differences are listed below:

Functional Specification	Use Cases
Speaks a very technical language	Uses layman language
Prepared keeping the design in mind	Independent of design and implementation
Cannot be prepared when only the high level requirements are known	Can be prepared in a stage where only the high level requirements are known
Gives all the technical details	Concentrates on the functional requirements