Software Requirements SpecificationforProjectVersion.docx

Software Requirements Specification
for
<Project>
Version 1.0 approved
Prepared by <author>
<organization>
<date created>
Table of Contents
TOC o "1-2" t "TOCentry,1" Table of Contents
PAGEREF _Toc441230970 h ii
Revision History
PAGEREF _Toc441230971 h ii
1.
Introduction
PAGEREF _Toc441230972 h 1
1.1
Purpose
1.2
Document Conventions

1.3
Intended Audience and Reading Suggestions
1.4
Product Scope
1.5
References
2.
Overall Description
2.1
Product Perspective
2.2
Product Functions
2.3
User Classes and Characteristics
2.4
Operating Environment
2.5
Design and Implementation Constraints

2.6
User Documentation
2.7
Assumptions and Dependencies
3.
External Interface Requirements
3.1
User Interfaces
3.2
Hardware Interfaces
3.3
Software Interfaces
3.4
Communications Interfaces
4.
System Features
4.1
System Feature 1

4.2
System Feature 2 (and so on)
5.
Other Nonfunctional Requirements
5.1
Performance Requirements
5.2
Safety Requirements
5.3
Security Requirements
5.4
Software Quality Attributes
5.5
Business Rules
6.
Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models

Appendix C: To Be Determined List
Revision History
Name
Date
Reason For Changes
Version
Introduction
Purpose
<Identify the product whose software requirements are specified
in this document, including the revision or release number.
Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a
single subsystem.>
<Describe any standards or typographical conventions that were
followed when writing this SRS, such as fonts or highlighting

that have special significance. For example, state whether
priorities for higher-level requirements are assumed to be
inherited by detailed requirements, or whether every
requirement statement is to have its own priority.>
Intended Audience and Reading Suggestions
<Describe the different types of reader that the document is
intended for, such as developers, project managers, marketing
staff, users, testers, and documentation writers. Describe what
the rest of this SRS contains and how it is organized. Suggest a
sequence for reading the document, beginning with the
overview sections and proceeding through the sections that are
most pertinent to each reader type.>
Product Scope
<Provide a short description of the software being specified and
its purpose, including relevant benefits, objectives, and goals.
Relate the software to corporate goals or business strategies. If
a separate vision and scope document is available, refer to it
rather than duplicating its contents here.>
References
<List any other documents or Web addresses to which this SRS
refers. These may include user interface style guides, contracts,
standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough
information so that the reader could access a copy of each
reference, including title, author, version number, date, and
source or location.>
Overall Description
Product Perspective

<Describe the context and origin of the product being specified
in this SRS. For example, state whether this product is a follow-
on member of a product family, a replacement for certain
existing systems, or a new, self-contained product. If the SRS
defines a component of a larger system, relate the requirements
of the larger system to the functionality of this software and
identify interfaces between the two. A simple diagram that
shows the major components of the overall system, subsystem
interconnections, and external interfaces can be helpful.>
Product Functions
<Summarize the major functions the product must perform or
must let the user perform. Details will be provided in Section 3,
so only a high level summary (such as a bullet list) is needed
here. Organize the functions to make them understandable to
any reader of the SRS. A picture of the major groups of related
requirements and how they relate, such as a top level data flow
diagram or object class diagram, is often effective.>
User Classes and Characteristics
<Identify the various user classes that you anticipate will use
this product. User classes may be differentiated based on
frequency of use, subset of product functions used, technical
expertise, security or privilege levels, educational level, or
experience. Describe the pertinent characteristics of each user
class. Certain requirements may pertain only to certain user
classes. Distinguish the most important user classes for this
product from those who are less important to satisfy.>
Operating Environment
<Describe the environment in which the software will operate,
including the hardware platform, operating system and versions,

and any other software components or applications with which
it must peacefully coexist.>
Design and Implementation Constraints
<Describe any items or issues that will limit the options
available to the developers. These might include: corporate or
regulatory policies; hardware limitations (timing requirements,
memory requirements); interfaces to other applications; specific
technologies, tools, and databases to be used; parallel
operations; language requirements; communications protocols;
security considerations; design conventions or programming
standards (for example, if the customer’s organization will be
responsible for maintaining the delivered software).>
User Documentation
<List the user documentation components (such as user
manuals, on-line help, and tutorials) that will be delivered along
with the software. Identify any known user documentation
delivery formats or standards.>
Assumptions and Dependencies
<List any assumed factors (as opposed to known facts) that
could affect the requirements stated in the SRS. These could
include third-party or commercial components that you plan to
use, issues around the development or operating environment, or
constraints. The project could be affected if these assumptions
are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors, such as
software components that you intend to reuse from another
project, unless they are already documented elsewhere (for
example, in the vision and scope document or the project
plan).>

External Interface Requirements
User Interfaces
<Describe the logical characteristics of each interface between
the software product and the users. This may include sample
screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard
buttons and functions (e.g., help) that will appear on every
screen, keyboard shortcuts, error message display standards,
and so on. Define the software components for which a user
interface is needed. Details of the user interface design should
be documented in a separate user interface specification.>
Hardware Interfaces
<Describe the logical and physical characteristics of each
interface between the software product and the hardware
components of the system. This may include the supported
device types, the nature of the data and control interactions
between the software and the hardware, and communication
protocols to be used.>
Software Interfaces
<Describe the connections between this product and other
specific software components (name and version), including
databases, operating systems, tools, libraries, and integrated
commercial components. Identify the data items or messages
coming into the system and going out and describe the purpose
of each. Describe the services needed and the nature of
communications. Refer to documents that describe detailed
application programming interface protocols. Identify data that
will be shared across software components. If the data sharing
mechanism must be implemented in a specific way (for
example, use of a global data area in a multitasking operating

system), specify this as an implementation constraint.>
Communications Interfaces
<Describe the requirements associated with any communications
functions required by this product, including e-mail, web
browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting.
Identify any communication standards that will be used, such as
FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization
mechanisms.>
System Features
<This template illustrates organizing the functional
requirements for the product by system features, the major
services provided by the product. You may prefer to organize
this section by use case, mode of operation, user class, object
class, functional hierarchy, or combinations of these, whatever
makes the most logical sense for your product.>
System Feature 1
<Don’t really say “System Feature 1.” State the feature name in
just a few words.>
4.1.1
Description and Priority
<Provide a short description of the feature and indicate whether
it is of High, Medium, or Low priority. You could also include
specific priority component ratings, such as benefit, penalty,
cost, and risk (each rated on a relative scale from a low of 1 to a
high of 9).>

4.1.2
Stimulus/Response Sequences
<List the sequences of user actions and system responses that
stimulate the behavior defined for this feature. These will
correspond to the dialog elements associated with use cases.>
4.1.3
Functional Requirements
<Itemize the detailed functional requirements associated with
this feature. These are the software capabilities that must be
present in order for the user to carry out the services provided
by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or
invalid inputs. Requirements should be concise, complete,
unambiguous, verifiable, and necessary. Use “TBD” as a
placeholder to indicate when necessary information is not yet
available.>
<Each requirement should be uniquely identified with a
sequence number or a meaningful tag of some kind.>
REQ-1:
REQ-2:
System Feature 2 (and so on)
Other Nonfunctional Requirements
Performance Requirements
<If there are performance requirements for the product under
various circumstances, state them here and explain their

rationale, to help the developers understand the intent and make
suitable design choices. Specify the timing relationships for real
time systems. Make such requirements as specific as possible.
You may need to state performance requirements for individual
functional requirements or features.>
Safety Requirements
<Specify those requirements that are concerned with possible
loss, damage, or harm that could result from the use of the
product. Define any safeguards or actions that must be taken, as
well as actions that must be prevented. Refer to any external
policies or regulations that state safety issues that affect the
product’s design or use. Define any safety certifications that
must be satisfied.>
Security Requirements
<Specify any requirements regarding security or privacy issues
surrounding use of the product or protection of the data used or
created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations
containing security issues that affect the product. Define any
security or privacy certifications that must be satisfied.>
Software Quality Attributes
<Specify any additional quality characteristics for the product
that will be important to either the customers or the developers.
Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability,
reliability, reusability, robustness, testability, and usability.
Write these to be specific, quantitative, and verifiable when
possible. At the least, clarify the relative preferences for
various attributes, such as ease of use over ease of learning.>

