Prepared by Dr.

Vijay Bhandari
9826446156

UNIT-II
L-11
PRODUCT AND PROCESS METRICS REQUIREMENT &
FUNCTIONALITIES
Product metrics − Describes the characteristics of the product such as size, complexity, design features,
performance, and quality level.
Process metrics − These characteristics can be used to improve the development and maintenance
activities of the software.
Project metrics − This metrics describe the project characteristics and execution. Examples include the
number of software developers, the staffing pattern over the life cycle of the software, cost, schedule, and
productivity.
Some metrics belong to multiple categories. For example, the in-process quality metrics of a project
are both process metrics and project metrics.
Software quality metrics are a subset of software metrics that focus on the quality aspects of the
product, process, and project. These are more closely associated with process and product metrics than
with project metrics as shown in below figure

fig 2.1 product and process metrics requirement

Software quality metrics can be further divided into three categories −

 Product quality metrics

 In-process quality metrics
 Maintenance quality metrics
Product Quality Metrics
This metrics include the following −

 Mean Time to Failure

 Defect Density
 Customer Problems
 Customer Satisfaction
 Mean Time to Failure
It is the time between failures. This metric is mostly used with safety critical systems such as the airline
traffic control systems, avionics, and weapons.
 Defect Density
It measures the defects relative to the software size expressed as lines of code or function point, etc.
i.e., it measures code quality per unit. This metric is used in many commercial software systems.
Customer Problems
It measures the problems that customers encounter when using the product. It contains the
customer’s perspective towards the problem space of the software, which includes the non-defect
oriented problems together with the defect problems.
The problems metric is usually expressed in terms of Problems per User-Month (PUM).

 PUM = Total Problems that customers reported (true defect and non-defect oriented
 problems) for a time period + Total number of license months of the software during
 the period

Where,

 Number of license-month of the software = Number of install license of the software ×

 Number of months in the calculation period

PUM is usually calculated for each month after the software is released to the market, and also for
monthly averages by year.
Customer Satisfaction
Customer satisfaction is often measured by customer survey data through the five-point scale −

 Very satisfied
 Satisfied
 Neutral
 Dissatisfied
 Very dissatisfied
Satisfaction with the overall quality of the product and its specific dimensions is usually obtained
through various methods of customer surveys. Based on the five-point-scale data, several metrics with
slight variations can be constructed and used, depending on the purpose of analysis. For example −

 Percent of completely satisfied customers

 Percent of satisfied customers
 Percent of dis-satisfied customers
 Percent of non-satisfied customers
 Usually, this percent satisfaction is used.
In-process Quality Metrics
In-process quality metrics deals with the tracking of defect arrival during formal machine testing for
some organizations. This metric includes −

 Defect density during machine testing

 Defect arrival pattern during machine testing
 Phase-based defect removal pattern
 Defect removal effectiveness

ELICIATION ANALYSIS & SPECIFICATION
Requirement: -
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
equirements Specification’ document.

Types of Requirements: -
 User Requirements: It is a collection of statement in natural language and description of the services the
system provides and its operational limitation. It is written for customer.
 System Requirement: It is a structured document that gives the detailed description of the system services.
It is written as a contract between client and contractor.

Software Requirement Specification: -

SRS is a document created by system analyst after the requirements are collected from various stakeholders.
SRS defines how the intended software will interact with hardware, external interfaces, speed of operation,
response time of system, portability of software across various platforms, maintainability, speed of recovery
after crashing, Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the responsibility of system analyst
to document the requirements in technical language so that they can be comprehended and useful by the
software development team.
SRS should come up with following features:
 User Requirements are expressed in natural language.
 Technical requirements are expressed in structured language, which is used inside the organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.
Software Requirements: -
We should try to understand what sort of requirements may arise in the requirement elicitation phase and
what kinds of requirements are expected from the software system.
Broadly software requirements should be categorized in two categories:
1. Functional Requirement
2. Non Functional Requirement
 L-12

FUNCTIONAL REQUIREMENTS:
It should describe all requirement functionality or system services. The customer should provide statement of
service. it should be clear how the system should be reacting to particular input and how a particular system
should behave in particular situation. Functional requirement is heavily depending upon he type of software
expected users and the type of system where the software is used. It describes system services in detail as
shown in below figure

Fig 2.2 functional requirement

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 are more critical
than functional requirement if the non-functional requirement do not meet then the complete system is of no
use as shown in below figure 2.2:-
Some typical non-functional requirements are:
 Product requirement-
Specify how a livered product should behave in particular way.
o Eg: efficiency, Usability, Reliability, portability
 Organizational requirement- The requirements which are unwelcome effect of organizational policies and
procedures come under this category.
o Eg: Delivery, implementation, standard
 External requirement-
These requirements arise due to the factors that are external of the system and its developed process.
o Eg: Interoperability, ethical, [Link] shown in below figure:
 Fig 2.3 Non Functional Requirement

