Software Engineering

Unit-III

Mrs. Amandeep Kaur

Assistant Professor
Gujarat University
Software Requirement Specifications
The production of the requirements stage of the software development
process is Software Requirements Specifications (SRS) (also called
a requirements document).
The SRS is a specification for a specific software product, program, or set
of applications that perform particular functions in a specific environment.
First, The SRS could be written by the client of a system.
Second, the SRS could be written by a developer of the system.
The two methods create entirely various situations and establish different
purposes for the document altogether.
The first case, SRS, is used to define the needs and expectation of the
users.
The second case, SRS, is written for various purposes and serves as a
contract document between customer and developer.
Characteristics of Good SRS
Features of a good SRS document
 Correctness: User review is used to provide the accuracy of
requirements stated in the SRS. SRS is said to be perfect if it covers all
the needs that are truly expected from the system.
 Completeness: The SRS is complete if, and only if, it includes the
following elements:
1) All essential requirements, whether relating to functionality, performance,
design, constraints, attributes, or external interfaces.
2) Definition of their responses of the software to all realizable classes of
input data in all available categories of situations.
3) Full labels and references to all figures, tables, and diagrams in the SRS
and definitions of all terms and units of measure.
Features of a good SRS document
Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible
conflict in the SRS:
1) The specified characteristics of real-world objects may conflicts. For
example,
a) The format of an output report may be described in one requirement as
tabular but in another as textual.
b) One condition may state that all lights shall be green while another states
that all lights shall be blue.
Features of a good SRS document
2) There may be a reasonable or temporal conflict between the two
specified actions.
a) One requirement may determine that the program will add two inputs, and
another may determine that the program will multiply them.
b) One condition may state that "A" must always follow "B," while other
requires that "A and B" co-occurs.
3) Two or more requirements may define the same real-world object but use
different terms for that object. For example, a program's request for user
input may be called a "prompt" in one requirement's and a "cue" in another.
The use of standard terminology and descriptions promotes consistency.
Features of a good SRS document
Unambiguousness: SRS is unambiguous when every fixed requirement
has only one interpretation. This suggests that each element is uniquely
interpreted. In case there is a method used with multiple definitions, the
requirements report should determine the implications in the SRS so that it
is clear and simple to understand.
Ranking for importance and stability: The SRS is ranked for importance
and stability if each requirement in it has an identifier to indicate either the
significance or stability of that particular requirement.
Typically, all requirements are not equally important. Some prerequisites
may be essential, especially for life-critical applications, while others may be
desirable. Each element should be identified to make these differences clear
and explicit. Another way to rank requirements is to distinguish classes of
items as essential, conditional, and optional.
Features of a good SRS document
Modifiability: SRS should be made as modifiable as likely and should be
capable of quickly obtain changes to the system to some extent.
Modifications should be perfectly indexed and cross-referenced.
Verifiability: SRS is correct when the specified requirements can be
verified with a cost-effective system to check whether the final software
meets those requirements. The requirements are verified with the help of
reviews.
Features of a good SRS document
Traceability: The SRS is traceable if the origin of each of the
requirements is clear and if it facilitates the referencing of each condition in
future development or enhancement documentation.
There are two types of Traceability:
1. Backward Traceability: This depends upon each requirement explicitly
referencing its source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS
having a unique name or reference number.
The forward traceability of the SRS is especially crucial when the software
product enters the operation and maintenance phase. As code and design
document is modified, it is necessary to be able to ascertain the complete
set of requirements that may be concerned by those modifications.
Features of a good SRS document
Design Independence: There should be an option to select from multiple
design alternatives for the final system. More specifically, the SRS should
not contain any implementation details.
Testability: An SRS should be written in such a method that it is simple to
generate test cases and test plans from the report.
Understandable by the customer: An end user may be an expert in
his/her explicit domain but might not be trained in computer science.
Hence, the purpose of formal notations and symbols should be avoided
too as much extent as possible. The language should be kept simple and
clear.
The right level of abstraction: If the SRS is written for the requirements
stage, the details should be explained explicitly. Where as, for a feasibility
study, fewer analysis can be used. Hence, the level of abstraction modifies
according to the objective of the SRS.
 Properties of a good SRS document