Business Rules
<List any operating principles about the product, such as which
individuals or roles can perform which functions under specific
circumstances. These are not functional requirements in
themselves, but they may imply certain functional requirements
to enforce the rules.>
Other Requirements
<Define any other requirements not covered elsewhere in the
SRS. This might include database requirements,
internationalization requirements, legal requirements, reuse
objectives for the project, and so on. Add any new sections that
are pertinent to the project.>
Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS,
including acronyms and abbreviations. You may wish to build a
separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project
in each SRS.>
Appendix B: Analysis Models
<Optionally, include any pertinent analysis models, such as data
flow diagrams, class diagrams, state-transition diagrams, or
entity-relationship diagrams.>
Appendix C: To Be Determined List
<Collect a numbered list of the TBD (to be determined)
references that remain in the SRS so they can be tracked to
closure.>

Copyright © 1999 by Karl E. Wiegers. Permission is granted to
use, modify, and distribute this document.
Software Requirements Specification for <Project>
Page PAGE * MERGEFORMAT ii
Software Requirements Specification for <Project>
Page PAGE * MERGEFORMAT 6
Chapter 6:
Requirements Engineering
1
Preparation for Requirements Engineering
1. Prior to actually performing the requirements engineering
activities, it is important to plan for the resources,
methodology, and time needed to perform this crucial step in
software engineering.
2. Some organizations even perform requirements engineering
as a separate, stand-alone activity and price it separately, with
the option of folding the cost into the whole project if they get
the call to complete the software project.
2

Major Requirements Engineering Activities
Elicitation
Documentation and definitions
Prototyping
Analysis
Specification(s)
Review and validations
Gain agreement and acceptance
Note: This list does not address “inventing” new requirements.
3
Requirements Engineering Activities
4
Why Is This Set of Activities Important and Why Should
Requirements Be Documented?
(Remember Chaos Report?)
Clear requirements are needed for design and implementation
activities.
Requirements documentation is needed to create test cases and
test scenarios—especially for large systems where the test team
is a separate group of people from the developers.
Requirements document is needed to control potential scope-
creep.
Requirements document is needed to create user training
material, marketing material, and documents for support and
maintenance.

Requirements document provides a way to segment a large
project, prioritize releases, and simplify project management.
Think about agile processes where this crucial step may
sometimes be
“compromised” by the novice software engineers.
5
Requirements Elicitation
Requirements:
May be given to the software engineers.
Initial product/system requirements
For second and/or third follow-on release of a “planned”
sequence of software product where a preliminary set of
requirements are already established
Requirements provided as part of a request for price quotation
for a software development project
Have to be established by software engineers.
Users sometimes have an understanding of only the
requirements related to their specific job tasks.
The business rationale and goals are not always clear to
individual user and needs to be established for prioritization
reason.
There may be contradicting and incomplete requirements stated
by the users and customers.
6

High-Level Requirements Elicitation
Need to seek out the business and management perceptions and
goals for the software project.
Business opportunity and business needs
Justification for the project
Scope
Major constraints
Major functionality
Success factor
User characteristics
Software engineers who have to interact with business
management
and handle requirements are sometimes called business analysts.
7
6 Dimensions of Detailed Requirements Elicitation
8
Requirements Analysis
Requirements “analysis” is composed of:
Categorizing the requirements (by some criteria)
Prioritizing the requirements
Also “start to look” for consistency and completeness (see
VORD Slide)

9
Requirements Classification/Categorization
Most high level:
Functional
Non-functional
Other more detailed grouping also exists.
Six dimensions of requirements
10
Requirements Categorization
By detailed six requirements areas:
Individual functionality
Business flow (usage “scenarios”)
Data and information needs
User interfaces
Other interfaces to external systems/platforms
Various constraints (non-functional)
Performance
Security
Reliability
Etc.
11

Requirements “Analysis/Categorization”
of Multiple Views
View-oriented requirements definition (VORD) is based on the
concept that requirements are viewed differently by different
people.
Identify stakeholders and their viewpoints of the requirements.
Categorize the viewpoints of requirements and eliminate any
duplication (look for consistency and completeness).
Refine the identified viewpoints of requirements.
Map the viewpoints of requirements to the system and the
services that the system must provide.
12
Requirements Prioritization
Most of the time we have some limitations in developing
software:
Time
Resources
Technical capabilities (existing)
We need to prioritize the requirements to satisfy these
limitations.
13
Requirements Priorities
Some criteria for prioritization:
Current user/customer demands or needs

Competition and current market condition
Anticipated future and new customer needs
Sales advantages
Existing critical problems in current product
These are often subjective and requirements should be
prioritized with the help of many of the stakeholders (different
viewpoints).
14
A Simple Requirements Prioritization List “Sample”
* Priority may be 1, 2, 3, or 4, with 1 being the highest.
15
Requirements Comparison and Prioritization
Requirements prioritization is an activity of comparing
requirements and placing them in some order relative to each
other.
Is it always performed with just experience and gut feel?
and/or
Done with a little more rigor?
Sort by priority groups (e.g., previous 2 charts) where the
priority groups are based on some prioritization criteria list

(e.g., current user needs has the highest priority).
Pair-wise comparison: normalize and compute relative value
using the Analytical Hierarchical Process (AHP) – see pages
159–161 of textbook (you are responsible for reading this).
16
Analytical Hierarchical Process (AHP) ExampleReq 1Req 2Req
3Req 1 1 2 3Req 2 1/2 1 2Req 3 1/3 1/2 1Req 1Req 2Req
3Req 1 .55 .57 .5Req 2 .27 .29 .33Req 3 .18 .14 .17
1.83
3.5
6.0
.49
.89
1.62
Requirements Prioritization
Req 1 = 1.62 / 3 = 54%
Req 2 = .89 / 3 = 30%
Req 3 = .49 / 3 = 16%
17
Requirements Definition/Prototyping/Review
Once the requirements are solicited, analyzed, and prioritized,
more details may/must be spelled out. Three major activities
that may be intertwined must be performed:

Requirements definition
Requirements prototyping
Requirements reviewing
18
Requirements Definitions/Documentation
Requirements definitions may be written in different forms:
Simple input/process/output (I-P-U) descriptions in English
Dataflow diagrams (DFD)
Entity relations diagram (ERD)
Use case diagram from Unified Modeling Language (UML)
Once the requirements are defined in detail using
any of the above forms, they still need to be
reviewed (see Chapter 10 of your textbook) by the
users/customers and other stakeholders.
Formal
review
by others
19
Requirements Definition Using English and
Input-Process-Output Diagram Form
English I-P-O: functionality, business, and data flow

20
Syntax of Data Flow Diagram (DFD)
21
Requirements Definition Using DFD
Captures functionality, business flow, data.
22
4
Requirements Definition Using
Entity Relation Diagram (ERD)
Captures relations among data.
23
Requirements Definition Specifying
Entity and Attributes
Captures relations among data.

24
Requirements Analysis & Definition Methodology Using UML
Using OO Use Case Methodology and Notation, which
identifies:
Basic/main functionalities
Pre-conditions of functionality
Flow of events or scenarios
Post-conditions for the functionality
Error conditions and alternative flows
Using OO Use Case Diagram, which identifies:
Actors (or all external interfaces with the system, including the
users)
Related “use cases” (major functionalities)
Boundary conditions
Use cases may be further refined during design.
25
Requirements Definition Using Use Case Diagram (for major
functionalities)

26
Requirements Definition Using
Use Case Description
Use case diagrams are mostly for functionalities and are not
detailed enough—so we need to use “English” text for further
descriptions of the requirements:
Functional details
Pre-conditions
Post-conditions
Non-functional characteristics about the functionalities
“Alternative paths” (e.g., error processing)
UI sample (e.g., “looks”)
Etc.
27
Requirements Traceability
Capability to trace a requirement is needed to ensure that the
product has fully implemented the requirements (while not part
of requirements process activities – it needs to be started early).
We need to trace requirements:
Requirements from source (people and documents)
Requirements to later steps (design, implementation, test, and
release)
We also need to link requirements to other
“prerequisite” requirements.
28

