LECTURE III

 OBJECTIVES
 Gain knowledge of requirement analysis
REQUIREMENTS ANALYSIS AND SPECIFICATION

 Before we start to develop our software, it becomes quite essential for

us to understand and document the exact requirement of the customer.
Experienced members of the development team carry out this job. They
are called as system analysts.
 The analyst starts requirements gathering and analysis activity by
collecting all information from the customer which could be used to
develop the requirements of the system. He then analyzes the collected
information to obtain a clear and thorough understanding of the product
to be developed, with a view to remove all ambiguities and
inconsistencies from the initial customer perception of the problem. The
following basic questions pertaining to the project should be clearly
understood by the analyst in order to obtain a good grasp of the
problem:
 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 likely 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?
 After the analyst has understood the exact customer requirements, he
proceeds to identify and resolve the various requirements problems. The
most important requirements problems that the analyst has to identify
and eliminate are the problems of anomalies, inconsistencies, and
incompleteness. When the analyst detects any inconsistencies,
anomalies or incompleteness in the gathered requirements, he resolves
them by carrying out further discussions with the endusers and the
customers.

 Parts of a Software Requirement Specification (SRS) document

 The important parts of SRS document are:

 Functional requirements of the system

 Non-functional requirements of the system, and
 Goals of implementation
Functional requirements:-

 Functional requirements:-
 The functional requirements part discusses the functionalities required
from the system. The system is considered to perform a set of high-level
functions {f }. The functional view of the i system is shown in fig. 5.1.
Each function f of the system can be considered as a transformation i
 of a set of input data (ii) to the corresponding set of output data (o ). The
user can get some i meaningful piece of work done using a high-level
function.
View of system performing set of 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, etc.
 Goals of implementation:-

 The goals of implementation part documents some general suggestions

regarding development. These suggestions guide trade-off among
design goals. The goals of implementation section might document
issues such as revisions to the system functionalities that may be
required in the future, new devices to be supported in the future,
reusability issues, etc. These are the items which the developers might
keep in their mind during development so that the developed system
may meet some aspects that are not required immediately.
 Identifying functional requirements from a problem description

 The high-level functional requirements often need to be identified either

from an informal problem description document or from a conceptual
understanding of the problem. Each highlevel requirement characterizes
a way of system usage by some user to perform some meaningful piece
of work. There can be many types of users of a system and their
requirements from the system may be very different. So, it is often
useful to identify the different types of users who might use the system
and then try to identify the requirements from each user’s perspective.
 Example: - Consider the case of the library system, where –

 F1: Search Book function

 Input: an author’s name

 Output: details of the author’s books and the location of these books in
the library

 So the function Search Book (F1) takes the author's name and transforms
it into book details.
 Functional requirements actually describe a set of high-level
requirements, where each high-level requirement takes some data from
the user and provides some data to the user as an output. Also each high-
level requirement might consist of several other functions.
 Documenting functional requirements

 For documenting the functional requirements, we need to specify the set
of functionalities supported by the system. A function can be specified
by identifying the state at which the data is to be input to the system,
its input data domain, the output data domain, and the type of
processing to be carried on the input data to obtain the output data. Let
us first try to document the withdraw-cash function of an ATM
(Automated Teller Machine) system. The withdraw-cash is a high-level
requirement. It has several sub-requirements corresponding to the
different user interactions. These different interaction sequences
capture the different scenarios.
 Example: - Withdraw Cash from ATM
 R1: withdraw cash
 Description: The withdraw cash function first determines the type of
account that the user has and the account number from which the user
wishes to withdraw cash. It checks the balance to determine whether
the requested amount is available in the account. If enough balance is
available, it outputs the required cash; otherwise it generates an error
message.
 R1.1 select withdraw amount option
 Input: “withdraw amount” option
 Output: user prompted to enter the account type

 R1.2: select account type
 Input: user option
 Output: prompt to enter amount
 R1.3: get required amount
 Input: amount to be withdrawn in integer values greater than 100 and
less than 10,000 in multiples of 100.
 Output: The requested cash and printed transaction statement.
 Processing: the amount is debited from the user’s account if sufficient
balance is available, otherwise an error message displayed
Properties of a good SRS
document
 The important properties of a good SRS document are the following:
 Concise. The SRS document should be concise and at the same time
unambiguous, consistent, and complete. Verbose and irrelevant
descriptions reduce readability and also increase error possibilities.

 Structured. It should be well-structured. A well-structured document is
easy to understand and modify. In practice, the SRS document
undergoes several revisions to cope up with the customer requirements.
Often, the customer requirements evolve over a period of time.
Therefore, in order to make the modifications to the SRS document easy,
it is important to make the document well-structured.
 Black-box view. It should only specify what the system should do and
