S/W REQUIREMENTS DEFINITION

CHAPTER - 4
 S/W Requirement Specification:
• Clearly and precisely define essential requirements for the
s/w product.
• External interface to h/w, firmware, other s/w and people.

Format of a Software Requirement Specification :

Section 1: Product Overview and summary
Section 2: Development/operations/maintenance environment
1 & 2 sections present an overview of product
• Features
• Processing environments for
– Development
– Operation
– maintenance
Section 3: External interfaces and data flow
• User display/report formats
• User command summary
• High-level data flow diagram specifies
• Logical data sources/sinks
• Logical data stores
• Conceptual data structure .
• Physical implementation details are suppressed.
• Logical characteristics emphasized.
• Logical data dictionary
• Flow of data between sources
• Transformation and stores
• Data flow diagram:
– Data sources and data sinks are depicted by shaded
rectangle.
– Transformation by ordinary rectangles.
– Data stores are by open ended rectangles.
– Arcs specify data flow
– Not concentrate on decision structure.
• Data Dictionary Entries:
– Include the name of the data item, attributes
• Where it is used
• Its purpose
• Where it is derived from
• Its sub items
• Any Notes.
– Each named data items on data flow diagram should
appear .
– The physical implementation details of data items
not considered.
Section 4: Functional Specifications:
• Expressed in relational and state oriented notations that
specify relationships among
– Inputs
– Actions
– Outputs
Section 5 : Performance requirements
• Performance characteristics such as
– Response time for various activities
– Processing time for various process
– Through put
– Primary and secondary memory constraints
– Required telecommunication bandwidth
– Extraordinary security constraints
• Section 6: Exception conditions/exception handling
– Exception handling
– Including the actions to be taken and
– The messages to be displayed in response to undesired situation
• Section7 : Early subset and implementation priorities
• Initial version may be skeletal prototype, frame work for evolution
of the product.
• Each successive versions can incorporate
• The capabilities of previous version.
• Provide additional functions.
• Successive versions provide increasing level of capabilities.
• Specify implementation priorities for system capabilities like
• Essential features
• Desirable features
• Nice if features
• Section 8 : Foreseeable modification and
enhancements
• Foreseeable modifications and enhancements that may
be incorporated into the product following the initial
product release.
• Foreseeable modifications might occur when
– Anticipated changes in project budget or mission.
– New hardware acquisition
– Experienced gained from an initial release of product.
Section 9 : Acceptance criteria
• Specifies
• Functional and performance tests
• Standards to be applied
• Applied to source code
• Internal Documentation standards
• External documents
• Design specifications
• Users manual
• Principles of operation.
• Installation and Maintenance procedures.
• The desired functional and Physical audits of
• Source code, documents and physical media.
• Verify functional and performance requirements stated in
Sections 4 and 5.
Section 10: Designs hints and guidelines
• How the product will provide the characteristics

Section 11: Sources of information

• Cross reference directory should be provided to index specific
paragraphs numbers
• Verification and re-examination of requirements, constraints and
assumptions.

Section 12: Glossary of terms

• Definitions of terms that may be unfamiliar to customer and
product developers.
Desirable Properties of SRS:
• Correct
• Complete
• Consistent
• Unambiguous
• Functional
• Verifiable
• Traceable
• Easily changed
• An incorrect or incomplete does not satisfy
customer need.
• An inconsistent state contradictory requirements
in different parts of documents.
• Should be functional
• Must be verifiable from two points of view.
– Satisfy the customer need
– Satisfy the requirements
• Should be indexed, segmented and cross
referenced to permit easy use and modifications.
• Success depends on the ability to incorporate
changes without starting over.
4.2 Formal Specifications
Technique
 4.2.1 Relational Notations