o REQUIREMENT SOURCES AND ELICITATION TECHNIQUES:

Requirements Sources:-
In a typical system, there will be many sources of requirements and it is essential that all potential sources are
identified and evaluated for their impact on the system. This subtopic is designed to promote awareness of
different requirements sources and frameworks for managing them.
The main points covered are:
 Goals: -The term ‘Goal’ (sometimes called ‘business concern’ or ‘critical success factor’) refers to the
overall, high-level objectives of the system. Goals provide the motivation for a. Requirements engineers
need to pay particular attention to assessing the value (relative to priority) and cost of goals. A feasibility
study is a relatively low-cost way of doing this.
 Domain knowledge: - The requirements engineer needs to acquire or to have available knowledge about
the application domain. This enables them to infer tacit knowledge that the stakeholders do not articulate,
assess the trade-offs that will be necessary between conflicting requirements and sometimes to act as a
‘user’ champion.
 System stakeholders: -Many systems have proven unsatisfactory because they have stressed the
requirements for one group of stakeholders at the expense of others. Hence, systems are delivered that are
hard to use or which subvert the cultural or political structures of the customer organization. The
requirements engineer needs to identify represent and manage the ‘viewpoints’ of many different types of
stakeholder.
 The operational environment: -Requirements will be derived from the environment in which the software
will execute. These may be, for example, timing constraints in a real-time system or interoperability
constraints in an office environment. These must be actively sought because they can greatly affect system
feasibility, cost, and restrict design choices.
 The organizational environment: -Many systems are required to support a business process and this may
be conditioned by the structure, culture and internal politics of the organization. The requirements
engineer needs to be sensitive to these since, in general, new software systems should not force unplanned
change to the business process.
 L-13

ANALYSIS MODELING FOR FUNCTION ORIENTED AND OBJECT ORIENTED SOFTWARE DEVELOPMENT :
Analysis model: -
The analysis model must achieve three primary objectives:
 To describe what the customer requires(analysis)
 To establish a basis for the creation of software with a combination of text and design are used to represent
the software requirement.
 To define a set of requirements that can be validated once the software is built.
The elements of analysis model: -
At the core of the model lies the data dictionary—a repository that contains descriptions of all data objects
consumed or produced by the software. Three different diagrams surround the core. The entity relation
diagram (ERD) depicts relationships between data objects. The ERD is the notation that is used to conduct the
data modeling activity. The attributes of each data object noted in the ERD can be described using a data
object description.
The data flow diagram (DFD) serves two purposes: (1) to provide an indication of how data are transformed as
they move through the system and (2) to depict the functions (and sub functions) that transform the data
flow.

The DFD provides additional information that is used during the analysis of the information domain and serves
as a basis for the modeling of function. A description of each function presented in the DFD is contained in a
process specification (PSPEC).
The state transition diagram (STD) indicates how the system behaves as a consequence of external events. To
accomplish this, the STD represents the various modes of behavior (called states) of the system and the
manner in which transitions are made from state to state. The STD serves as the basis for behavioral modeling.
Additional information about the control flow in the control specification (CSPEC). Process specification
describes each function in DFD. Data object description of various data object used.

Data Flow
Data Object Diagram
description

Entity DFD
Relationship
Diagram
Data
Dictionary

State- transition Diagram

Control
Specification

Figure 2.4: State Transition Diagram

Analysis and Modeling: -
Structured Approach
Data Modeling -> ERD
Functional Modeling -> DFD
 Behavior Modeling -> State chart diagram
Object Oriented Approach (UML)
 Use case
 Class diagram
 Activity diagram
 Sequence diagram
 Deployment diagram
 Component diagram
The structured approach - plan the right way first
 plans to avoid crisis
 covers all eventualities
 useful for team working
 shorter in the end
In SA data object are modeled in a way in which data attributes and their relationship is defined in structured
approach.
 L14

Analysis Modeling & Data Flow Diagram (DFD):

 The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows the

different processing activities or functions that the system

 Performs and the data interchange among these functions. Each function is considered as a processing
station (or process) that consumes some input data and produces some output data. The system is
represented in terms of the input
 Data to the system, various processing carried out on these data, and the output
 Data generated by the system. A DFD model uses a very limited number of primitive symbols as shown
in below Figure to represent the functions performed by a system and the data flow among these
functions.

Levels of DFD
 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire information
system as one diagram concealing all the underlying details. Level 0 DFDs are also known as context level
DFDs.

User registration
(view the book detail)
Library User/student
Administrator
Management
System
Read and write

Book request/return

Library Database

Figure 2.5: Level 0 DFD

Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1DFD depicts basic modules in
the system and flow of data among various modules. Level 1 DFD also mentions basic processes and sources of
information.

Account

Finance
Verification

Customer Order Store

Date Processing
Verif Issue
Proces Order
Sales
order

Customers Deliver