Concise: The SRS report should be concise and at the same time,
unambiguous, consistent, and complete. Verbose and irrelevant descriptions
decrease readability and also increase error possibilities.
Structured: It should be well-structured. A well-structured document is simple
to understand and modify. In practice, the SRS document undergoes several
revisions to cope up with the user requirements. Often, user requirements
evolve over a period of time. Therefore, to make the modifications to the SRS
document easy, it is vital to make the report well-structured.
Black-box view: It should only define what the system should do and refrain
from stating how to do these. This means that the SRS document should
define the external behavior of the system and not discuss the implementation
issues. The SRS report should view the system to be developed as a black
box and should define the externally visible behavior of the system. For this
reason, the SRS report is also known as the black-box specification of a
system.
Properties of a good SRS document
Conceptual integrity: It should show conceptual integrity so that the
reader can merely understand it. Response to undesired events: It should
characterize acceptable responses to unwanted events. These are called
system response to exceptional conditions.
Verifiable: All requirements of the system, as documented in the SRS
document, should be correct. This means that it should be possible to
decide whether or not requirements have been met in an implementation.
Requirements Analysis
Requirement analysis is significant and essential activity after elicitation.
 We analyze, refine, and scrutinize the gathered requirements to make
consistent and unambiguous requirements.
This activity reviews all requirements and may provide a graphical view of
the entire system.
After the completion of the analysis, it is expected that the
understandability of the project may improve significantly.
 Here, we may also use the interaction with the customer to clarify points
of confusion and to understand which requirements are more important
than others.
Steps of requirement analysis
Steps of requirement analysis
• Draw the context diagram: The context diagram is a simple model that
defines the boundaries and interfaces of the proposed systems with the
external world. It identifies the entities outside the proposed system that
interact with the system. The context diagram of student result
management system is given below:
 Steps of requirement analysis
Development of a Prototype (optional): One effective way to find out what the
customer wants is to construct a prototype, something that looks and preferably acts
as part of the system they say they want.
We can use their feedback to modify the prototype until the customer is satisfied
continuously. Hence, the prototype helps the client to visualize the proposed system
and increase the understanding of the requirements. When developers and users
are not sure about some of the elements, a prototype may help both the parties to
take a final decision.
Some projects are developed for the general market. In such cases, the prototype
should be shown to some representative sample of the population of potential
purchasers. Even though a person who tries out a prototype may not buy the final
system, but their feedback may allow us to make the product more attractive to
others.
The prototype should be built quickly and at a relatively low cost. Hence it will
always have limitations and would not be acceptable in the final system. This is an
optional activity.
Steps of requirement analysis
• Model the requirements: This process usually consists of various
graphical representations of the functions, data entities, external entities,
and the relationships between them. The graphical view may help to find
incorrect, inconsistent, missing, and superfluous requirements. Such
models include the Data Flow diagram, Entity-Relationship diagram, Data
Dictionaries, State-transition diagrams, etc.
• Finalise the requirements: After modeling the requirements, we will have
a better understanding of the system behavior. The inconsistencies and
ambiguities have been identified and corrected. The flow of data amongst
various modules has been analyzed. Elicitation and analyze activities have
provided better insight into the system. Now we finalize the analyzed
requirements, and the next step is to document these requirements in a
prescribed format.
 Data Flow Diagram (DFD)