Partially Filled Traceability
TableRequirementDesignCodeTestOther Related
Requirements 1compon. XModule 3Test Case 32 2, 3
2compon. w Module 5 Test Case 161 3compon. XModule
2Test Case 271 4 5 6 7
29
Requirements Prototyping
Requirements prototyping mostly addresses the user interface
(UI) part of the requirement in terms of:
Visual looks (size, shape, position, color)
Flow (control and logical flow; depth of flow)
The prototyping may be performed in one of the two modes:
Low fidelity: using paper/cardboard to represent screens and
human to move the boards
High fidelity: using automated tools such as Visual Basic to
code the screens and direct the logical flow of these screens
30
Requirements Specification
Once the requirements are defined, prototyped, and reviewed,
they must be placed into a Requirements Specification
document.
IEEE /EIA Standard 12207.1-1997 may be purchased from
IEEE. It outlines the guideline for three major sections of a
requirements specification document.
Introduction
High-level description
Detailed descriptions

Details of each functionality (input-output-process)
Interfaces, including user interfaces and network interfaces
Performance requirements (response time, throughput, etc.)
Design constraints, standards, etc.
Additional attributes such as security, reliability, etc.
Any additional unique requirements
31
Finally — Requirements “Sign-Off”
Having a requirements specification agreed to and signed off on
is important.
Serves as a milestone marker and formally exits a phase of
software engineering.
Serves as baseline from which any future changes can be
monitored and controlled.
Remember “agile”—which wants less “legalese” like sign-off
—obviously, I disagree when it comes to large/expensive
projects!
32
CSci 713
Script for Requirements Engineering
<< Alex, I would like you to read the material before Slide 1:
without opening Powerpoint to the slides. Instead, I hope you
will be willing to sow your face and introduce yourself during
that time. I think students would be much happier to be able to

associate a name and a face with the presentations. Thank
you!!>>
One huge caveat before we begin. The range and variety of
modern software development projects is very wide. Some
projects are single developer, informal efforts with perhaps the
developer or a few co-workers as the only intended users. At
the other extreme are projects with more than a1,000 developers
in many locations throughout the world. There are projects at
every point over this entire range.
Some projects result in a page r less of code. Others result in
tens of millions of lines of code in many programming and
scripting languages. Again, there are projects at every point in
between.
Some projects are finished in just a few hours. Others can take
more than five years. Again, there are projects at every
intermediate point also.
The range of product types is vast also. Some products have
only a ingle user and run on a single computer, perhaps in a
single process. Other products run on servers throughout the
world and support tns of thousands or more simultaneous users.
Clearly, with the huge variety of projects and products over
several dimensions, no coherent presentation can speak to all of
them. This presentation is targeted towards larger projects
produced by one or more teams of developers over one to five
years. Smaller projects can ignore some or all of the practices
detailed here. Unfortunately, smaller projects tend to ignore too
many of these practices, resulting in much more rework and
reduced prospects for success.
Slide 1:
Onc a software development project has received authorization,
a tentative schedule, and a team of developers, the project
proposal must be greatly expanded with an extensive set of
requirements. The process of developing this set of
requirements is called Requirements Engineering.
There are three targets for the initial requirements engineering,
depending on the development lifecycle and methodology being

used on this project. If a sequential lifecycle such as Waterfall
is used, every reasonable effort is made to produce a complete,
accurate set of requirements. Developers and most business
stakeholders know that the requirements almost certainly will
require revision as the project proceeds, but the more complete
and accurate the initial set of requirements, the less often
expensive responses to revisions must be made.
The second possible target is to spend less effort than with the
first target, but try to produce a tentative set of requirements for
the entire product. Many iterative lifecycle methodologies
adopt this target. This target allows better scheduling of the
overall project, and better development of a product architecture
than the third possible target.
The third possible target is use din Agile and Lean development
methodologies. Just enough requirements for the first release
are produced. This target requires the least effort initially, but
also results in a greater likelihood that the product architecture
will need extensive revision during development.
If a sequential development is attempted, the requirements
production is done once at the beginning of the development
lifecycle. Small scale efforts may be needed during
development to revise the requirements if and when significant
changes occur
If an iterative development is attempted, requirements
production is done at the start of development and at the start of
each iteration.
In this course, we provide an overview of Requirements
Engineering. Another course, CSci 715, spends an entire
semester going much deeper into Requirements Engineering.
Slide 2:
There are different types of requirements. Functional
requirements concern specific features of interest to users
and/or business stakeholders. One trend over the last thirty
years gas veeb for production of functional requirements to
involve potential product users to a much greater degree.
Functional requirements have an advantage that they usually are

easier for users, business stakeholders, and developers to
understand to mean the same thing. Other requirements are
much more likely to result in miscommunication among these
groups. Another advantage of functional requirements is that
identification of how they affect the product is usually
straightforward. In most cases, a functional requirement has a
very local impact on only a small part of the product. For
example, consider the functional requirement: A user should be
able to upload a new description at any time after the sale item
has been created. This requirement likely would be
implemented in one or two methods within a single class.
Nonfunctional requirements are more difficult to identify and to
get the three groups to form the same meaning for the words
written. Further, the impact of a nonfunctional requirement
may be difficult to discern and diffuse throughout the product.
For example, consider the requirement that all responses to user
requests must take no more than 2 seconds to complete.
Determining whether or not this requirement is met cannot be
definitive until the entire product is available and tested under
actual production conditions. Some potential users and the
developers could disagree on whether or not this requirement is
met. Developers may ignore the background updating of a
database that occurs. The user might be upset because the data
is not updated in time for another application to retrieve the
latest value.
Quality attributes are requirements that affect the quality of the
product. These requirements are in such areas as product
performance, reliability, security, precision, privacy,
environmental impact, and so on. This type of requirement
often is the most difficult to discover, but also the most
important in determining eventual user satisfaction.
Constraints on the product are such requirements as to work
with specific releases of specific database management systems
or operating systems. This classification includes the need for
the product to work in the Cloud or as a software as a service.
Constraints on the development process might include the need

to have a working, competitive product by a specific date. This
category includes a requirement to implement in a given
language or with a given set of tools and computers.
Business requirements are those imposed either by Legal or
Accounting requirements, or by other business concerns. For
example, the company may demand that the product record
specified user activity for use in targeting paid ads.
Marketing requirements include the possible need for specific
“wow” features to address the competition. There might be
additional marketing requirements based on what the
competition provides, or is rumored to provide in the future.
Slide 3:
Requirements are described in any of several ways,some textual,
and others graphical. Thisslide presents three functional
requirements for different applications. Each is expressed as a
single sentence requesting a single capability be available to
users. Each needs various terms such as student grades or
weighted assignments to be defined elsewhere. These terms are
defined in the last part of the Requirements Specification called
the Glossary. Since some methodologies do not use a formal
requirements specification document, the definitions might
instead appear in a standalone document, usually online, called
the Data Dictionary. Developers have found it is better to
define these terms separately rather than bogging down each
requirement with a set of needed definitions.
Slide 4:
This slide provides three example non-functional requirements
as single sentences. The first example is a performance
requirement. That requirement might affect many other
functional and no n-functional requirements for this product. In
fact, even experienced developers usually are not correct in
figuring out which requirements might be affected by a quality
attribute such as performance or security. Some important
dependencies might not be discovered until the product has been
in operation for considerable time.
The second example requirement is another quality attribute,

this time related to providing full access to disabled users.
Developers and business stakeholders need to understand that
potential users who are disabled In some way make up a
significant percentage of potential users. This percentage is
growing as the world’s population, especially the developed
world, ages. There is a trend in the developed world for
increasing numbers of employees to be older, sometimes into
their 80’s. They are more likely to have disabilities than
younger employee.
The third sample requirement is another quality attribute. This
requirement is in the area of reliability.
Slide 5:
There are many ways to describe requirements, some textual and
some graphical. The textual forms usually involve either
imperative sentences such as the examples on the previous two
slides, or using an explicit template such as:
For <class of users or set of business stakeholders> the
product must support <operation> on <explicit set of data>
producing <specific result> with <list of explicit side effects>.
Using this template, a requirement might be:
For administrative users the product must support tracing
user modifications to inventory data with the saving of these
traces in the administrative database.
Various terms within this requirement would need definitions in
the Glossary or the Data Dictionary including administrative
user, user, inventory data, and administrative database.
User story and, especially, use case provide other approaches to
describing requirements. These approaches tend to be used in
Agile and Lean methodologies. The next several slides will
describe these two, more recent, approaches.
Slide 6:
The user story starts with a name which must be unique among
all the specified requirements. Then, the requirement is
described in one to three sentences. The main difference
between user stories and the previous approaches is that user