Figure 2.6: Level 1 DFD

Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with deeper level of understanding
unless the desired level of specification is achieved.
 L15
Requirement sources
Requirements Sources:-
In a typical system, there will be many sources of requirements and it is essential that all potential sources are
identified and evaluated for their impact on the system. This subtopic is designed to promote awareness of
different requirements sources and frameworks for managing them.
The main points covered are:
 Goals: -The term ‘Goal’ (sometimes called ‘business concern’ or ‘critical success factor’) refers to the
overall, high-level objectives of the system. Goals provide the motivation for a. Requirements engineers
need to pay particular attention to assessing the value (relative to priority) and cost of goals. A feasibility
study is a relatively low-cost way of doing this.
 Domain knowledge: - The requirements engineer needs to acquire or to have available knowledge about
the application domain. This enables them to infer tacit knowledge that the stakeholders do not articulate,
assess the trade-offs that will be necessary between conflicting requirements and sometimes to act as a
‘user’ champion.
 System stakeholders: -Many systems have proven unsatisfactory because they have stressed the
requirements for one group of stakeholders at the expense of others. Hence, systems are delivered that are
hard to use or which subvert the cultural or political structures of the customer organization. The
requirements engineer needs to identify represent and manage the ‘viewpoints’ of many different types of
stakeholder.
 The operational environment: -Requirements will be derived from the environment in which the software
will execute. These may be, for example, timing constraints in a real-time system or interoperability
constraints in an office environment. These must be actively sought because they can greatly affect system
feasibility, cost, and restrict design choices.
 The organizational environment: -Many systems are required to support a business process and this may
be conditioned by the structure, culture and internal politics of the organization. The requirements
engineer needs to be sensitive to these since, in general, new software systems should not force unplanned
change to the business process.
 L16

Elicitation techniques: -
When the requirements sources have been identified the requirements, engineer can start eliciting
requirements from them. It also means requirement discovery. This subtopic concentrates on techniques for
getting human stakeholders to articulate their requirements. This is a very difficult area and the
requirements engineer needs to be sensitized to the fact that (for example) users may have difficulty
describing their tasks, may leave important information unstated, or may be unwilling or unable to cooperate.
It is particularly important to understand that elicitation is not a passive activity and that even if cooperative
and articulate stakeholders are available, the requirements engineer has to work hard to elicit the right
information. A number of techniques will be covered, but the principal ones are:
 Interviews:-Interviews are a ‘traditional’ means of eliciting requirements. It is important to understand the
advantages and limitations of interviews and how they should be conducted.
 Scenarios: - Scenarios are valuable for providing context to the elicitation of users’ requirements. They allow
the requirements engineer to provide a framework for questions about users’ tasks by permitting ‘what if?’
and ‘how is this done?’ questions to be asked. (Conceptual modeling) because recent modeling notations
have attempted to integrate scenario notations with object-oriented analysis techniques.
 Prototypes: -Prototypes are a valuable tool for clarifying unclear requirements. They can act in a similar way
to scenarios by providing a context within which users better understand what information they need to
provide. There is a wide range of prototyping techniques, which range from paper mock-ups of screen
designs to beta-test versions of software products. There is a strong overlap with the use of prototypes for
requirements validation.
 Facilitated meetings: -The purpose of these is to try to achieve a summative effect whereby a group of
people can bring more insight to their requirements than by working individually. They can brainstorm and
refine ideas that may be difficult to surface using (e.g.) interviews.
 Observation: -The importance of systems’ context within the organizational environment has led to the
adaptation of observational techniques for requirements elicitation. The requirements engineer learns about
users’ tasks by immersing themselves in the environment and observing how users interact with their
systems and each other. These techniques are relatively new and expensive but are instructive because they
illustrate that many user tasks and business processes are too subtle and complex for their actors to
describe easily.
1. Requirement
Discovery

2. Requirement
4. Requirement
Classification &
Specification
Organization

3.
Requirement
Prioritization &
Negotiations

Figure 2.7 Requirement Prototype

 L17
ANALYSIS MODELING FOR FUNCTION ORIENTED AND OBJECT ORIENTED SOFTWARE DEVELOPMENT :
Analysis model: -
The analysis model must achieve three primary objectives:
 To describe what the customer requires(analysis)
 To establish a basis for the creation of software with a combination of text and design are used to represent
the software requirement.
 To define a set of requirements that can be validated once the software is built.
The elements of analysis model: -
At the core of the model lies the data dictionary—a repository that contains descriptions of all data objects
consumed or produced by the software. Three different diagrams surround the core. The entity relation
diagram (ERD) depicts relationships between data objects. The ERD is the notation that is used to conduct the
data modeling activity. The attributes of each data object noted in the ERD can be described using a data
object description.
The data flow diagram (DFD) serves two purposes: (1) to provide an indication of how data are transformed as
they move through the system and (2) to depict the functions (and sub functions) that transform the data
flow.

