Requirements Analysis and Specification 2.

2
REQUIREMENTS ANALYSIS AND
SPECIFICATION

 INTRODUCTION
 FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS
 USER REQUIREMENTS
 SYSTEM REQUIREMENTS

 SOFTWARE REQUIREMENTS DOCUMENT

 REQUIREMENTS ENGINEERING PROCESS

 CLASSICAL ANALYSIS
2. 2 Software Engineering

REQUIREMENTS ANALYSIS AND SPECIFICATION

2.1 INTRODUCTION
IEEE defines a requirement as
1. A condition or capability needed by a user to solve aproblem (or) achieve an
objective.
2. A condition (or) a capability that must be met (or) possessed by a system to
satisfy a contract.
The description of services and contraints are the requirements for the system and the
process of finding out, analysis, documenting and checking these services and constraints is
called requirement engineering.
Different types of requirements
User Requirements
User requirements are statements in a natural language plus diagrams of what service the
system is expected to provide and the constraints under which it must operate.
The readers of user requirements are client managers, system end - user, client
engineers, contractor managers and system architects.
System Requirements
System requirements set out the system services and constraints in detail. The system
requirement document (or) functional requirement should be precise. It may serve as a
contract between the system buyer and software developer.
The reader of the system requirements are system end users, client engineers, system
architects and software developers.
Software Design Specification
A software design specification is an abstract description of the software design which is
a basis for more detailed design and implementation.
The readers of software design specification requirements are system architects and
software developers.
Two kinds of Requirement Document
1. User Requirement Definition Document
2. System Requirement Specification Document
Requirements Analysis and Specification 2. 3

User Requirement Definition

The requirement definition is a complete listing of everything the customer expects the
proposed system to do. It represents an understanding between the customer and developer.

System Requirement Specification

1. The system requirement specification restates the user requirement definition in
technical terms needed for the development of a system.
2. Technical counterpart to user requirement definition which is written by
requirements analysts.
Types of Requirements
Requirements may also fall under the following categories
a. Physical Environment
b. Interfaces
c. Users and Human Factors
d. Functionality
e. Documentation
f. Data
g. Resources
h. Security
i. Quality Assurance Factors
Characteristics of Requirements
To ensure that both the users and developers understand and use the requirements
properly, it is important that the requirement be of high quality. Some of the characteristics
are:
1. Are the requirements Correct?
2. Are the requirements Consistent?
3. Are the requirements Complete?
4. Are the requirements Realistic?
5. Does each requirement describe something that is needed by the customer?
6. Are the requirements Verifiable?
7. Are the requirements Traceable?
2. 4 Software Engineering

2.2 FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS

Software system requirements are often classified as functional (or) non-functional
requirements (or) as domain requirements.
Functional Requirements
These are statements of services the system should provide how the system should react
to particular input and how the system should behave in particular situations. In some cases, it
also specifies what the system should not do.
Non-Functional Requirements
These are constraints on the services (or) functions offered by the system. They include
timing constraints, constraints on the development process, standards etc.
Domain Requirements
These are requirements that were from the application domain of the system and that
reflect characteristics of that domain. It may be functional (or) non-functional requirements.
2.2.1 Functional Requirements

A functional requirement describes an interaction between the system and its

environment. For example, to determine functional requirement, we decide what states are
acceptable ones for the system to be in. Further, function requirements describe how the
system should behave on given certain stimuli. Functional system requirements describe the
system function in detail, its input and output, exception etc.

For example: For a system printing weekly paychecks, the functional requirement must
answer the following questions:
1. What input is necessary for a paycheck to be printed?

2. Under what conditions the amount of pay can be changed?

3. What causes the removal of an employee from the payroll list?
In principle, the functional requirement specification of a system should be

Complete: that all services required by user should be defined.

Consistent: the requirements should not have contradicting defintions.

In practice, for large, complex systems it is practically impossible to achieve

requirements consisting and completeness. The reason for this is partly because of the
inherent system complexity and partly because different viewpoints have inconsistent needs.
Requirements Analysis and Specification 2. 5

2.2.2 Non-Functional Requirements

These are requirements which are not directly concerned with the specific functions
delivered by the system. They may relate to emergent system properties such as realibility,
response time and store occupancy. Alternatively, they may define constraints on the system
such as the capabilities of input devices and output devices data representations used in
system interfaces.
They relate to the system as a whole rather than to individual system features which
means that they are more critical than individual functional requirements.
While failure to meet an individual functional requirement may degrade the system,
failure to meet a non-functional system requirement may make the whole system unusable.
Non-functional requirements are not always concerned with the software system to be
developed.
Fig. 2.1 describes the types of non-functional requirements.
1. Product Requirements
Requirements which specify product behaviour. Examples
Performance Requirements - how the system must execute and how much memory
it requires.
Reliability Requirements - set out the acceptable failure rate.
Portability Requirement Usability Requirement 2. Organistional
requirements
These are derived from policies and procedures in the customers and developers
organisation (eg.) include process standards which must be used. Implementation
requirements such as the programming language (or) design method used. Delivery
requirements to specify when the product and its documentation are to be delivered.
Non functional
requirements

Product Organisational External

requirements requirements requirements

Fig. 2.1 Types of Non-Functional Requirements

2. 6 Software Engineering

3. External Requirements
These are all requirements which are derived from factors external to the system and its
development process.
Interoperability requirements defines how the system interacts with system in other
organisations.
Legistative requirements which must be followed to ensure that the system operates
within the law and ethical requirements
Ethical requirements are requirements placed on a system to ensure that it will be
acceptable to its users and the general public.
A common problem with non-functional requirement is that they are sometimes difficult
to verify. They may be written to reflect general goals of the customer such as ease of use, the
ability of the system to recover from failure (or) rapid user response.
A non-functional requirement should be expressed quantitatively using metrics that can
be objectively tested as followed:
Property Measure
Speed Proceed transactions / Event response time
Size k bytes, No. of RAM chips
Ease of use Training time, No. of help frames
Reliability Mean time to failure, rate of failure occurence
Robustness Time to restart after failure
Portability % of target dependent statements, No.of target systems.

