1

Helping Material
Software Requirement
Specifications

1. Project Scope...................................................................................................................3
1.1 What is project scope?...............................................................................................3
1.2 How Scope is usually defined....................................................................................3
1.3 Write a scope statement.............................................................................................3
1.3.1 The project justification information..................................................................3
1.3.2 Identify the project product................................................................................3
1.3.3 Identify the project deliverables.........................................................................3
1.3.4 Identify the project objectives............................................................................3
1.4 Sample Scope Statement [3].................................................................................3
2. Functional and Non Functional Requirement..................................................................3
2.1 Software Requirements Definitions...........................................................................3
2.2 Importance of Requirements......................................................................................3
2.3 Role of Requirements................................................................................................3
2.4 Levels of Software Requirements..............................................................................3
2.4.1 Business Requirements:......................................................................................3
2.4.2 User Requirements:............................................................................................3
2.4.3 Functional Requirements:...................................................................................3
2.5 Non-Functional Requirements...................................................................................3
2.6 Stakeholders...............................................................................................................3
3. Use Case Diagrams..........................................................................................................3
3.1. Components:.............................................................................................................3
3.1.1 Actors:.................................................................................................................3
3.1.2 Use Cases:...........................................................................................................3
3.1.3 Associations:.......................................................................................................3
3.1.4 System boundary:...............................................................................................3
3.1.5 Relationship between Use cases.........................................................................3
3.2. Use Case Diagram:...................................................................................................3
4.0 Usage Scenario..............................................................................................................3

3
1. Project Scope
1.1 What is project scope?
Project scope is the work that needs to be accomplished to deliver a product, service, or
result with the specified features and functions. Scope Plays a Vital Role in Projects.
"Scope" includes the expected work effort and results for a given project, and must be
documented and accepted before the project begins.
1.2 How Scope is usually defined
Defining the project scope is a challenging job. All projects are defined by their goals,
objectives, boundaries and constraints. Getting a detailed but clear picture of your
project scope will put you toward completing your project successfully.
Goals and objectives define what has to be done. A goal is simply a broad statement of
what you want to do. The objectives are sub-goals, more detailed, that explain what must
be done to achieve the goal. Your project should have only one goal, but may have
several objectives.
Here is an example of a goal with several objectives.

Goal (more broad): We want to move the office to Houston, Texas.

Objective (more specific): Locate an office in Houston.

Objective (more specific): Arrange for personnel and equipment transfer

Objective (more specific): Transfer equipment and furnishings

Objective (more specific): Transfer personnel

Objective (more specific): Maintain business-as-usual during the transition

Project Boundaries identify inclusions and exclusions -- things that we do or don't want
to do in conjunction with the goals and objectives. These are things that may not be
related to the project, but that must be considered anyway. For example:

Personnel not wishing to transfer will be replaced and arrangements made for
outplacement.
Company vehicles will be sold and replaced with new ones in Houston.

Disposal of current facilities is not part of this project.

Project Constraints define cost, schedule, or quality requirements. These may include
budget limitations or schedule requirements or minimum acceptability. For example:

The cost of the entire move can't exceed 50,000.

The move must be completed during the month of June, next year.

Payments on outplacement services can't exceed 1200 per employee.

The new Offices must support 200 office workers.

5
1.3 Write a scope statement
A comprehensive scope statement is a key section. It is an agreement that defines the
work of the project and the customer's business objectives. A comprehensive scope
statement can help you identify changes in scope after the project has started and help
you plan for any modifications or adjustments that might be needed during the life cycle
of the project.
A well-written scope statement is crucial to a project. You create a project scope
statement to establish a solid agreement between the project team and the customer by
clarifying, identifying, and relating the work of the project to the business owner's
objectives. The two parties reach an agreement by explaining the need or issue to be
resolved by the project, what the product or deliverables will include, and what potential
costs, gains, and success measures are involved.
Writing a successful scope statement means that you include:

Project justification
Project product

Project deliverables

Project objectives

You should have the scope statement reviewed and approved by the both the project
sponsor and the customer.
To write a scope statement, include the following criteria:
1.3.1 The project justification information
The project justification describes a problem to be resolved, an opportunity to be
exploited, or a benefit to be obtained. You always derive the project justification from the
strategic objectives of the parent organization. The following are examples of project
justification:

Market demand
Business need

Customer request

Technological advance

Legal requirement

The project justification needs to be clear and precise, and you should include both
qualitative and quantitative measures.

6
1.3.2 Identify the project product
Define possible solutions to your problem (for example, the project justification);
specifically, identify the solution that you selected for your project. The project product is
a summary of the product description and includes:

Work required to resolve the problem and achieve the benefits.

Work that falls outside the project scope.

Interactions with other projects.

It is crucial that you identify work that might fall outside or inside the project scope.
Identifying the inclusion and exclusions is important because it enables you to set
expectations with your customer and project team.
Note: If you clearly identify exclusions at the beginning of a project, future projects are
more easily identified.
1.3.3 Identify the project deliverables
List the summary-level sub deliverables of the project for which full and satisfactory
delivery would mark the completion of the project. These include the project deliverables
and the high-level Work Breakdown Structure (WBS).
Rather than breaking the work of the project into a list of low-level deliverables and
details, identify high-level deliverables so that project reviewers can readily focus on the
business problems that the project is trying to resolve.
1.3.4 Identify the project objectives
Identify project objectives that you can define as quantifiable criteria.
The project objectives must:

Address all the work within the scope of the project.

Not address work outside the scope of the project.

Note: Unquantifiable objectives, such as customer satisfaction, involve high risk.

1.4

Sample Scope Statement [3]

Project Title: Project Management Intranet Site Project

Project Justification: Joe expertise to current and potential clients though the sections of
the intranet that will be accessible to them. It will also help improve profitability by
reducing internal costs by providing standard tools and techniques, templates, and project
management knowledge to all internal consultants.

7
Product Characteristics/Requirements:
1. Templates and tools: The intranet site will allow authorized users to download
files to assist them in created project-management documents and using
project management tools. These files will be in Microsoft Word, Excel,
Access, Project, html, or PDF format, as appropriate.
2. User submissions: Users will be encouraged to e-mail files with sample
templates and tools to the Webmaster. The Webmaster will forward the files to
the appropriate person for review and then post the additional files, if desired.
3. Articles: Any articles posted on the site will have appropriate copyright
permission. The preferred format for articles will be in PDF files. The project
manager may approve other formats.
4. Requests for articles: The intranet site will include a section for users to
request someone from the Project Management Office (PMO) at JWD
Consulting to research appropriate articles for them. The PMO manager must
first approve the request and negotiate payments, if appropriate.
5. Links: All links to external sites will be tested on a weekly basis. Broken links
will be fixed or removed within five working days of discovery.
6. The Ask the expert feature must provide a user-friendly screen to solicit
questions, immediate acknowledgement that the question has been received in
the proper format, forwarding of the question to the appropriate expert, as
maintained in the systems expert database, and status of answering the
question. The system must also allow for payment for advice, if appropriate.
7. Security: The site must provide several levels of security. All internal
employees will have access to the entire site when they enter their security
information for the main corporate intranet. Part of the site will be available to
the public from the corporate Web site. Other portions of the site will be
available to current clients based on verification with the current client
database. Other portions of the site will be available after negotiating a fee or
entering a fixed payment using pre-authorized payment methods, as described
in Appendix A.
8. Search feature: The site must include a search feature for users to search by
topic, key words, etc.
9. The site must be accessible using a standard Internet browser. Users must
have appropriate application software to open several of the templates and
tools.
10. The site must be available 24 hours a day, 7 days a week, with one hour for
system maintenance and other periodic maintenance, as appropriate.