The DFD provides additional information that is used during the analysis of the information domain and serves
as a basis for the modeling of function. A description of each function presented in the DFD is contained in a
process specification (PSPEC).
The state transition diagram (STD) indicates how the system behaves as a consequence of external events. To
accomplish this, the STD represents the various modes of behavior (called states) of the system and the
manner in which transitions are made from state to state. The STD serves as the basis for behavioral modeling.
Additional information about the control flow in the control specification (CSPEC). Process specification
describes each function in DFD. Data object description of various data object used.

Data Flow
Data Object Diagram
description

Entity DFD
Relationship
Diagram
Data
Dictionary

State- transition Diagram

Control
Specification

Figure 2.8: State Transition Diagram

Analysis and Modeling: -
Structured Approach
Data Modeling -> ERD
Functional Modeling -> DFD
 Behavior Modeling -> State chart diagram
Object Oriented Approach (UML)
 Use case
 Class diagram
 Activity diagram
 Sequence diagram
 Deployment diagram
 Component diagram
The structured approach - plan the right way first
 plans to avoid crisis
 covers all eventualities
 useful for team working
 shorter in the end
In SA data object are modeled in a way in which data attributes and their relationship is defined in structured
approach.

Behavior Modeling: -
Structure Charts: -
Structure chart is a chart derived from Data Flow Diagram. It represents the system in more detail than DFD. It
breaks down the entire system into lowest functional modules, describes functions and sub-functions of each
module of the system to a greater detail than DFD.
A structure chart represents the software architecture, i.e. the various modules making up the system, the
dependency (which module calls which other modules), and the parameters that are passed among the
different modules. The basic building blocks which are used to design structure charts are the following:
 Rectangular boxes: Represents a module.
 Module invocation arrows: Control is passed from one module to another module in the direction of
the connecting arrow.
 Data flow arrows: Arrows are annotated with data name; named data passes from one module to
another module in the direction of the arrow.
 Library modules: Represented by a rectangle with double edges.
 Selection: Represented by a diamond symbol.
 Repetition: Represented by a loop around the control flow arrow.

Transform Analysis: -
Transform analysis identifies the primary functional components (modules) and the high-level inputs and
outputs for these components. The first step in transform analysis is to divide the DFD into 3 types of parts:
 Input
 Logical processing
 Output

The input portion of the DFD includes processes that transform input data from physical (e.g. character from
terminal) to logical forms (e.g. internal tables, lists etc.). Each input portion is called an afferent branch. The
output portion of a DFD transforms output data from logical to physical form. Each output portion is called an
efferent branch. The remaining portion of a DFD is called the central transform.
Example: Structure chart for the RMS software
For this example, the context diagram was drawn earlier.
 L18

Object-oriented Software Development:

- Object-oriented design: -
In the object-oriented design approach, the system is viewed as collection of objects (i.e. entities). The state is
decentralized among the objects and each object manages its own state information. For example, in a Library
Automation Software, each library member may be a separate object with its own data and functions to
operate on these data. In fact, the functions defined for one object cannot refer or change data of other
objects. Objects have their own internal data which define their state. Similar objects constitute a class. In
other words, each object is a member of some class. Classes may inherit features from super class.
Conceptually, objects communicate by message passing.

What is a model: -
A model captures aspects important for some application while omitting (or abstracting) the rest. A model in
the context of software development can be graphical, textual, mathematical, or program code-based. Models
Are very useful in documenting the design and analysis results. Models also facilitate the analysis and design
procedures themselves. Graphical models are very popular because they are easy to understand and
construct. UML is primarily a graphical modeling tool. However, it often requires text explanations to
accompany the graphical models.

Need for a model:

An important reason behind constructing a model is that it helps manage complexity. Once models of a system
have been constructed, these can be used for a variety of purposes during software development, including
the following:
 Analysis
 Specification
 Code generation
 Design
 Visualize and understand the problem and the working of a system
 Testing, etc.
In all these applications, the UML models can not only be used to document the results but also to arrive at
the results themselves. Since a model can be used for a variety of purposes, it is reasonable to expect that the
model would vary depending on the purpose for which it is being constructed. For example, a model
developed for initial analysis and specification should be very different from the one used for design. A model
that is being used for analysis and specification would not show any of the design decisions that would be
made later on during the design stage. On the other hand, a model used for design purposes should capture all
the design decisions. Therefore, it is a good idea to explicitly mention the purpose for which a model has been
developed, along with the model.
 L19

Unified Modeling Language (UML):-

UML, as the name implies, is a modeling language. It may be used to visualize, specify, construct, and
document the artifacts of a software system. It provides a set of notations (e.g. rectangles, lines, ellipses, etc.)
to create a visual model of the system. Like any other language, UML has its own syntax (symbols and
sentence formation rules) and semantics (meanings of symbols and sentences). Also, we should clearly
understand that UML is not a system design or development methodology, but can be used to document
object-oriented and analysis results obtained using some methodology.