Table 2.1 Metrics for Specifying Non-Functional Requirements

2.2.3 Domain Requirements
Domain requirements are derived from the application domain of the system rather than
from the specific needs of system users. They usually include specialized domain
terminology or reference to domain concepts. They may be new functional requirements in
their own right, constrain existing functional requirements or set out how particular
computations must be carried out. Because these requirements are specialized, software
engineers often find it difficult to understand how they are related to other system
requirements.
Domain requirements are important because they often reflect fundamentals of the
application domain. If these requirements are not satisfied, it may be impossible to make the
system work satisfactorily. The LIBSYS system includes a number of domain requirements:
Requirements Analysis and Specification 2. 7

1. There shall be a standard user interface to all databases that shall be based the Z39.50
standard.
2. Because of copyright restrictions, some documents must be deleted immediately on
arrival. Depending on the user’s requirements, these documents will either be printed
locally on the system server for manual forwarding to the user or routed to a network
printer.
The first requirement is a design constraint. It specifies that the user interface to the
database must be implemented according to a specific library standard. The developer
therefore have to find out about that standard before starting the interface design. The second
requirement has been introduced because of copyright laws that apply to material used in
libraries. It specifies that the system must include an automatic delete-on-print facility for
some classes of document. This means that users of library system cannot have their own
electronic copy of the document.
2.3 USER REQUIREMENTS
The user requirements for a system should describe the functional and non-functional
requirements so that they are understandable by system users who don’t have detailed
technical knowledge. It should specify the external behaviour of the system and should avoid
system design characteristics. The user requirements must be written using natural language,
forms and simple interactive diagram.
When user requirements are written in natural language they face several problems such
as:
a. Lack of Clarity: It is sometimes difficult to use language in a precise and
unambigious way without making the document word and difficult to read.
b. Requirements Confusion: Functional requirements, non-functional requirements,
system goals and design information may not be clearly distinguished.

c. Requirements Amalgamation: Several different requirements may be combined to

express it as single requirement.
When user requirements include too much information, it constraints the freedom of the
system developer to provide innovative solutions to user problems and makes the
requirements difficult to understand.
Guidelines for writing user requirements
1. Invent a standard format and ensure that all requirement definitions adhere to that
format.
2. Use language consistently and to distinguish between mandatory and desirable
requirements.
2. 8 Software Engineering

3. Use text highlighting (bold and italic) to pickout key parts of the requirements.
4. Avoid the use of computer jargon as far as possible.
2.4 SYSTEM REQUIREMENTS
System requirements are more detailed descriptions of user requirements which is the
basis for implmentation of the system. It should be complete and consistent specification of
the whole system. The system requirement specification may include different models of the
system such as an object model (or) a data-flow model.
The system requirement should state what the system should do and not how it should be
implemented. However to specify the system completely, it is virutally impossible to exclude
all design information. There are several reasons for this:
1. An initial architecture of the system may be defined to help structure the requirements
specification. The system requirements are organised according to the different sub
system which make up the system.
2. The system must interoperate with other existing systems. These constrain the design and
these constraints generate requirements for the new system.
3. The use of a specific design may be an external system requirement.
Natural language is often used to write system requirement specification but there arises
problems as described in Section 2.3 so we suggest some of the alternatives to the use of
natural language which add structure to the specification and which help to reduce ambiguity.

Notations for Requirements Specification

Structured Natural Language
The approach which depends on defining standard forms or templates to express the
requirements specification.
Design description languages
It is similar to programming language but with operational system. This approach is not
now widely used although it can be useful for interface specifications.
Graphics Notations
A graphical language, supplemented by text annotations is used to define the functional
requirements for the system.
Mathematical Specifications
Notation based on mathematical concepts such as finite state machines (or) sets. These
unambigious specifications reduce the arguments between customer and contractor about
system functionality.
Requirements Analysis and Specification 2. 9

2.5 SOFTWARE REQUIREMENTS DOCUMENT

The software requirements document or software requirement specification is produced
at the culmination of the analysis task. It is the official statement of what is required of the
system developers.
Contents and Structure of software requirement specification
A number of different large organisations such us 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 suggests the following structure.

1. Introduction

1.1 Purpose of the requirements document

1.2 Scope of the product.

1.3 Defintions, 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

2. 10 Software Engineering

3. Specific Requirements:
involving functional, non-functional and interface requirements
4. Appendices
5. Bibliography and Index
The requirements document should be organised in such a manner that it aids validation
and system design. For different projects, many of the sections may not be needed and can be
omitted.
Users of Software Requirement Document
The requirements document has a diverse set of users as illustrated in Fig. 2.5.

Specify the requirements and read them to check

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

Use the requirements document to plan a bid for

Managers
the system and to plan system development process.

System Use the requirements to understand what

Engineers system is to be developed.

System test Use the requirements to develop validation

Engineers tests for the system.

System
Maintenance
Use the requirements to help understand the
Engineers system and the relationship between its parts.

Fig. 2.2 Users of Requirements Document

Characteristics of an SRS
To properly satisfy the basic goals, an SRS should have certain properties and should
contain different types of requirements. 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. Unambigious – Every requirement stated how one and only intrepretation.
4. Verifaible– If and only if every stated requirement verifiable.
5. Consistent– No Requirement conflicts with another.

6. Ranked for importance and / or stability.

Requirements Analysis and Specification 2.11

7. Modifiable– An SRS is modifiable if its structure and style are such that any necessary
change can be made while preserving completeness and consistency
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 Interfaces
Specification Languages
Some of the commonly used languages for requiements specification are

1. Standard English – Natural languages are widely used for specifing requirements
but sometimes it may be imprecise and ambigious.

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

3. Decision table – Provide a mechanism for specifying complex decision logic.

4. Finite state Automata – An FSA can be specified pictorally formally as grammer and
translation rules or transition tables. Used for specifying
communication protocols.

2.6 REQUIREMENTS ENGINEERING PROCESS