8
Summary of Project Deliverables:
Project management-related deliverables: (business case, charter, team contract, scope
statement, WBS, schedule, cost baseline, status reports, final project presentation, final
project report, lessons learned report, etc.)
Product-related deliverables:
1. Survey: Survey current consultants and clients to help determine desired content
and features for the site.
2. Files for templates: The initial site will include templates for the following items:
(business case, charter, etc.)
3. Examples of completed templates: The initial site will include examples of
projects that have used templates for the following items: business case, charter,
etc.
4. File for tools: The initial site will include information on how to use several
project management tools, including, as a minimum, the following: work
breakdown structures, critical path analysis, cost estimates, earned value
management, etc. Where appropriate sample files will be provided in the
application software appropriate for the tool.
5. Example applications of tools: The initial site will include examples of projects
that have applied tools for the following items: work breakdown structures,
critical path analysis, cost estimates, earned value management, etc.
6. Articles: The initial site will include at least ten useful articles about relevant
topics in project management.
7. Links: The initial site will include links along with brief descriptions of the site
being linked to for at least twenty useful sites. The links will be categorized into
meaningful groupings.
8. Expert database: In order to deliver an Ask the Expert feature, the system must
access a database of approved experts, their contact information, etc.
9. User request: The site will include an application to solicit and process requests
from users.
10. Intranet site design: An initial design of the new site will include a site map,
suggested formats, appropriate graphics, etc.
11. Intranet site content: The initial site will include content for the templates and
tools section, articles section, links section, Ask the Expert section, user
requests, security, and payment features.
12. Test plan: The test plan will document how the site will be tested, who will do the
testing, how bugs will be reported, etc.
13. Site promotion: A plan for promoting the new site will describe various
approaches for soliciting inputs while designing the site as well as announcing the
availability of the new site.
14. Project benefit measurement plan: A plan for measuring the financial value of the
site.
Project Success Criteria: Our goal is to complete this project within six months for no
more than 140,000. The project sponsor, Joe Fleming, has emphasized the importance of
the project paying for itself within one year after the site is completed. In order to meet

9
this financial goal, the site must be designed with strong user inputs, and we must
develop a method for capturing the benefits of the site while it is being developed, tested,
and after it is rolled out. If the project takes a little longer to complete or costs a little
more than planned, it will still be viewed as a success if it has a good payback and helps
promote our companys image as a world-class consulting organization.
Reference:
1. http://office.microsoft.com/en-us/project-help/write-a-scope-statementHA001142472.aspx
2. http://www.managingsmallprojects.com/define-the-project-scope.html
3. www.augsburg.edu/ppages/~schwalbe/scope_statement.doc

10

2. Functional and Non Functional Requirement

2.1 Software Requirements Definitions
Before talking about the requirement process in general and discussing different tools and
techniques used for developing a good set of requirements, let us first look at a few
definitions of software requirements.
Jones defines software requirements as a statement of needs by a user that triggers the
development of a program or system.
Alan Davis defines software requirements as a user need or necessary feature, function,
or attribute of a system that can be sensed from a position external to that system.
IEEE defines software requirements as:
A condition or capability needed by user to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a system or system component
to satisfy a contract, standard, specification, or other formally imposed document.
As can be seen, these definitions slightly differ from one another but essentially say the
same thing: a software requirement is a document that describes all the services provided
by the system along with the constraints under which it must operate.
2.2 Importance of Requirements
Many of the problems encountered in development are attributed to shortcoming in
requirement gathering and documentation process. We cannot imagine start building a
house without being fully satisfied after reviewing all the requirements and developing all
kinds of maps and layouts but when it comes to software we really do not worry too
much about paying attentions to this important phase. This problem has been studied in
great detail and has been noted that 40-60% of all defects found in software projects can
be traced back to poor requirements.
Fred Brooks in his classical book on software engineering and project management The
Mythical Man Month emphasizes the importance of requirement engineering and writes:
Let us try to understand this with the help of an analogy of a house. If we are at an
advanced stage of building a house, adding a new room or changing the dimensions of
some of the rooms is going to be very difficult and costly. On the other hand if this need
is identified when the maps are being drawn, one can fix it at the cost of redrawing the
map only. In the case of a software development, we experience the exact same
phenomenon - if a problem is identified and fixed at a later stage in the software
development process, it will cost much more than if it was fixed at and earlier stage.
2.3 Role of Requirements
Software requirements document plays the central role in the entire software
development process. To start with, it is needed in the project planning and feasibility
phase. In this phase, a good understanding of the requirements is needed to determine the
time and resources required to build the software. As a result of this analysis, the scope of
the system may be reduced before embarking upon the software development.
Once these requirements have been finalized, the construction process starts. During this
phase the software engineer starts designing and coding the software. Once again, the
requirement document serves as the base reference document for these activities. It can