• Includes
1. Implicit Equations
2. Recurrence Relations
3. Algebraic Axioms
4. Regular Expressions
1. Implicit Equations :
• State the properties of a solution without stating a
solution method.
• Eg Matrix Inversion as
– M X M’ = I + E
• Matrix inversion is specified such that the matrix
product of the original matrix M.
• The inverse of M, M’ yields the identity matrix I
plus or minus the error matrix E.
• E specifies allowable computational errors.
• Implicit specification must include items such as
• Matrix Size
• Type of Data Element
• Degree of Sparseness.
• Matrix Inversion Design involves specifying
• A data structure ,
• An algorithm for computing the inverse and
• Packaging technique for the inversion module.
• Not all specification guaranteed to have
algorithmic solutions.
2. Recurrence Relations :
• Consists of an initial part called basis part
• One or more recursive parts
– Describe the desired value of a function in terms of
other values of the function.
– Recurrence Relations are easily transformed into
recursive programs.
• For Example
– Successive Fibonacci numbers are formed as
– Sum of the Previous two Fibonacci numbers.
– The First on is defined as 0.
– The Second as 1.
– This number can be defined by the recurrence
F(0) = 0
– F(1) = 1
F1(N) = F1(N-1)+ F1(N-2)+ for all N > 1
3. Algebraic Axiom :
• Mathematical systems are defined by axioms.
• Specify functional properties of s/w systems.
• Axiom
• Specify fundamental properties of a system
• Provide basis for deriving additional properties that are implied by
axioms.
• Additional properties are called theorems.
• Set of axioms must be complete and consistent.
• No axioms can be derived from the other axioms
• This approach used abstract data types.
– Set of objects
– Set of permissible operations
– Emphasize important characteristics.
– Defining Syntax of the operations
– Specifying axiomatic relations among operations.
– The Syntactic definition specifies
• Names
• Domains
• Range of operations to be performed on the data objects
• Interactions among operations
 LIFO
• Definition of stack
• NEW creates new stack
• PUSH adds a new item to the top of a stack.
• TOP returns a copy of the top item
• POP removes the top item
• EMPTY tests foe an empty stack.
• Operation NEW yields a newly created stack
• PUSH requires two arguments.
 Fig - Algebraic specification of the LIFO property

•SYNTAX:

OPERATION DOMAIN RANGE

NEW ( ) -------------> STACK
PUSH (STACK,ITEM)--------> STACK
POP (STACK) --------> STACK
TOP (STACK) --------> ITEM
EMPTY (STACK) --------> BOOLEAN
AXIOMS
(stk is of STAK type, itm is type ITEM)
1)EMPTY(NEW) = true
2)EMPTY(PUSH(stk, itm)) = false
3)POP(NEW) = error
4)TOP(NEW) = error
5)POP(PUSH(stk, itm) = stk
6)TOP(PUSH(stk,itm)) = itm
 Definition of STACK function behavior
NEW PUSH(stk,item)
PURPOSE :create a new stack Purpose : place an item on stk
Exception : Memeory_Full = true Exception : Valid_Stack(stk) = false
Effects : Number_Items(NEW) = 0 Number_items(stk) = MAX

EMPTY(Stk)
Purpose : Test stk for empty property
Exception : Valid_Stack(stk) = false
Effects : if Number_Item
• New operations can be defined in terms of existing ones.
• Algebraic axioms can be used in 3 distinct ways:
– Definitional tools
– Foundation for deductive proofs of desired properties.
– Frame works for examining the completeness and consistency of
functional requirements.
• 2 types of completeness
– Internal :
• Requirement specification is internally complete has no un-
define entities in the specified.
• Consistency involves the relationship among specifications.
– Extern : pragmatic considerations
• Requirement specification is externally complete if all the
desired properties are specified.
• Symbolic execution :
• Used to execute algebraic
specifications.
• Performs sequence of function
applications and report the results
obtained.
• Report error condition encountered in
attempting a sequence of operations.
• Used to investigate completeness and
consistency of algebraic specifications.
4. Regular Expressions :
• Used to specify the syntactic structure of
symbol strings.
• Viewed as language generators.
• The rules for forming regular expression are
quite simple :
1. Atoms :
• The basic symbols in the alphabet of interest form regular
expressions.
2. Alternation :
• if R1 and R2 are regular expressions, then (R1| R2)
is a regular expression.
3. Composition :
• If R1 and R2 are regular expressions, then (R1 R2) is
a regular expression.
4. Closure :
• If R1 is a regular expression, the (R1)* is a regular
expression.
5. Completeness :
• Nothing else is a regular expression.
• An alphabet of basic symbol provides the atoms.
• Rule 1 is the basic rule
• Rule 5 complete the regular expression.
• Examples:
1. Given atoms a and b, then a denotes the set {a} and
b denotes the set {b}.
2. Given atoms a and b, then (a|b) denotes the set
{a,b}.
3. Given atoms a, b, and c then ((a|b|c)) denotes the
set {{a,b},c}
4. Given atoms a and b, then (a,b) denotes the set {ab}
containing one element ab.
5. Given atoms a,b, and c, then ((a,b,c)) denotes
the set {abc} containing one element abc.
6. Given atom a, then (a)* denotes the set
{e,a,aa,aaa,…} where e denote the empty string.
• Closure, (R1)*
• Denotes zero or more concatenation of elements
from R1.
• A commonly used notation is (R1)+ which denotes
one or more concatenation of elements in R1.
• The ‘*’ and ‘+’ notations are called the kleene star and
kleene plus notations.
• Interpretations of Regular expression:
1. Data Stream :
• If a,b and c are i/p data symbol.
• Valid data stream start with a followed by b and c.
2. Message Transmission :
• ‘a’,b, and c can be interpreted as message type such
as resource request or release.
• Job initiation request or end of file.
3. Operation Sequence:
• If a,b and c represent procedures, then legal calling
sequences are a followed by a call to b or c followed
by zero or more returns to a followed by b or c.
4. Resource flow:
• Symbols a,b, and c might denote system
components such as a process or a user.
• Hierarchical Specification:
• Constructed by assigning names to regular expressions and
using the names in other regular expression.
 4.2.2 State Oriented Notations
