Unit 2

Functional and Non-functional Requirements

Functional Requirements

• Requirements, which are related to functional aspect of software

fall into this category.
• They define functions and functionality within and from the
software system.

• Examples -
• Search option given to user to search from various invoices.
• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given separate
rights.
• Should comply business rules and administrative functions.
• Software is developed keeping downward compatibility intact.
 Non-Functional Requirements

Requirements, which are not related to functional aspect of software, fall into this
category. They are implicit or expected characteristics of software, which users make
assumption of.
Non-functional requirements include –

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Disaster recovery
Accessibility
• Requirement Engineering
• The process to gather the software requirements from client, analyze and
document them is known as requirement engineering.

• The goal of requirement engineering is to develop and maintain

sophisticated and descriptive ‘System Requirements Specification’
document.

• Requirement Engineering Process

• It is a four step process, which includes –
• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation
 Requirement Elicitation Techniques

• Requirements Elicitation is the process to find out the requirements for an

intended software system by communicating with client, end users, system users
and others who have a stake in the software system development.
• There are various ways to discover requirements
• Interviews
• Interviews are strong medium to collect requirements. Organization may conduct
several types of interviews such as:
• Structured (closed) interviews, where every single information to gather is decided
in advance, they follow pattern and matter of discussion firmly.
• Non-structured (open) interviews, where information to gather is not decided in
advance, more flexible and less biased.
• Oral interviews
• Written interviews
• One-to-one interviews which are held between two persons across the table.
• Group interviews which are held between groups of participants. They help to
uncover any missing requirement as numerous people are involved.
• Surveys
• Organization may conduct surveys among various
stakeholders by querying about their expectation and
requirements from the upcoming system.
• Questionnaires
• A document with pre-defined set of objective questions and
respective options is handed over to all stakeholders to
answer, which are collected and compiled.
• A shortcoming of this technique is, if an option for some issue
is not mentioned in the questionnaire, the issue might be left
unattended.
Brainstorming Sessions:

• It is a group technique
• It is intended to generate lots of new ideas hence providing a
platform to share views
• A highly trained facilitator is required to handle group bias
and group conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of
requirements and their priority if possible.
• Domain Analysis
• Every software falls into some domain category. The expert people in the domain
can be a great help to analyze general and specific requirements.
• Prototyping
• Prototyping is building user interface without adding detail functionality for user to
interpret the features of intended software product. It helps giving better idea of
requirements. If there is no software installed at client’s end for developer’s
reference and the client is not aware of its own requirements, the developer
creates a prototype based on initially mentioned requirements. The prototype is
shown to the client and the feedback is noted. The client feedback serves as an
input for requirement gathering.
• Observation
• Team of experts visit the client’s organization or workplace. They observe the
actual working of the existing installed systems. They observe the workflow at
client’s end and how execution problems are dealt. The team itself draws some
conclusions which aid to form requirements expected from the software.
 Analysis Modeling for Function Oriented and object Oriented
software development

• Analysis Model is a technical representation of the system. It acts as a link

between system description and design model. In Analysis Modelling,
information, behavior, and functions of the system are defined and
translated into the architecture, component, and interface level design in
the design modeling.

• Objectives of Analysis Modelling:

• It must establish a way of creating software design.
• It must describe the requirements of the customer.
• It must define a set of requirements that can be validated, once the
software is built.
Elements of Analysis Model:
• Data Dictionary:
It is a repository that consists of a description of all data objects
used or produced by the software. It stores the collection of data
present in the software. It is a very crucial element of the analysis
model. It acts as a centralized repository and also helps in modeling
data objects defined during software requirements.

• Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and is used in
conducting data modeling activities. The attributes of each object in
the Entity-Relationship Diagram can be described using Data object
description. It provides the basis for activity related to data design.
• Data Flow Diagram (DFD):
It depicts the functions that transform data flow and it also shows
how data is transformed when moving from input to output. It
provides the additional information which is used during the
analysis of the information domain and serves as a basis for the
modeling of function. It also enables the engineer to develop
models of functional and information domains at the same time.