• A data flow diagram is a visual representation of the flow of information for a
process or a system.
• It is a mirror image of the whole system or a plant.
• The data flow diagram helps the engineers and plant workers to plan the work
efficiently by picturizing the entire system.
• Creating a data flow diagram is a good practice adopted by almost all
manufacturers, industries, software houses, and other institutions.
• It can be used as a tool for communication between a system analyst and everyone
involved in the order that serves as a beginning point for system change.
• The goal is to demonstrate the breadth and bounds of a system as a whole.
Data Flow Diagram (DFD)
Components of DFD
Process: A circle is a process in data flow diagrams and depicts how the
data is handled and processed in the system.
Data Flow: The data flow is the curved line that shows the flow of data in
or out of the system.
Data Store: A data store denotes the storage of information that can be
retrieved later or by other processes in a different order. A single element
or a set of elements can be found in the data storage. The group of parallel
lines denotes a location to collect the data items.
Entity: An external entity that serves as a source of system inputs or a
sink of system outputs is called a source or sink.
Levels of Data Flow Diagrams
Level 0 DFDs: The level 0 data flow diagrams are the most basic, and
they do not provide every little detail of the information or the structure;
instead, it gives a broad view that can easily be understood. These
diagrams are straightforward and show single process nodes and
connections of those nodes with externalities.
Level 1 DFDs: The level 1 data flow diagrams provide more information
than the Level 0 DFDs. It shows the general overview of the system. The
single process node from the level 0 diagram is split into subprocesses in
a level 1 data flow diagram. Additional data flows and data stores will be
required as these processes are added to the diagram.
Level 2 DFDs: The level 2 data flow diagrams are way too detailed, where
processes from Level 1 DFDs are further broken down into more chunks.
The objective is to create a map of every little detail of the system to help
the engineers to understand and work on it.
Data Flow Diagram Examples
• Example 1: DFD Login
In this type of data flow diagram, the
whole process of the login system is
picturized.
It is intended to be a quick overview of
password update, authentication, and
login, presenting the system as a
single high-level process with
externalities such as username,
password, and register.
Data Flow Diagram Examples
Example 2: Data Flow Diagram for
Library Management System
The data flow diagram for the library
management system displays more
pertinent information about library
employees and how they interact
with the library management system
internally, such as adding or
removing information, authenticating
students, issuing and returning
books, etc. This type of diagram
identifies and clarifies the software
system's boundaries.
Data Dictionaries
A data dictionary is a file or a set of files that includes a database's metadata.
The data dictionary hold records about other objects in the database, such as
data ownership, data relationships to other objects, and other data. The data
dictionary is an essential component of any relational database. Ironically,
because of its importance, it is invisible to most database users. Typically, only
database administrators interact with the data dictionary.
The data dictionary, in general, includes information about the following:
• Name of the data item
• Aliases
• Description/purpose
• Related data items
• Range of values
• Data structure definition/Forms
Data Dictionaries
The name of the data item is self-explanatory.
Aliases include other names by which this data item is called DEO for
Data Entry Operator and DR for Deputy Registrar.
Description/purpose is a textual description of what the data item is used
for or why it exists.
Related data items capture relationships between data items e.g., total_
marks must always equal to internal_marks plus external_marks.
Range of values records all possible values, e.g. total marks must be
positive and between 0 to 100.
Data structure Forms: Data flows capture the name of processes that
generate or receive the data items. If the data item is primitive, then data
structure form captures the physical structures of the data item. If the data
is itself a data aggregate, then data structure form capture the composition
of the data items in terms of other data items.
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 software in Software
Engineering
Used for finding data items from a description in Software
Engineering
Importance of Data Dictionary
It provides developers with standard terminology for all data.
It provides developers to use different terms to refer to the
same data.
It provides definitions for different data
Query handling is facilitated if a data dictionary is used in
RDMS.
Advantages of Data Dictionary
Consistency and Standardization: A data dictionary helps to ensure that
all data elements and attributes are consistently defined and named
across the organization, promoting standardization and consistency in
data management practices.
Data Quality: A data dictionary can help improve data quality by providing
a single source of truth for data definitions, allowing users to easily verify
the accuracy and completeness of data.
Data Integration: A data dictionary can facilitate data integration efforts by
providing a common language and framework for understanding data
elements and their relationships across different systems.
Advantages of Data Dictionary
Improved Collaboration: A data dictionary can help promote
collaboration between business and technical teams by providing a shared
understanding of data definitions and structures, reducing
misunderstandings and communication gaps.
Improved Efficiency: A data dictionary can help improve efficiency by
reducing the time and effort required to define, document, and manage
data elements and attributes.
Disadvantages of Data Dictionary
• Implementation and Maintenance Costs: Implementing and maintaining
a data dictionary can be costly, requiring significant resources in terms of
time, money, and personnel.
• Complexity: A data dictionary can be complex and difficult to manage,
particularly in large organizations with multiple systems and data sources.
• Resistance to Change: Some stakeholders may be resistant to using a
data dictionary, either due to a lack of understanding or because they
prefer to use their own terminology or definitions.
• Data Security: A data dictionary can contain sensitive information, and
therefore, proper security measures must be in place to ensure that
unauthorized users do not access or modify the data.
• Data Governance: A data dictionary requires strong data governance
practices to ensure that data elements and attributes are managed
effectively and consistently across the organization.
Functional Requirements
Functional requirements define a function that a system or system element
must be qualified to perform and must be documented in different forms.
The functional requirements describe the behavior of the system as it
correlates to the system's functionality.
Functional requirements should be written in a simple language, so that it
is easily understandable. The examples of functional requirements are
authentication, business rules, audit tracking, certification requirements,
transaction corrections, etc.
These requirements allow us to verify whether the application provides all
functionalities mentioned in the application's functional requirements. They
support tasks, activities, user goals for easier project management.
There are a number of ways to prepare functional requirements. The most
common way is that they are documented in the text form. Other formats
of preparing the functional requirements are use cases, models,
prototypes, user stories, and diagrams.
Non-functional requirements
Non-functional requirements are not related to the software's
functional aspect. They can be the necessities that specify the
criteria that can be used to decide the operation instead of specific
behaviors of the system. Basic non-functional requirements are -
usability, reliability, security, storage, cost, flexibility, configuration,
performance, legal or regulatory requirements, etc.
They are divided into two main categories:
Execution qualities like security and usability, which are
observable at run time.
Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software
system.
Non-functional requirements
• Non-functional requirements specify the software's quality
attribute. These requirements define the general characteristics,
behavior of the system, and features that affect the experience
of the user. They ensure a better user experience, minimizes
the cost factor. Non-functional requirements ensure that the
software system must follow the legal and adherence rules. The
impact of the non-functional requirements is not on the
functionality of the system, but they impact how it will perform.
For a well-performing product, atleast some of the non-
functional requirements should be met.
 Functional Requirements v/s