11
be clearly seen that other activities such as user documentation and testing of the system
would also need this document for their own deliverables.
On the other hand, the project manager would need this document to monitor and track
the progress of the project and if needed, change the project scope by modifying this
document through the change control process.
2.4 Levels of Software Requirements
Software requirements are defined at various levels of detail and granularity.
Requirements at different level of detail also mean to serve different purposes. We first
look at these different levels and then will try to elaborate the difference between these
with the help of different examples.

2.4.1 Business Requirements:

These are used to state the high-level business objective of the organization or customer
requesting the system or product. They are used to document main system features and
functionalities without going into their details. They are captured in a document
describing the project vision and scope.

2.4.2 User Requirements:

User requirements add further detail to the business requirements. They are called user
requirements because they are written from a users perspective and the focus of user
requirement describe tasks the user must be able to accomplish in order to fulfill the
above stated business requirements. They are captured in the requirement definition
document.

2.4.3 Functional Requirements:

The next level of detail comes in the form of what is called functional requirements. They
bring-in the systems view and define from the systems perspective the software
functionality the developers must build into the product to enable users to accomplish
their tasks stated in the user requirements - thereby satisfying the business requirements.
Functional requirements define the internal workings of the software: that is, the
calculations, technical details, data manipulation and processing and other specific
functionality. They are supported by non-functional requirements, which impose
constraints on the design or implementation (such as performance requirements, security,
quality standards, or design constraints). Functional requirements capture the intended
behavior of the system. This behavior may be expressed as services, tasks or functions
the system is required to perform.
Typically, a requirements analyst generates functional requirements after building use
cases. However this may have exceptions since software development is an iterative
process and sometimes certain requirements are conceived prior to the definition of the
use cases. Both artifacts (use cases documents and requirements documents) complement
each other in a bidirectional process.
A typical functional requirement will contain a unique name and number, a brief
summary. This information is used to help the reader understand why the requirement is
needed, and to track the requirement through the development of the system.

12
The core of the requirement is the description of the required behavior, which must be a
clear and readable description of the required behavior. This behavior may come from
organizational or business rules, or it may be discovered through elicitation sessions with
users, stakeholders, and other experts within the organization. Many requirements will be
uncovered during the use case development. When this happens, the requirements analyst
should create a placeholder requirement with a name and summary, and research the
details later, to be filled in when they are better known.
Software requirements must be clear, correct, unambiguous, specific, and verifiable.
Functional requirements are typically phrased with subject/predicate constructions, or
noun/verb. "The system prints invoices."
Non-functional requirements may be found in adverbs or modifying clauses, such as
"The system prints invoices *quickly*"
Or
"The system prints invoices *with confidentiality*".
From a mathematical point of view, a "function" takes an input(s) and yields an output(s).
"Functional" refers to the set of functions the system it to offer, while "non-functional"
refers to the manner in which such functions are performed.
Following are IEEE definitions:
Functional requirement: A system/software requirement that specifies a function that a
system/ software system or system/software component must be capable of performing.
These are software requirements that define behavior of the system, that is, the
fundamental process or transformation that software and hardware components of the
system perform on inputs to produce outputs.
Functional Requirements are a key area of project management and they are very
important system requirements in the system design process. These requirements are the
technical specifications, system design parameters and guidelines, data manipulation,
data processing, and calculation modules etc, of the proposed system.
Functional Requirements are in contrast to Non-Functional Requirements which are
descriptive of the parameters of system performance, quality attributes, reliability and
security, cost, constraints in design/implementation, etc. The key goal of determining
functional requirements is to capture the required behavior of a system in terms of
functionality.
Listed below are a total of fifty examples of functional requirements. These examples are
from five basic systems:

Accounts Payable
Purchasing
Sales
Human Resources
Finance

Accounts Payable
The following is a running list of possible Accounts Payable functional requirements
examples:
Supports three way matching - purchase order, receipts, and supplier invoices
Supports the option to place an individual invoice on hold