1. Decision Tables:
•Specify actions in terms of complex decision logic.
•provide a mechanism for recording complex
decision logic.
•Tables are widely used in data processing
applications and have an extensively developed
literature.
•Four quadrants
1. Condition Stub :
Contains all of the conditions being examined.
 Decision Rules
Rule 1 Rule 2 Rule 3 Rule 4
Condition entries
Condition Stub
Action Stub Action entries

Limited-entry decision table

Decision Rules
1 2 3 4
Credit Limit is satisfactory Y N N N

Pay experience is favorable - Y N N

Special clearance is obtained - - Y N

Perform approve order X X X

Go to reject order X
2.Condition entry :
Used to combine conditions into decision rules.
3.Action stub :
Describes the action to be taken in response to
decision rules.
4. Action entry :
Relates decision rules to actions.
Eg. Orders are approved
– if the credit limit is not exceeded, or
– if the credit limit is exceeded but past experience is good,
or
– If a special arrangement has been made.
– If none of these conditions hold, the order is rejected.
• Ambiguous Rules:
– If more one decision rule has identical
• Contradictory :
– Ambiguous pairs of decision rules that specify identical
actions are said to be redundant, and specify different
actions are contradictory.
• This rules permit specification of nondeterministic
and concurrent actions.
• Complete:
• Table is complete if every possible set of condition
has a corresponding action prescribed.
• For 2 ** N combination of conditions in a table that
has N condition entries.
• Karnaugh map is used to check the completeness
and multipy-specified actions of decision table.
• Specification is incomplete if there are any blank
entries in this map.
• Specification is multiply specified action if there
are any multiple entries in the map.
A1 A1 A2 A2
A2 A2
A1 A1 A3
2. Event tables :
• Relates actions to system conditions and incorporate
the concept of system state.
• Specify actions to be taken when events occur under
different set of conditions.
• A two-dimensional event table relates actions to two
variables.
f(M, E) = A
• where M current set of operating conditions.
• E is the event,
• A is the action.
• Special notations:
– (A14:A32)-first sequentially followed by the 2nd.
– (A6,A2)-concurrent activation.
– Dash (-)- no action required.
– (X)-impossible configuration.
• 2-Dimensional Event Table
Mode Event

Rule 1 Rule 2 Rule 3 Rule 4

Start-up E13 E37 E45

Steady A16 - A14;A32

Shut-down X A6,A2 -

Alarm
3. Transition Table :
• Specify changes in the state of a system as a
function of driving forces.
• Summarizes the status of all entities in the
system at a particular time.
• Given the current state and current conditions,
the next state results.
• If when in state Si, condition Cj result in a
transition to state Sk, say f(Si,Cj)=Sk
• Transition Diagram
Alternative representation for transition tables.
States become node in a directed graph.
Transition represented by arc between nodes.
Arc labeled with conditions.
Table a a