• State Transition Diagram:

It shows various modes of behavior (states) of the system and also
shows the transitions from one state to another state in the system.
It also provides the details of how the system behaves due to the
consequences of external events. It represents the behavior of a
system by presenting its states and the events that cause the
system to change state. It also describes what actions are taken due
to the occurrence of a particular event.
• Process Specification:
It stores the description of each function present in the data flow diagram. It
describes the input to a function, the algorithm that is applied for the
transformation of input, and the output that is produced. It also shows regulations
and barriers imposed on the performance characteristics that are applicable to the
process and layout constraints that could influence the way in which the process
will be implemented.

• Control Specification:
It stores additional information about the control aspects of the software. It is
used to indicate how the software behaves when an event occurs and which
processes are invoked due to the occurrence of the event. It also provides the
details of the processes which are executed to manage events.

• Data Object Description:

It stores and provides complete knowledge about a data object present and used
in the software. It also gives us the details of attributes of the data object present
in the Entity Relationship Diagram. Hence, it incorporates all the data objects and
their attributes.
• Data Modeling (Entity Relationship Diagram)

• Functional Modeling ( Data Flow Diagram , Data Dictionary )

• Behavior Modeling ( State Diagram , Sequence Diagram )

 Functional Modeling
• Data flow diagram

• Data dictionary
 Data Flow Diagram
• A Data Flow Diagram (DFD) is a traditional visual representation of
the information flows within a system. A neat and clear DFD can
depict the right amount of the system requirement graphically. It
can be manual, automated, or a combination of both.
• It shows how data enters and leaves the system, what changes the
information, and where data is stored.
• The objective of a DFD is to show the scope and boundaries of a
system as a whole. It may be used as a communication tool
between a system analyst and any person who plays a part in the
order that acts as a starting point for redesigning a system. The DFD
is also called as a data flow graph or bubble chart.
• 0-level DFD:
It is also known as a context diagram. It’s designed to be an abstraction view,
showing the system as a single process with its relationship to external entities. It
represents the entire system as a single bubble with input and output data
indicated by incoming/outgoing arrows.
• 1-level DFD:
In 1-level DFD, the context diagram is decomposed into multiple
bubbles/processes. In this level, we highlight the main functions of the system and
breakdown the high-level process of 0-level DFD into subprocesses.
• 2-level DFD:
2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to plan
or record the specific/necessary detail about the system’s functioning.

•
 Object Oriented s/w development
• We know that the Object-Oriented Modelling (OOM) technique visualizes
things in an application by using models organized around objects. Any
software development approach goes through the following stages −
• Analysis,
• Design, and
• Implementation.
• Phases in Object-Oriented Software Development
• The major phases of software development using object–oriented methodology are object-
oriented analysis, object-oriented design, and object-oriented implementation.

• Object–Oriented Analysis
• In this stage, the problem is formulated, user requirements are identified, and then a model is built
based upon real–world objects. The analysis produces models on how the desired system should
function and how it must be developed. The models do not include any implementation details so
that it can be understood and examined by any non–technical application expert.
• Object–Oriented Design
• Object-oriented design includes two main stages, namely, system design and object design.

• System Design
• In this stage, the complete architecture of the desired system is designed. The system is conceived
as a set of interacting subsystems that in turn is composed of a hierarchy of interacting objects,
grouped into classes. System design is done according to both the system analysis model and the
proposed system architecture. Here, the emphasis is on the objects comprising the system rather
than the processes in the system.
• Object–Oriented Implementation and Testing
• In this stage, the design model developed in the object design is translated into code in an
appropriate programming language or software tool. The databases are created and the
specific hardware requirements are ascertained. Once the code is in shape, it is tested using
specialized techniques to identify and remove the errors in the code.

