AnjalaiAmmalMahalingam Engineering College

Kovilvenni-614 403
Department of Information Technology

UNIT II
REQUIREMENTS ANALYSIS AND SPECIFICATION
Software Requirements: Functional and Non-Functional, User requirements, System requirements, Software
Requirements Document Requirement Engineering Process: Feasibility Studies, Requirements elicitation and
analysis, requirements validation, requirements management-Classical analysis: Structured system Analysis, Petri
Nets- Data Dictionary.
Requirement:
A requirement is a feature of the system or a description of something the system is
capable of doing in order to fulfill the systems purpose.
It may range from a high-level abstract statement of a service or of a system constraint to
a detailed mathematical functional specification.
Requirement Engineering:
The process of finding out, analyzing, documenting and checking these services and
constraints is called requirements engineering.
Requirement engineering provides a description of what the system will do without
knowing how to do it.
Types of Requirements:
User requirements:
Statements in natural language plus diagrams of the services that the system is
expected to provide and its operational constraints.
Written for customers
System requirements:
A structured document setting out detailed descriptions of the system services.
Written as a contract between client and contractor
Software specification:
A detailed software description which can serve as a basis for a design
orimplementation.
Written for developers.

1
 Functional and non-Functional Requirements
Software system requirements are often classified as follows:
Functional Requirements
Non-Functional Requirements
Domain Requirements
1. Functional Requirements
Afunctional requirement defines a function of a systemis expected to provide.
A function is described as a set of inputs, the behavior, and outputs
Statements of services the system should provide how the system should react to
particular inputs and how the system should behave in particular situations.
It depend on the type of software, expected users and the type of system where the
software is used
Functional user requirements may be high-level statements of what the system should do
but functional system requirements should describe the system services in detail
E.g.Library system
The user shall be able to search either all of the initial set of databases or select a subset
from it.
The system shall provide appropriate viewers for the user to read documents in the
document store.
Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be
able to copy to the accounts permanent storage area.
Problems:
Requirements imprecision:
Problems arise when requirements are not precisely stated.
Ambiguous requirements may be interpreted in different ways by developers and
users.
Requirements completeness and consistency:
In principle requirements should be both complete and consistent
Complete:-They should include descriptions of all facilities required.
Consistent:-There should be no conflicts or contradictions in the descriptions of
the system facilities.
In practice, it is impossible to produce a complete and consistent requirements document.

2
 2. Non-Functional Requirements
As the name suggests that those requirements are not directly concerned with specific
functions delivered by the system.
It define system properties and constraints such as reliability, response time and storage
occupancy. Constraints are I/O device capability, system representations, etc.
Many non-functional requirements relate to the system as a whole rather than to
individual system features. While failure to meet an individual functional requirement
may degrade the system.
Process requirements may also be specified mandating a particular CASE system,
programming language or development method.
Non-functional requirements may be more critical than functional requirements. If these
do not meet the complete system, the system is useless.
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements

Product requirements:
Requirements which specify that the delivered product must behave in a particular
way e.g. execution speed, reliability, etc.
Organisational requirements:
Requirements which are a consequence of organisational policies and procedures
e.g. process standards used, implementation requirements, etc.

3
 External requirements:
Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements,
etc.
3. Domain Requirements
Domain requirements are derived from the application domain and describe system
characteristics and features that reflect the domain.
It may be new functional requirements, constraints on existing requirements or define
specific computations.
Domain requirements are important because they often reflect fundamentals of the
application domain.
If domain requirements are not satisfied, the system may be unworkable.
E.g. Library system domain requirements
There shall be a standard user interface to all databases which shall be based on the
Z39.50 standard.
Because of copyright restrictions, some documents must be deleted immediately on
arrival. Depending on the users requirements, these documents will either be printed
locally on the system server for manually forwarding to the user or routed to a network
printer.
Problems:
Understandability:
Requirements are expressed in the language of the application domain (For e.g. in
mathematical form)
This is often not understood by software engineers developing the system.
Implicitness:
Domain specialists understand the area so well that they do not think of making
the domain requirements explicit.
User Requirements
The user requirements of a system should describe the functional and non-functional
requirements so that they are understandable by system users who dont have detailed
technical knowledge.
User requirements are defined using natural language, tables and diagrams.

4
Problems with Natural Language:
Various problems will arise when requirements are written in natural language:
Lack of clarity:
It is sometimes difficult to use language in a precise and unambiguous way
without making the document wordy and difficult to read.
Requirements confusion:
Functional, non-functional requirements, system goals and design information
may not be clearly distinguished.
Requirements amalgamation:
Several different requirements may be expressed together as a single document.
E.g. Library System
LIBSYS shall provide a financial accounting system that maintains records of all
payments made by users of the system. System managers may configure this system so
that regular users may receive discounted rates.
Guidelines for writing requirements:
To minimise misunderstandings when writing user requirements, the following guidelines
should be followed.
Invent a standard format and ensure that all requirement definitions adhere to that format.
Use language in a consistent way. Use shall for mandatory requirements, should for
desirable requirements.
Use text highlighting to identify key parts of the requirement.
Avoid the use of computer jargons.
System Requirements
System requirements are more detailed description of user requirements.
They may serve as the basis for a contract for the implementation of the system and
should therefore be a complete and consistent specification of the whole system.
They are used by the software engineers as the starting point for the system design.
System requirements specification may include different models of the system such as an
object model or data model.
Requirements should state what the system should do and not how it should be
implemented.

