CSST 134

Software Engineering

Requirements Analysis

Requirements Engineering

Requirements Engineering is the branch of systems

engineering concerned with real-world goals for,
services provided by, and constraints on software
systems. (Chang, 2008)

Requirements Engineering is also concerned with

the relationship of these factors to precise
specifications of system behavior and to their
evolution over time and across system families.
(Ibid)

Requirements Analysis
Requirements

Analysis answers the question

What is the problem?
The goal is to determine the nature of the
customers problem.
Thus, requirements should be focused on the
customer and the problem, not the solution
or implementation.

Importance of Requirements Analysis

They

may be a legal contract.

They are basis for later testing.
Lack of requirements or poor requirements
are common reason for project failure.

Who Needs to be Involved

Everybody.
Here are some and the reasons:

Customers and the people representing them

Marketing

Documentation

Dont want something required they cant build.

Needs to be complete and usable

Technical Support

They will test against it

Developers

They will use requirements to produce documentation

Testers

They are probably promoting its development

They have to figure out how to sell it.

Since they will have to support it

Customer Training

Need to develop any courses if needed.

Definition vs. Specification

Requirements

definition is a complete
listing of everything the customer expects the
proposed system to do. It represents an
understanding between customer and
developer of what the customer needs or
wants.
Requirements Specification restates the
requirements definition in technical terms
appropriate for the development of the
system design

Functional & Nonfunctional

Requirements
Functional

Requirement describes an
interaction between the system and its
environment. It also describes how the system
should behave given a certain stimuli.
Nonfunctional Requirements (or constraints)
describes a restriction on the system that limits
our choices for constructing a solution to the
problem

Types of Requirements

Physical Environment
Interfaces
Users and Human Factors
Functionality
Documentation
Data
Resources
Security
Quality Assurance

Characteristics of Requirements
Are

the requirements correct?

Are the requirements consist?
Are the requirements complete?
Are the requirements realistic?
Does each requirement describe something
that is needed by the customer?
Are the requirements verifiable?

Specification Principles

Separate functionality from implementation.

Develop a model of the desired behavior that encompasses
data and the functional responses of the system.
Establish the context in which the software operates by
specifying interactions with other system components.
Define the environment in which the system operates.
Create a cognitive model rather than a design or
implementation model. That is, it should be described from a
users perspective.
Recognize that it is an abstraction, a model that will always be
incomplete, and must be amenable to change

Specification Guidelines
Representation

format and content should be

relevant to the problem.
Information should be nested.
Diagrams and other notational forms should
be restricted in use and consistent in use.
Representations should be revisable.

Words Make a Difference

Be

on the lookout for persuasive connectors

(certainly, therefore, clearly, obviously, it
follows that), and ask why?
Watch out for vague terms (some, sometimes,
often, usually, ordinarily, most, mostly) and
ask for clarification
When lists are given and not completed (etc.,
and so forth, and so on, such as) be sure all
items are understood.

Words Make a Difference

Be

sure stated ranges dont contain unstated

assumptions (valid codes range from 10 to
100)
Beware of vague verbs (handled, rejected,
processed, skipped, eliminated)
Beware of ambiguous pronouns (The I/O
module communicates with the data
validation module and its control flag is set.)

Words Make a Difference

Look

for statements that imply certainty

(always, every, all, none, never) and ask for
proof.
When a term is explicitly defined in one
place, try substituting the definition for other
occurrence.
When a structure is defined in words, draw a
picture.
When a calculation is specified, work at least
two examples.