Professional Documents
Culture Documents
FSD Unit-2
FSD Unit-2
REQUIREMENTS ANALYSIS
After requirements gathering is completed the analyst analyzes the gathered requirements to clearly
understand the exact customer requirements.
IEEE defines requirement analysis as
[1] The process of studying user needs to arrive at a definition of system, hardware or software
requirements.
[2] The process of studying and refining system, hardware or software requirements.
The main purpose of the requirement analysis activity is to analyze the collected information to obtain a clear
understanding of the product to be developed, with a view to removing all ambiguities, incompleteness and
inconsistencies.
The following basic questions should be clearly understood by the analyst:
✓ What is the problem?
✓ Why is it important to solve the problem?
✓ What are the possible solutions to the problem?
✓ What exactly are the data input to the system and what exactly are the data output by the system?
✓ What are the complexities that might arise while solving the problem?
✓ If there are external software or hardware with which the developed software has to interface, then
what exactly would the data interchange formats with the external system be?
When the analyst detects any inconsistencies, anomalies or incompleteness in the gathered requirements,
he resolves them by carrying out further discussions with the customers.
Benefits of SRS
1. SRS provides foundation for design work because it works as a input to the design phase.
2. It enhances communication between customer and developer.
3. Developers can get the idea what exactly the customer’s want.
4. It enables project planning and helps in verification and validation process.
5. High quality SRS reduces the development cost and time efforts.
6. As it is working as an agreement between user and developer, we can get the partial satisfaction of the end
user for the final product.
7. SRS is also useful during the maintenance phase.
REQUIREMENTS SPECIFICATION TYPES
Requirement specification activity is translating the gathered information during the analysis phase into a
document that defines a set of requirements. Two types of requirements may be included in this document:
1. Customer Requirement
2. System Requirement
✓ System Requirements are further classified into more two types.
i. Functional requirements
ii. Nonfunctional requirements
Functional Requirements
The functional requirements discuss the functionalities expected from the system. These are statements
of services that provide how the system should react to particular inputs and how the system should behave
in particular situation. It describes the relationship between input and output. It also state what the system
should do if any situation occurs.
The system is considered to perform a set of high level functions. Each function of the system can be
considered as a transformation of set of input data to the corresponding set of output data. The user can get
some meaningful pieces of work done using a high level function.
Display ac-
count type
options
Enter option
Prompt for
amount to be
withdrawn
Enter amount
Document the functional requirements of a system it is necessary to first learn to identify the high level function
of the system.
The high level function would be split into smaller sub requirement.
A high level function is one using which the user can get some useful piece of work done.
For example, the receipt printing work during withdrawal of money from an ATM is called a useful
piece of work? Receipt printing should not be considered a high-level requirement, because the user does not
specifically request for this activity. The receipt gets printed automatically as part of the withdraw money
function.
In a library automation software a high level functional requirement might be search-book. This function
involves accepting a book name or a set of keywords from the user running a matching algorithm on the
book list and finally outputting the matched books. The generated system response can be in several form e.g.
display on the terminal, a print out or transferred to the other system.
High level function usually involves a series of interactions between the system and one or more users.
For example as shown in figure user inputs have been represented by rectangles and the response produced by
the system by circles.
In figure the different scenarios occur depending on the amount entered for withdrawal. Different behavior
for different scenarios of the system for the same high level functions.
Nonfunctional requirements
Nonfunctional requirements deal with the characteristics of the system which cannot be expressed as functions -
such as the maintainability of the system, portability of the system, usability of the system, maximum number
of current users etc.
Nonfunctional requirements may include:
✓ reliability issues
✓ accuracy of results
✓ Constraints on the system implementation, etc.
Example of a non functional requirement can be that the user interface of software should be usable by factory
shop floor worker who may not even have a high school degree.
DESIGN PROCESS
The design process is a sequence of steps that enable the designer to describe all aspects of the software to
be built. It describes how the system will be implemented and how it will work.
Software design deals with transforming the customer requirements, as described in the SRS document,
into appropriate form that is suitable for implementation in a programming language.
The activities in the design process vary depending on the type of system being developed. The below
figure suggest that the stage of the design process are sequential. Design process can be classified as:
Architectural design, where you identify the overall structure of the system, the principal components
(sometimes called sub-systems or modules), and their relationships and how they are distributed. It can be
derived from DFD.
Interface design, where you define the interfaces between system components. It describes how system
communicate itself and with the user. It can be derived from DFD and state transition diagram.
Component design, where you take each system component and design how it will operate. This is defined
the expected functionality to be implemented. It can be derived from state transition diagram.
Database design, where you design the system data structures and how these are to be represented in a
database. The data objects and relationships defined in the ER diagram and the detailed data content
illustrated in the data dictionary. It can be derived from ER diagram.
CLASSIFICATION OF DESIGN METHODOLOGIES
A design methodology can be simply defined as a set of design procedure that one follows from the beginning
to the completion of the software development process.
The nature of the methodology is dependent on a number of factors including type of the software being
developed, requirements of the users, qualification and training of software development team, available
hardware and software resources.
There are fundamentally two different approaches:
1. Function oriented design: it can be further divided in two category
I. Structured Analysis
II. Structured Design
2. Object oriented design
COHESION
Cohesion means the measure of the strength of function relatedness of elements within a module.
Elements include instructions, groups of instructions, data definition, and call of another module.
Cohesion means how closely the elements of a module are related to each other.
It represents how tightly bound the internal elements of the module are to one another.
Coincidental cohesion
It is the lowest cohesion. A module is said to have coincidental cohesion, if it performs a set of tasks that relate
to each other very loosely. Means the module contains a random collection of functions.
For example, in a transaction processing system (TPS), the get-input, print-error, and summarize- members
functions are grouped into one module. The grouping does not have any relevance to the structure of the
problem.
Logical cohesion
A module is said to be logically cohesive, if all elements of the module perform similar operations.
An example of logical cohesion is the case where a set of print functions generating different output reports
are arranged into a single module.
Temporal cohesion
When a module contains functions that are related by the fact that all the functions must be executed in the
same time span, the module is said to temporal cohesion.
The set of functions for start-up, shutdown of some process, etc. exhibit temporal cohesion.
Procedural cohesion
A module is said to possess procedural cohesion, if the set of functions of the module are all part of a procedure
(algorithm) in which certain sequence of steps have to be carried out for achieving an objective, e.g. the
algorithm for decoding a message.
Communicational cohesion
A module is said to have communicational cohesion, if all functions of the module refer to or update the same
data structure, e.g. the set of functions defined on an array or a stack.
Sequential cohesion
A module is said to possess sequential cohesion, if the elements of a module form the parts of sequence,
where the output from one element of the sequence is input to the next.
For example, in a TPS, the get-input, validate-input, sort-input functions are grouped into one module.
Functional cohesion
It is the strongest cohesion.
Functional cohesion is said to exist, if all the elements of a module are related to perform a single task.
All the elements are achieving a single goal of a module.
For example, sort the array are examples of these module.
COUPLING
Coupling between two modules is a measure of the degree of interdependence or interaction between the two
modules.
It refers to the strengths of relationship between modules in a system. It indicates how closely two modules
interact and how they are independent.
As modules become more independent the coupling increases and loose coupling minimize
interdependency that is better for any system development.
If two modules interchange large amount of data then they are highly interdependent.
High coupling between modules make the system difficult to understand and increase the development
efforts. So low coupling is the best.
Data coupling
Two modules are data coupled, if they communicate through a parameter. An example is an elementary
data item passed as a parameter between two modules, e.g. an integer, a float, a character, etc.
It is lowest coupling and best for the software development.
Stamp coupling
Two modules are stamp coupled, if they communicate using a composite data item such as a record in PASCAL
or a structure in C.
Control coupling
Control coupling exists between two modules, if data from one module is used to direct the order of
instructions execution in another.
An example of control coupling is a flag set in one module and tested in another module.
Common coupling
Two modules are common coupled, if they share data through some global data items.
Content coupling
Content coupling exists between two modules, if they share code. That is a jump from one module into the code
of another module can occur. E.g. a branch from one module into another module.
DATA MODELING CONCEPTS
ER diagram represent a set of real-world entities and the logical relationships among them. This diagram
depicts entities, the relationships between them, and the attributes pictorially in order to provide a high-
level description of conceptual data models.
Once an ER diagram is created, the information represented by it is stored in the database. The
information depicted in an ER diagram is independent of the type of database and can later be used to create
database of any kind such as relational database, network database, or hierarchical database.
ER diagram includes data objects and entities, data attributes, relationships, cardinality and modality.
Data object
A data object is a real world entity or things.
Data object is a representation of composite information used by software.
Composite information refers to different features or attributes of a data object and this object can be in any of
the following forms: External entity, Event or Place etc.
An entity is the data that stores information about the system in a database. Examples of an entity is student,
department etc.
Data attributes
Data attributes describe the properties or characteristics of a data object.
Attributes that identify entities are known as key attributes. On the other hand, attributes that describe
an entity are known as non-key attributes.
Data attribute is used to perform the following functions: Naming an instance of data object, Description
of the instance, making reference to another instance in another table.
For example, attributes of 'account' entity are 'number', 'balance', and so on.
Similarly, attributes of 'user' entity are 'name', 'address', and 'age'.
Entities are represented by rectangles, attributes are represented by ellipses, and relationships are represented
by diamond symbols. A key attribute is also depicted by an ellipse but with a line below it.
Relationships
Entities are linked to each other in different ways. This link or connection of data objects or entities with
each other is known as relationship. Note that there should be at least two entities to establish a relationship
between them.
Once the entities are identified, the development team checks whether a relationship exists between them.
Relationship is represented using diamond shape symbol with joined relationship name.
Cardinality
Cardinality specifies the number of occurrences (instances) of one data object or entity that relates to the
number of occurrence of another data object or entity. It also specifies the number of entities that are included
in a relationship.
Different cardinalities are explained below:
✓ One-to-one (1:1): Indicates that one instance of an entity is related only to one instance of another entity. For
example, in a bank, each user is related to only one account number.
✓ One-to-many (1: M): Indicates that one instance of an entity is related to several instances of another
entity. For example, one user can have many accounts in different banks.
✓ Many-to-many (M: M): Indicates that many instances of entities are related to several instances of another
entity. For example, many users can have their accounts in many banks.
Modality
• Modality describes the possibility whether a relationship between two or more entities and data objects is
required. The modality of a relationship is 0 if the relationship is optional. However, the modality is 1 if an
occurrence of the relationship is essential.
• For example, Customer entity is related to order entity. Here, cardinality for 'customer' entity indicates that the
customer places an order whereas modality for 'customer' entity indicates that it is necessary for a customer to
place an order.
Cardinality for 'order' indicates that a single user can place many orders whereas modality for 'order' entity
indicates that a user can arrive without any 'order'.
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.
PRIMITIVE SYMBOLS OF DFD
A DFD model uses a very limited number of primitive symbols as shown in figure to represent the
functions performed by a system and the data flow among these functions.
External entity: The external entities are those physical entities external to the software system which interact
with the system by inputting data to the system or by consuming the data produce by the system. External
entity is represented by a rectangle. For example librarian, library member.
Name Description
Actor Actors are different kinds of users who use the system in various ways. For example,
one actor can be a library user whereas another user can be part of the library staff.
Use-case Describes a specific instance of a system function.
Relationship Actor are connected to the use case with which they interact by a line which represent a
relationship between the actors and the use case.
Association Indicates the interaction between the actor and the system.
Include Relationship It involves one use case including the behavior of another use case.
Extend Relationship It allows you to show optional behavior of the system.
Customer (actor) uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw cash and
transfer funds (use cases). ATM Technician provides maintenance and repairs. All these use cases also involve
Bank actor whether it is related to customer transactions or to the ATM servicing.
Generalization
Use case generalization can be used when one use case that is similar to another, but does something slightly
differently or something more.
The child use case inherits the behavior and meaning of the parent use case.
The notation for generalization is as shown in figure.
Pay membership
fee
Includes
The includes relationship involves one use case including the behavior of another use case.
The includes relationship occurs when a part of behavior that is similar across a number of use cases.
The factoring of such behavior will help in not repeating the specification and implementation across different
use cases.
It is represented using a predefined stereotype <<include>>.
Deposit <<include>>
Funds
Customer
Authentication
Withdraw
cash <<include>>
ACTIVITY DIAGRAM
An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity
to activity. An activity represents an operation on some class in the system that results in a change in the
state of the system.
Typically, activity diagrams are used to model workflow or business processes and internal operation.
.
Example – Activity Diagram for ATM process-