refrain from stating how to do these. This means that the SRS document
should specify the external behavior of the system and not discuss the
implementation issues. The SRS document should view the system to be
developed as black box, and should specify the externally visible
behavior of the system. For this reason, the SRS document is also called
the black-box specification of a system.
 Conceptual integrity. It should show conceptual integrity so that the
reader can easily understand it.
 Response to undesired events. It should characterize acceptable
responses to undesired events. These are called system response to
exceptional conditions.
 Verifiable. All requirements of the system as documented in the SRS
document should be verifiable. This means that it should be possible to
determine whether or not requirements have been met in an
implementation.
 Problems without a SRS document

 The important problems that an organization would face if it does not

develop a SRS document are as follows:

 Without developing the SRS document, the system would not be

implemented according to customer needs.

 Software developers would not know whether what they are developing
is what exactly required by the customer.

 Without SRS document, it will be very much difficult for the maintenance
engineers to understand the functionality of the system.
 It will be very much difficult for user document writers to write the
users’ manuals properly without understanding the SRS document.
 Problems with an unstructured specification

 It would be very much difficult to understand that document.

 It would be very much difficult to modify that document.

 Conceptual integrity in that document would not be shown.

 The SRS document might be unambiguous and inconsistent.

SOFTWARE DESIGN
 SOFTWARE DESIGN
 Software design is a process that transform user requirements into some
suitable form, which helps the programmer in software coding and
implementation.
 For assessing user requirements, an SRS (Software Requirement
Specification) document is created whereas for coding and
implementation, there is a need of more specific and detailed
requirements in software terms. The output of this process can directly
be used into implementation in programming languages.
 Software design is the first step in SDLC (Software Design Life Cycle),
which moves the concentration from problem domain to solution
domain. It tries to specify how to fulfill the requirements mentioned in
SRS.
 Software Design Levels
 Software design yields three levels of results:
 Architectural Design - The architectural design is the highest abstract version
of the system. It identifies the software as a system with many components
interacting with each other. At this level, the designers get the idea of proposed
solution domain.
 High-level Design- The high-level design breaks the ‘single entity-multiple
component’ concept of architectural design into less-abstracted view of sub-
systems and modules and depicts their interaction with each other. High-level
design focuses on how the system along with all of its components can be
implemented in forms of modules. It recognizes modular structure of each sub-
system and their relation and interaction among each other.
 Detailed Design- Detailed design deals with the implementation part of what is
seen as a system and its sub-systems in the previous two designs. It is more
detailed towards modules and their implementations. It defines logical structure
of each module and their interfaces to communicate with other modules.
 Modularization
 Modularization is a technique to divide a software system into multiple
discrete and independent modules, which are expected to be capable of
carrying out task(s) independently. These modules may work as basic
constructs for the entire software. Designers tend to design modules such
that they can be executed and/or compiled separately and independently.
 Modular design unintentionally follows the rules of ‘divide and conquer’
problem-solving strategy this is because there are many other benefits
attached with the modular design of a software.
 Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects  Desired level of
abstraction ca n be brought in the program  Components with high
cohesion can be re-used again.
 Concurrent execution can be made possible
 Desired from security aspect
 Design Verification
 The output of software design process is design documentation, pseudo
codes, detailed logic diagrams, process diagrams, and detailed
description of all functional or non-functional requirements.
 The next phase, which is the implementation of software, depends on all
outputs mentioned above.
 It is then becomes necessary to verify the output before proceeding to
the next phase. The early any mistake is detected, the better it is or it
might not be detected until testing of the product. If the outputs of
design phase are in formal notation form, then their associated tools for
verification should be used otherwise a thorough design review can be
used for verification and validation.
 SOFTWARE DESIGN STRATEGIES
 Software design is a process to conceptualize the software requirements
into software implementation. Software design takes the user
requirements as challenges and tries to find optimum solution. While the
software is being conceptualized, a plan is chalked out to find the best
possible design for implementing the intended solution.
 There are multiple variants of software design. Let us study them briefly:
 There are multiple variants of software design. Let us study them briefly:
Structured Design
 Structured design is a conceptualization of problem into several well-
organized elements of solution. It is basically concerned with the
solution design. Benefit of structured design is, it gives better
understanding of how the problem is being solved. Structured design
also makes it simpler for designer to concentrate on the problem more
accurately.
 Structured design is mostly based on ‘divide and conquer’ strategy
where a problem is broken into several small problems and each small
problem is individually solved until the whole problem is solved.
 The small pieces of problem are solved by means of solution modules.
Structured design emphasis that these modules be well organized in
order to achieve precise solution.
 Function Oriented Design
 In function-oriented design, the system is comprised of many smaller