5
But requirements and design are inseparable, because of following reasons:
A system architecture may be designed to structure the requirements
The system may inter-operate with other systems that generate design requirements
The use of a specific design may be a domain requirement.
Natural language (NL) is often used to write system requirements specifications.
Problems with NL specification:
Ambiguity:
The readers and writers of the requirement must interpret the same words in the
same way. This leads to misunderstandings because of the ambiguity of natural
language.
Over-flexibility:
The same thing may be said in a number of different ways in the specification.
Lack of modularisation:
It may be difficult to find all related requirements. If you need any change, you
may have to look at every requirements rather than group of requirements.
Structured language specifications:
Structured language is a restricted form of natural language for writing system
requirements
This removes some of the problems resulting from ambiguity and flexibility and imposes
a degree of uniformity on a specification.
Structured language notations may limit the terminology used and may use templates to
specify system requirements.
Often used a forms-based approach.
To use form based approach, we must use one or more standard forms or templates to
express the requirements.
When standard form is used for specifying functional requirements, the following information
should be included:
A description of the function or entity being specified.
A description of its input and where these come from
A description of its outputs and where these go to
An indication of what other entities are used.

6
Requirements specification using PDL:
Requirements may be defined operationally using a language like a programming
description language (PDL) but with more flexibility of expression.
The advantage of PDL is that it may be checked syntactically and semantically by
software tools.
PDL is most appropriate in two situations:
Where an operation is specified as a sequence of actions and the order is important.
When hardware and software interfaces have to be specified.
Disadvantages:
The PDL may not be sufficiently expressive to describe the system functionality.
The notation can be understood only the people have programming language.
The specification will be taken as a designspecification rather than a model to help the
user understand the system.
Interface Specification:
Most software systems must operate with other systems.
If the new system and existing system work together, the interface of the existing system
must be precisely specified.
Three types of interface may have to be defined
Procedural interfaces:
In this interface where the existing sub-systems offer a range of services which
are accessed by calling interface procedures.
Data structures that are exchanged from one sub system to another.
Data representations:
Representation of data which have been established for an existing system.
Generally, Formal notations are an effective technique for interface specification.
Requirements Engineering Processes
Requirement engineering is a processthat involves all of the activities required to create
and maintain a system requirement document.
Requirement engineering process activities are as follows:
Feasibility Study
Requirements elicitation and analysis
Requirements specification and their documentation
Validation of requirements

7
Feasibility Studies:
The Requirement engineering process should start with feasibility study.
Feasibility study is a study made to decide whether or not the proposed system is
worthwhile.
The input to the feasibility study is the outline description of the system and how it will
be used within the organization.
The result of feasibility study is the report which reports whether or not to implement the
system.
Feasibility study that checks that
Does the system contribute to organisational objectives?
If the system can be engineered using current technology and within budget?
Can the system be integrated with other systems that are already used?
Feasibility study involves information assessment, information collection and report
writing.
Information assessment identifies the information which is required to answer the three
questions set above.
Once the information has been identified, you should question information sources to
discover the answer to these questions.
Some examples of possible Questions for people in the organisation are:
What if the system wasnt implemented?
What are current process problems?
How will the proposed system help?
What will be the integration problems?

8
 Is new technology needed? What skills?
What facilities must be supported by the proposed system?
Feasibility study should be done with the help of project managers who is going to handle
the project, software engineers, technical experts, end-users of the system etc.,
Feasibility study should be completed within two or three weeks.
When the information is available, Feasibility study report is prepared.
Requirements Elicitation and Analysis:
AfterFeasibility studies, the next stage of requirement engineering process is requirement
elicitation and analysis.
In this activity, technical staff working with customers to find out about the application
domain, the services that the system should provide and the systems operational
constraints, hardware constraints and so on.
Elicitation and analysis is a difficult process for a number of reasons:
Stakeholders dont know what they really want in the computer system.
Stakeholders express their requirements in their own terms.
Different stakeholders may have different requirements and they may express in different
way.
Organisational and political factors may influence the system requirements
The requirements change during the analysis process. New stakeholders may emerge
from new stakeholders who were not originally consulted and the business environment
change.
Various process activities are discussed in the following diagram.

9
 Domain Understanding Analysts must develop their understanding of the application