• Object Design
• In this phase, a design model is developed based on both the models developed in the system analysis phase and the
architecture designed in the system design phase. All the classes required are identified. The designer decides whether −
• new classes are to be created from scratch,
• any existing classes can be used in their original form, or
• new classes should be inherited from the existing classes.
• The associations between the identified classes are established and the hierarchies of classes are identified. Besides, the
developer designs the internal details of the classes and their associations, i.e., the data structure for each attribute and the
algorithms for the operations.
 Data Dictionaries in Software Engineering

• Data Dictionary is the major component in the structured

analysis model of the system. A data dictionary in Software
Engineering means a file or a set of files that includes a
database’s metadata (hold records about other objects in the
database), like data ownership, relationships of the data to
another object, and some other data.
 Components of Data Dictionary :

• In Software Engineering, the data dictionary contains the

following information as follows.
• Name of the item –
It can be your choice.
• Aliases –
It represents another name.
• Description –
Description of what actual text is all about.
• Related data items –
Relationship with other data items.
• Range of values –
It will represent all possible answers.
 Data Dictionary Notations tables

Notations Meaning
The Notations used within the data dictionary are given in the table below as follows.

X = a+b X consists data elements a and b.

X = [a/b] X consists of either elements a or b.

X=aX X consists of optimal data elements a.

X = y[a] X consists of y or more events of data element a

X = [a] z X consists of z or less events of data element a

X = y [a] z X consists of some events of data elements between y and z.

Features of Data Dictionary :
Here, we will discuss some features of the data dictionary as follows.

It helps in designing test cases and designing the software.

It is very important for creating an order list from a subset of the items list.
It is very important for creating an order list from a complete items list.
The data dictionary is also important to find the specific data item object from the
list.
Uses of Data Dictionary :
Here, we will discuss some use cases of the data dictionary as follows.
Used for creating the ordered list of data items
Used for creating the ordered list of a subset of the data items
Used for Designing and testing of software in Software Engineering
Used for finding data items from a description in Software Engineering
 Requirements Validation

• Requirements validation is the process of checking that requirements defined

for development, define the system that the customer really wants. To check
issues related to requirements, we perform requirements validation. We
usually use requirements validation to check error at the initial phase of
development as the error may increase excessive rework when detected later
in the development process.

• In the requirements validation process, we perform a different type of test to check the
requirements mentioned in the Software Requirements Specification (SRS), these checks
include:
• Completeness checks
• Consistency checks
• Validity checks
• Realism checks
• Ambiguity checks
• Verifiability
There are several techniques which are used either individually or in conjunction
with other techniques to check to check entire or part of the system:

• Test case generation:

Requirement mentioned in SRS document should be testable, the conducted tests
reveal the error present in the requirement. It is generally believed that if the test
is difficult or impossible to design than, this usually means that requirement will
be difficult to implement and it should be reconsidered.
• Prototyping:
In this validation techniques the prototype of the system is presented before the
end-user or customer, they experiment with the presented model and check if it
meets their need. This type of model is generally used to collect feedback about
the requirement of the user.
• Requirements Reviews:
In this approach, the SRS is carefully reviewed by a group of people including
people from both the contractor organisations and the client side, the reviewer
systematically analyses the document to check error and ambiguity.
• Automated Consistency Analysis:
This approach is used for automatic detection of an error, such as
nondeterminism, missing cases, a type error, and circular definitions, in
requirements specifications.
 Traceability
• Traceability comprises of two words i.e. trace and ability. Trace means to find
someone or something and ability means to a skill or capability or talent to do
something. Therefore, traceability simply means the ability to trace the
requirement, to provide better quality, to find any risk, to keep and verify the
record of history and production of an item or product by the means of
documented identification. Due to this, it’s easy for the suppliers to reduce any risk
or any issue if found and to improve the quality of the item or product. So, it’s
important to have traceability rather than no traceability. Using traceability, finding
requirements, and any risk to improve the quality of the product becomes very
easy.
 There are various types of traceability given below:

• Source traceability –
These are basically the links from requirement to stakeholders who
propose these requirements.
• Requirements traceability –
These are the links between dependent requirements.
• Design traceability –
These are the links from requirement to design.