stories are intended to be written by potential users and
business stakeholders. The earlier requirements descriptive
techniques were written by developers with indirect input from
users and business stakeholders through surveys or interviews.
Just as with other means of describing requirements, the user
story contains several nouns, and sometimes verbs, which must
be defined elsewhere, Elsewhere is either the Glossary portion
of the Requirements Specification document or the standalone
Data Dictionary.
Slide 7:
Use cases usually incorporate what would be several
requirements in the other forms of description. The use case
presents a complete dialog between a user and the product.
Uses cases are based on the classic stimulus-response model of
Psychology. The user makes a request (stimulus) of the
product. The product responds in some way. Then the user
makes another request. The back-and-forth continues until the
interaction is complete.
As you can see from the example, the user stimuli are the odd
statements. The product responses are the even statements.
Generally, the use case begins with the user starting the product
and ends with the product ceasing to interact with this user.
However, since many products tend to interact with a user
through multiple transactions before the user leaves the product,
most uses of use cases do not require that each use case
represent an entire session for one user. Instead, there are one
or more use cases for starting the relationship between a user
and the product, and one or more for terminating the
relationship.
Use cases do not describe user interfaces. The use case
describes the user providing certain information to the product
and the product providing certain information to the user. The
format of that information and the way in which the user and
product access that information is not described.
Use cases treat the user and the product as black boxes.
Nothing is described in how the product does its work. Nothing

is described as to how the user decides on the specific input to
provide.
Individual use cases do not contain conditional statements such
as if-then-else. Instead, use cases are organized into families.
The primary use case in a family is the one where everything
succeeds (login is successful, the database is available, etc.).
Secondary use cases in the same family show alternatives. Each
secondary use case in a family branches off from the primary or
another secondary use case when a decision is made differently.
Where a secondary use case branches off from another use case
can be shown in the base use case by placing the name of the
secondary use case in the left margin of the base use case at the
point of divergence.
Sometimes a dialog includes repetition of a sequence of
stimulus-response pairs. This can be shown by prefixing the
repetition with the keyword LOOP and ending the repetition
with the keyword END. Either the LOOP or the END keyword
can be followed by the reason for ending the repetition.
Slide 8:
A typical set of requirements contains hundred, thousands, or
even tens of thousands of individual requirements. No human
can comprehend this complex set without it being organized in
some effective way. The top-level organization by type of
requirement is not sufficient. Within each type of requirement
such as Functional, individual requirements are organized into
features and the features organized by another criterion. This
other criterion depends on the characteristics of the product.
For example, the criterion might be different types of user.
Another possible criterion is where that feature will be
supported (client or server, for example). Another possible
criterion is the data collection upon which that feature might
act. For example, an application that determines whether or not
an applicant qualifies for a specific loan might organize features
by those that affect information on the user’s income,,
information on the lender, information on loan history, etc. A
single feature might be repeated in more than one category.

Requirement engineering consists of six activities. The first
five activities are done in sequence, either once at the beginning
of the project, or once at the beginning and then once each
iteration. The sixth activity is done throughout the entire
project.
Elicitation is the collecting of potential requirements.
Analysis and negotiation is the activity that checks that the
candidate requirements have certain desirable properties such as
being unambiguous. Then the requirements are estimated by the
developers. Finally, this activity includes negotiations with the
business stakeholders to determine tentatively which
requirements will be included in the current release or iteration.
System modeling is done by the developers to assist in their
determining an architectural design for this product.
Specification is the organization and documentation of the
active requirements. Documentation might be ina requirements
specification document or in several backlogs. These have been
explained in the earlier presentations on development
methodologies.
Validation ensures that the requirements and their
documentation satisfy certain properties. These properties will
be presented on a future slide.
Management ensures that the requirements are as current and
accurate as possible. This activity also tracks the completion of
specific requirements. The amount of and rate of progress in
satisfying requirements is measured and monitored every work
day. Responses to any deviations from expected results must be
effective.
The following slides describe one or a few methods among the
many possible for doing each of these activities. CSci 715
spends an entire semester going into much more depth.
Slide 10:
Elicitation is the activity of collecting as many candidate
requirements as possible. Elicitation involves as many business
stakeholders and developers as possible.

Rapid Application Development (RAD) is a frequently used
method. RAD consists of one or two days of meetings at a
location away from the business. As many business
stakeholders and developers as possible get together for a
morning meeting and an afternoon meeting each day to develop
as many requirements as possible. A professional moderator is
hired to conduct the meetings. There are at least two people
recording the conversation results for later reference. The
recorders do not participate in the actual discussions.
Participants are expected to carry on informal offline
discussions during the frequent breaks and between meetings to
wor out disagreements and provide clarifications. However,
only what happens in the formal meetings counts. The
developers participate to present the feasibility of proposed
requirements and to get clarifications as to what a proposed
requirement means to the business stakeholder who presents it.
Other approaches are less one-shot. Two developers can
interview a single business stakeholder. The interview should
have three parts: a brief social interaction of perhaps five
minutes; a question and answer session of about forty minutes,
and a brief closing social interaction of, perhaps, five minutes.
The total interview should not be longer than one hour. One
developer takes notes while the other developer asks the
questions.
There are two types of interviews. A structured interview
consists of ten to twenty prepared questions with limited
opportunities for follow-up. An open-ended interview has only
five or six prepared questions with ample opportunity to request
clarification or bring up doubts.
The developers attempt to interview all relevant business
stakeholders. These interviews are scheduled. They occur in
the stakeholder’s office or a nearby conference room.
Following an interview, the developers involved write up their
conclusions including any proposed requirements. This report
is sent to the interviewee for revision and approval.
If the set of potential users of a product is large and/or

geographically scattered, the developers might use a
questionnaire or survey to elicit potential requirements from a
sample of potential users. These instruments usually result in
about a five percent response rate unless efforts are made to
remind potential participants or to offer a desired reward. The
most commonly offered rewards are t-shirts with the company
logo, or entry in a drawing for a prize. These efforts generally
bring the response rate up to about twelve to fifteen percent.
Slide 11:
Once a large set of potential requirements have been gathered
using one or more of these techniques, the analysis phase
begins. Each potential requirement is evaluated to determine if
it has several necessary properties. The first such property is
not being ambiguous. The developers try to evaluate if the
requirement has the same meaning to all of them and to the
relevant stakeholders. The second property is completeness.
Does the requirement and the associated definitions in either the
Glossary or the Data Dictionary fully describe what the relevant
business stakeholders need? Determination of these two
properties benefits greatly from business stakeholder
involvement. When developers must decide upon these
properties on their own, they often make mistakes.
The third property is one the developers can determine without
business stakeholder involvement. This property is the
feasibility of satisfying this requirement. Can this requirement
be satisfied within all known constraints with an acceptable
amount of effort?
The potential requirements that are determined to have all three
properties move onto the next phase of requirements
engineering. The potential requirements that fail either of the
first two properties are returned to the originating stakeholders
for further clarification. If that clarification is received within a
few business days, the requirement is reevaluated for the three
properties.
Slide 12:

The Modeling phase tries to understand the large set of
requirements by using graphical diagrams to show relationships
among different requirements or features. There are many
diagrams that might be used. We will consider just two which
are part of the Unified Modeling Language. UML consists of
fourteen type s of diagrams and a constraint programming
language to extend those diagrams. UML is very frequently
used in almost every aspect of software development and
maintenance.
The Use Case Diagram is defined to show relationships among
various use cases and between use cases and the actors that are
involved. An actor is an entity such as a person, another
application, or a device separate from the product, but with
which the product interacts to implement one or more use cases.
While the Use Case Diagram is defined to involve use cases, the
actual internals of a use case are not shown in this diagram.
Only the name of the use case or use case family is the given.
Hence, the use case diagram may be used to show relationships
among user stories or features or subsystems or natural
language requirements just as well.
Each Use Case Diagram should be restricted to no more than
about a dozen use cases (or stories or features or subsystems or
requirements). . Otherwise, the diagram becomes too cluttered
and may actually retard communication rather than enhance it.
Multiple diagrams may be used to cover all of the requirements
units of interest.
The Class Diagram is defined in terms of individual classes or
modules and their relationships. Here again, it has been drafted
for use in showing relationships among requirements or user
stories or use cases or subsystems.
The Class Diagram should be limited in scope just as the Use
Case Diagram and for the same reason. Multiple class diagrams
may be used to cover all the requirement units of interest.
The extensions to these diagrams have not been standardized.
Different development teams use them or other diagrams
indifferent ways. System modeling tries to identify