2.6.1 Introduction
Requirements engineering provides the appropriate mechanism for understanding what
the customer wants, analyzing need, assessing feasibility, negotating a reasonable solution,
specifying the solution unambigiousaly, validating the specification and managing the
requirements as they are transformed into an operational system.
The requirements engineering process can described in five distinct steps.
• Requirements Elicitation
• Requirements Analysis and Negotiation
• Requirements Specification
• Requirements Validation
• Requirements Management
2. 12 Software Engineering

Feasibility
elicitation &
Study
analysis

Feasibility
Specification
report
System Requirement
models Validation
User & System
requirements
Requirement
document

Fig. 2.3 Requirements Engineering Process

The requirements engineering activities are shown in Fig. 2.3.

The figure illustrates the relationship between the activities and also shows the
documents produced at each stage of the Requirement Engineering (RE) process. In virtually,
all systems however requirements change. The people involved develop a better more
abstract features to specify the requirements by defining an operational model of the system.

2.7 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
organisation.
Requirements Analysis and Specification 2. 13

A feasibility study is a short, focussed study which aims answers to the following
questions:
1. Does the system contribute to the overall objectives of the organistion?

2. Can the system be implemented using current technology and within given cost and
schedule constraints?

3. 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 Assesment

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:
1. How would the organisation cope if this system was not implemented?

2. What are the problems with current process and how would a new system
help allievate these problems?
3. What direct contribution will the system make to the business objectives?
4. Can information be transferred to and from other organisational systems?

5. Does the system require technology which has not previously been used in
the organisation?
6. What must be supported by the system and what need not be supported?

Information sources may include the managers of department where the system will be
used, software engineers who are familiar with the type of system that is proposed,
technology experts and end users of the system.

When the information is available, the feasibility study report is prepared. It should make
a recommendation about whether or not the system development should continue. It may
propose changes to the scope, budget and schedule of the system and suggest further high
level requirement for the system.
2. 14 Software Engineering

2.8 REQUIREMENTS ELICITATION

The next phase followed by feasibility studies is requirements elicitation which involves
asking the customer, user, others what the objectives of system, what is to be accomplished,
how the system (or) product fits into the needs of the business and how the system (or)
product is to be used on a day-day basis.
Problems making requirements elicitation difficult
• Problem of scope: The customers/users specify unnecessary technical detail which
confuse rather than clarifying system objectives (i.e.) the boundary of the system is
defined.
• Problem of understanding: The customers/users have a poor understanding of the
capabilities and limitations of computing environment, don’t have a full
understanding of problem domain. They have trouble in communicating needs to the
system engineer or specify requirements that are ambigious (or) untestable.
• Problems of volatility: The requirements change over time.
• Problems of political factors: These may come from managers who demand
specific system requirements because these allow them to increase their influence in
the organisation.
A generic process model of the elicitation and analysis process is shown in Fig. 2.3.
The process activities are
• Domain Understanding: Analysts must develop their understanding of the
application domain.

Requirement
Requirement Specification
Checking
Requirement
Domain Document
Prioritisation
Process Understanding
entry
Requirement Conflict
Collection resolution

Classification

Fig. 2.4 Requirements Elicitation and Analysis Process

• Requirements Collection: Process of interacting with customers/users in the
system to discover their requirements.
Requirements Analysis and Specification 2. 15

• Classification: It takes the unstructered collection of requirements and organises

them into coherent clusters.
• Conflict Resolution: It is concerned with finding and resolving conflicts of multiple
user requirements.
• Prioritization: In any set of requirements source will be more important than
others. It involves interaction with customers/users to discover the most important
requirement.
• Requirements Checking: The requirements are checked to discover if they are
complete, consistent and in accordance with what customers really want from the
system.
• Requirements Specification: A specification can be a written document, a
graphical model, a formal mathematical model, a collection of usage scenario, a
prototype (or) any combination of these.
• Requirements Documents: The software requirements document (sometimes
called the Software Requirement Specification SRS) is the official statements of
what is required of the system developers. It should include both the user
requirements for a system and a detailed specification of the system requirement.
Fig. 2.3 shows that requirement elicitation and analysis is an iterative process write
continual feedback from each activity to other activities.
Guidelines for Requirements Elicitation
1. Assess the business and technical feasibility for the proposed system.
2. Identify the people who will help specify requirements and understand the
organisational bias.
3. Identify domain constraints such as characteristics of the business environment
specific to the application domain that limit the functionality (or) performance of
the system.
4. Define technical environment (eg. computing architecture, OS, telecommunication
needs) into which the product will be placed.
5. Define one or more requirement elicitation methods such as interviews, focus
groups, team meetings.
6. Identify ambigious requirements as candidates for prototyping.
7. Create usage scenarios to help customers/users better identify key requirements.
2. 16 Software Engineering

2.9 REQUIREMENTS ANALYSIS & NEGOTIATION

Once requirements have been gathered, the work products noted earlier form the basis
for requirements analysis. Analysis categorizes requirements and organizes them into related
subsets; explores each requirement in relationship to others; examines requirements for
consistency, omissions, and ambiguity; and ranks requirements based on the needs of
customers/users.
As the requirements analysis activity commences, the following questions are asked and
answered:
❖ Is each requirement consistent with the overall objective for the system
/ product?
❖ Have all requirements been specified at the proper level of abstraction? That
is, do some requirements provide a level of technical detail that is
inappropriate at this stage?
❖ Is the requirement really necessary or does it represent an add-on feature that
may not be essential to the objective of the system?
❖ Is each requirement bounded and unambiguous?
❖ Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
❖ Do any requirements conflict with other requirements?
❖ Is each requirement achievable in the technical environment that will house
the system or product?
❖ Is each requirement testable, once implemented?
It isn’t unusual for customers and users to ask for more than can be achieved, given
limited business resources. It also is relatively common for different customers or users to
propose conflicting requirements, arguing that their version is “essential for our special
needs.”
The system engineer must reconcile these conflicts through a process of negotiation.
Customers, users and stakeholders are asked to rank requirements and then discuss conflicts
in priority. Risks associated with each requirement are identified and analyzed. Rough
guestimates of development effort are made and used to assess the impact of each
requirement on project cost and delivery time. Using an iterative approach, requirements are
eliminated, combined, and/or modified so that each party achieves some measure of
satisfaction.
2.9.1 Requirements Specification
In the context of computer-based systems (and software), the term specification means
different things to different people. 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.
Requirements Analysis and Specification 2. 17

