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
|
No comments:
Post a Comment