13

Allows for modifications to invoice account distribution after processing

Supports the partial payment of invoices
Supports the vendor payments without purchase orders
Vendor return processing is fully integrated with the warehouse and accounts
payable functionality
Vendor return processing provides the user the ability to tie the return to a specific
purchase order
Vendor return processing supports return of roods received against closed
purchase orders
Supports the linkage of the return's debit memo to a single purchase order
Supports basic Internet based purchasing functionality

Purchasing
The following is a running list of possible Purchasing functional requirements:
Supports user defined vendor types
Supports unique vendor address and contact information for vendor corporate
address, remit to address, and ship to address
Supports automatic purchase order generation default by vendor
Supports minimum and maximum receipt allowances by vendor
Supports tracking of last price paid for an item
Supports calculation of purchased price variances (PPV)
Supports online inquiry or report to compare actual vs. expected purchase costs
Allows purchase order price to default to last amount paid
Tracks vendor performance on late deliveries
Tracks vendor performance on order fill rates
Sales
The following is a running list of Possible Sales functional requirements:
Application must capture appropriate information and produce comparative
analysis reports
Application must capture appropriate information and produce trend analysis
reports
Trend analysis by customer and product, including profitability by customer
Monthly detail by customer and invoice
Graphic trend charts by customer, salesman, product type, and others Sales of
products by vendor, by zip code.
Sales by source code (for mail order companies)
Sales analysis by state
Daily activity report
Human Resources

14
The following is a running list of Possible Human Resources functional
requirements:
Tracks employee sick and personal time allowed versus time taken
Supports the tracking of individual employee date of hire and anniversary dates
Supports the tracking of time and attendance reporting for hourly employees
Supports the tracking of time and attendance reporting for salary employees
Supports integration of time and attendance functionality to the manufacturing
plant floor schedule
Supports printing of payroll checks
Supports the tracking of federal payroll tax processing
Supports the tracking multi-state and providence payroll tax processing
Federal, state, and providence based payroll tax tables are included with Software
Sale and Post-Sale Updates Provided
Supports employee tax accruals and reports
Finance
The following is a running list of Possible Finance: General Ledger functional
requirements:
Supports user defined general ledger account structure
Allows two or more accounting periods to be open at one time
Allows for automatic period close processing
Supports the automatic close of income and expense accounts to retained earnings
Supports automatic year-end processing
Allows the user to run year-end more than once
Standard report for chart of accounts
Standard report for comparative balance sheets for individual period review
Standard report for cash flow
User defined financial reports
Allows prior period adjustment

2.5 Non-Functional Requirements

Non-functional requirement play a significant role in the development of the system. If
not captured properly, the system may not fulfill some of the basic business needs. If
proper care is not taken, the system may collapse. They dictate how the system
architecture and framework. As an example of non-functional requirements, we can
require software to run on Sun Solaris Platform. Now it is clear that if this requirement
was not captured initially and the entire set of functionality was built to run on Windows,
the system would be useless for the client. It can also be easily seen that this requirement
would have an impact on the basic system architecture while the functionality does not
change.

15
Let us now look at an example to understand the difference between these different types
of requirements.
Let us assume that we have a word-processing system that does not have a spell checker.
In order to be able to sell the product, it is determined that it must have a spell checker.
Hence the business requirement could be stated as: user will be able to correct spelling
errors in a document efficiently. Hence, the Spell checker will be included as a feature in
the product.
In the next step we need to describe what tasks must be included to accomplish the
above-mentioned business requirement. The resulting user requirement could be as
follows: finding spelling errors in the document and decide whether to replace each
misspelled word with the one chosen from a list of suggested words. It is important to
note that this requirement is written from a users perspective.
After documenting the users perspective in the form of user requirements, the systems
perspective: what is the functionality provided by the system and how will it help the user
to accomplish these tasks. Viewed from this angle, the functional requirement for the
same user requirement could be written as follows: the spell checker will find and
highlight misspelled words. It will then display a dialog box with suggested
replacements. The user will be allowed to select from the list of suggested replacements.
Upon selection it will replace the misspelled word with the selected word. It will also
allow the user to make global replacements.
Finally, a non-functional requirement of the system could require that it must be
integrated into the existing word-processor that runs on windows platform.
The official definition for a non-functional requirement specifies how the system should
behave:
"A non-functional requirement is a statement of how a system must behave; it is a
constraint upon the systems behavior."
Non-functional requirements specify all the remaining requirements not covered by the
functional requirements. They specify criteria that judge the operation of a system, rather
than specific behaviors, for example: "Display of the patient's vital signs must respond to
a change in the patient's status within 2 seconds."
Nonfunctional requirement: In software system engineering, a software requirement that
describes not what the software will do, but how the software will do it, for example,
software performance requirements, software external interface requirements, software
design constraints, and software quality attributes. Nonfunctional requirements are
difficult to test; therefore, they are usually evaluated subjectively.
Performance - Response Time, Throughput, Utilization, Static Volumetric
Scalability
Capacity
Availability
Reliability
Recoverability
Maintainability
Serviceability
Security
Regulatory