relationships, especially dependencies which could be important
to the rest of the development process.
The next set of slides present these two diagrams with one way
to adjust them to be effective in Requirements Engineering.
Following those presentations, we will return to describing the
phases of Requirements Engineering.
Slide 13:
In the use case diagram, each actor is identified by a stick
figure in either the left margin or the right margin of the
diagram. Each stick figure has the name of its role typed under
the figure. If the same name appears beneath more than one
figure, those stick figures represent the same actor. The actor is
repeated solely to make the diagram less cluttered.
In the center of the diagram are the list of use cases or use case
families, each presented in a single oval. Solid lines connect
each use case oval to the actors involved in that use case.
There are two relationships among use cases shown by dotted
lines with arrow heads. One relationship is contains which
indicates that the containing use case generalizes the contained
use case. The contained use case is the one with the arrow
head. The second relationship is uses which indicates that the
using case calls the used case as a subroutine. The used case
has the arrow head.
How can developers extend this diagram to be useful in Systems
Modeling? The actors can remain unchanged. Whichever
requirements unit (user stories, use cases, use case families,
features, subsystems, individual requirements) we want to
consider appears in the ovals. The solid lines linking actors to
the chosen requirements unit can remain unchanged.
What other relationships among requirements units might we
want to show? Consider the following relationships:
• Depends upon: the initial requirement unit cannot be
satisfied until the related requirements units are satisfied.
• Uses the same resource: this set of requirements units
all use the same resource whether data or another application or
a device. There are two subsets of this relationship: exclusive

in which only one requirements unit may use the resource at a
time, and shared in which multiple requirements units can use
the resource at the same time.
• Co-located: the satisfaction of these requirements
units must be located on the same device or in the same process.
The first relationship is asymmetric. We will use the solid line
with an arrow head on one end to indicate this relationship. The
arrow head will appear at the requirements unit upon which the
initial requirements unit depends.
The other two relationships are symmetric. They will be shown
by dotted lines linking the units. Alternatively, a rectangle
could be drawn around the set of units. In either situation, the
relationship should be labeled on the lines or above the
rectangle. For example, a relationship could be labeled co-
located in public cloud.
Slide 14:
This slide shows a use case diagram for a design. You should
try to modify this version to show a possible set of requirements
for the same application.
<<Pause for 20 seconds >>
Slide 15:
The Class Diagram probably is the most often extended diagram
in UML. Originally, this diagram was defined to describe the
classes and their relationships during Software Design.
There are two basic forms of the Class Diagram: preliminary,
and full. In the preliminary diagram, each class is represented
by a rectangle containing the name of the class. Solid lines are
drawn between these rectangles to represent any of the
following relationships:
• A method in the originating class calls a method in
the receiving class. The direction of the call is indicated by an
arrow head. The line is annotated with the signature of the
method call followed bya the type of the return value.
• This class contains a reference to one or more
members of the other class. The arrow head is placed on the
contained class’s end. The link is annotated with the name of

the reference. The multiplicity of each end of the link appears
as a number over the link at that end. For example, if one end
has a 3 and the other end has a 1, that means each class element
at the 1 end has exactly three references to elements of the other
class and each element of the other class is referenced by
exactly one element of the other class. We will see more
options for this multiplicity when we present Design.
• This class inherits from that class. The parent class
has an open arrow head at its end of the link.
In the full version, each class description is expanded into three
parts separated by horizontal lines. The top third shows the
class name. The middle third shows the class and element data
of this class, Each item kn this third has a visibility symbol, a
name, and a datatype. The bottom third shows the class and
element methods of this class. Each has a visibility, a name,
and a signature. The visibility symbols will be explained when
we revisit the class diagram in the Design presentation.
How do we adapt this diagram for use with requirements? We
will use only the preliminary form. The same three
relationships:
• Depends upon
• Uses the same resource
• Co-located
may be shown in the same ways.
Slide 16:
This slide shows a Clas Diagram for a design. You should try
to modify it to describe requirements for the same application.
<<Pause for twenty seconds >>
Slide 17:
There are other ways to use a Class Diagram to model
requirements. This slide and the next show two other
approaches. On this slide, a method for showing which major
user data each requirement unit accesses is given.
Slide 18:
This slide shows a method which is simpler and more flexible
for showing the relationships among different requirements.

Some developers might wish to employ both this method and the
method on the previous slide since each shows different
relationships that could be valuable in understanding how the
requirements interact.
Developers also might find value in doing different diagrams
with the same approach, but different levels of requirements
unit. Other combinations of approaches could be useful as well.
For example, developers could start with identifying co-located
requirements units. Then for each set of requirements units
which is co-located, the developers could use the data approach
of the previous slide to suggest where different user data should
be located. Your imagination or development experience
probably can uncover other valuable combinations.
<<Pause for 5 seconds >>
Slide 19:
The Waterfall development process mandates use of a Formal
Requirements Specification(SRS) document. In practice, many
development projects, regardless of the label placed on the
process, actually use some form of SRS. Even the various
backlogs used in Agile and Lean processes often contain at least
some of the fields of an SRS. Therefore, the next several slides
discuss the Software Requirements Specification.
Note that the actual requirements in the SRS may be in any
format including natural language or user stories or use cases.
The SRS has several goals. For the most part, these goals are
shared by the various backlogs.
The first goal is to be a place where the current requirements
for this project may be found. The current requirements should
be accessible by the developers and any concerned business
stakeholder at any time throughout the project.
The second goal is to serve as the basis for reviews. Agile and
non-Agile projects alike review the current requirements at
specified times throughout the project. The amount and speed
of satisfying these requirements is the major determiner of if
and when adjustments in the development process are desirable.
The third goal is to provide a basis for product design. All

projects do architectural design in some form. The architecture
comes from the requirements. The test-driven design done by
Agile projects and the requirements driven design done by other
projects both originate in requirements.
The fourth goal is to serve as a basis for system tests and
acceptance tests. System tests are from the developers’
perspective. Acceptance tests are from the perspectives of
business stakeholders, and then users. These groups base their
tests on their understanding of the product’s requirements.
The fifth goal is to improve communication among the various
groups concerned about the developing product. The most
common reason for project failure is miscommunication. The
requirements are the primary shared medium among developers,
potential users, and business stakeholders. Some Agile
methodologies such as SCRUM consider working code to be
more important, but the groups other than the developers value
working code to the extent the code satisfies their understanding
of product requirements.
The sixth goa reiterates this point by emphasizing the
importance of requirements as the basis for all communication
between developers and business stakeholders. At least until
the product is released to users, the business stakeholders are
the ones who determine whether or not the project proceeds.
Business stakeholders base their decisions about the product on
their understanding of how well the product is satisfying the
functional and quality requirements together with how well the
project is meeting its requirements such as schedule.
The seventh goal is to support effective tracking. Progress
during development is measured by how well subsequent phases
of development after the first five phases of requirements
engineering satisfy current requirements. Remember that the
sixth phase, management, occurs throughout the project. We
need to track individual requirements satisfaction through the
design and working code to measure progress.
Slide 20:
The next several slides present a representative format for the

SRS. Much of this format is applicable to backlogs in Agile
projects as well. In any project, the information mentioned here
should be documented somewhere.
The first section is the Introduction. This section forms a large
portion of the Project Vision in some Agile methodologies. The
project goals are the business reasons this project is being
undertaken. How will the eventual product help the company
doing the development? The business stakeholders are the areas
of this company that are concerned with the success of this
project and with the form of the resulting product. Business
stakeholders might include:
• Upper management which is providing the resources
to undertake this project
• Legal which might need to ensure the product meets
applicable laws and regulations.
• Accounting which might need to ensure the product
follows accepted accounting procedures including supporting
user privacy, and necessary audit trails.
• Sales and Marketing which might need to ensure the
product will be a viable competitor when released and that
special times such as the Christmas season for consumer
products or the end of fiscal year for commercial products are
not missed.
• The departments of the intended users, if the product
is intended for internal use.
The intended audience is the specific individuals or business
roles who need to access and understand the requirements.
The project scope gives a high level, often tentative description
of which features and non-functional requirements should be
supported by the product. The expected duration and level of
staffing for the project are given here.
Document conventions explains the use of any special formats
or fonts within the Software Requirements Specification. For
example, italics might be used to indicate examples.
The entire introduction is supposed to be short. Five typed
pages is ideal, but more than twenty pages is too long.