domain.
Requirements Collection - Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
Requirements classification - Groups related requirements and organises them into
coherent clusters.
Conflict Resolution If multiple stakeholders involved, requirements will conflict. In
this activity those conflicts are resolved.
Prioritisation Interaction with stakeholders to discover the most important
requirements.
Requirements Checking Requirements are checked to discover whether they are
complete and consistent.
Interviewing:
This is an effective way of requirements gathering.
In formal or informal interviewing, the requirement engineering team puts questions to
stakeholders about the system that they use and the system to be developed.
Types:
Closed interviews: - where a pre-defined set of questions are answered by stakeholder.
Open interviews: - where there is no pre-defined agenda and a range of issues are
explored and discussed with stakeholders.
Effective Interview:
The interview should be conducted with open minded approach. The requirement
engineers should listen to the stakeholders with patience. Similarly some stakeholders are
expecting some unrealistic things about the system they should be ready to change their
mind and ideas about the system.
Interviewee should start the discussion by asking questions and requirements should be
gathered together.
Use cases:
Use case is a scenario for understanding user requirements.
Use-cases are a scenario based technique in the UML which identify the actors in an
interaction and which describe the interaction itself.
A set of use cases should describe all possible interactions with the system.

10
E.g. Use case Diagram for Library management System

Quality Function Deployment (QFD):

Quality Function Deployment is a quality management technique which translates the
customer needs and wants into technical requirements.
There are three types of requirements in QFD are:
Normal Requirements:
Requirements as per goals and objectives of the system.
E.g.: Handling mouse and keyboard events for any GUI based system
Expected Requirements:
These type of requirements in which the system must be having even if the
customer did not mention them.
E.g. A software package for presentation (MS-PPT) must have option of new
slide insert.
Exciting Requirements:
When certain requirements are satisfied by the software beyond the customer
expectations.
E.g. spell check facility in Ms-word.

11
Ethnography:
Ethnography is an observational technique that can be used to understand social and
organizational factors.
Requirements Validation:
Requirements validation concerned with demonstrating that the requirements define the
system that the customer really wants.
Requirements validation is important because errors in a requirement document can lead
to extensive rework costs when after the system is in service.
During Requirements validation process, different types of checks should be carried out.
Validity - Does the system provide the functions which best support the customers
needs?
Consistency - Are there any requirements conflicts?
Completeness- Are all functions required by the customer included?
Realism - Can the requirements be implemented given available budget and
technology
Verifiability - Can the requirements be checked?
Requirements Validation Techniques:
Requirements reviews- The requirements are analysed systematically by a team
ofreviewers.
Prototyping-Using an executable model of the system is demonstrated to the end user
or customers.
Test-case generation-Developing tests for requirements to check testability.
Requirement Reviews:
Regular reviews should be held while the requirements definition is being formulated.
Both client and contractor staff should be involved in reviews.
Reviews may be formal (with completed documents) or informal. Good
communications between developers, customers and users can resolve problems at an
early stage.
Reviewers may also check for:
Verifiability. Is the requirement as stated realistically testable?
Comprehensibility. Is the requirement properly understood by the end-users of the
system?

12
 Traceability. Is the origin of the requirement clearly stated?
Adaptability. Can the requirement be changed without a large impact on other
requirements? Or Is the requirement adaptable?
Requirements Management:
Requirements management is the process of managing changing requirements during the
requirements engineering process and system development.
Requirements are inevitably incomplete and inconsistent
Requirements Management Planning:
During the requirements engineering process, you have to plan:
Requirements identification - How requirements are individually identified.
A changemanagement process - The process followed when analysing a
requirements change.
Traceability policies - The amount of information about requirements relationships
that is maintained.
CASE tool support - The tool support required to help manage requirements change.
Traceability:
Traceability is concerned with the relationships between requirements, their sources and
the system design
Source traceability
Links from requirements to stakeholders who proposed these requirements;
Requirements traceability
Links between dependent requirements;
Design traceability
Links from the requirements to the design.

Software document

The software requirements document (sometimes called the software requirements

specification or SRS) is the official statement 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 requirements.

13
 The SRS is useful in estimating cost, planning team activities, performing tasks, and
tracking the team's progress throughout the development activity.

Fig., Users of a requirements document

There are six requirements which a software requirements document should satisfy:
It should specify only external system behavior.
It should specify constraints on the implementation.
It should be easy to change.
It should serve as a reference tool for system maintainers.
It should record forethought about the lifecycle of the system.
It should characterize acceptable responses to undesired events.

14
Characteristics of SRS
Various characteristics of SRS are
Correct - The SRS should be made up to date when appropriate requirements are
identified.

Unambiguous - When the requirements are correctly understood then only it is possible
to write an unambiguous SRS.
Complete - To make the SRS complete, it should be specified what a software designer
wants to create a software.

Consistent - It should be consistent with reference to the functionalities identified.

Specific - The requirements should be mentioned specifically.

Traceable - What is the need for mentioned requirement? This should be correctly
identified.

SOFTWARE REQUIREMENT SPECIFICATION