UML Diagrams:
UML can be used to construct nine different types of diagrams to capture five different views of a system. Just
as a building can be modeled from several views (or perspectives) such as ventilation perspective, electrical
perspective, lighting perspective, heating perspective, etc.; the different UML diagrams provide different
perspectives of the software system to be developed and facilitate a comprehensive understanding of the
system. Such models can be refined to get the actual implementation of the system.
The UML diagrams can capture the following five views of a system:
 User’s view
 Structural view
 Behavioral view
 Implementation view
 Environmental view

User’s view: This view defines the functionalities (facilities) made available by the system to its users. The
users’ view captures the external user’s view of the system in terms of the functionalities offered by the
system. The user’s view is a black-box view of the system where the internal structure, the dynamic behavior
of
Different system components, the implementation etc. are not visible.
Structural view: The structural view defines the kinds of objects (classes) important to the understanding of
the working of a system and to its implementation. It also captures the relationships among the classes
(objects). The structural model is also called the static model, since the structure of a system does not change
with time.
Behavioral view: The behavioral view captures how objects interact with each other to realize the system
behavior. The system behavior captures the time-dependent (dynamic) behavior of the system.
Implementation view: This view captures the important components of the system and their dependencies.
Environmental view: This view models how the different components are implemented on different pieces of
hardware.
USE-CASE MODELING:
Use case modeling was originally developed by Jacobson et al. (1993) in the 1990s and was incorporated into
the first release of the UML (Rumbaugh et al., 1999). Use case modeling is widely used to support
requirements elicitation. A use case can be taken as a simple scenario that describes what a user expects from
a system.

Use-case Model: -
The use case model for any system consists of a set of “use cases”. Intuitively, use cases represent the
different ways in which a system can be used by the users. A simple way to find all the use cases of a system is
to ask the question: “What the users can do using the system?”
Thus, for the Library Information System (LIS), the use cases could be:

 issue-book
 query-book
 return-book
 create-member
 add-book etc

Login

Renew
book

Search Figure 2.5

book
User
Check
availability book

Reserve
book Update
Book_Recored

Check
account

Return_Book
Libr
ar
Use cases correspond to the high-level functional requirements. The use cases partition the system behavior

into transactions, such that each transaction performs some useful action from the user’s
complete each transaction may involve either a single message or multiple message exchanges between the
user and the system to complete.

Purpose of use cases: -

The purpose of a use case is to define a piece of coherent behavior without revealing the internal structure of
the system. The use cases do not mention any specific algorithm to be used or the internal data
representation, internal structure of the software, etc. A use case typically represents a sequence of
interactions between the user and the system. These interactions consist of one mainline sequence. The
mainline sequence represents the normal interaction between a user and the system. The mainline sequence
is the most occurring sequence of interaction.

Representation of use cases: -

Use cases can be represented by drawing a use case diagram and writing an accompanying text elaborating
the drawing. In the use case diagram, each use case is represented by an ellipse with the name of the use case
written inside the ellipse. All the ellipses (i.e. use cases) of a system are enclosed within a rectangle which
represents the system boundary. The name of the system being modeled (such as Library Information System)
appears inside the rectangle.

Text Description: -
Each ellipse on the use case diagram should be accompanied by a text description. The text description should
define the details of the interaction between the user and the computer and other aspects of the use case. It
should include all the behavior associated with the use case in terms of the mainline sequence, different
variations to the normal behavior, the system responses associated with the use case, the exceptional
conditions that may occur in the behavior, etc.
Contact persons: This section lists the personnel of the client organization with whom the use case was
discussed, date and time of the meeting, etc.
Actors: In addition to identifying the actors, some information about actors using this use case which may help
the implementation of the use case may be recorded.
Pre-condition: The preconditions would describe the state of the system before the use case execution starts.
Post-condition: This captures the state of the system after the use case has successfully completed.
Non-functional requirements: This could contain the important constraints for the design and
implementation, such as platform and environment conditions, qualitative statements, response time
requirements, etc.
Exceptions, error situations: This contains only the domain-related errors such as lack of user’s access rights,
invalid entry in the input fields, etc. Obviously, errors that are not domain related, such as software errors,
need not be discussed here.
Sample dialogs: These serve as examples illustrating the use case.
Specific user interface requirements: These contain specific requirements for the user interface of the use
case. For example, it may contain forms to be used, screen shots, interaction style, etc.
Document references: This part contains references to specific domain related documents which may be
useful to understand the system operation.
 L20

SYSTEM AND SOFTWARE REQUIREMENT SPECIFICATIONS:

Software Specification: -
Software Specification is an activity that is use to describe he thing you are trying to achieve to establish what
services are required from the system and limitation on the system operation and development. His activity is
often called Requirement Engineering. Requirement Engineering is a particularly critical stage of the software
process as error at this stage certain to happen lead to later problem in the system design and
implementation.