The next section is a product overview. This section often is
the last section read by non-technical readers.
The Potential Users described the groups of individuals (often
by their business roles) expected to use the product.
The next subsection describes how each of these types of
expected users will employ the product.
The Operating Environments lists all the environments in which
the product is expected to operate. These descriptions might
include hardware, browser versions, operating system versions,
and any supporting software such as database management
systems.
The modes the product should support are described also. A
mode might be as a standalone application, as software as a
service, as a cloud application under Continuous Deployment,
etc.
Assumptions and Dependencies presents any requirements the
product has on its user or on other hardware or software. For
example, the product might require the user to understand gene
splicing and be familiar with its terminology. The product
might require that a new computer being developed by the same
company be available at least six months before the product.
Slide 22:
The next section lists the current requirements divided into the
categories presented earlier. The functional requirements
should be divided into those saved for consideration in a future
release, those already satisfied in earlier releases, those
satisfied in the current release, and those remaining to be
satisfied in the current release. Wthin the last category, the
requirements should be further divided into those satisfied in an
earlier iteration, those satisfied in the current iteration, and
those yet to be satisfied in the current iteration. Of course, this
last division is done only if an iterative lifecycle is used.
Within each of these classifications, the requirements should be
further classified by one of the criteria described when we

discussed System Modeling. Those included: by feature, by
user data used, and by co-location.
Remember that classification into Satisfied and not yet satisfied
is always tentative. Any requirement can move from satisfied
to unsatisfied when a problem is discovered. A requirement can
move from unsatisfied to satisfied when the developers believe
it should be.
Each requirement should have its originator’s name and position
associated with it. The date it was first documented and the
dates of each subsequent modification should be associated
with the requirement also.
Slide 23:
The final section is an important one. The Glossary is a
lexicographic ordering of definitions of all the noun phrases and
some of the verbs used anywhere in the requirements. These
definitions should be clear, unambiguous, and complete. They
must be understood in the same way by all the readers of the
Requirements document. Examples should be included when an
example aids understanding.
Remember that some Agile methodologies place the Glossary as
a standalone Data Dictionary.
Slide 24:
The Software Requirements Specification or the backlogs
should satisfy sevral properties. These properties are not
always easy to establish, but a requirements description that
does not satisfy all eight properties often leads to
communication problems.
Correct means the requirements express the true needs of the
business stakeholders as accurately as possible. Of course, it is
very likely that user expectations will change enough over the
project to force modifications to the requirements. Noticing
and responding to these changes is usually the key to a
successful project. Nevertheless, the developers should try to
keep the requirements as correct as they can.
Unambiguous means the requirements mean the same thi ng to

all concerned parties. The developers need to understand how
the business stakeholders intend a requirement.
Complete means the requirements should fully address their
overall purpose. If this is the list of requirements for the
current release, that list should describe everything the release
must provide. If the list is for the current iteration, the list
should describe everything currently expected in this iteration.
Consistent means there is no place where a requirement
contradicts what another requirement states. For example, if
one requirement stated a user id could contain punctuation and
another requirement stated the id could not containan
ampersand, that would be inconsistent. If and when a developer
discovers an inconsistency, the relevant business stakeholders
must be consulted to resolve the inconsistency.
Slide 25:
The requirements must be traceable through the design to the
code and associated test cases.
The requirements must be prioritized, generally by the
concerned busiess stakeholders. This prioritization allows the
developers to make decisions as to what to implement first that
are consistent with business stakeholder expectations. If the
sacrifice or one or more requirements from the current iteration
is necessary to meet the scheduled ending date of the iteration,
the developers can make reasonable, business stakeholder
decisions as to what to delay.
Finally, the requirements should be testable. This means the
developers can write test cases that establish whether or not a
requirement or group of requirements have been satisfied.
Slide 26:
Finall, we are returning to methods for doing each of the
activities of requirements engineering. We finished the first
four before discussing the requirements document. There are
only two left.
In the Validation activity we make a final check of the
requirements individually before we move to either Design or
test-driven development, depending on the methodology.

Remember that the sixth activity, Management of Requirements
occurs throughout development.
In the Validation activity the properties checked overlap
somewhat with those mentioned earlier. The first two are new,
however.
Atomic means the requirement describes only one thing. For
example, the requirement
A student may enroll in undergraduate and graduate courses
Is not atomic because the product can partially satisfy this
requirement by supporting enrollment in one type of course, but
not the other type. This requirement should be divided in two:
A student may register in undergraduate courses.
A student may register in graduate courses.
Note that the requirement:
A student may register in courses
Could be ambiguous because some might interpret it to mean
only certain types of courses while others might interpret it to
mean any possible course.
Each requirement must have an identifier or name which is
unique among all the requirements. A unique identifier or name
allows the requirement to be referenced without any ambiguity
in any context.
Slide 27:
The final activity in Requirements Engineering is Requirements
Management. Management works during the other activities to
ensure developers and business stakeholders work together to
determine requirement priorities and to select the requirements
to be attempted in the current release and the current iteration.
When the other activities are not active, management does three
tasks:
• Track the currently active requirements through
design, coding, and testing.
• Control revisions to the currently active requirements
• Maintaining a variety of sub-lists of requirements.
Slide 28:

Requirements Engineering starts by trying to identify as many
potential requirements as possible. The relevant business
stakeholders are the sources for potential requirements.
Different development methodologies have different goals for
this elicitation of requirements. The three possibilities are
given on this slide.
The other Requirements Engineering activities other than
management, try to refine and reduce the set of potential
requirements to those requirements that will be satisfied by the
current release or the current iteration.
Non-functional requirements tend to be more abstract than
functional requirements. The greater abstractness makes them
more difficult to discover and prioritize. The diffuse, difficult
to predict impact of some non-functional requirements on the
functional requirements makes testing non-functional
requirements difficult.
Finally, developers must always remember that requirements are
the primary means of communication among developers,
business stakeholders, and eventual users. The biggest potential
source of miscommunication is poorly stated or incompletely
discovered requirements. Miscommunication is the largest
reason for project failure.
Types of Requirements
Functional
Non-functional
Quality Attributes
Constraints on the Product
Constraints on the Development process
Business

Marketing
Examples of Functional Requirements
The product should be able to compute student grades from
weighted examinations, assignments, and projects.
I want the product to track all online automobile sales within a
one hundred mile radius of my home for the past six months.
I need to be able to provide an explanation to my customer why
they do not qualify for a loan.
Examples of NonFunctional Requirements
The software must provide at least 1/10th second response to up
to 1,000 simultaneous users.
Users with vision no better than 20/100 must be able to use all
features of the product.
The software must be available for use by at least 200
simultaneous users at least 99.99% of the time.
Describing Requirements
Natural Language
Structured Natural Language
User Story
Use Case
User Story Example
User Login
A non-administrative user should be able to access all the user
functionality of the system by enteringa correct user name and
password.
What constitutes a correct user name and a valid password

should be described in the Glossary of the Requirements
Specification.
Use Case Example
Recipe Program
List recipes for Specified Ingredients
1. Start application
2. Display Welcome Screen
3. Select List recipes
4. Request Ingredients
5. Enter ingredients
6. Display corresponding recipes
7. Exit application
A Term
Feature
A functional capability of interest to users.
Examples
Working with a single appointment
Viewing my future schedule for a day, week, or month
Monitoring Database Usage
Activities of Requirements Engineering
Elicitation
Analysis and Negotiation
System Modeling
Specification
Validation
Management
An Elicitation Method
Rapid Appplication Development

Interview
Structured
Open-ended
Questionaire
Survey
Analysis Method
Examine each requirement
Is it unambiguous
Is it complete
Is it feasible
If uncertain, need prototyping or modeling
Modeling Using UML
Use Case Diagram
Using the Class Diagram
Use Case Diagram Example
Personal Scheduler
Establish Identity
Add Appointment
Dellete Appointment
Move Appointment
Change Appointment
View a Day
View a Week
View a Month
Delete Schedule
Create New Schedule