Some suggest that a “standard template” should be developed and used for a system
specification, arguing that this leads to requirements that are presented in a consistent and
therefore more understandable manner. However, it is sometimes necessary to remain flexible
when a specification is to be developed. For large systems, a written document, combining
natural language descriptions and graphical models may be the best approach. However,
usage scenarios may be all that are required for smaller products or systems that reside within
well-understood technical environments.
The System Specification is the final work product produced by the system and
requirements engineer. It serves as the foundation for hardware engineering, soft ware
engineering, database engineering, and human engineering. It describes the function and
performance of a computer-based system and the constraints that will govern its
development. The specification bounds each allocated system element. The System
Specification also describes the information (data and control) that is input to and output from
the system.
2.10 REQUIREMENTS VALIDATION

Requirements validation is the process of determining that the specification is consistent

with the requirements definition (i.e.,) the validation makes sure that the requirements will
meet the customer needs. Requirements validation examines to ensure that all system
requirements have been stated unambigiously, 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.
During the requirements validation process, different types of checks should be carried
out on the requirements in the requirement document. These checks include:
Validity Checks: A user may think that a system is needed to perform functions.
Systems have different users with different needs and any set of requirement is inevitable a
compromise across the user community.
Consistency Checks: Requirements in the document should not conflict (ie.) there
should not be contradictory constraints or different description of the same system function.
Completeness Checks: The requirements document should include requirements which
define all functions and constraints intended by the system user.
Realism Checks: Using knowledge of existing technology, the requirements should be
checked to ensure that they can actually be implemented. It also takes into account of the
budget and schedule for the system development.
Verifiability: The system requirements should always be written so that they are
verifiable.
There are a number of requirements validation techniques and which can be used
conjuction or individually as shown in Table 2.2.
2. 18 Software Engineering

Manual Techniques Reading

Manual Cross Referencing
Interviews
Reviews
Checklists
Manual models to check functions & relationships
Scenarios
Mathematical proofs
Automated techniques Automated cross referencing
Automated models to exact functions
prototypes
Table 2.2 Requirements Validation Techniques
Requirements Reviews
A requirements review is manual process which involves multiple readers from both
client and contractor staff checking the requirements document for anamolies and omissions.
Requirements reviews can be unformal or formal. The review team should check whether the
requirements are complete and consistent. Reviews may also check for
1. Verifiability
2. Comprehensibility
3. Traceability

Prototyping: In this approach to validation, an executable model of the system is

demonstrated to end users and customers. They can experiment with the model to see if it
meet their real needs.
Test Case Generation: Requirements should be testable. If a test is difficult or
impossible to design, this usually means that the requirements will be difficult to implement
and should be reconsidered.

Automated Cross Referencing: It uses processor to verify some properties of

requirements. Any automated processing of requirement is possible if the requirements are
written in a formal specification language or a language specifically designed for machine
processing. They typically focus on checks for internal consistency and completeness which
sometimes lead to checking of external completeness.
Requirements Analysis and Specification 2. 19

Scenarios: Scenarios describe different situations of how the system will work once it is
operational. Constructing scnarios is good for clarifying misunderstandings in the human-
computer interaction area. They are of limited value for verifying the consistency and
completeness of requirements.
Reading: The goal in reading is to have something other than the author of the
requirements read the requirements specification document to identify potential problems.
Reading is effective only if the reader takes the job seriously and reads the requirements
carefully. Reading is limited in scope for completeness and consistency errors, particularly
for large software systems.
2.11 REQUIREMENTS MANAGEMENT

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 as the project
proceeds.
Like SCM requirements management begins with identification. 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 = Behavioural requirement I = Interface requirement
P = Output requirement
Requirements Classes
1. Enduring Requirements: Stable requirements which are derived from the core activity
of the organisation and which relate directly to the domain of the system.
2. Volatile Requirements: These requirements are likely to change during the system
development or after the system has been put into operation.
a. Mutable Requirment: Requirements which change because of changes to the
environment in which the organisation is operating.
b. Emergent Requirement: Requirements whcih emerge as the customers
understanding of the system develops during the system development.
c. Consequential Requirement: Requirements which result from the introduction of
the computer system which may change the organisations process and open up for
new system requirements.
2. 20 Software Engineering

d. Compatibility Requirements: Requirements which depend onthe particular

systems or business processes within an organisation.
Requirements Management Planning
As requirements management is very expensive and for each project planning is an
external first stage which involves the following stages:
❖ Requirements Identification: Each requirements must be uniquely identified which can
be cross referenced by other requirements and used in traceability assessements.
❖ Change Management Process: The set of activities which assesses the impact and cost
of changes.
❖ Traceability Policies: Traceability is an overall property of a requirements specification
which reflects the ease of finding related requirements. Some of the traceability
information are :
1 . Source traceability information: links the requirements to the customers/
stakeholders who propsoed the requirements.
2 . Requirements traceability information: links dependent requirements written the
requirements document. It is used to assess how many requirements are likely to be
affected by a proposed change and the extent of consequential requirement changes.

3 . Design traceability information: links the requirements to the design modules where
these requirements are implemented.
❖ Case Tool Support: Requirements management involves the processing of large
amounts of information about the requirements (eg.) spread sheets and databases. Some
of the ease tools are need for automated support and for the following purposes:
Requirements Storage: Requirements should be maintained in a secure, managed data
store which is accessible to everyone involved in requirements engineering process.

Change Management: Requirements change management should be applied to all

proposed changes to the requirements as illustrated in the Fig. 2.4.

Identifie Problem Analysis Change Analysis

d & Change & Change Revised
Implementation
Problem specification Costing Requirements

Fig. 2.5 Requirements Change Management

Requirements Analysis and Specification 2. 21

Problem analysis and change specification

During this stage, the problem or the change proposal is analysed to check whether it is
valid.

Change analysis and costing: The effect of the proposed change is assessed using
traceability information. The cost incurred by both modifications of requirements documents,
system design and implementation is analysed and a final decision is made.