Current state Current Input

a b b
S0 S1

S0 S0 S1
Diagram b
S1 S1 S0

NEXT STATE
4. Finite state Mechanism:
• DFD, regular expression and transition tables
combined in this.
• Draw back is-state explosion, hierarchical
decomposition is the solution.

D11
Split
Ds,D11,D12,De
D12
5. Petri Net :
• Petri net is primarily used for studying the dynamic
concurrent behavior of network-based systems where
there is a discrete flow.
• Petri Nets are applied in practice by industry, academia,
and other places.
• Petri net consist two types of nodes: places and
transitions.
• Arc exists only from a place to a transition or from a
transition to a place.
• A place may have zero or more tokens.
• Graphically, places, transitions, arcs, and tokens are
represented respectively by: circles, bars, arrows, and dots.

p1 t1 p2
 Definition of Petri Net
• C = ( P, T, I, O)
– Places
P = { p1, p2, p3, …, pn}
– Transitions
T = { t1, t2, t3, …, tn}
– Input
I : T  Pr (r = number of places)
– Output
O : T  Pq (q = number of places)

• marking µ : assignment of tokens to the places of Petri net µ =

µ1 , µ 2 , µ 3 , … µ n
Properties of Petri Nets
• Sequential Execution
Transition t2 can fire only after
the firing of t1. This impose the
p1 t1 p2 t2 p3
precedence of constraints "t2
after t1."
• Synchronization
Transition t1 will be enabled
only when a token there are at
least one token at each of its
input places. t1
• Merging
Happens when tokens from
several places arrive for service
at the same transition.
Properties of Petri Nets -continued

• Concurrency
t1 and t2 are concurrent. t1
- with this property, Petri net is
able to model systems of t2
distributed control with multiple
processes executing concurrently
in time.
Properties of Petri Nets -continued

• Conflict
t1 and t2 are both ready to fire but
the firing of any leads to the
t1
disabling of the other transitions.
t2

t1

t2
Properties of Petri Nets -continued

• Conflict - continued

– the resulting conflict may be resolved in a purely

non-deterministic way or in a probabilistic way, by
assigning appropriate probabilities to the conflicting
transitions.

there is a choice of either t1 and t2, or t3 and t4

t1 t2

t3 t4
Example: In a Restaurant (A Petri Net)

Waiter
Customer 1 free Customer 2

Take Take
order order

wait Order wait

taken

eating eating
Tell
kitchen Serve food
Serve food
 Example: In a Restaurant
(Two Scenarios)
• Scenario 1:
– Waiter takes order from customer 1; serves
customer 1; takes order from customer 2; serves
customer 2.
• Scenario 2:
– Waiter takes order from customer 1; takes order
from customer 2; serves customer 2; serves
customer 1.
 Example: In a Restaurant (Scenario 1)

Waiter
Customer 1 free Customer 2

Take Take
order order

wait Order wait

taken

eating eating
Tell
kitchen Serve food
Serve food
 Example: In a Restaurant (Scenario 2)

Waiter
Customer 1 free Customer 2

Take Take
order order

wait Order wait

taken

eating eating
Tell
kitchen Serve food
Serve food
 Example: Vending Machine (A Petri net)

Take 15c bar

Deposit 10c
15c
5c
Deposit 5c

Deposit Deposit
0c 5c Deposit 5c
5c

Deposit 10c
10c 20c
Deposit 10c
Take 20c bar
 Example: Vending Machine (3 Scenarios)

• Scenario 1:
– Deposit 5c, deposit 5c, deposit 5c, deposit 5c, take 20c
snack bar.
• Scenario 2:
– Deposit 10c, deposit 5c, take 15c snack bar.
• Scenario 3:
– Deposit 5c, deposit 10c, deposit 5c, take 20c snack bar.
 Example: Vending Machine (Token Games)

Take 15c bar

Deposit 10c
15c
5c
Deposit 5c

Deposit Deposit
0c 5c Deposit 5c
5c

Deposit 10c
10c 20c
Deposit 10c
Take 20c bar