16

Manageability
Environmental
Data Integrity
Usability
Interoperability

2.6 Stakeholders
As mentioned earlier, in order to develop a good requirement document, it is imperative
to involve all kinds of user in the requirement engineering process. The first step in
fulfillment of this need is the identification of all the stakeholders in the system.
Stakeholders are different people who would be interested in the software. It is important
to recognize that management carries a lot of weight, but they usually are not the actual
users of the system. We need to understand that it is the actual user who will eventually
use the system and hence accept or reject the product. Therefore, ignoring the needs of
any user class may result in the system failure.
The following diagram shows the role of different stakeholders in the setting the system
requirements.

The following figure depicts the relationship between different documents produced
during the requirement engineering phase.

17

18

3. Use Case Diagrams

A use case is a functionality the users need from the system. A use case diagram depicts
the relationships among the actors and use cases.
Generally a single use case is supposed to cover all the actions or events that an actor can
perform on the system at one go. The size of use case should not be very large or very
small. For example Add User, Manage Profile, View Sales Report, Update Order etc are
good medium size use cases. Whereas Enter Password, Display Error Message etc are
very small use cases and Manage Sale & Purchase is a very large use case.
3.1. Components:
The components in a use case diagram include:
3.1.1 Actors:
Actors are first thing you need to find for the use case diagram. Actors represent external
entities of the system. These can be people or things, such as external hardware that
interact with the system.
For example, if an online store is being modeled there can be more than one actor that
interacts with the store functionality. Such as the Customer and stocker will be the actors
in the system.
It is represented simply by a stick figure with its name at the bottom of it.

3.1.2 Use Cases:

Use cases are functional parts of the system. They figure out what actions/functionalities
a user will perform. Use cases are basically the functional requirements that you have
pointed out in the functional and non functional requirements topic.

19
For example: The customer "browses the catalog", "chooses items to buy", and
"pays for the items". Here browse catalog, buy item and pay for item are the use cases.
Many actors can share a single use cases.
The notation for a use case is an ellipse. As it is displayed below:

3.1.3 Associations:
Associations between actors and use cases are indicated in use case diagrams by solid
lines. An association exists whenever there is direct interaction between actor and use
case. Associations are modeled as lines connecting use cases and actors to one another,
with an arrowhead on one end of the line.

3.1.4 System boundary:

Systems boundary is drawn by a rectangle that contains use cases. The actors are placed
outside the system boundary and use cases inside it.

20

3.1.5 Relationship between Use cases

i)
Include/Uses:
Include relationship is a relationship in which one use case (the base use case) includes
the functionality of another use case (the inclusion use case). <<include>> use cases must
be used by the use cases that use them before the latter can be complete. It is displayed
in the diagram editor as a dashed line with an open arrow pointing from the base use case
to the inclusion use case. The keyword include is attached to the connector.

ii)

Extend:

A use case extends another use case to do more than the latter. It extends the
functionality of one use case to further level. is displayed in the diagram editor as a
dashed line with an open arrowhead pointing from the extension use case to the base use
case. The arrow is labeled with the keyword extend.

21

3.2. Use Case Diagram:

Reference:
http://agile.csc.ncsu.edu/SEMaterials/tutorials/use_case_diagram/
http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=
%2Fcom.ibm.xtools.modeler.doc%2Ftopics%2Fcextend.html
http://blog.casecomplete.com/post/Master-the-Use-Case-Include-Relationship.aspx

22

4.0 Usage Scenario

Usage scenario is the actual text-based representation of the use case, among various
representation methods discussed above. A usage scenario is likely to have various
sections depending upon the level of details required in a given system. There is no fixed
standard so far for number of sections in a use case (usage scenario).
Following is a typical table structure for usage scenario, note that it is not mandatory to
write a usage scenario in the table format only, and it is likely that you will find different
structures for the same representation.
Use Case Title
Abbreviated
Title
Use Case Id
Requirement Id
Description:

Write Title Here (must match use case title in use case diagram)

Pre Conditions:
Task Sequence
1.
2.
3.
.
.
Post Conditions:
Unresolved issues:
Authority:
Modification history:
Author:
Description:
Lets explore each section from the template provided above.

Use Case Title

It is the name or label of the use case for which we are writing the usage scenario.
Generally it must start with a Verb and it should consist of 2 to 4 words e.g. Add User,
Manage User Roles etc.
Use Case Title

Exceptions

Add User

Abbreviated Title
Some times we find ourselves in a situation where the use case title is too long. In this
case we can use abbreviation in the use case title e.g. using Manage HRM
Department in place of Manage Human Resource Management Department. In such

23
cases we should elaborate the abbreviation under the section Abbreviated Title. So we
should write: Human Resource Management (HRM) against this section.
Abbreviated
Title

Human Resource Management (HRM)

Use Case Id
Sometimes use cases are indexed for better reference in overall project
documentation/artifacts. This can be any form of series e.g. 1, 2, 3 etc. Priority based
use case id is another famous use for this section. Use cases are indexed to present
their importance in the system. You would want to set ascending or descending rating
or priority for all use cases i.e. the most important use cases are ranked higher so that
the project team knows what should be implemented first in the upcoming
phases/deliverable of the project.
Use Case Id

Requirement Id
The purpose of this section is same as Use Case Id section. The number written
against this section represents the corresponding functional requirements this use case
belongs to. It is compulsory to index all the functional requirements properly before
this section can be used:
Requirement Id

Description
It should be a very brief description of the use case under discussion. Generally this
portion should consist of 2/3 lines.
Description

This use case is about adding a new user to existing

system with the privileges defined at time of user
account creation.

Pre Conditions
This section should enlist what must be true before this use case can be performed.
Pre Conditions:
1. All must-required information about the new user should be
available.
2. Database should be available in online mode.
OR

24
Pre Conditions:
Administrator is logged in, and there is a need to add a new
user account.

Task Sequence & Exceptions

This is the most important section of the usage scenario. It is also referred as Success
Scenario, Actions, (or simply) Scenario. This should be a list of actors interaction
with the use case.
Task Sequence
1. Administrator opts to Add a new user account.
2. System asks for necessary information
3. Administrator provides all the required information and
opts to complete the operation.
4. System after confirmation adds the new account.
5. System sends the account creation email to the
administrators email id and users email address.
6. A log is saved on the successful operation of the use case.

Exceptions

Another style that is commonly used is as follows:

Task Sequence
User Action
Administrator opts to Add a
new user account.
Administrator provides all the
required information and opts
to complete the operation.

System Response
System asks for necessary
information
System after confirmation
adds the new account.
System sends the account
creation email to the
administrators email id and
users email address.
A log is saved on the
successful operation of the
use case.

Some times there are one or more alternate scenarios within a particular usage
scenario that must be discussed in order to elaborate the use case properly.
Task Sequence
1. Administrator opts to Add a new user account.
2. System asks for necessary information.
3. Administrator provides all the required information
and opts to complete the operation.
4. There is a problem in the data provided; some data

Exceptions