Class Diagram Example
Some requirements for a TV Log
Cap-1:Must support information on up to 5,000 television
episodes.
Cap-2: Must be able to handle up to 1,000 distinct TV shows.
Cap-3: Must be able to have 300 word opinion of any episode.
Rep-1: Must be able to retrieve list of episodes and dates for
any show.
Des-1: Must be able to report show, network, episodes about
which we have information.
Sec-1: Muust keep all information encrypted when not actively
in use.
A Class Diagram Example
Showing relationships to major User data
Identify major user data
Place each identified type of data in a rectangle.
Put each requirement in a rectangle.
Draw a line from each requirement rectangle to those data
rectangles it affects.
Showing relationships among requirements
Place each requirement in a rectangle.
Draw a line between each pair of requirements where one
affects the other.
Put an arrowhead at the end of each line to show the direction
of the relationship.
Label the line the name of that relationship.

Using Software requirements Specification
Goals
Describe the current requirements
Facilitate reviews
Provide a reference for the design
Testing use cases
Explaining vocabulary
Communication between developers and business stakeholders
Support tracing
A Sample Format
Introduction
Product Goals
Business Stakeholders
Intended Audience
Project Scope
More sample Format
Product Overview
Potential Users
What Users Might do with the Product
Operating Environments
Assumptions and dependencies
More Sample format
The Current Requirements
Funtional
Nonfunctional
Quality Attributes
Performance
Reliability

Satety
Security
etc
More Sample Format
Constraints on the Product
Constraints on the Development Process
Business
Marketing
Glossary of Terms
Desirable properties for the SRS
Correct
Unambiguous
Complete
Consistent
According to the IEEE Standard 830
More desirable Properties
Unambiguous
Traceable
Prioritized
Testable
A method for Validation
Each individual requirement should be:
Atomic

Uniquely identified
Complete
Consistent and unambiguous
Traceable
Prioritized
Testable
A Method for requirements Management
Tracking
Controling Revisions
Maintaining sublists
Completed
Top Priority uncompleted
Current iteration backlog
Postponed to later iteration
Postponed to later release
Requirements Summary
Three types of Requirements Engineerinng
Comprehensive initial requirements
Tentative initial requirements with periodic updates
Just enough requirements for this release or iteration with
periodic updates
Non-functional requirements often are much harder to satisfy
because their impact is diffuse.
Requirements must be understood by all stakeholders.
Customer
Manager
Supplier
Point of Sale System
Check Inventory
Order Stock

Cashier
Generate Invoice
<<include>>
Check out
Update Inventory
Payment
Scan Item
Bank
Refund
Exchange
Cash Payment
Card Payment
Recieve Stock
Generate Sales
Reports
<<include>>
<<include>>
<<extend>>
<<extend>>
<<include>>
Service Desk
<<include>>
<<include>>
<<include>>
dispatch
close
dateReceived: Date[0..1]
isPrepaid: Boolean[1]
number: String[1]
price: Money
Order
getCreditRating(): String
name[1]
address[0..1]
Customer
quantity: Integer

price: Money
Order Line
Product
{If Order.customer.getCreditRating is "poor"
then Order.isPrepaid must be true}
billForMonth(Integer)
remind()
contactName
creditRating
creditLimit
Corporate Customer
creditCardNumber
Personal Customer
Employee
*
1
1
*
{ordered}lineItems
*
1
0..1salesRep
*
UML Class DIagram
The Waterfall Model
A Word on Vocabulary
Waterfall is called
Process Model
Lifecycle
We use lifecycle.

More VocabuLary confusion
Software development activities:
Pressman: Sommerville:
Communication Specification
Planning Development
Modeling Validation
Construction Evolution
Deployment
We will use
Proposal
Planning
Design
Construction
Testing
Deployment
Maintenance
The Waterfall Lifecycle
Each activity is a phase
For the most part, the phases are done in order once.
At the end of each phase a document is reviewed
There is limited capability for backtracking
From one phase to its immediate predecessor
From a later phase back to Requirements Engineering or Design
Go/No-go decision at the end of each phase
Waterfall Advantages
Easier for upper management to track
Easier use of specialists

Reviewed formal documents valuable to maintenance and
support
Emphasis on formal communication
Minimal involvement of customer and potential users
Disadvantages
Difficult, if not impossible to do a phase completely before
moving on.
Expensive to backtrack
Software development is a learning process
Significant change is almost always frequent and unpredictable
No partial products available before development is complete
When to Use
Some government agencies provide complete requirements as a
Request for Proposal
Developing prototypes as part of a larger project
Some informal projects.
Still frequently used in 2018.
Variations on Waterfall
V Model
Requirements Engineering Acceptance Testing
Architectural Design System Testing
Component Design Integration Testing
Code Generation Unit Testing
Another Variation
Partition the Product
When it needs to be available
Risk (see Spiral Model)

Pick one partition and develop it using Waterfall
Select another partition and develop it using Waterfall
Continue until you have the entire product.
More on the Last Variation
Each partition may be implemented at the same time
Supports multiple development teams, perhaps located
differently.
Or implementation may proceed one partition at a time.
Typically, three to six months for each partition
implementation.
Script for
The Waterfall Model
Slide 1:
Each software product has a lifecycle, the sequence of phases
thru which that product passes from inception to retirement
from active use. Successful products may have lifecycles
extending over several decades. The actual development
portion of those lifecycles is usually a few years ( 1- 3) with the
products spending most of their lifecycles in maintenance and
support. Royce published a description of the first software
lifecycle in 1970. This is the Waterfall. This presentation
describes the Waterfall Model and a couple of major variants of
it. Later presentations will describe the iterative, iterative-
incremental, continual, and combinations of these models.
Slide 2:
As with many areas of Software Engineering, vocabulary for
lifecycles is not standardized. Some software engineers refer to
a lifecycle as a process model. Others use the term lifecycle.
We use lifecycle to mean the phases thru which a product
passes, either sequentially or iteratively. The lifecycle

describes how the phases fit together. Later, we will examine
major methodologies. A methodology is how the various phases
are implemented. A methodology, such as Scrum, describes
practices the developers should follow, and the relationships
among those practices and the phases.
Slide 3:
A phase may include multiple activities. The Waterfall does not
specify whether these activities are to be performed sequentally,
in parallel, or in some more complex fashion.
The Waterfall uses a largely sequential movement thru the
phases with limited opportunities to backtrack to an earlier
phase when problems, inconsistencies, mistakes, or infeasible
situations arise. However, different software engineers define
different sets of phases. Sometimes multiple terms are used for
the same phase, and sometimes the phases are partitioned
differently.
Roger Pressman defines five phases in his version of the
Waterfall. Communication includes project initiation and
requirements gathering. Planning includes establishing a
schedule and staffing plan as well as setting up mechanisms to
track progress thru the remainder of the development portion of
the lifecycle. Modeling includes analysis of the requirements
and design of the product. Construction includes writing the
product code, and testing that code. Finally, deployment
includes delivery of the final product, support, and feedback
from users.
Ian Sommerville actually has two different sets of phases in his
textbook. Only one of those sets is presented here. For the
other, see page 49 in his book. The details of the book are
given in the Course Syllabus. Specification includes initiation,
requirements engineering, an design. Development includes
coding, unit testing, and integration testing. Validation
includes system testing, and acceptance testing. Evolution
includes delivery, support, and maintenance.
Slide 4:

In this course, we will employ a different set of phases. The
proposal phase starts with a project proposal, usually by a
business unit. This phase includes the decision to attempt the
development. Requirements engineering then develops the
product requirements and does some preliminary analysis of
them. Planning develops a project schedule, and staffing plan.
Design completes the analysis of the requirements and
determination of the structure, data, user interface, and
algorithms for the product. Construction includes coding and
unit testing. Testing includes integration testing, system test,
and acceptance testing. Deployment is the release of the
product to potential customers and support. Finally,
maintenance is the correction of errors and the evolution of the
product to fit new environments.
The actual phases do not matter. The basic idea of the
Waterfall is that the phases are performed largely sequentially
with limited backtracking.
Slide 5:
Now let us discuss the most important aspects of the Waterfall.
Although almost no published description shows it, some other
activities are going on in parallel with the main development.
These include monitoring the development project to ensure that
the project is proceeding according to schedule. Management is
tasked with responding to significant deviations from the
schedule. Management responses might range from trying to
encourage the developers to work more effectively through
forcing extra work hours such as evenings or weekends, or
negotiating with upper management to reduce requirements or
lengthen the schedule, to recommending cancelation of the
project.
Other parallel activities include:
• Preparation of user and operating documentation;
• Preparation of training materials;
• Bringing new developers up to speed on the project as
needed