sub-systems known as functions. These functions are capable of
performing significant task in the system. The system is considered as
top view of all functions.
 Function oriented design inherits some properties of structured design
where divide and conquer methodology is used.
 This design mechanism divides the whole system into smaller functions,
which provides means of abstraction by concealing the information and
their operation. These functional modules can share information among
themselves by means of information passing and using information
available globally.
Object Oriented Design
 Object oriented design works around the entities and their characteristics
instead of functions involved in the software system. This design strategy
focuses on entities and its characteristics. The whole concept of software
solution revolves around the engaged entities. (NEXT SLIDE TREATS)
Let us see the important concepts of Object Oriented Design:
 Objects - All entities involved in the solution design are known as
objects. For example, person, banks, company and customers are
treated as objects. Every entity has some attributes associated to it and
has some methods to perform on the attributes.
 Classes - A class is a generalized description of an object. An object is
an instance of a class. Class defines all the attributes, which an object
can have and methods, which defines the functionality of the object.
 In the solution design, attributes are stored as variables and
functionalities are defined by means of methods or procedures.

Encapsulation - In OOD, the attributes (data variables) and methods

(operation on the data) are bundled together is called encapsulation.
Encapsulation not only bundles important information of an object
together, but also restricts access of the data and methods from the
outside world. This is called information hiding.
 Inheritance - OOD allows similar classes to stack up in hierarchical
manner where the lower or sub-classes can import, implement and re-
use allowed variables and methods from their immediate super classes.
This property of OOD is known as inheritance. This makes it easier to
define specific class and to create generalized classes from specific
ones.
 Polymorphism - OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned same
name. This is called polymorphism, which allows a single interface
performing tasks for different types. Depending upon how the function is
invoked, respective portion of the code gets executed.
Design Process

Software design process can be perceived as series of well-defined steps.

Though it varies according to design approach (function oriented or object
oriented, yet It may have the following steps involved:
 A solution design is created from requirement or previous used system
and/or system sequence diagram.
 Objects are identified and grouped into classes on behalf of similarity in
attribute characteristics.
 Class hierarchy and relation among them are defined.
 Application framework is defined.
Software Design Approaches
 There are two generic approaches for software designing:
Top down Design
 We know that a system is composed of more than one sub-systems and it
contains a number of components. Further, these sub-systems and components
may have their one set of sub-system and components and creates hierarchical
structure in the system.
 Top-down design takes the whole software system as one entity and then
decomposes it to achieve more than one sub-system or component based on
some characteristics. Each subsystem or component is then treated as a system
and decomposed further. This process keeps on running until the lowest level of
system in the top-down hierarchy is achieved.
 Top-down design starts with a generalized model of system and keeps on defining
the more specific part of it. When all components are composed the whole system
comes into existence.
 Top-down design is more suitable when the software solution needs to be
designed from scratch and specific details are unknown.
Bottom-up Design

 The bottom up design model starts with most specific and basic
components. It proceeds with composing higher level of components by
using basic or lower level components. It keeps creating higher level
components until the desired system is not evolved as one single
component. With each higher level, the amount of abstraction is
increased.
 Bottom-up strategy is more suitable when a system needs to be created
from some existing system, where the basic primitives can be used in
the newer system.
 Both, top-down and bottom-up approaches are not practical individually.
Instead, a good combination of both is used.
 SOFTWARE ANALYSIS & DESIGN TOOLS
 Software analysis and design includes all activities, which help the transformation
of requirement specification into implementation. Requirement specifications
specify all functional and non-functional expectations from the software. These
requirement specifications come in the shape of human readable and
understandable documents, to which a computer has nothing to do.
 Software analysis and design is the intermediate stage, which helps human-
readable requirements to be transformed into actual code.
 Let us see few analysis and design tools used by software designers:
 Data Flow Diagram
 Data flow diagram is a graphical representation of data flow in an information system. It
is capable of depicting incoming data flow, outgoing data flow and stored data. The DFD
does not mention anything about how data flows through the system.
 There is a prominent difference between DFD and Flowchart. The flowchart depicts flow
of control in program modules. DFDs depict flow of data in the system at various levels.
DFD does not contain any control or branch elements.
Types of DFD
 Data Flow Diagrams are either Logical or Physical.(read***)
 Logical DFD - This type of DFD concentrates on the system process and flow of data in
the system. For example in a Banking software system, how data is moved between
different entities.
 Physical DFD - This type of DFD shows how the data flow is actually implemented in
the system. It is more specific and close to the implementation.

 UML(Unified modelling language)

 READ DATA FLOW DIAGRAMS(SYSMBOLS AND HOW TO DRAW)