Change Implementation: The requirements document the system design and

implementation is modified.

2.12 CLASSICAL ANALYSIS

2.12.1 Introduction
❖ Specification document must satisfy two mutually contradictory requirements
❖ Must be clear and intelligible to client
– Client probably not a computer expert
– Client must understand it in order to authorize
❖ Must be complete and detailed
– Sole source of information available to the design team

❖ Specification document must be in a format that is

– Sufficiently nontechnical to be intelligible to client
– Yet precise enough to result in a fault-free product
❖ Analysis (specification) techniques are needed
– Classical (structured) analysis
– Object-oriented analysis
2. 22 Software Engineering

2.12.2 Products of Classical Analysis Workflow

2.12.2.1 The Specification Document
❖ Specification document is a
– Detailed description of what system will do
– Faults in specification lead to faults in final software, so
– Considerations:
▪ Feasibility - can software be built as specified?
▪ Q: How to check specification correctness?
❖ Specification document must be
• Informal enough for client to understand, but
• Formal enough for developers, and be contractually binding.
• Free of omissions, contradictions, ambiguities
❖ Acceptance Criteria determinable as part of Specification
• Can even begin (some) test case development based on Requirements
Document without yet having any code!
• If product passes tests, deemed to satisfy specifications
2.12.3 Software Specification Methods
The Classification of specification techniques are
Informal methods: Written in a natural language like English.
Semiformal methods: Techniques between informal and formal is known as semiformal
methods. Techniques such as Structured Systems Analysis & Entity-Relationship Modeling
(ER Diagrams).

Formal methods: Techniques such as Petri nets, Finite State Machines(FSMs) and
Z.
Requirements Analysis and Specification 2. 23

2.13 STRUCTURED SYSTEMS ANALYSIS

❖ Use of graphics to specify software

– Important technique of the 1970s
– A few popular techniques are DeMarco, Gane and Sarsen & Yourdon and
Constantine
– All are equivalent
– All are equally good
Data Flow Diagram- Foundation of Gane and Sarsen’s Structured System Analysis

❖ Graphical Notation used to Describe how data flows between Processes in a System:

– Use Notation that Represents Functional Processing, Data Stores and Data
Movements (flows) Between Sequences of Functional Units.
– Focus is on ‘What’ Happens, Not ‘How’ It Happens.
– Development Proceeds Stepwise
– Start with “Context Level” diagram, and then refine.
Sally’s Software Shop Mini Case Study - An Example Using DFDs
❖ Sally’s Software Store buys software from various suppliers and sells it to the public.
Popular software packages are kept in stock, but the rest must be ordered
as required. Institutions and corporations are given credit facilities, as are some
members of the public. Sally’s Software Store is doing well, with a monthly turnover
of 300 packages at an average retail cost of $250 each. Despite her business success,
Sally has been advised to computerize. Should she?
❖ A better question
o What business functions should she computerize?
– Accounts payable
– Accounts receivable
– Inventory
• Still better
o How? Batch, or online? In-house or outsourcing?
• The fundamental issue
o What is Sally’s objective in computerizing her business?
2. 24 Software Engineering

• Because she sells software?

o She needs an in-house system with sound and light effects.
• Because she uses her business to launder “hot” money?
o She needs a product that keeps five different sets of books, and has no audit
trail.
• We assume: Sally wishes to computerize “in order to make more money”
o We need to perform cost–benefit analysis for each section of her business.
• The danger of many standard approaches
o First produce the solution, then find out what the problem is!
• Gane and Sarsen’s method
o Nine-steps method
o Stepwise refinement is used in many steps
To perform the Structures System Analysis the nine steps are followed:
1. Draw the data flow diagram
2. Decide what sections to computerize and how (batch or online)
3. Determine the details of the data flows
4. Define the logic of the processes
5. Define the data stores
6. Define the physical resources
7. Determine the input-output specifications
8. Perform the sizing
9. Determine the hardware requirements
Step 1: Draw the Data Flow Diagram (DFD)
– A pictorial representation of all aspects of the logical data flow
Logical data flow — What happens
Physical data flow — How it happens
– Any non-trivial product contains many elements
– DFD is developed by stepwise refinement
Requirements Analysis and Specification 2. 25

– For large products a hierarchy of DFDs instead of one DFD

– Constructed by identifying data flows: Within requirements document or rapid
prototype
Four basic symbols
▪ Source or destination of data (double-square box)
▪ Data flow (arrow)
▪ Process (rounded rectangle)

▪ Data store (open-ended rectangle)

Fig. 2.6 Four Basic Symbols of DFD

• First refinement
o Infinite number of possible interpretations.
2. 26 Software Engineering

Fig 2.7 DFD Level 0 - Sally’s Software Shop

• Second refinement
o PENDING ORDERS is scanned daily.

Fig 2.8 DFD Level 1 - Sally’s Software Shop

• Portion of third refinement

• The final DFD is larger
o But it is easily understood by the client
Requirements Analysis and Specification 2. 27

Fig 2.9 DFD Level 2 - Sally’s Software Shop

• When dealing with larger DFDs
➢ Set up a hierarchy of DFDs
➢ A box becomes a DFD at a lower level
Step 2: Decide what sections to computerize and how (batch or online)
• It depends on how much client is prepared to spend
• Large volumes, tight controls
o Batch
• Small volumes, in-house microcomputer
o Online
• Cost/benefit analysis is applied.
Step 3: Determine the details of data flows
• Determine the data items for each data flow.
2. 28 Software Engineering

• Refine each flow stepwise.

Example;
order:
order_identification
customer_details
package_details
• We need a data dictionary for larger products.

Name of Data element Description Narrative

order Record comprising field The field contain all details

order_identification of an order
customer_details
customer_name
customer_address
.....
package_details
package_name
package_price
order_identification 12 digit integer Unique number generated
by procedure
generate _order _ number.
The first 10 digits contain
the order number itself, hte
last 2 digits are check
digits.
verify_order_is_valid procedure This procedure takes order
input parameter as input and checks the
order validity of every field; for
output parameter each error found, an
number_of_errors approximate message is
displayed on the screen
(the total number of
errors found is returned
in parameter
number_of_errors)