Non-functional requirements
Functional Requirements Non-functional requirements
Functional requirements help to They help to understand the system's
understand the functions of the system. performance.
Functional requirements are mandatory. While non-functional requirements are
not mandatory.
They are easy to define. They are hard to define.
They describe what the product does. They describe the working of product.
It concentrates on the user's It concentrates on the expectation and
requirement. experience of the user.
It helps us to verify the software's It helps us to verify the software's
functionality. performance.
 Functional Requirements v/s
Non-functional requirements
Functional Requirements Non-functional requirements
These requirements are specified by the user. These requirements are specified by the
software developers, architects, and technical
persons.
There is functional testing such as API testing, There is non-functional testing such as
system, integration, etc. usability, performance, stress, security, etc.
Examples of the functional requirements are- Examples of the non-functional requirements
Authentication of a user on trying to log in to are -The background color of the screens
the system. should be light blue.
These requirements are important to system These are not always the important
operation. requirements, they may be desirable.
Completion of Functional requirements allows While system will not work only with non-
the system to perform, irrespective of meeting functional requirements.
the non-functional requirements.
 Cohesion
It is a measure of degree to which the elements of the module are functionally
similar. A degree to which all elements directed towards performing a single task
are stored in the component. It is the internal glue that keeps the module together.
A software design will have high of cohesion.
Types of Cohesion:
 Functional Cohesion: Each required element for a single computation is stored
in the component. It performs the task and functions. It is an ideal situation.
Example : read transaction record, cosine angle computation, seat assignment to
an airline passenger etc.
Sequential Cohesion: An element results some data that becomes the input for
other element, i.e., data flow between the parts. It occurs naturally in programming
languages. Example: cross validate record and formatting of module, raw records
usage, formatting of raw records, cross validation of fields in raw records.
Cohesion
Communicational Cohesion: Two elements operate on the same input
data or distribute towards the same output data. Example- modify record
into the database and send it to the printer.
Procedural Cohesion: It ensure the order of execution. Actions are still
connected and unlikely to be reusable. Ex- calculate student GPA, print
student record. Example : read, write, edit of the module, record use out,
writing out the record, reading the record, zero etc.
Temporal Cohesion: The elements are similar by their timing involved. It
is connected with all the tasks must be executed in the same time-span. It
contains the code for initializing the parts of the system. Example: A
function is called after catching an exception which closes open files,
creates an error log.
Cohesion
Logical Cohesion: All elements are logically similar and not functionally.
Ex- It reads inputs from tape, disk, and network. The code for these
functions is in the same component. They are similar, but the functions are
different. Example: a group of print functions generating different output
reports are arranged into a single module.
Coincidental Cohesion: The elements are not related. The elements
have no abstract relationship other than location in source code. It is the
worst form of cohesion. Ex- print next line and reverse the characters of a
string in a single component, a “Utilities” class.
Coupling
Types of Coupling:
Data Coupling: Tthe dependence between the modules is based on the
strategy that they interact by passing only data, then the modules are said
to be data coupled. In data coupling, the components are freely to each
other and communicating through data. Module communications don’t
contain tramp data. Example-customer billing system. Example : illustrated
as a module which retrieves customer address using customer id.
Stamp Coupling: In this, the complete data structure is passed from one
module to another module. It involves tramp data. It may be mandatory
due to efficiency factors- this choice made by the insightful designer, not a
lazy programmer.
Coupling
Control Coupling: If the modules meet by passing control information,
then they are to be control coupled. It can be worst parameters showed
completely different behavior and good if parameters allow factoring and
reuse of functionality. Example- sort function that takes comparison
function as an argument. Example : a control flag, a comparison function
passed to a sort algorithm.
External Coupling: The modules depend on another module, outside to
the software being establish or to a particular type of hardware. Ex-
protocol, external file, device format, etc.
Coupling
Common Coupling: The modules have shared data such as global data
structures. The changes in data mean tracing back to all modules which
access that data to evaluate the effect of the change. Disadvantages are
likely to difficult in reusing modules, reduced ability to control data
accesses. Example : global information status regarding an operation, with
the multiple modules reading and writing to that location.
Content Coupling: In this ,module can modify the data of another module
or control flow is passed from one module to the other module. This is the
bad form of coupling and should avoided.
 Cohesion v/s Coupling