There are four main phases in the Requirement Engineering process:

 Feasibility study: user satisfaction, cost estimation.
 Requirement elicitation analysis: meeting for description of development.
 Requirement Specification: is the activity of translating the information gathered during the analysis activity
into a document that defines a set of requirements. 2 types of requirements may be including in his
document.
 User Requirements (b) System Requirement
 Requirements Validation: this activity checks the requirement for realism, consistency and completeness.
 L21

Software Requirement Specification [SRS]: -

A software requirements specification (SRS) is a document that captures complete description about how the
system is expected to perform. It is usually signed off at the end of requirements engineering phase.
The Software Requirements Specification is produced at the culmination of the analysis task. The function and
performance allocated to software as part of system engineering are refined by establishing a complete
information description, a detailed functional description, a representation of system behavior, an indication
of performance requirements and design constraints, appropriate validation criteria, and other information
pertinent to requirements.
 A description of each function required to solve the problem is presented in the Functional Description.
A processing narrative is provided for each function, design constraints are stated and justified,
performance characteristics are stated, and one or more diagrams are included to graphically
represent the overall structure of the software and interplay among software functions and other
system elements.
 The Behavioral Description section of the specification examines the operation of the software as a
consequence of external events and internally generated control characteristics.
 Validation Criteria is probably the most important and, ironically, the most often neglected section of
the Software Requirements Specification. How do we recognize a successful implementation? What
classes of tests must be conducted to validate function, performance, and constraints? We neglect this
section because completing it demands a thorough understanding of software requirements—
something that we often do not have at this stage. Yet, specification of validation criteria acts as an
implicit review of all other requirements. It is essential that time and attention be given to this section.
 Finally, the specification includes a Bibliography and Appendix. The bibliography contains references to
all documents that relate to the software. These include other software engineering documentation,
technical references, vendor literature, and standards. The appendix contains information that
supplements the specifications. Tabular data, detailed description of algorithms, charts, graphs, and
other material are presented as appendixes.
In many cases the Software Requirements Specification may be accompanied by an executable prototype
(which in some cases may replace the specification), a paper prototype or a Preliminary User’s Manual. The
Preliminary User’s Manual presents the software as a black box. That is, heavy emphasis is placed on user
input and the resultant output. The manual can serve as a valuable tool for uncovering problems at the
human/machine interface.

Characteristics of SRS:
 Correct: Requirement must be correctly mentioned and realistic by nature.
 Unambiguous: Transparent and plain SRS must be written.
 Complete: To make the SRS complete I should be specified what a software designer wants to create
on software.
 Consistent: If there are not conflicts in the specified requirement then SRS is said to be consistent.
 Stability: The SRS must contain all the essential requirement. Each requirement must be clear and
Explicit.
 Verifiable: the SRS should be written in such a manner that the requirement that is specified within it
must be satisfied by the software.
 Modifiable: It can easily modify according to user requirement.
 Traceable: If origin of requirement is properly given of the requirement are correctly mentioned then
such a requirement is called as traceable requirement.
 L22
REQUIREMENTS VALIDATION:
The work products produced as a consequence of requirements engineering are assessed for quality during a
validation step. Requirements validation examines the specification to ensure that all system requirements
have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and
corrected; and that the work products conform to the standards established for the process, the project, and
the product.
The primary requirements validation mechanism is the formal technical review. The review team includes
system engineers, customers, users, and other stakeholders who examine the system specification 5 looking
for errors in content or interpretation, areas where clarification may be required, missing information,
inconsistencies , conflicting requirements, or unrealistic (unachievable) requirements.
Although the requirements validation review can be conducted in any manner that results in the discovery of
requirements errors, it is useful to examine each requirement against a set of checklist questions. The
following questions represent a small subset of those that might be asked:
 Are requirements stated clearly? Can they be misinterpreted?
 Is the source (e.g., a person, a regulation, a document) of the requirement identified? Has the final
statement of the requirement been examined by or against the original source?
 Is the requirement bounded in quantitative terms?
 What other requirements relate to this requirement? Are they clearly noted via a cross-reference
matrix or other mechanism?
 Does the requirement violate any domain constraints?
 Is the requirement testable? If so, can we specify tests (sometimes called validation criteria) to exercise
the requirement?
 Is the requirement traceable to any system model that has been created?
 Is the requirement traceable to overall system/product objectives?
 Is the system specification structured in a way that leads to easy understanding, easy reference, and
easy translation into more technical work products?
 Has an index for the specification been created?
 Have requirements associated with system performance, behavior, and operational characteristics
been clearly stated? What requirements appear to be implicit?

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
Once requirements have been identified, traceability tables are developed. Shown schematically in Figureure,
each traceability table relates identified requirements to one or more aspects of the system or its
environment. Among many possible traceability tables are the following:
 Features traceability table. Shows how requirements relate to important customer observable