7.1 Introduction
7.1.1 Purpose
SRS defines specific functional and performance requirements of the Sharing Based system
(ORPUTTLBC). It also gives a brief description of interfaces and flow of data among the
ORPUTTLBC system stakeholders and subsystems.
7.1.2 Scope
The main objective of this project is to reduce the client access latency and minimizing the
communication over the network environment.
7.1.3 References
7.1.3.1 Governmental Documents
DOD 2167A Defence Standard Software Development
IEEE STD 830-1998 Edition, IEEE guide for developing System Requirements
Specification
7.1.3.2 Non Government Documents

15
 Ali Bahrami, Object Oriented System Development, using UML, McGraw Hill
international Edition, 1999
Roger S.Pressman, Software Engineering, 5th edition, 2004
David Budgen, Software Design, Third edition, 2001.
7.1.4 Overview
Section two of this document describes overall description of the Optimal Replica
Placement under TTL based Consistency (ORPUTTLBC). It will include a description of all
interfaces (Hardware, Software and User), General constraints and assumptions and users
view of the product.
Section three addresses specific design requirements, including the external interfaces
requirements, a detailed of the functional requirements, performances requirements and
quality attributes.

7.2 Overall Description

7.2.1 Product Perspective
This product will be wireless based, so the network hardware and network server are required for
this product. External interfaces include keyboard and mouse, enabling navigation across
screens. This product should require special hardware for wireless processing.
7.2.2 Product Functions
The main function of this system reducing the client access latency and minimizing the
communication cost.
7.2.3 User Characteristics
The user will have to be familiar with the ORPUTTLBC system. This product is used by all the
users who have the wireless enabled connections.
7.2.4 General Constraints
This product should be wireless broadcast based system.
This product should use Java technology.
7.2.5 Assumptions, Dependencies, Guidelines
Assumptions
The users have basic knowledge wireless broad cast environment.
The users are familiar with networking protocols and TCP/IP, java programming, windows
operating system.

16
Dependencies
This product depends on local and remote area network connection.
Guidelines
This product guides to user to transmitted from source and destination.

7.3 Specific Requirements

7.3.1 External Interface Requirements
Wireless broadcast based application should have basic interface with each host which are
enabled with this environment.
GUI:Helps user to give input and show the result of the system according to input.
The user interface from human perceptive
Interface format will be easy and intuitive to the use for human user.
User interface with product shall be through standard input device (Keyboard/Mouse) and
standard output device (monitor). Interface design will contain information about ORPUTTLBC
System.
Characteristic Requirement Between software and Hardware:
This product is basically building the OS such as Windows 2000 Advanced Server.
Software Interaction: ORPUTTLBC should be written in Java, networking technologies such as
socket programming, multi threading and require machine capable of running a Java-equipped
operating system.
Hardware interaction:
A NIC card should be required, Wireless LAN, which are java enabled. Additionally, the
program will require a java virtual Machine.
7.3.2Functional Requirements

7.3.2.1 Client
The purpose of the client send the request to server.
Input:
Html files, Web page.
Process:
First of all request goes to access point

17
Output:
Display request.
7.3.2.2 Access point
Analysis the request
Input:
Html files, webpage.
Process:
Select the appropriate server and get the request and analysis.
Output:
Get the response from the server.
7.3.2.3 Server
Get the response to the client
Input:
Html files, web page.
Process
Give the response
Output:
Send the response to the clients.
Sequence Diagram for ORPUTTLBC

18
Client Access point
Server
1 : Send the Request()

2 : Analysis request and server status()

3 : probhibt the client Request()

4 : select the approprite server()

5 : Get the Request and analysis()

6 : Give the Response()

7 : Get Response from the server()

8 : Send the Response to the client()

9 : Recive the Response()

Fig 7.1 Sequence diagram for ORPUTTLBC

19
Activity diagram for ORPUTTLBC

Sent the request Get the Reuest and analysis

Analysis the Request

Select approprite server
Give Response

If Free
Get the Response from the server

Prohibi the clients Request

Send the Response to the clients

Recive the Response

Fig 7.3 Activity diagram for ORPUTTLBC

7.3.2.6 System Security Requirements

7.3.2.6.1 Manage Active System
The ORPUTTLBC system should display all active system addresses and it supports to user to
request from access point.
7.3.2.6.2 Other Host Information
The access point can store the request and network transferred requests in
file format for future use.