Fig. 2.10 Sample Data Dictionary Entries

Requirements Analysis and Specification 2. 29

Step 4: Define logic of processes

• We have process give educational discount
➢ Sally must explain the discount she gives to educational institutions.
▪ 10% on up to 4 packages
▪ 15% on 5 or more
• Translate this into a decision tree

• The advantage of a decision tree

➢ Missing items are quickly apparent.
Step 5: Define data stores
• Define the exact contents and representation (format)
➢ COBOL: specify to pic level
➢ Ada: specify digits or delta
• Specify where immediate access is required
➢ Data immediate-access diagram (DIAD)

Step 6: Define physical resources

• For each file, specify
➢ File name
➢ Organization (sequential, indexed, etc.)
➢ Storage medium
2. 30 Software Engineering

➢ Blocking factor
➢ Records (to field level)
➢ Table information, if a DBMS is to be used
Step 7: Determine input-output specifications
• Specify
➢ Input forms
➢ Input screens
➢ Printed output
Step 8: Determine sizing
• Obtain the numerical data needed in Step 9 to determine the hardware requirements

➢ Volume of input (daily or hourly)

➢ Size, frequency, deadline of each printed report
➢ Size, number of records passing between CPU and
➢ mass storage
➢ Size of each file
Step 9: Determine hardware requirements
• Mass storage requirements
• Mass storage for back-up
• Input needs
• Output devices
• Is the existing hardware adequate?
➢ If not, recommend whether to buy or lease additional hardware
However
• Response times cannot be determined
• The number of I/O channels can only be guessed
• CPU size and timing can only be guessed
• Nevertheless, no other method provides these
• Data for arbitrary products
Overall
• The method of Gane and Sarsen/De Marco/ Yourdon has resulted in major
improvements in the software industry.
Requirements Analysis and Specification 2. 31

2.13.1 Structured Systems Analysis: The MSG Foundation Case Study

Fig. 2.11 The MSG Foundation DFD

❖ As reflected in the DFD, the user can perform three different types of operations:
1. Update investment data, mortgage data, or operating expenses data:
• The USER enters an update_request
• To update investment data, process
perform_selected_update solicits the
updated_investment_details from the USER, and sends
then to the INVESTMENT_DATA store of data
• Updating mortgage data or expenses data is similar
2. 32 Software Engineering

2. Print a listing of investments or mortgages:

• To print a list of investments, the USER enters an investment_report_request.
Process generate_listing_of_investments then obtains investment data from store
INVESTMENT_DATA, formats the report, and then prints the report
• Printing a listing of mortgages is similar
3. Print a report showing available funds for mortgages for the week:
• The USER enters a funds_availability_report_request.
• To determine how much money is available for mortgages for the current week,
process compute_availability_of_funds_and_generate_funds_report then obtains
(see next slide):
• investment_details from store INVESTMENT_DATA and computes the
expected total annual return on investments
• mortgage_details from store MORTGAGE_DATA and computes the expected
income for the week, expected mortgage payments for the week, and expected
grants for the week
• annual_operating_expenses from store EXPENSES_DATA and computes the
expected annual operating expense
• Process compute_availability_of_funds_and_generate_funds_report then uses
these results to compute available_funds_for_week, and format and print the
report
2.13.2 Other Semi - formal Techniques
Other Semi-formal (graphical) techniques for classical analysis include
❖ PSL/PSA
❖ SADT
❖ SREM
❖ PSL/PSA — A computer-aided technique for specifying information processing products

• Composed of: Problem statement language (PSL) and problem statement analyzer
(PSA)
• Particularly used for documenting products
❖ SADT — Consists of structural analysis (SA) a box-and-arrow diagramming
technique and a design technique (DT)
• Used specially in complex, large-scale projects
Requirements Analysis and Specification 2. 33

❖ SREM — Software requirements engineering method

• For specifying the conditions under which actions are to occur
• Useful for specifying real-time systems
• Has been extended to distributed systems
• Components
RSL— A specification language
REVS — Set of tools for specification-related tasks
DCDS — Distributed computing design systems
• Power of SREM from finite state machine (FSM)
• Consistency checking is possible
• Used by millitary to specify two C3I software systems
• C3I — Command, control, communications, and intelligence

2.13.3 Entity-Relationship Modeling

Entity-relationship modeling (ERM) is a semiformal data-oriented technique for specifying a
product. It Emphasis on data instead of operations and widely used for over 30 years specifying
databases. In data modelling technique the Enity Relation Attribute (ERA Modelling) which
shows data enities, associated attributes and relationship between these entities.
The data model consists of data objects an entity to represent all objects, attributes that
describe the properties of data objects, and the relationships that connect data object to one
another.
Data Objects
A data object is an entity that produces or consumes information, a thing, an occurence, a
role, a place, a structure (eg. file). An entity is a fundamental thing of an organisation about
which data may be maintained. It has its own identity which distinguishes it from other entity.

For example, a student is an entity which relates to another entity course where each
entity has its own attributes as illustrated in Table 2.3(a).
Entity
Name Reg. No. Age Sex Grade
X 001 24 M S
Y 005 23 F A
Z 007 27 M B
Student
Table 2.3(a) Representation of Student Data Objects
2.34 Software Engineering

Emp. Name Emp. No. Desig. DoJ Basic Pay

Arun E0057 Manager 5.11.73 >12000
Karthi E5053 Worker 18.1.05 <5000

Siva E1023 Daily Wager 13.11.03 – Employee

Table 2.3(b) Representation of Employee Data Objects

We use capital letters in naming an entity type and in an ER diagram the name is placed
inside a rectangle representing that entity as shown in Fig. 2.12.

Employee Department

Fig. 2.12 Two Entity types in E–R diagram.

