Requirement Analysis
SOFTWARE ENGINEERING
What are Requirements?
• Expression of desired behavior
• Deals with objects or entities, the states they can be in, and the
functions that are performed to change states or object
characteristics
Steps of
Capturing Requirements
Forms of Requirements
• Functional Requirement-Describes required behavior in terms of
required activities, such as reactions to inputs
• Quality Requirement-Describes some quality characteristic that the
software solution must possess, such ease of use and high reliability
• Design Constraint-Design decision, such as choice of platform or
interface components
• Process Constraint-Restriction on the techniques or resources that
can be used to build the system
Forms of Requirements
How Users & Developers View Each Other
Common Stereotypes
Sources of Requirements
The Volere
requirement process
Model, shows sources
of possible requirements
Requirement Documentation
• Two types
•
•
Requirements Definition Document-aimed at a business audience, such as
clients, customers, users
Requirements Specification Document-aimed at a technical audience, such
as designers, testers, project managers
• Requirements Definition-a complete listing of everything the
customer wants to achieve
• Requirements Specification-restates the requirements as a
specification of how the proposed system shall behave
Requirement Documentation Examples
Causes of Failed Projects
According to Standish Group survey in 1995
from over 350 companies
Incomplete requirements
Lack of user involvement
Lack of resources
Unrealistic expectations
Lack of executive support
Changing requirements and specifications
Lack of planning
System no longer needed
Cost to Fix Bugs at Different Stages of Design
• According to Boehm and Papaccio 1988
$1-find and fix a requirements based problem during the requirements
definition process
• $5-to repair it during design
• $10-during coding
• $20-during unit testing
• $200-after delivery of system
•
Characteristics of Requirements
•
•
•
•
•
•
•
•
Correct-Make sure there are no errors
Consistent-There are no conflicting requirements
Unambiguous-Requirements has only one interpretation
Complete-Everything stated in the requirement documents should be
there
Feasible-Solution to every customer need should exist
Relevant-To user needs
Testable-Every requirement stated is verifiable
Traceable-The requirements organized and uniquely labeled for easy
reference
Modeling Notations:
Entity-Relationship Diagrams
A popular, graphical
notational paradigm for
representing conceptual
models
Example:
Modeling Notations:
Unified Modeling Language(UML) Class Diagrams
A collection of notations
used to document
software specifications and
designs
Example:
Modeling Notations:
Event Traces
A graphical description of a
sequence of events that
are exchanged between
real-world entities
Example:
Modeling Notations:
Message Sequence Charts
An enhanced event-trace
notation, with facilities for
creating and destroying
entities, specifying actions
and timers, and composing
traces
Example:
Modeling Notations:
• State Machines
•
a graphical description of all
dialog between the system and its
environment
• UML Statechart Diagrams
•
depicts the dynamic behavior of
the objects in a UML class
Modeling Notations:
• Petri Nets
•
a form of state-transition notation
that is used to model concurrent
activities and their interactions
• Data-Flow Diagrams
•
models functionality and the flow
of data from one function to
another
Modeling Notations:
• Use-Case Diagram
•
similar to a top-level data-flow
diagram that depicts observable,
user-initiated functionality in
terms of interactions between the
system and its environment
Modeling Notations:
• Formal Methods
•
mathematically based
specification and design
techniques
• Decision Tables
•
a tabular representation of a
functional specification that maps
events and conditions to
appropriate responses or actions
Modeling Notations:
• Parnas Tables
•
tabular representations of
mathematical functions or
relations
Modeling Notations:
• First –Order Logic
•
logic commonly used to express
properties of software
requirements
• Temporal Logic
•
introduces additional logical
connectives for constraining how
variables can change value over
time – more precisely, over
multiple points in an execution
Modeling Notations:
• Object Constraint Language
•
an attempt to create a constraint
language that is both
mathematically precise and is
easy for non-mathematicians
• Z
•
structures set-theoretic
definitions of variables into a
complete abstract-data-type
model of a problem
Prototyping Requirements
• Throw-Away Prototype
•
software that is developed to
learn more about a problem or
about a proposed solution, and
that is never intended to be part
of the delivered software.
• Evolutionary Prototype
•
software that is developed not
only to help us answer questions
but also to be incorporated into
the final product
Documenting Requirements
• Need documents so customers
and developers can refer to it
throughout development and
maintenance
• Requirements definition is a
record of the requirements
expressed in the customer’s
terms
• Requirements specification
covers exactly the same
ground as the requirements
definition, but from the
perspective of the developers
IEEE standard for Software Requirements Specification
• Provides templates for
organizing the requirements
specification by mode of
operation, function, feature,
category of user, and so on
Participants in the Requirement Process
• Clients, the ones paying for the
software to be developed
• Customers, buy the software
after it is developed
• Users, familiar with the current
system and will use the future
system
• Domain experts, familiar with
the problem that the software
must automate
• Market researchers, conducted
surveys to determine future
trends and potential
customers’ needs
• Lawyers or auditors, familiar
with government, safety, or
legal requirements
• Software engineers or other
technology experts
Validation and Verification
• In requirements validation, we
check that our requirements
definition accurately reflects
the customer’s needs
• In a review, representatives
from our staff and the
customer’s staff examine the
requirements document
individually and then meet to
discuss identified problems
Measuring Requirements
• Measure by 1 to 5
•
•
1 being you understand the
requirements completely
5 being you do not understand
the requirement at all
Good
Bad
Measuring Requirement Readiness
Choosing a Specification Technique
• Applicability
• Verifiability
• Implementability
• Run-time safety
• Testability
• Tools Maturity
• Checkability
• Looseness
• Maintainability
• Level of expressibility
• Soundness
• Learning curve
• Technique Maturity
• Data Modeling
• Discipline
Sources
• http://www.scielo.br/img/fbpe/jbcos/v5n1/v5n1a4f349.gif
• http://www.cse.msu.edu/~chengb/RE-491/Papers/atleechapter4.pdf
• http://rajeshg.info/book/export/html/5