20
7.3.4 Performance Requirements.
Reliability
ORPUTTLBC system should send all requests without lose.
Correctness
ORPUTTLBC is correctly send the appropriate sever.
Efficiency
ORPUTTLBC system should manage heavy traffic and huge network systems.
7.3.5 Non-Functional Requirements
Security (ORPUTTLBC _SRS_NF_01) linked with (ORPUTTLBC _SAS_013)
If the system is compromised with attackers then it should reflect what are the activities are made
by attacker like tools, techniques etc. The host stored the incoming and outgoing request from
ORPUTTLBC system terminal.
Maintainability (ORPUTTLBC SRS_NF_02)linked with (ORPUTTLBC _SAS_014)
ORPUTTLBC system should be maintainable by means of user comments and based on new
techniques and tools.
Availability (ORPUTTLBC _SRS_NF_03) linked with (ORPUTTLBC _SAS_015)
The ORPUTTLBC system should be run on JVM.
Reliability (ORPUTTLBC _SRS_NF_04) linked with (ORPUTTLBC _SAS_016)
The Access point Module send the all request without loses, and updates the access point if the
data are not present in its access point.
Usability (ORPUTTLBC _SRS_NF_05) linked with (ORPUTTLBC _SAS_017)
The ORPUTTLBC system should be easily understood by users.
Durability (ORPUTTLBC _SRS_NF_06)
This system will be there as long as the wireless environment available.
Reusability (ORPUTTLBC _SRS_NF_07)
These project modules can apply to various projects.
Testability (ORPUTTLBC _SRS_NF_08)
The responsible organization can check the product after delivery and used by them and
modifications can be performed by incremental testing.

Usability (ORPUTTLBC _SRS_NF_09)

21
 The software development organization will provide the software user guide for new network
administrator or network supervisors.

Analysis and Modeling

Analysis modeling is otherwise called structured analysis which considers data and process that
transform the data as separate entities.
Data objects are modeled in a way that defines their attributes and relationships.
Process that manipulates the data objects are modeled in a manner that shows how they
transform data as data objects flow through the system.

Data Modeling
Data Modeling is the basic step in the analysis modeling.
The software engineer or analyst defines all data objects that are processed within the
system, the relationships between the data objects and other information that is pertinent
to the relationships.
In data modeling, the data objects are examined independently of processing.
The data domain is focused and a model is created at the customers level of abstraction.
The data model represents how data objects are related with one another.
Data Object:
A data object is a representation of any composite information that must be understood
by software.

22
 By composite information, we mean something that has a number of different properties
or attributes.
A data object can be an external entity, a thing, a person, an occurrence, a role, an
organizational unit, a place etc.,

E.g: student, car

Data Attributes:
Data attributes define properties of a data object.
E.g: A object car has attribute ID number, body type, color, owner, price, make, model
etc.,
Relationship:
Relationship represents the connection between the data objects.
They can be used to:
name of an instance
Description of an instance.
reference to another entity
E.g:
owns
Person Car

Cardinality:
Cardinality defines how the number of occurrences of one object is related to the number of
occurrences of another object.
The relationship may be:
One to One (1:1)-one object can relate to only one other object.
One to Many (1:N)-one object can relate to many objects.
Many to Many (M:N)-some no. of occurrences of an object can relate to some other
number of occurrences of another object.

23
Notations to show Cardinality:

Modality:
Modality indicates whether or not a particular data object must participate in the relationship.
Modality is 0(zero) if there is no explicit need for the relationship to occur or the
relationship is optional.
The modality is 1(one) if an occurrence of the relationship is mandatory (compulsory).
E.g for Cardinality and Modality:

Example: E-R Diagram:

E-R stands for Entity Relationship diagram.
It represents the relationship between two entities (data objects).

Notations used in E-R Diagram:

Entity (Data Object)

24
 Attribute

Relationship

E.g E-R Diagram for teacher and course relationship:

25
 Functional Modeling
Functional models are used to represent the flow of information in any computer based
system.
It represents three generic functionalities: input, process, and output.
When the functional model is prepared, the software engineer focuses on problem
specifications.(PSPEC).
In structured analysis approach the functional modelling is done by using the data flow
diagrams.

Data Flow Diagrams:

The data flow diagrams depict the information flow and the transforms that are applied
on the data as it moves from input to output.
The DFD takes an input-process-output view of a system.
That is, data objects flow into the software, are transformed by processing elements &
resultant data objects flow out of the software.
Data objects are represented by labeled arrows and transformations (process) are
represented by circles (also called bubbles).
The DFD is presented in a hierarchical fashion.
That is, the first data flow model (sometimes called a level 0 DFD or context diagram)
represents the system as a whole.
Subsequent data flow diagrams refine the context diagram, providing increasing detail
with each subsequent level.
The data flow diagram enables the software engineer to develop models of the
information domain and functional domain at the same time.
Notations used in DFD:

Process

Data Store

Flow of data (may be Input or Output)

26
Example: Safe Home Security System - Concept
The safe Home security function enables the homeowner to configure the security system
when it is installed, monitors all sensors connected to the security system, and interacts
with the homeowner through the Internet, a PC, or a control panel.
During installation, the PC is used to program and configure the system. Each sensor is
assigned a number and type, a master password is programmed for arming and disarming
the system, and telephone number(s) are input for dialing when a sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm attached to the
system.
After a delay time that is specified by the homeowner during the system configuration
activities, the software dials a telephone number of a monitoring service, provides
information about the location, reporting the nature of the event that has been detected.
The telephone number will be redialed every 20 seconds until a telephone connection is
obtained.
The homeowner receives security information via a control panel, the PC, or a browser,
collectively called an interface.
The interface displays prompting messages and system status information on the control
panel, the PC, or the browser window. Homeowner interaction takes the following
form
Example: DFD for Safe Home Security System
Level 0 DFD:
In level 0 DFD, the whole system can be represented in single process (bubble).
A context level DFD for the security function is shown below.