Attributes
Attributes define the properties of data objects and are used to
1. Name an instance of the data object.
2. Describe the instance
3. Make reference to another instance in another table.
Attributes are also identified using an identifier which is unique and becomes a key. For
example referring to data object Employee, Emp. No. becomes the ID or key. The data object
employee and its respective attributes are illustrated in Table 2.3(b).
Relationships
Two entity types or data objects are connected to one another using a relationship.
Consider two data objects employee and organization whice are related to each other by a
relationship called “works for”. These relationships are called binary relationships as they
involve 2 entities or dataobjects.
Relationships are represented by diamond notation in ER diagram as shown in Fig.
2.13.

Works
Employee Organisation
for

Fig. 2.13 Relationship in ER diagram

Requirements Analysis and Specification 2. 35

Degree Relationship

Degree of Relationship is the number of entity types that participate in that relationship.
Some of the common relationships are
Unary Relationship

It is also called as recursive relationship. An instance is a single ocurrence of an entity

type.

Person Married Person Sex

to

Fig. 2.14(a) Unary Relationship.

Binary Relationship
Two different entities are related to one another by means of various relationship such
as
• One–to–One

1 Is 1
Car assigned Parking Place

One – to – One

• One–to–Many

1 N
Book Store Order Books

One – to – Many
2. 36 Software Engineering

• Many to Many

M N
Book Store Regosters Course

Many – to – Many

Fig. 2.14(b) Binary Relationship

Ternary Relationship
It is a simultaneous relationship among instances of 3 entity types. In Fig. 2.14(c) the
entity employee works for a particular entity department which in turn related with another
entity project. All these entities are related by a relationship Project. In general “n” entities
can be related by the same relationship which is known as “n” ary relationship. Each entity
may have one or more participants.

Works
for

Employee Department

Project

Fig. 2.14(c) Ternary Relationship

Cardinality and Modality
The elements of data modelling - data objects (entities) attribute and relationships
provide the basis for understanding the information domain of a problem. To understand
additional information about these basic elements, we come up with cardiality and modality.
Cardinality
Cardinality defines the maximum number of objects that can participate in a relationship.
It is the specification of number of occurrences of one object that can be related to the
number of occurrences of another object. Cardinality is usually expressed as
❖ One–to–one (1:1)
❖ One–to–many (1:N)
❖ Many–to–Many (M:N)
Requirements Analysis and Specification 2. 37

Modality: The modality of a relationship is 0 if there is no explicit need for the

relationship to occur or the relationship is optional. The modality is 1 if an occurrence of the
relationship is mandatory.
Attributes
Attributes are the description about the data objects and there may be of following types

1. Simple and Composite Attributes

2. Single-valued and Multi Valued Attributes
3. Derived Attributes
Simple and Composite Attributes
Attributes which are simple and not divided into subparts are called as simple attributes.
For example,
Age

Employee Dept. Simple attributes

Sex

Attributes which are divided into subparts are called as composite attributes. For
example,
First Name
Emp. Name Middle Name Composite
Employee Attributes
SSN Last Name

Single-valued and Multivalued Attributes

Attributes which have a single value for a particular entity are called single-valued
attributes. For eg. Age is a single valued attributes.
Attributes which can have a set of values for the same entity are called multivalued
attribute. A multivalued attribute may have lower and upper bounds on the number of values
for an individual entity.
Derived Attributes
Two or more attributes values are related. (eg.) For a particular person entity, the value
of Age can be determined from the current date and the value of that person’s
birthdate. The age attribute is hence called derived attribute which is derived from Birthday
attribute. Note that the Age and Birthdate are the attributes of the person entity.
2. 38 Software Engineering

Age (Derived attribute)

Person
Birthdate (Stored attribute)

Entity Relationship Diagram (ERD):

The ERD is intended for the design of relational database systems which is used to
represent dataobjects and their relationships.
Notations

Dataobjects – labeled rectangle Eg. Person

Relationships – labeled line connecting objects

(or) Eg.
for
diamond with a connectingline

Cardinality(single) – Implies a simple object to be denoted Eg. 1

Cardinality(multiple) – Implies multiple object to be denoted Eg. <

Modality (1) – If an occurence of relationship is Eg. 1

mandatory

Modality (0) – If an occurence of relationship is Eg. 0

optional

Expanding the model, a simplified ERD model of an automobile is illustrated in Fig. 2.15
which denotes different objects, relationships, their cardinality and modality among them
with respect to the notations referred previously.

Licences Dealership Stacks Relationship

Modality (mandatory)
Cardinality
Cardinality (Single)
(Multiple)

Manufacturer Builds Car Data

Objects

Contracts Transports
Modality
(Optional)

Shipper Fig. 2.15 ER Diagram for Automobile

Requirements Analysis and Specification 2. 39

2.14 PETRI NETS

❖ A major difficulty with specifying real-time systems is timing
• Synchronization problems
• Race conditions
• Deadlock
❖ Often a consequence of poor specifications
❖ Petri nets
• A powerful technique for specifying systems that have potential problems 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 functions:
I(t1) = {p2, p4}

I(t2) = {p2}

❖ Output functions:
O(t ) = {p }
1 1 Fig. 2.16 a) A Petri Net
O(t2) = {p3, p3}
❖ More formally, a Petri net is a 4-tuple C = (P, T, I, O)
• P = {p1, p2, .. pn} is a finite set of places, n  0

• T = {t1, t2, .. tm} is a finite set of transactions, 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
2. 40 Software Engineering

• (A bag is a generalization of a set that allows for multiple instances of elements,

as in the example on the previous slide)
• A marking of a Petri net is an assignment of tokens to that Petri net.

Fig. 2.16(b) A marked Petri net

❖ 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
placed in p1
• Transition t2 is also enabled
❖ Important:
• The number of tokens is not conserved
❖ Petri nets are indeterminate

• Suppose t1 fires

Fig. 2.16(c) The Petri net of Fig.2.16(b) after transition t 1 fires

Requirements Analysis and Specification 2. 41

• The resulting marking is (2,1,0,0)

❖ Now only t2 is enabled

• It fires

Fig. 2.16(d) The Petri net of Fig.2.16(c) after transition t2 fires

❖ 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

M : P → {0, 1, 2, …}
❖ A marked Petri net is then a 5-tuple (P, T, I, O, M )
❖ Inhibitor arcs
• An inhibitor arc is marked by a small circle, not an arrowhead