25
needs to be corrected.
Administrator checks the available
information and corrects the error.
Administrator continues from the step 3.
5. System after confirmation adds the new account.
6. System sends the account creation email to the
administrators email id and users email address.
7. A log is saved on the successful operation of the use
case.
Alternate scenarios could be more than one; in this case, it will be better to make a
bold heading to show each alternate scenario separately. Again there can be multiple
ways to show the alternate scenarios.
Exceptions are any unhandled scenarios that must be discussed under this section.
Some times there are ambiguous situations in start of project that might hurdle the
flow of events in the Task Sequence portion. In such situations the details are
provided in the Exceptions section. Generally this section should be left blank as in
case of final project, you will get fixed requirements at the start and thus there should
be no ambiguity.

Post Conditions
The conditions that must be true depending upon the successful use case are
mentioned in this section.
Post Conditions:
A new user account is successfully created.

Unresolved Issues
In addition to the Exceptions portion, we write unresolved issues (if any) in this
section, so that in later phases (when the situation gets more clear).
Just like Exceptions section, this will be generally left blank (or its row can be deleted
from the use case table-structure.

Authority
The role that is allowed to perform this use case, in our current example it will be
Administrator.

Modification History
If a use case is updated in later stages of the project development, the versioning
information should be mentioned in this section (version can be a series such as 1.0,
2.0, 3.0 or 1.1, 1.2, 1.3 etc)

Author
It means the author of this usage scenario. Put your project/group id in this section.

26

Description
Any more details about author, revision of the use case should be provided in this
section.

So our final usage scenario is as follows:

Use Case Title
Add User
Use Case Id
1
Requirement Id
3
Description: This use case is about adding a new user to existing system with the privileges
defined at time of user account creation.
Pre Conditions:
1. All must-required information about the new user should be available.
2. Database should be available in online mode.
Task Sequence
Exceptions
1. Administrator opts to add a new user account.
2. System asks for necessary information.
3. Administrator provides all the required information and opts to
complete the operation.
4. There is a problem in the data provided; some data needs to be
corrected.
Administrator checks the available information and
corrects the error.
Administrator continues from the step 3.
5. System after confirmation adds the new account.
6. System sends the account creation email to the administrators
email id and users email address.
7. A log is saved on the successful operation of the use case.
Post Conditions:
- A new user account is successfully created.
Unresolved issues:
Authority: Administrator
Modification history: 1.0
Author: <Project or Group ID>
Description:

How to handle <<uses>> (or <<includes>>) and <<extends>> relations:

There might be situations in use case model having some hierarchy, suppose a hierarchy:

27

<<uses
>>

Generate
Receipt

Process
Order
<<extends
>>

Process
Item
Return

Here Process Order is the main use case and Generate Receipt and Process Item Return
are its sub-use cases. In this case, just provide the usage scenario for all the sub-use cases
as usual, and to refer them inside the usage scenario for main use case, just write User
performs Sub-UseCaseNameHere in the task sequence e.g. in this example, the Task
Sequence portion of the use case Process Order will be as follows:
Task Sequence
1. Salesman enters the purchase information in the system.
2. System generates the total amount to be paid by customer.
3. Salesman performs Generate Receipt use case.
4. The customer wants to return some particular items from the
order, so step 3 cannot be performed.
Salesman picks the returned items.
Salesman performs Process Item Return use case.
System recalculates and displays the total bill amount.
Salesman performs step 3 to complete the operation.

Important Points:

28
There should be a usage scenario for each use case from use case diagram e.g. if
there are (let say) 10 use cases in use case diagram, then there must be 10 separate
usage scenarios (i.e. one for each).
Title of use cases in use case diagram and in the usage scenario must be same.
As said earlier, there is no standard for any fixed sections in usage scenario, so if
you dont have any thing to write in a particular section, then just leave it blank or
delete its row/cell from the table. It is important to note that some sections are
very common across different representations of usage scenarios and such
sections should not be removed/kept blank at all. These sections are: Use Case
Title, Pre Conditions, Post Conditions, Task Sequence, Author etc. Again it all
depends upon the situation and level of details required in a given system.
Generally a good approach for Task Sequence portion is not to mention very small
GUI level details such as:
Administrator clicked on Submit button
OR
System shows the confirmation message

References:
WRITING EFFECTIVE USE CASES (Alistair Cockburn), Addison-Wesley, 2000.