system/product features.
 Source traceability table. Identifies the source of each requirement
 Dependency traceability table. Indicates how requirements are related to one another.
 Subsystem traceability table. Categorizes requirements by the subsystem(s) that they govern.
  Interface traceability table. Shows how requirements relate to
both internal and interfaces.
In many cases, these traceability tables are maintained as part of a requirements
database so that they may be quickly searched to understand how a change in one
requirement will affect different aspects of the system to be built.
Requirements validation techniques are used to ensure that the software requirements are
complete, consistent, and correct. Some common techniques used in software engineering
include:
1. Inspection: This technique involves reviewing the requirements document with a
group of experts, looking for errors, inconsistencies, and missing information.
2. Walkthrough: This technique involves a group of experts reviewing the requirements
document and walking through it line by line, discussing any issues or concerns that
arise.
3. Formal verification: This technique involves mathematically proving that the
requirements are complete and consistent, and that the system will meet the
requirements.
4. Model-based verification: This technique involves creating a model of the system
and simulating it to see if it meets the requirements.
5. Prototyping: This technique involves creating a working prototype of the system and
testing it to see if it meets the requirements.
6. Black-box testing: This technique involves testing the system without any knowledge
of its internal structure or implementation, to see if it meets the requirements.
7. Acceptance testing: This technique involves testing the system with real users to see
if it meets their needs and requirements.
8. User feedback: This technique involves gathering feedback from the users and
incorporating their suggestions and feedback into the requirements.
Traceability: This technique involves tracing the requirements throughout the entire software
development life cycle to ensure that they are being met and that any changes are tracked and
managed.
Agile methodologies: Agile methodologies such as Scrum and Kanban, provide an iterative
approach to validate requirements by delivering small chunks of functionality and getting
feedback from the customer.
It is important to note that no single technique is sufficient on its own and a combination of
different techniques is usually used to validate software requirements effectively.
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
The output of requirements validation is the list of problems and agreed on actions of detected
problems. The lists of problems indicate the problem detected during the process of
requirement validation. The list of agreed action states the corrective action that should be
taken to fix the detected problem. 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:
1. 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.
2. 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.
3. 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.
4. 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. First, the requirement is structured in
formal notation then CASE tool is used to check in-consistency of the system, The
report of all inconsistencies is identified and corrective actions are taken.
5. Walk-through: A walkthrough does not have a formally defined procedure and does
not require a differentiated role assignment.
 Checking early whether the idea is feasible or not.
 Obtaining the opinions and suggestion of other people.
 Checking the approval of others and reaching an agreement.
 Fig2.10 requirement validation

ADVANTAGES OR DISADVANTAGES:

Advantages Of Using Requirements Validation Techniques:

1. Improved quality of the final product: By identifying and addressing requirements
early on in the development process, using validation techniques can improve the
overall quality of the final product.
2. Reduced development time and cost: By identifying and addressing requirements
early on in the development process, using validation techniques can reduce the
likelihood of costly rework later on.
3. Increased user involvement: Involving users in the validation process can lead to
increased user buy-in and engagement in the project.
4. Improved communication: Using validation techniques can improve communication
between stakeholders and developers, by providing a clear and visual representation
of the software requirements.
5. Easy testing and validation: A prototype can be easily tested and validated, allowing
stakeholders to see how the final product will work and identify any issues early on
in the development process.
6. Increased alignment with business goals: Using validation techniques can help to
ensure that the requirements align with the overall business goals and objectives of
the organization.
7. Traceability: This technique can help to ensure that the requirements are being met
and that any changes are tracked and managed.
8. Agile methodologies: Agile methodologies provide an iterative approach to validate
requirements by delivering small chunks of functionality and getting feedback from
the customer.
Disadvantages Of Using Requirements Validation Techniques:
1. Increased time and cost: Using validation techniques can be time-consuming and
costly, especially when involving multiple stakeholders.
2. Risk of conflicting requirements: Using validation techniques can lead to conflicting
requirements, which can make it difficult to prioritize and implement the
requirements.
3. Risk of changing requirements: Requirements may change over time and it can be
difficult to keep up with the changes and ensure that the project is aligned with the
updated requirements.
4. Misinterpretation and miscommunication: Misinterpretation and miscommunication
can occur when trying to understand the requirements.
5. Dependence on the tool: The team should be well trained on the tool and its
features to avoid the dependency on the tool and not on the requirement.
6. Limited validation: The validation techniques can only check the requirement that
are captured and may not identify the requirement that are missed
7. Limited to functional requirements: Some validation techniques are limited to
functional requirements and may not validate non-functional requirements.
 L23