❖ Transition t1 is enabled
❖ In general, a transition is enabled if there is at least one token on each (normal) input
arc, and no tokens on any inhibitor input arcs

Fig. 2.16(e) A Petri Net with an inhibitor arc

2. 42 Software Engineering

2.14.1 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 that an elevator is at floor Ff
First constraint
1. Each elevator has a set of m buttons, one for each floor. These illuminate when
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

Fig. 2.17 A Petri net representation of an elevator button

❖ 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
❖ Now, no matter how many times the button is pressed, transition EBf pressed cannot
be enabled
❖ When the elevator reaches floor g
• A token is in place Fg
• Transition Elevator in action is enabled, 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
Requirements Analysis and Specification 2. 43

❖ Motion from floor g to floor f cannot take place instantaneously

• We need timed Petri nets
Second constraint
2. Each floor, except the first and the top floor, has two buttons, 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 buttons are represented by places FBuf and FBdf

Fig. 2.18 A Petri net representation of floor buttons

❖ The Petri net in the previous slide models the situation when an elevator reaches
floor Ff from floor Fg with one or both buttons illuminated.
❖ If both buttons are illuminated, only one is turned off
❖ A more complex model is needed to ensure that the correct light is turned off
Third constraint
3. If an elevator has no requests, it remains at its current floor with its doors closed
❖ If there are no requests, no Elevator in action transition is enabled
2. 44 Software Engineering

❖ Petri nets can also be used for design

❖ Petri nets possess the expressive power necessary for specifying synchronization
aspects of real-time systems.

2.15 DATA DICTIONARY

The data dictionary is an organised 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 quasi-formal
grammar during structured analysis and may contain the following information.
❖ Name of the data item.
❖ Aliases (Other names for items)
❖ Description/Purpose – a notation for representing its goal or content.
❖ Related data items
❖ Range of value
❖ Data structure definition / form
❖ Where used / how-used (eg.) input to the process, output from the process, as
a store and external entity.
❖ Supplementary information – data types, preset values, restrictions or limitations.
A data dictionary is simplistically an alphabetic list of names which are included in
different models of the system.
The mathetical operation used in data dictionary is defined in Table 2.7.

S.No. Notation Meaning

1. X = a+b X consists of data elements a & b.

2. X = [a/b] X consists of either dataelements 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 consists of some occurence of data element a which are between Y and Z.

Table 2.4 Data dictionary Notation and Mathematical Operation

Requirements Analysis and Specification 2. 45

To illustrate the use of data dictionary, we refer to a data item telephone number which
consists of
1. 8 digit local number
2. 3 digit extension
3. 25 digit long distance carrier sequence
The data dictionary provides us with the precise definition of the telephone number as
follows.
Name : telephone number
aliases : none
where used/ how used: assess against set up (output) dial phone (input)
Description
telephone number = [local number / long distance number]
local number = prefix + access number
long distance number = 1 + area code + local number
area code = [800/888/561]

prefix = * a three digit number that never starts with 0 or 1*

access number = * any four number string*

For large computer systems, the data dictionary grows rapidly in size and complexity. In
fact, it is extremely difficult to maintain a dictionary manually. For these reasons, CASE tools
should be used.
The data dictionary defines information items unambigiously. Most case tools which
support system modelling also include support for data dictionaries.
Advantages
1. Mechanism for name management. The data dictionary software can check for name
uniquenss and tell requirements analysts of name duplications. The names should be
used consisting and should not clash.
2. It serves as a store of organisational information that can link analysis, design,
implementation and evolution.
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.
2. 46 Software Engineering

REVIEW QUESTIONS
PART - A

1. What are the broad categories of system requirements?

2. What are functional requirements?
3. What are non-functional requirements?
4. Classify non-functional requirements.
5. What are user requirements?
6. What are system requirements?
7. Define requirements engineering.
8. What is meant by feasibility study?
9. What are the various steps in requirement engineering process?
10. What is requirement elicitation?
11. Why requirements elicitation process is difficult?
12. Mention the work products produced in the requirement elicitation process.
13. What is the function of requirement analysis and negotiation?
14. What is meant by specification?
15. What is the function of requirement validation?
16. What is the function of requirement management?
17. Mention the various traceability tables developed during requirements management.
18. What is software requirements definition?
19. What do the requirement document contains?
20. Mention some of the software documents?
21. What is data modeling concerned with?
22. What are the components of data model?
23. What is ER diagram? Where it will be useful?
24. What is the notation used by the data modeling?
25. What do you mean by structural analysis?
26. What does the data dictionary contains?
27. What is the information contained in data dictionary?
28. What is the outcome of feasibility study?
29. Distinguish between expected requirements and exciting requirements.
Requirements Analysis and Specification 2. 47

30. List the metrics for specifying non functional requirements.

31. What is the Software Requirements Document (SRD)?
32. Define the following. (a) Cardinality (b) Modality
33. Define Data flow diagram.
34. List any four guidelines for creating DFDS.
35. What are the two types of Analysis (specification) techniques?
36. Define specification document.
37. Mention the differnet classification of specification techniques.
38. Mention the nine steps for Gane and Sarsen’s method.
39. Mention the use of Petri nets.
40. What are the four parts of Petri nets.

PART – B
1. Explain the function and non – functional requirements in detail.
2. Explain the SRS for a typical software project.
3. Explain the feasibility studies. What are the outcomes? Does it have either explicit or
implicit effects on software requirement collection.
4. Explain the requirement engineering process in detail.
5. Describe how software requirements and documented? State the importance of
documentation.
6. Write short notes on data modeling.
7. Draw an E-R diagram for the relationship of manufacturing and dealership. Also
specify the association, cardinality and modality.
8. Explain the semiformal method-structured systems analysis in detail.
9. Explain the Semiformal method - Entity Relationship Modelling in detail.
10. Write a short notes on Petri Nets.
11. Explain Gane and Sargen’s methods in detail.
12. Explain Petri Nets with an case study in detail.
13. Explain the Structured Systems Analysis with an case study in detail.
14. Write a short notes on Data Dictionary.