REQUIREMENTS

ENGINEERING PROCESS
 Requirements engineering provides the appropriate mechanism for understanding what
the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution,
specifying the solution unambiguously, validating the specification and managing the
requirements as they are transformed into an operational system.

Requirements
Feasibility Elicitation &
Study Analysis

Requirement
Specification
Feasibility Report System Models

Requiremen
User & System t Validation
Requirements

Requirement
Document
The Requirements Engineering process can described in five distinct steps:
1. Feasibility Studies
2. Requirements Elicitation
3. Requirements Analysis and Negotiation
4. Requirements Specification
5. Requirements Validation
6. Requirements Management

1. Feasibility Studies
The Requirements engineering process should start with a feasibility study. The input to
the feasibility study is an outline description of the system and how it will be used within an
organization.
a. Does the system contribute to the overall objectives of the organization.
b. Can the system be implemented using current technology and within given cost and
schedule constraints
c. Can the system be integrated with other systems which are already in place?
 If a system does not support these objectives, it has no real value to the business.
Carrying out a feasibility study involves.
a. Information Assessment
b. Information Collection
c. Report Writing
Information Assessment
This phase identifies the information which is required to answer the three questions set
out above. Once the information have been identified, the information sources has to be
questioned to answer the following:
a. How would the organization scope if this system was not implemented.
b. what are the problems with current process and how would a new system help
alleviate (improve) these problems?
c. What direct contribution will the system make to the business objectives?
d. Can information be transferred to and from other organizational systems?
e. Does the system require technology which has not previously been used in the
organization?
f. What must be supported by the system and what need not be supported?
Requirements Elicitation
Problems making requirements elicitation difficult:
a. Problem of scope (Unnecessary technical details)
b. Problem of understanding (Poor Understanding)
c. Problems of Volatility (Change over time)
d. Problems of political factors (any influence of political)
e. Domain Understanding (To Understanding the specialized area)
f. Requirements Collection (System to discover their requirements)
g. Classification (Prober organization)
h. Conflict Resolution (To resolve the two same user requirements)
i. Prioritization (Important requirement to solve first priority)
j. Requirements Checking (Validate the user Requirements)
k. Requirements Specification (Written documents, Graphical model, and
formal mathematical model)
l. Requirements Documents ( To prepare the SRS document)
Guidelines for Requirements Elicitation
a. Assess the business and technical feasibility for the proposed system.
b. Identify the people who will help specify requirements and understand the organizational
bias.
c. Identify domain constraints
d. Define technical environment (Eg. Computing architecture, OS, Telecommunication.
e. Define one or more requirement elicitation methods such as interviews, focus groups and
team meetings.
f. Identify ambiguous requirements as candidates for prototyping.
g. Identify key requirements.

Requirements Analysis & Negotiation

a. Is each requirement consistent with the overall objective for the system / product?
b. Have all requirements been specified in the proper level of abstraction?
c. Is the requirement really necessary?
d. Is each requirement bounded and Unambiguous?
e. Does each requirement have attribution?
 f. Do any requirements conflict with other requirements?
g. Is each requirement achievable in the technical environment that will house the system
or product?
h. Is each requirement testable, once implemented.

Requirements Specification
a. Requirements Specification means different things to different people.
b. A Specification can be a written document, a graphical model, a formal mathematical
model, a collection of usage scenarios; a prototype, or any combination of these.
c. The System Specification is the final work product produced by the system and
requirements engineer. It server as the foundation for hardware engineering, software
engineering, database engineering and human engineering.
d. The System Specification also describes the information that is input to and output from
the system.
Requirements Validation
a. Requirements validation is the process of determining than the specification is consistent
with the requirements definition.
b. Requirements validation examines to ensure that all system requirements have been
stated unambiguously, that inconsistences, omissions and errors have been detected and
corrected and the work products conform to the standards established for the process and
the product.
c. During the requirements validation process, different types of checks should be carried
our on the requirements in the requirement document. These checks include:
i. Validity Checks (Inevitable a compromise across the user community)
ii. Consistency Checks (Different description of the same system function)
iii. Completeness Checks (Define all functions and constraints intended by
the system user)
iv. Realism (Practically) Checks (Requirements should be checked to ensure
that they can actually be implemented)
v. Verifiability (The System requirements should always be written so that
they are verifiable.
 Requirements Validation Techniques

Technologies Description

Manual Techniques Reading

Manual Cross Referencing

Interviews

Reviews (Complete, Consistent, Verifiability,

Comprehensibility, Traceability)
Checklists

Manual models to check functions & relationships

Scenarios

Mathematical proofs

Automated Techniques Automated cross referencing

Automated models to exact functions

Prototypes
Requirements Management
a. Requirements management is a set of activities that help the project team to identify,
control and track requirements and changes to requirements at any time to the project
proceeds.
b. Each requirement is assigned a unique identifier that might take the form:
<requirement type> <requirement #>
Requirement type may be
F - Functional Requirement D – Data Requirement
B – Behavioral Requirement I – Interface Requirement
P – Output Requirement
Requirement Classes
a. Enduring Requirements (Stable Requirements)
b. Volatile Requirements (Change during the System development)
Mutable Requirement (Changes to the environment)
Emergent Requirement (Customer understanding of the system develops)
Consequential Requirement ( Change the organizations process)
Compatibility Requirements (Business processes within an organization)
Requirements Management Planning
a. Requirements Identification (Uniquely Identified)
b. Change Management Process (Assesses the impact and cost of changes)
c. Traceability Policies (Overall property of a requirements specification)
i. Source traceability information (Links the requirements to the customers or
Stockholder who proposed the requirements)
ii. Requirement Traceability information (links dependent requirements written
the requirement document)
iii. Design Traceability information (links the requirement to the design modules
where these requirements are implemented)
d. Case Tool Support (Requirement management involves the processing of large amounts
of information about the requirements (eg.) spread sheets and database.)
i. Requirement Storage (Requirements should be maintained in a secure,
managed data store)
ii. Change Management (Requirements change management should be applied to
all proposed changes to the requirement.
 e. Problem analysis and change specification
i. Change analysis and costing (The effect of the proposal change is assessed
using traceability information)
ii. Change Implementation (The requirement document the system design and
implementation is modified)

SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT

The Software Requirement Specification (SRS) document is procedure at the
combination of the analysis task. It is the official statement of what is required of the system
developers
A number of different large organizations such as DoD (Department of Defence) and
IEEE have defined standards for requirement document. The most widely known standard is
IEEE / ANSI 830 – 1993 standard. The IEEE standard suggest the following standard:
1. Introduction
1.1 Purpose of the requirements document
1.2 Scope of the products
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General Description
2.1 Product perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements:
4. Appendices
5. Bibliography and Index
Users of Software Requirement Document

Specify the requirements and read them to check that

System Customers they meet their needs. They specify changes to the
requirements

Use the requirements document to plan a bid for the

Managers
system and to plan system development process.

Use the requirements to understand what system is to

System Engineers
be developed

System test Use the requirement to develop validation tests for

Engineers the system

System
Use the requirements to help understand the system
Maintenance
and the relationship between its parts
Engineers
Characteristics of an SRS
A good SRS should be
1. Correct - If every requirement represents something required in
the final system.
2. Complete - Ensures everything (ie) every requirement is indeed
specified.
3. Unambiguous - Every requirement stated how one any only
interpretation
4. Verifiable - If an only if every stated requirement verifiable.
5. Consistent - No Requirement conflicts with another
6. Ranked for importance and / or stability
7. Modifiable - SRS is well structure so easily change the requirement.
8. Traceable - All requirements are clear and facilitates referencing of
other in future development
Components of an SRS
The basic issues all SRS must address are
1. Functionality
2. Performance
3. Design constraints imposed on an implementation
4. External Interface

Specification Languages

Notations Description
Standard English Natural languages are widely used for specifying requirements but
sometimes it may be imprecise and ambiguous.

Regular Expression Used to specify the structure of symbol strings formally. Used in
compiler construction for recognition of symbols and tokens.

Decision table Provide a mechanism for specifying complex decision logic

Finite state Automata An FSA can be specified pictorially formally as grammar and
translation rules or transition tables, used for specifying
communication protocols.
Bad SRS Document

Content Descriptions

Noise Presence of text containing information irrelevant to the problem.

Silence aspects important to proper solution of the problem are omitted

Over specification Over specification restricts the solution space for the designer.

Contradictions if the same thing described at several places in different ways.

Ambiguity Literary expressions

Forward References References to aspects of problem

Wishful Thinking for which realistic solutions will be hard to find.

CLASSICAL ANALYSIS
Petri Net Introduction
A Petri net (also known as a place / transition net or P / T net) is one of several
mathematical modeling languages for the decryption of distributed System.
A Petri net is a directed bipartite graph, in which the nodes represent transitions (i.e.
events that may occur, signified by bars) and places (i.e. conditions, signified by circles).
The directed arcs describe which places are pre – and / or post conditions for which
transitions (signified by arrows).
It was first introduced by Carl Adam Petri in 1962. It is a diagrammatic tool to model
concurrency and synchronization in distributed systems.
Petri Nets
• A major difficulty with specifying real – time systems is timing
 Synchronization problems
 Race condition
 Deadlock
• Often a consequences of poor specification.
• Petri nets
A powerful techniques for specifying systems that have potential with interrelations
• A Petri net consists of four parts:
 A set of places P
 A set of transitions T
 An input function I
 An output function O
• Set of places P is {p1,p2,p3,p4}
• Set of transitions T is {t1,t2}
• Input function:
 I(t1) = {P2,P4}
 I(t2) = {P2}
• Output function
 O(t1) = {P1}
 O(t2) = {P3,P3}
• More formally, a Petri net is a 4 – tuple C = (P,T,I,O)
 P = {P1,P2,P3, . . . . Pn} is a finite set of places, n >= 0
 T = {t1,t2,t3, . . . . tn} is a finite set of transaction, m >= 0 with P and T disjoint
 I: T -> P is the Input function, a mapping from transitions to bags of places.
 O: T -> P is the Output function, a mapping from transitions to bags of places.
P2
t2
P1
t1

P3

P4
• A marking of a Petri net is an assignment of tokens to that Petri net.

P2
.. t2
P1
t1
. P3

. P4

• Four tokens: one in P1, two in P2, none in P3, and one in P4
 Represented by the vector (1,2,0,1)
 A transition is enabled if each of its input places has as many tokens in it as there are arcs
from the place to that transition.
• Transition t1 is enabled (ready to fire)
 If t1 fires one token is removed from P2, and one from P4, and one new token is places in
P1
 Transition t2 is also enabled
• Important
 The number of tokens in not conserved
• Petri nets are indeterminate
 Suppose t1 fires
 The resulting marking is (2,1,0,0)

P2
. t2
P1
t1
..
P3

P4

• Now only t2 is enabled

 It fires
 P2
t2
P1
t1
.. ..
P3

P4

• The marking is now (2, 0, 2, 0)

• More formally, a marking M of a Petri net C = (P, T, I, O) is a function from the set of places P
to the non – negative integers P2
M : P -> {0,1,2, ……}
• A marked Petri net is then a 5 – tuple (P, T, I, O, M) P1
t1
• Inhibitor arcs
 An inhibitor arc is marked by a small circle, not an arrowhead
• Transition t1 is enabled P3 .
• In general, a transition is enabled if there is at least one token on each (normal) input are, and
no tokens on any inhibitor input arcs.
ADVANTAGES

 Petri nets can also be used for design

 Petri nets possess the expressive power necessary for specifying synchronization
aspects of real-time systems
Petri Nets: The Elevator Problem Case Study
• A Product is to be installed to control n elevators in a building with m floors
• Each floor is represented by a place, Ff, 1<= f <= m
• An elevator is represented by a token
• A token in Ff denotes than an elevator is at floor Ff.

First constraint
1. Each elevator has a set of m buttons, one for each floor. These illuminate where pressed and
cause the elevator to visit the corresponding floor. The illumination is canceled when the
corresponding floor is visited by an elevator.
 The elevator button for floor f is represented by place EBf, 1<= f <= m
 A token in EBf denotes that the elevator button for floor f is illuminated
 A button must be illuminated the first time the button is pressed and subsequent button
presses must be ignored
• If button EBf is not illuminated, no token is in place and transition EBf pressed is enabled.
 The transition fires, a new token is placed in EB
 Elevator in action
EBf pressed EBf Ff

.
Fg

.
• Now, no matter how many times the button is pressed, transition EBf pressed cannot be
enabled
• Wen the elevator reaches floor g
 A token is in place Fg
 Transition Elevator in action is enabed, and then fires
• The tokens in EBf and Fg are removed
 This turns off the light in button Ebf
• A new token appears in F
 This brings the elevator from floor g to floor f
• Motion from floor g to floor f cannot take place instantaneously
 We need timed petri nets

Second constraints
2. Each floor, except the first and the top floor, has two button, one to request an up elevator, one
to request a down elevator, These buttons illuminate when pressed . The illumination is canceled
when the elevator visits the floor, and then moves in desired direction.
• Floor button are represented by places FBuf and FBdf
• The Petri net in the previous slide models the situation when an elevator reaches floor Fj from
floor Fg with one or both buttons illuminated.
• If both buttons are illuminated, only on e turned off.
• A more complex model is needed to ensure that the correct light is turned off.
 Elevator in action
EBf pressed EBuf Ff

. Fg

EBf pressed EBdf Ff

.
Elevator in action
Third Constraints
3. If an elevator has no requests, it remains at its current floor with its doors closed.
• If there are not requests, no Elevator in action transition is enabled.
• Petri nets can also be used for design
• Petri nets posses the expressive power necessary for specifying synchronization aspects of real
– time system.
Data Dictionary
The data dictionary is an organized testing of all data elements that are relevant to the
system so that both the user and system analyst will have a common understanding inputs,
outputs, components of stores and intermediate calculations. It is proposed as quasiformat
grammar during structured analysis and may contain the following information:
A data Dictionary is simplistically an alphabetic list of names which are included in
different models of the system.
Field Name Description
Name Name of the data item.
Aliases Other name of the data item.
Description / Purpose A notation for representing its goal or context.
Related data item Relevant data item.
Range of value Value between the item.
Data Structure Definition Form of the data item
Where used / How used Input to the process, output from the process, as a store and
external entity
Supplementary information Data types, preset values, restrictions or limitations.
Example
Field Name Description
Name Telephone_Number
Aliases Phone_Number, Mobile_Number
Description / Purpose First 2 digit indicates Country Code, Next 4 digits represents
district code, Last 6 digit indicates your number, etc.
Where used / How used Address / Visiting Card / Display / read the
Telephone_Number
Format Numeric / Min 6 digit / max 10 digit / Starts with +, etc..

Data Dictionary Notation

The mathematical operation used in data dictionary is defined as follows:
Sl.No. Notation Meaning
1. X=a+b X consists of data elements a & b.
2. X = [a / b] X consists of either data elements a or b.
3. X=a X consists of an optional data element a.
4. X = Y{a} X consists of Y or more occurrence of data element a.
5. X = {a}z X consists of Z or fever occurrences of data element a
6. X = y {a} z X consist of some occurrence of data element a which are between Y
and Z.
Advantages
1. Mechanism for name management. The data dictionary software can check for name
uniqueness and tell requirements analysts of name duplications. The names should be used
consisting and should not clash.
2. It serves as a store of organizational information that can link analysis, design,
implementation and evaluation.
3. The data dictionary software might be integrated with other tools so that dictionary creation
is partially automated.
4. Design the software and test cases.