27
 The primary external entities (boxes) produce information for use by the system and
consume information generated by the system.
The labeled arrow represents data objects or data object hierarchies.

Level 1 DFD:
The context level process shown above has been expanded into six processes which are
shown in Level 1 DFD.
The information flow continuity is maintained between level 0 &1.

28
Level 2 DFD:
The processes represented at DFD level 1 can be further refined into lower levels.
For example, the process monitor sensors can be refined into a level 2 DFD as shown in fig.

Process Specification (PSPEC):

The Process Specification (PSPEC) is used to describe all flow model processes that
appear at the final level of refinement.
The contents of PSPEC include narrative text, PDL description of process algorithm,
mathematical equations, tables, diagrams or charts.
By providing PSPEC to accompany each bubble in the flow model, the software engineer
creates a mini-spec that can serve as a guide for design of the software component.
In level 1 DFD diagram, the process password transform represents PSPEC.(Refer diag.)

Behavioral Modeling/CSPEC
Behavioral models are used to describe the overall behaviour of a system.
State transition diagram and sequence diagrams are used to demonstrate the behavioural
model (CSPEC).
CSPEC represents the behaviour of the system.

29
State Transition Diagram:
Definition:
State transition diagram defines number of states in the system. The machine receives
events from the outside world, and each event can cause the machine to transition from one state
to another.
Notations used in State Transition Diagram:

State/Event

Transition

Start

Stop

Example 1: State Transition Diagram for Safe Home Security System

The state diagram indicates that the transitions from the idle state can occur if the system
is reset, activated or powered off.

30
 If the system is activated (i.e., alarm system is turned on), a transition to the
MonitoringSystemStatus state occurs, display messages are changed as shown & the
process Monitor and control system is invoked.
Two transitions occur out of the monitoring system status state:
1. When the system is deactivated a transition occurs back to IDLE state.
2. When the sensor is trigged a transition to the acting OnAlarmState occurs

Example 2: State Transition Diagram for Control Panel Process

Sequence Diagram:
Definition:
A sequence diagram represents object collaboration and is used to define event sequences
between objects for a certain outcome in a timing sequence.
Notations used in Sequence Diagram:

Start

State/Event

Object/Interface

31
Example: Sequence Diagram for Safe Home Security System

In above diagram, each of the arrows represents an event and indicates how the event
channels behaviour between SafeHome objects. Time is measured vertically (downward),
and the narrow vertical rectangles represent time spent in processing an activity. States
may be shown along a vertical timeline.
The first event, System Ready, is derived from the external environment and channels
behaviour to a Homeowner object.
The homeowner enters a password. A request lookup event is passed to system which
looks up the password in a simple database and returns a result (found or not found) to
ControlPanel(now in the comparing state).A valid password results in a
password=correct event to System which activates sensors with a request activation
event. Ultimately, control is passed back to the homeowner with the activation successful
event.

Scenario based Modeling

32
 Analysis model with UML begins with creation of scenarios in the form of use-case diagrams
and activity diagrams.
Use case Diagram:
Use case is a scenario for understanding user requirements.
Use-cases are a scenario based technique in the UML which identify the actors in an
interaction and which describe the interaction itself.
A set of use cases should describe all possible interactions with the system.
Notations used in Use case Diagram:

Actor

Use Case

Example: Use Case Diagram for Safe Home Security System (camera surveillance function)

\
Activity Diagram:
Definition:
In UML, an activity diagram provides a view of the behavior of a system by describing the
sequence of actions in a process. Activity diagrams are similar to flowcharts because they show
the flow between the actions in an activity. However, activity diagrams can also show parallel or
concurrent flows and alternate flows.
Similar to flow chart, activity diagram uses rounded rectangles to imply a specific system
function.

33
 Arrows represent flow through the system.
Decision diamonds depicts branch decision
Solid horizontal line represents parallel activities are occurring.
Notations used in Activity Diagram:

System Function

Flow through the system

Branch Decision

Parallel Activities

Example: Activity Diagram for Safe Home Security System

34
 Data Dictionary
Definition:
Data dictionary can be defined as an organized collection of all the data elements of the
system with precise and rigorous definitions so that user and system analyst will have a common
understanding of inputs, outputs, components of stores and intermediate calculations.
The data models are less in detail hence there is a need for Data Dictionary.
Data Dictionaries are lists of all of the names used in the system model.
Descriptions of the entities, relationships and attributes are also included in the data
dictionary.
Typically, the data dictionaries are implemented as a part of structured analysis and
design tool.
The data dictionary stores the following information:
Name-Primary name is specified.
Alias-Another name for primary name.
Where we used/how we used-specifies input or output.
Notations used in Data Dictionary:
= Composed of
+ Sequence
{|} Or
{}^n Repetitions- n repetitions of optional data
** Comments
Example:

Consider the Reservation System. The data item Passenger can be entered in the data
dictionary as:

Name: Passenger
Alias: none
Where used/How used: Passengers Query(Input), ticket(Output)
Description:
Passenger = Passenger_name+Passenger_address
Passenger_name = Passenger_firstname+Passenger_lastname+Passenger_middlename
Passenger_address = Local address+community_adrress+zip code
Local_adrress = house_number+street_name
community_adrress = city_name+[state_name|province_name]
35
 Advantages:
Data Dictionary support name management and avoid duplication
It is a store of organisational knowledge linking analysis, design and implementation.

Unit - II
1. What is meant by system requirement?
Set out the system services and constraints in detail.
Serves as a contract between the system buyer & the system developer.
2. Define Requirement Engineering.
Requirement Engineering is a process that involves all of the activities required to create
and maintain a system requirements document.
The four generic Requirement Engineering activities are:
Feasibility study
Requirement Elicitation & Analysis
Requirement Specification
Validation.
3. What are the types of Software system requirements?
Functional requirements: Services the system should provide.
Non-functional requirements: Constraints on the services.
Domain requirements: reflect characteristics of the domain.
4. Write down the functional requirement for an Library management system.
The user should able to search either all of the initial set of databases or select a subset of
databases or select subset from it.
The system shall provide appropriate viewers for the user to read documents in the
document store.
Every order shall be allocated a unique identifier.
5. Mention some of the Notations for requirements specification.
Structured natural language: Use standard form or Templates.
36
 Design description language: Programming language is used.
Graphical notation: Text annotations is used.
Mathematical Specifications: Based on finite state machines or sets.
6. Mention some of the process activities of Requirement Elicitation & analysis.
Domain Understanding
Requirement Collection
Classification
Conflict resolution
Prioritisation
Requirement Checking
7. What are the different types of checks carried out during Requirement Validation?
Validity checks
Consistency checks
Completeness checks
Realism checks
Verifiability.
8. Define Traceability
Traceability is the overall property of requirements specification which reflects the ease
of finding related requirements.
9. What are the types of traceability?
Source traceability information
Requirement traceability information
Design traceability information
10. Define Prototyping.
Software prototyping is defined as a rapid software development for validating the requirements.
11. What are the benefits of prototyping?
Prototype serves as a basis for deriving system specification. Design quality can be
improved.
System can be maintained easily.
Development efforts may get reduced.
System usability can be improved.
Database programming

37
 Component and application assembly
12. What are the characteristics of SRS?
i. Correct - The SRS should be made up to date when appropriate requirements are identified.
ii. Unambiguous - When the requirements are correctly understood then only it is possible to
write unambiguous software.
iii. Complete - To make SRS complete, it should be specified what a software designer wants
to create software.
iv. Consistent - It should be consistent with reference to the functionalities identified

13. What are the objectives of Analysis modeling?

To describe what the customer requires.
To establish a basis for the creation of software design.
To devise a set of valid requirements after which the software can be built.
14. What are the elements of Analysis model?
i. Data Dictionary
ii. Entity Relationship Diagram
iii. Data Flow Diagram
iv. State Transition Diagram
v. Control Specification
vi. Process specification
15. What is data modeling?
Data modeling is the basic step in the analysis modeling. In data modeling the data objects are
examined independently of processing. The data model represents how data are related with one
another.
16. What is a data object?
Data object is a collection of attributes that act as an aspect, characteristic, quality, or descriptor of
the object.
17. What are attributes?
Attributes are the one, which defines the properties of data object.
18. What is cardinality in data modeling?
Cardinality in data modeling, cardinality specifies how the number of occurrences of one object is
related to the number of occurrences of another object.

38
19. What does modality in data modeling indicates?
Modality indicates whether or not a particular data object must participate in the relationship.
20. What is ERD?
Entity Relationship Diagram is the graphical representation of the object relationship pair. It is
mainly used in database applications.
21. What is DFD?
Data Flow Diagram depicts the information flow and the transforms that are applied on the data as
it moves from input to output.
22. Draw the Context level DFD for the Safe home Software.

23. What does Level0 DFD represent?

Level0 DFD is called as fundamental system model or context model. In the context model the
entire software system is represented by a single bubble with input and output indicated by incoming
and outgoing arrows.
24. What is a state transition diagram?
State transition diagram is basically a collection of states and events. The events cause the system
to change its state. It also represents what actions are to be taken on the occurrence of particular
event.
25. Define Behavioral Modeling.
The state transition diagram represents the behavior of a system by depicting its states and the
events that cause the system to change state.
26. What is meant by Data dictionary?
The Data dictionary is an organized listing of all data elements that are pertinent to the system,
with precise, rigorous definitions so that both user & system analyst will have a common
understanding of inputs, outputs, components of store & intermediate calculations.