One very important characteristic of Waterfall is that most
communication among developers occurs through a formal
document which must be reviewed and approved before
development can proceed to the next phase. The Proposal phase
ends with review and approval of a Project Vision. The
Requirements Engineering phase ends with review and approval
of a Requirements Specification Document. The Planning Phase
ends with review and approval of a Schedule document and a
staffing plan. The Design phase ends with a Design
Specification. Construction ends with actual code and a
complete set of unit tests and their execution results.
Backtracking within a phase is very common and not disruptive.
Although Backtracking between phases is possible, in most
cases it is very disruptive. However, backtracking between
Construction and Testing is often the exception to this.
Slide 6:
Waterfall is still used in many software development projects
today. Most developers do not like it, however, because
Waterfall is designed more to benefit management than the
developers. Project and upper management make the decisions.
Management finds the reviewed and approved documents which
must be produced to move on to the next phase a much more
effective way to evaluate development progress than asking the
developers. Managers get to make decisions on whether or not
the project should proceed at the end of each phase.
Waterfall encourages the use of specialists in such areas as
database, user interface, testing, or networking. These
specialists may be employed for one phase of the development.
Compared to the other lifecycles, Waterfall may be more
feasible for inexperienced or less-than very capable developers.
The collection of reviewed and approved documents produced at
the end of each phase provides a very valuable resource for
maintenance and support. Some of these documents can be
excellent foundations for the work of an independent Quality

Assurance group.
Waterfall emphasizes formal communication through
documents. Compared to the oral communication encouraged in
some other lifecycles, formal communication at least guarantees
that some necessary communication among developers and
between developers and other parts of the company occurs.
Finally, customers and potential users are busy with their own
jobs and interests. Waterfall requires their involvement only at
the very beginning of the project and once the product is
deployed. Potential users do not have to take valuable time
from their jobs to exercise and provide feedback upon partial
products.
Slide 7:
Of course, Waterfall has several significant disadvantages.
Determining if the developers actually have all the correct
requirements at the end of the Requirements Engineering phase
is extremely difficult, if not impossible in most situations.
Deciding if a design is actually complete and feasible before it
is implemented is extremely difficult. Determining if a program
has been adequately tested is often impossible. As we will see
later in this course, testing nonfunctional requirements
adequately is much more difficult than testing functional
requirements.
Some backtracking such as from Design to Requirements or
Testing to Construction is expected and not too difficult.
However, backtracking all the way from Testing to
Requirements because some requirements turn out to be
infeasible is very expensive and unlikely to be successful.
Other possible backtracking can be expensive as well. In some
cases, the developers might need to use specialists who are no
longer available because they have moved on to other projects.
Any significant backtracking requires a major adjustment of the
schedule and, maybe, the project staffing.
In most companies, for a development team to remain
unchanged thru a single project lasting three to five years is

unlikely. For that team to remain unchanged through multiple
projects is even more unlikely. Furthermore, each software
development project undertaken even by the same company is
very different than the other projects that company has done.
The developers learn a great deal as the development proceeds.
Therefore, adhering to a previously specified schedule is often
impractical.
Change is inevitable for the clear majority of development
projects. Not only does the development team learn important
things they did not know at the start of the project, but the
competitive landscape and user expectations change
significantly during the years that the project takes. Some
software engineers have estimated that a typical commercial
development project has an average of 1% change in
requirements for each month. Thus, a three-year project would
see more than one third of the initial requirements change. Of
course, these requirements changes would result in design and
code changes as well as test case changes.
Finally, the lack of partial releases partway through the project
means the developers receive no feedback until the project is
complete. The risk of implementing an incomplete or
inappropriate product is great.
Slide 8:
In spite of these disadvantages, there are still times when the
Waterfall lifecycle is a viable choice. While it is less common
than in the 1960’s and 1970’s, some governmental agencies,
especially Defense Departments, still use Requests for Proposal
(RFP) to request outside companies to implement needed
software for them. The RFP contains a complete set of
requirements, and often, a date by which the software must be
produced. A company can bid to produce this software. The
winning company receives a contract specifying penalties for
not producing the software on time, and a mechanism for
receiving additional pay, if the project runs into unexpected
difficulties.

If a development project, perhaps using a different lifecycle,
needs a prototype, Waterfall can be a viable approach to
producing the prototype as a subproject. Prototypes often are
used to evaluate and refine possible user interfaces, or to
explore the feasibility of a given algorithm or data structure.
Finally, some informal projects may benefit from the use of
Waterfall. The insistence on formal rather than informal
communication might be helpful when more than one developer
is involved. Inexperienced developers can benefit from the
sequential nature of the Waterfall phases.
Note, that in all three circumstances where Waterfall might be a
reasonable lifecycle, the product requirements are unlikely to
change significantly.
Slide 9:
The remainder of this presentation examines a couple of popular
variations on the Waterfall. The V Model emphasizes the fact
that once the code is produced, there are a sequence of
evaluation phases which use successively higher level
documents to guide the testing of the code. Thus, unit testing is
based on the source code itself. Integration testing is based on
the document reviewed and approved to end the Component
Design phase. System testing is based on the document that
comes from Architectural design. Acceptance testing uses the
Requirements Specification as its basis.
When applied, the V model generally has a planning phase
before requirements engineering and a deployment phase after
acceptance testing.
Slide 10:
Another Waterfall variation involves dividing the proposed
software product into two or more largely independent pieces.
The pieces should interact only through a limited set of narrow
calls, usually implemented using application programming
interfaces (API). Scheduling of the implementation of each

piece can be done in either of two ways: based on the sequence
in which the pieces need to be available for users; or based on
the amount of risk believed to be associated with that piece.
Then the lifecycle works by doing a separate Waterfall project
to implement each piece.
Slide 11:
We could have separate development teams implement each
piece at the same or overlapping times. These teams could be
co-located or in different places. As an alternative, we could
implement one piece at a time. Sequential implementation
might support recognizing needed modifications to an earlier
piece and using their implementation as a new Waterfall.
Whatever of these slightly different approaches is used, each
piece implementation should take three to six months.
Note that if the pieces are implemented by different teams, care
must be taken to ensure the teams have the same meaning for
the interfaces between pieces. In this variation of Waterfall,
formal documents are used for each interface. These documents
are reviewed by each team and approved.
College of Administrative and Financial Sciences
Assignment 2
Deadline: 2/11/2019 @ 23:59
Course Name: Accounting Info system
Student’s Name:
Course Code: ACCT 402
Student’s ID Number:
Semester: I
CRN:
Academic Year: 1440/1441 H

For Instructor’s Use only
Instructor’s Name:
Students’ Grade: Marks Obtained/Out of
Level of Marks: High/Middle/Low
Instructions – PLEASE READ THEM CAREFULLY
· The Assignment must be submitted on Blackboard (WORD
format only) via allocated folder.
· Assignments submitted through email will not be accepted.
· Students are advised to make their work clear and well
presented, marks may be reduced for poor presentation. This
includes filling your information on the cover page.
· Students must mention question number clearly in their
answer.
· Late submission will NOT be accepted.
· Avoid plagiarism, the work should be in your own words,
copying from students or other resources without proper
referencing will result in ZERO marks. No exceptions.
· All answered must be typed using Times New Roman (size 12,
double-spaced) font. No pictures containing text will be
accepted and will be considered plagiarism).
· Submissions without this cover page will NOT be accepted.
Assignment Question(s): (Marks.….)
1. (Write no less that 500 words) Based on what you have
learned in Chapter 12, Choose an existing business. This could
be a service business, merchandising business; or a
manufacturing business. Try to describe the revenue cycle in
details. Then, write a case (hypothetical) in which this
organization face three types of the following threats and how
the organization could resolve these dilemmas:
General Revenue Cycle Threats.
Sales Order Threats.
Shipping Threats.

Billing Threats.
Cash Collections Threats.
2. What is meant by concurrent audits and how it could be
achieved?
3. In your own words, differentiate between COSO and COBIT
in terms of their purpose and application. Why do organizations
need to apply both of them not only one. (write 200 words).
Answer:
1.
2.
3.
.
.

Software Requirements SpecificationforProjectVersion.docx

Recommended

Recommended

More Related Content

Similar to Software Requirements SpecificationforProjectVersion.docx

Similar to Software Requirements SpecificationforProjectVersion.docx (20)

More from rosemariebrayshaw

More from rosemariebrayshaw (20)

Recently uploaded

Recently uploaded (20)

Software Requirements SpecificationforProjectVersion.docx