Cohesion Coupling
It is the concept of intra module. It is the concept of inter module.
It represents the relationship within It represents the relationships between
module. modules.
Increasing in cohesion is good for Increasing in coupling is avoided for
software. software.
It represents the functional strength of It represents the independence among
modules. modules.
Highly cohesive gives the best software. Loosely coupling gives the best
software.
Function Oriented Design
The design process for software systems often has two levels. At the
first level, the focus is on deciding which modules are needed for the
system based on SRS (Software Requirement Specification) and
how the modules should be interconnected.
Function Oriented Design is an approach to software design where
the design is decomposed into a set of interacting units where each
unit has a clearly defined function.
Generic Procedure
Start with a high-level description of what the software/program
does. Refine each part of the description by specifying in greater
detail the functionality of each part. These points lead to a Top-Down
Structure.
Top-Down Design Method
• Problem in Top-Down Design Solution to the Problem
Method Designing of reusable module. It
• Mostly each module is used by means modules use several
at most one other module and modules to do their required
that module is called its Parent functions.
module.
Function Oriented Design Strategies
1.Data Flow Diagram (DFD): A data flow diagram (DFD) maps
out the flow of information for any process or system. It uses
defined symbols like rectangles, circles and arrows, plus short
text labels, to show data inputs, outputs, storage points and the
routes between each destination.
2.Data Dictionaries: Data dictionaries are simply repositories to
store information about all data items defined in DFDs. At the
requirement stage, data dictionaries contains data items. Data
dictionaries include Name of the item, Aliases (Other names for
items), Description / purpose, Related data items, Range of
values, Data structure definition / form.
Function Oriented Design Strategies
3.Structure Charts: Structure chart is the hierarchical
representation of system which partitions the system into black
boxes (functionality is known to users, but inner details are
unknown). Components are read from top to bottom and left to
right. When a module calls another, it views the called module
as a black box, passing required parameters and receiving
results.
4.Pseudo Code: Pseudo Code is system description in short
English like phrases describing the function. It uses keyword
and indentation. Pseudocodes are used as replacement for flow
charts. It decreases the amount of documentation required.
 Structure Charts
• For a function-oriented design, the design can be represented graphically by
structure charts. The structure of a program is made up of the modules of that
program together with the modules of that program together with the
interconnections between modules. The structure chart of a program is a graphic
representation of its structure.
1.In a structure chart a module is represented by a box with the module name written
in the box.
2.In general, procedural information is not represented in a structure chart, and the
focus is on representing the hierarchy of modules.
3.However, there are situations where the designer may wish to communicate certain
procedural information explicitly, like major loop and decisions.
 Structure Charts
4.Such information can also be represented in a structure chart.
5.Modules in a system can be categorized into few classes as below:
6.Input module: There are some modules that obtain information from their
subordinates and then pass it to their superordinate.
7.Output module: Module which take information from their superordinate and
pass it on to its subordinates.
8.Transform module: Modules that exist solely for the sake of transforming data
into some other form.
9.Coordinate module: Modules whose primary concern is managing the flow of
data to and from different subordinates.
10.A structure chart is a nice representation for a design that uses functional
abstraction.