39
27. What does data dictionary contains?
Name: The primary name of the data.
Alias: other names used
Where-used/How-used: A listing of processes that use the data or control item.
Content description: A notation for representing the content
Supplementary information: Other information like restrictions, limitations etc.
28. Write down the Data dictionary for the data item Telephone Number.
Names: Telephone number
Aliases: none
Where used/How used: assess against set-up
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.
Part-A
Semester S.No. Questions
1 Define data dictionary
NOV/DEC 1 Define behavioral modeling.
2012 2 List the criterias of data dictionary.
MAY/JUNE 1 Why context system models are useful for requirements validation?
2012 2 State the merits and demerits of rapid prototyping techniques.
NOV/DEC 1 What is Ethnography?
2011 2 State the advantages of requirement change management.
APRIL/MAY 1 Distinguish between functional and non-functional requirements?
2011 2 Mention the types of models produced during the analysis process.
NOV/DEC 1 What is software prototyping?
2010 2 Define functional and non-functional requirements.
APRIL/MAY 1 Specify at least four meta questions?
2010 2 What is the purpose of domain analysis?
NOV/DEC 1 What are context free questions? How it differ from Meta questions?
2009 2 Specify at least four questionnaire which supports to select the prototyping
approach.
MAY /JUNE 1 List out the requirements engineering.
2009
2 What are the linkages between data flow and ER diagrams?
NOV/DEC 1 How do we use the models that we create during requirement analysis?
2008 2 What steps are required to build ERD?

40
APRIL/MAY 1 Define S/W architecture.
2008 2 What is QFD?

Part-B
Semester S.No. Questions
2 Explain the method of gathering eliciting requirement for the engineering
process.
NOV/DEC 1 Consider the following specification from SRS document. If an electronic
2012 message is sent to party A and party A is not on-line, the message shall be
stored in the mail box. The software engineer develops the system using
following design specification:
(i) Message arrives for A
(i) If A is online, write the message on As screen.
(ii) If A is not online, write the message in the mail boxes not currently
On-line
The system is delivered and cause chaos. Why? Explain your
answer.
2 An independent Truck company wants to track and record its drivers driving
habits. For this purpose the company has rented 800 phone numbers and has
printed the numbers on the front, back and side of all trucks owned by the
company. Next to the 800 numbers a message is written PLEASE REPORT
ANY DRIVER OR TRUCK PROBLEM BY CALLING THIS NUMBER.
The hacking company waits for you to develop a system that
(i) Collects information from caller about the driver performance and
behavior as well as truck condition.
(ii) Generates daily and monthly reports for each driver and truck
management,
(iii) Reports problems that require immediate action to an On- Duty
manager.
Analyze the problem statement and list major function to be
incorporatedwith SRS document.
MAY/JUNE 1 To develop a automated grocery store software with details involving customer,
2012 suppliers, purchased, items, item- cost, number of items sold, etc, State its
entire requirement phases. List the software requirement specification (SRS) for
the same.
2 (i) Requirements should state what a system should do, without stating how it
should do it. Why is this distinction useful? Why is requirement engineering
considered to be the most important part of software engineering?
(ii) Explain the functional and behavioral model with illustration.
NOV/DEC 1 (i)What is sequence diagram? Develop a sequence diagram showing the
2011 interactions involved when a student registered for a course in a university.
Courses may have a limited enrolment, so the registration process must include
checks that places are available. Assume that the student accesses an electronic
course catalogue to find out above available courses.
(ii) What is data dictionary? State the advantages of data dictionary.
2 (i) What is behavioral model? Explain the data flow model with example.
(ii)What is non-functional requirement of software system? List the different
types of non-functional requirements.

41
 2 Explain the contents required in a generic software requirements specification
NOV/DEC 1 Discuss any four process models with suitable application.
2010 2 Explain the execution of seven distinct functions accomplished in requirement
engineering process.
APRIL/MAY 1 (ii) Draw an ER diagram for Railway reservation system.
2010 2 (i) What is the use of context diagram? Draw a level-1 DFD and STD for ATM
machine.
(ii) Describe about control specification and process specification.
NOV/DEC 1 (i) Prepare SRS document for Hospital Management system.
2009 (ii) Why the customer interaction is a difficult process? Explain one formal
procedure used for customer interaction.
(i) Draw an E-R diagram for Video Rental System.
(ii) Explain the relationship between data and control models with diagram.
MAY /JUNE 1 What are the crucial process steps of requirements engineering? Discuss
2009 with the help of a diagram.

2 Consider the problem of railway reservation system and design the following:
(i) Problem statement. (6)
(ii) Use case diagram. (5)
(iii)Use cases. (5)
NOV/DEC 1 (i) Explain the prototyping model. How do we select appropriate prototyping
2008 approach?
(ii) Explain rapid prototyping techniques.

2
Develop context level DFD, level-1 DFD, level-2 DFD for a library
management system.

APRIL/MAY 1 State and explain the requirements tasks in detail.

2008
2 (i) Describe the primary differences between structured analysis and object
oriented analysis.
(ii) Write a detailed note on scenario based modeling.

42