TRACEABILITY:
Traceability is a property of an element of documentation or code that indicates the
degree to which it can be traced to its origin or "reason for being". Traceability also
indicates the ability to establish a predecessor- successor relationship between one work
product and another.
A work product is said to be traceable if it can be proved that it complies with its
specification. For example, a software design is said to be traceable if it satisfies all the
requirements stated in the software requirements specification. Examples of traceability
include:
 External source to system requirements
 System requirements to software requirements
 Software requirements to high level design
 High level design to detailed design
 Detailed design to code
 Software requirement to test case.
 Software Requirement Analysis (SRS) Forward to architecture
Backward from architecture

Software Architecture Design Description (SADD)

Forward from architecture

Backward to architecture
Software Detailed Design Description (SDDD)

Figure 2.11: Tracing a Software Architecture Design Description

Traceability in software engineering is the ability to trace work items across the development lifecycle. It's
used to keep track of what's going on in the development lifecycle — and show what's happened. Achieving
regulatory compliance is a common purpose for traceability in software engineering.

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:
1. Source traceability – These are basically the links from requirement to stakeholders who propose these
requirements.
2. Requirements traceability – These are the links between dependent requirements.
3. Design traceability – These are the links from requirement to design.
4. Testing traceability – These are the links between requirements and test cases, which ensure that each
requirement has been properly tested.
5. Code traceability – These are the links between the requirements and the actual code that is developed
to implement those requirements.
6. Version traceability – These are the links between different versions of software or documents, which
allow for tracking of changes and updates over time.
7. Release traceability – These are the links between the requirements and the specific software release or
version in which they were implemented.
8. Risk traceability – These are the links between risks identified in the project and the mitigating actions
taken to address those risks.
9. Business traceability – These are the links between project requirements and overall business goals and
objectives.
10. Quality traceability – These are the links between requirements, design, testing, and implementation,
which ensure that quality is maintained throughout the software development process.
 Traceability matrix is generally used to represent the information of traceability. For mentioning the
traceability of small systems usually the traceability matrix is maintained. If one requirement is dependent
upon another requirement then in that row-column cell ‘D’ is mentioned and if there is a weak relationship
between the requirements than corresponding entry can be denoted by ‘R’. For example:

Requirement ID A B C D E F
A D R
B D
C R
D D R
E
F R D

Fig2.12 A simple traceability matrix structure

When it comes to software engineering, convoluted code can behave in ways that seemingly make no apparent
sense. Engineering software often lacks interconnection among existing requirements, the source of these
requirements, and the underlying system infrastructure. This results in frustration for users, developers, and
software engineers.
Traceability in software engineering describes the extent to which documentation or code can be traced back
to its point of origin. The goal of traceability is to provide better quality and consistency of product
development. It brings the ability to verify the history, location, and application of an item by means of
documented identification.
In complex system industries like aerospace or defense, traceability is often a legal constraint to prove
standard compliance of deliverables from stakeholder requirements to the qualified products. Not only is
traceability mandated for safety-critical systems but without it, it is difficult to maintain consistency from
early user requirements to the final phase of tested and delivered products.

Requirements traceability in Software Engineering

Increased usage of modeling in engineering makes traditional approaches less relevant as surrogate assets are imported
from authoring tools.
Using requirement tooling as the only focal point of traceability implies flattening authored models and counterproductive
mass conversions during design phases. By formally recording the relationships between all elements in the engineering
process, we can identify the impact a change in one element will have across the entire project. This impact analysis
immediately identifies which parts of the architecture, design, tests, or software need to be changed in order to adapt to a
requested or mandated change.
Very often a project is forced to retroactively, and manually, recreate traceability at the end of a project in order to deliver.
This task requires engineers to stop all other engineering activities, or may even require hiring external bodies, to create
Excel spreadsheets (or other documents) to capture the links across engineering artifacts and software. Not only does this
make the engineering team less effective and responsive rather than proactive, but it typically results in unexpected
supplementary expenses. Traceability allows teams to benefit from early impact analysis as shown in below figure
 Fig2.13 Requirements traceability in Software Engineering

Characteristics of quality traceability

Any type of traceability is better than no traceability. However, there's a broad spectrum here, with some companies leveraging
standards spreadsheets as tracing matrices while others opt for third-party solutions. Despite this variation, there are several
characteristics that describe quality traceability solutions:
 Origin Points — Who proposed specific requirements? When were they implemented? Tying current requirements back
to their origin points provides the framework for critical cross-linking and references.
 Key Associations — How are requirements interrelated? How does changing or adding code impact overall software
functionality? Quality traceability details any dependent associations between existing requirements and ensures new
requirements are similarly detailed.
 Forward and Back — In practice, this means that existing requirements tie back to preceding requirements, effectively
creating a "chain" to origin points, while also ensuring previous requirements "fall forward" to describe next-in-line
requirements.
 Technical Specificity — In addition to basic descriptions, quality traceability solutions must include connections to
relevant code sections, their location, and any critical testing performed.
 Auditability — Ultimately, traceability must provide assurances that stakeholder expectations have been met and that no
unspecified features have been added to (current) end results.
Fig 2.14 requirement ,design ,code