The document discusses software requirements and requirement analysis. It defines a software requirement as conditions needed by users or that systems must possess. Requirement analysis involves understanding the problem domain through meetings with clients. The output is a Software Requirements Specification (SRS) document that describes what the software should do without describing how. The SRS must be correct, complete, unambiguous, verifiable and consistent. It is structured with sections for introduction, detailed requirements and more. Data flow diagrams are used during analysis to show the flow of data through processes in a system.

1. Software Requirement
A requirement is –
1) A condition of capability needed by a user to solve a
problem or achieve an objective,
(2) A condition or a capability that must be met or
possessed by a system.
The software requirements dealing with the requirements of
the proposed system, that is, the capabilities that the
system, which is yet to be developed, should have.
1

2. Software Requirement
All development models require requirements to be specified.
The goal of the requirements activity is to produce the
Software Requirements Specification (SRS) that describes
what the proposed software should do without describing
how the software will do it.
2

3. Software Requirement Analysis
The requirement process is the sequence of activities that
need to be performed in the requirements phase and that
terminate in producing the SRS document.
The requirements process typically consists of three basic
tasks:
• Requirement analysis
• Requirements specification
• Requirements validation.
3

4. Software Requirement Analysis
Requirement analysis
Requirement analysis starts with a high-level “problem
statement.”
During analysis the problem domain and the environment are
modeled to understand the system behavior, constraints
on the system, its inputs and outputs, etc.
The basic purpose of this activity is to obtain a thorough
understanding of what the software needs to provide.
During analysis, the analyst will have a series of meetings
with the clients and end users.
4

5. Software Requirement Analysis
Requirement analysis
Once the analyst understands the system to some extent, he
uses the next few meetings to seek clarifications of the parts
he does not understand.
In the final few meetings, the analyst essentially explains to
the client what he understands the system should do.
Analyst uses the meetings to verify the proposed system is
indeed consistent with the objectives of the clients.
5

6. Software Requirement Analysis
Requirement Specification
The understanding obtained by problem analysis forms the
basis of requirements specification, in which the focus is on
clearly specifying the requirements in a document.
Requirements validation
It focuses on ensuring that what have been specified in the
SRS are indeed all the requirements of the software and
making sure that the SRS is of good quality.
The requirements process terminates with the production of
the validated SRS. 6

7. Requirement Specification
The understanding obtained by problem analysis forms the
basis of requirements specification, in which the focus is on
clearly specifying the requirements in a document.
The final output of requirement analysis is the SRS
document.
Performance constraints, design constraints, standards
agreement, recovery, etc., are must be specified clearly in
the SRS, because the designer must know about these to
properly design the system.
7

8. Requirement Specification
A good SRS needs to specify many things, some of which are
not satisfactorily handled during analysis.
The knowledge acquired about the system, passes from
requirements analysis activity to the specification.
The SRS is written based on the knowledge acquired during
analysis.
8

9. Advantages of SRS
1. An SRS establishes the basis for agreement between the
client and the supplier on what the software product will
do.
1. An SRS provides a reference for validation of the final
product.
1. A high-quality SRS is a prerequisite (precondition) to high-
quality software.
1. A high-quality SRS reduces the development cost
9

10. Desirable Characteristics of an SRS
Desirable characteristics of an SRS are:
1.Correct
2.Complete
3.Unambiguous
4.Verifiable
5.Consistent
6.Ranked for importance and/or stability
10

11. Desirable Characteristics of an SRS
Correct - An SRS is correct if every requirement included in
the SRS represents something required in the final system.
Complete - It is complete if everything the software is
supposed to do and the responses of the software to all
classes of input data are specified in the SRS.
Unambiguous - It is unambiguous if and only if every
requirement stated has one and only one interpretation.
Requirements are often written in natural language, which is
inherently ambiguous. If the requirements are specified in a
natural language, the SRS writer has to be careful to ensure
that there are no ambiguities.
11

12. Desirable Characteristics of an SRS
Verifiable - An SRS is verifiable if and only if every stated
requirement is verifiable.
A requirement is verifiable if there exists some cost-effective
process that can check whether the final software meets that
requirement.
Consistent - It is consistent if there is no requirement that
conflicts with another. Terminology can cause
inconsistencies, different requirements may use different
terms to refer to the same object.
12

13. Desirable Characteristics of an SRS
Ranked for importance and/or stability - all the requirements
for software are not of equal importance.
Some are critical, others are important but not critical, and there
are some which are desirable but not very important.
Some requirements are “core” requirements which are not likely
to change as time passes, while others are more dependent on
time.
An SRS is ranked for importance and/or stability if for each
requirement the importance and the stability of the requirement
are indicated.
Stability of a requirement reflects the chances of it changing in
the future 13

14. Structure of SRS document
14
All the requirements for a system, have to be included in a
document that is clear and brief.
For this, it is necessary to properly organize the requirements
document.
The IEEE standards recognize the fact that different projects
may require their requirements to be organized differently.
There is no one method that is suitable for all projects.
It provides different ways of structuring the SRS.
The first two sections of the SRS are the same in all of them.

15. Structure of SRS document
15
The general structure of an SRS

16. Structure of SRS document
16
The introduction section contains the purpose, scope,
overview, etc., of the requirements document.
This section clarifies the motivation and business
objectives that are driving this project, and the scope of the
project.
The next section gives an overall perspective of the system,
how it fits into the larger system,
and an overview of all the requirements of this system.
Product perspective is the relationship of the product to
other products; defining if the product is independent or is a
part of a larger product, and what the principal interfaces of
the product are.

17. Structure of SRS document
17
A general abstract description of the functions to be
performed by the product is given.
Schematic diagrams showing a general view of different
functions and their relationships with each other can be
useful.
Typical characteristics of the end user and general
constraints are also specified.

18. Structure of SRS document
18

19. Structure of SRS document
19
The detailed requirements section describes the details of
the requirements that a developer needs to know for
designing and developing the system.
One method to organize the specific requirements is to first
specify the external interfaces, followed by functional
requirements, performance requirements, design
constraints, and system attributes.
The external interface requirements section specifies all the
interfaces of the software: to people, other software,
hardware, and other systems.

20. Structure of SRS document
20
In the functional requirements section, the functional
capabilities of the system are described.
For each functional requirement, the required inputs,
desired outputs, and processing requirements will have to
be specified.
The performance section should specify both static and
dynamic performance requirements.
All factors that constrain the system design are described
in the performance constraints section.
The attributes section specifies some of the overall
attributes that the system should have.

21. Data Flow Diagrams (DFD)
21
Data flow diagrams (also called data flow graphs) are
commonly used during problem analysis.
A DFD shows the flow of data through a system.
It views a system as a function that transforms the inputs
into desired outputs.
Any complex system will not perform this transformation in
a “single step,” and data will typically undergo a series of
transformations before it becomes the output.
The DFD shows the transformations that take place to the
input data so that the output data is produced.

22. Data Flow Diagrams (DFD)
22
The agent that performs the transformation of data from
one state to another is called a process (or a bubble).
A DFD shows the movement of data through the different
transformations or processes in the system.
The processes are shown by named circles and data
flows are represented by named arrows entering or leaving
the bubbles.
A rectangle represents a source or sink and is originator or
consumer of data.

23. Data Flow Diagrams (DFD)
23

24. Data Flow Diagrams (DFD)
24
All external files such as employee record, company
record, and tax rates are shown as a labeled straight line.
The need for multiple data flows by a process is
represented by a “*” between the data flows.
This symbol represents the AND relationship.
In the DFD, for the process “weekly pay” the data flow
“hours” and “pay rate” both are needed, as shown in the DFD.
The OR relationship is represented by a “+” between the
data flows.

25. Data Flow Diagrams (DFD)
25
Many systems are too large for a single DFD to describe
the data processing clearly.
Some decomposition and abstraction mechanism be used
for such systems.
DFDs can be hierarchically organized, which helps in
progressively partitioning and analyzing large systems.
Such DFDs together are called a leveled DFD set.
A leveled DFD set has a starting DFD, which is a very
abstract representation of the system, identifying the major
inputs and outputs and the major processes in the system.

26. Data Flow Diagrams (DFD)
26
Before the initial DFD, a context diagram may be drawn in
which the entire system is shown as a single process with all
its inputs, outputs, sinks, and sources.
Then each process is refined and a DFD is drawn for the
process.
A bubble in a DFD is expanded into a DFD during
refinement.
The net inputs and outputs of a DFD for a process are the
same as the inputs and outputs of the process in the higher-
level DFD.

27. Role of Software Architecture
27
Architecture of a system provides a very high level view of
the parts of the system and how they are related to form
the whole system.
Architecture partitions the system in to logical parts such
that each part can be understand independently, and then
describes the system in terms of these parts and the
relationship between these parts.
The software architecture of a system is the structure or
structures of the system, which comprise
software elements, the externally visible properties of

28. Role of Software Architecture
28
1. Understanding and communication
An architecture description is primarily to communicate the
architecture to its various stakeholders, which include
the users who will use the system,
the clients who commissioned the system,
the builders who will build the system, and,
the architects.

29. Role of Software Architecture
29
2. Reuse
The software can be assembled from parts that are
developed by different people and are available for others to
use.
The architecture has to be chosen in a manner such that
the components which have to be reused can fit properly and
together with other components that may be developed.

30. Role of Software Architecture
30
3. Construction and Evolution.
As architecture partitions the system into parts, some
architecture-provided partitioning can be used for
constructing the system
It also requires that the system be broken into parts such
that different teams can separately work on different parts.

31. Role of Software Architecture
31
4. Analysis
 Some important properties about the behavior of the
system can be determined before the system is actually built.
This will allow the designers to consider alternatives and
select the one that will best suit the needs.
It is possible to analyze or predict the properties of the
system being built from its architecture.
Such analysis can help determine whether the system will
meet the quality and performance requirements, and if not,
what needs to be done to meet the requirements.

32. Design
32
The design activity begins when the requirements
document for the software to be developed is available and
the architecture has been designed.
 During design further refine the architecture.
 Design focuses on the module.
 During design we determine what modules the system
should have and which have to be developed.
 The design of a system is a blueprint or a plan for a
solution for the system.

33. Design
33
 A system is a set of modules with clearly defined behavior
which interact with each other in a defined manner to produce
some behavior or services for its environment.
The design process for software systems has two levels.
Module design
Focuses on deciding which modules are needed for the
system, the specifications of these modules, and how the
modules should be interconnected.
Detailed design or logic design.
In this, the internal design of the modules, or how the
specifications of the module can be satisfied, is decided.

34. Design Concepts
34
 The design of a system is correct, if a system built
according to the design, satisfies the requirements of that
system.
 The goal during the design phase is to produce correct
designs.
 The goal of the design process is to find the best possible
design within the limitations imposed by the requirements and
the physical and social environment in which the system will
operate.

35. Design Concepts
35
To evaluate a design, we will focus on modularity of a
system, which is decided mostly by design, as the main
criterion for evaluation.
A system is considered modular if it consists of discrete
modules so that each module can be implemented
separately, and a change in one module has minimal impact
on other modules.
Modularity helps in system debugging—isolating the system
problem to a module is easier if the system is modular.

36. Design Concepts
36
In system repair - changing a part of the system is easy as
it affects few other parts;
In system building - a modular system can be easily built
by putting its modules together.
To produce modular designs, some criteria must be used to
select modules.
Coupling and cohesion are two modularization criteria,
which are often used together.
The open-closed principle, which is another criterion for
modularity.

37. Design Concepts
37
Coupling
 Coupling between modules is the strength of
interconnections between modules or a measure of
interdependence among modules.
 The concept of coupling explains “how strongly” different
modules are interconnected.
Highly coupled modules are joined by strong
interconnections
 Loosely coupled modules have weak interconnections.
 Independent modules have no interconnections.

38. Design Concepts
38
Coupling
The choice of modules decides the coupling between
modules.
 The coupling between modules is decided during system
design and cannot be reduced during implementation.
Coupling increases with the complexity of the interface
between modules.
The more complex each interface is, the higher will be the
degree of coupling.

39. Design Concepts
39
Coupling
In OO systems, three different types of coupling exist : -
– Interaction coupling
– Component coupling
– Inheritance coupling
Interaction coupling occurs due to methods of a class
invoking methods of other classes.
This is similar to a function calling another function
This coupling is similar to coupling between functional
modules.

40. Design Concepts
40
Coupling
Component coupling :- refers to the interaction between two
classes where a class has variables of the other class.
Eg : -A class C can be component coupled with another class
C1, if C has an instance variable of type C1, or C has a
method whose parameter is of type C1, or if C has a method
which has a local variable of type C1.
 Whenever there is component coupling, there is likely to be
interaction coupling.

41. Design Concepts
41
Coupling
Inheritance coupling :- is due to the inheritance relationship
between classes.
Two classes are considered inheritance coupled if one class
is a direct or indirect subclass of the other.

42. Design Concepts
42
Cohesion
Cohesion of a module represents how tightly bound the
internal elements of the module are to one another.
Cohesion determines, how closely the elements of a
module are related to each other.
The greater the cohesion of each module in the system, the
lower the coupling between modules is.

43. Design Concepts
43
Cohesion
Levels of cohesion:
 Coincidental
 Logical
 Temporal
 Procedural
 Communicational
 Sequential
 Functional

44. Design Concepts
44
Cohesion
Coincidental : - It is the lowest level. Coincidental cohesion
occurs when there is no meaningful relationship among the
elements of a module. Coincidental cohesion can occur if an
existing program is “modularized” by chopping it into pieces
and making different pieces modules.
Logical :- if there is some logical relationship between the
elements of a module, and the elements perform functions
that fall in the same logical class.

45. Design Concepts
45
Cohesion
Temporal : - The elements are related in time and are
executed together. Modules that perform activities like
“initialization,” “cleanup,” and “termination” are usually
temporally bound.
Procedural :- A procedurally cohesive module contains
elements that belong to a common procedural unit.
For example, a loop or a sequence of decision statements in
a module may be combined to form a separate module

46. Design Concepts
46
Cohesion
Communicational : - A module with communicational
cohesion has elements that are related by a reference to the
same input or output data. In this, the elements are together
because they operate on the same input or output data.
Sequential :- In this, the elements are together in a module
and the output of one forms the input to another.
Functional :- all the elements of the module are related to
performing a single function. Function like “sort the array” is
an example.

47. Detailed Design
47
Once the modules are identified and specified during the
highlevel design, the internal logic that will implement the
given specifications can be designed.
The detailed design is useful for the more complex and
important modules.
The basic goal in detailed design is to specify the logic for
the different modules that have been specified during system
design.

48. Detailed Design
48
1. Logic/Algorithm Design
Specifying the logic will require developing an algorithm
that will implement the given specifications.
The starting step in the design of algorithms is statement
of the problem.
The problem for which an algorithm is developing has to
be clearly stated and properly understood by the person
responsible for designing the algorithm.
For detailed design, the problem statement comes from the
system design.

49. Detailed Design
49
1. Logic/Algorithm Design
The next step is development of a mathematical model for
the problem.
In modeling, one has to select the mathematical structures
that are best suited for the problem.
The next step is the design of the algorithm.
During this step the data structure and program structure
are decided. Once the algorithm is designed, its correctness
should be verified.

50. Detailed Design
50
1. Logic/Algorithm Design
The most common method for designing algorithms or the
logic for a module is to use the stepwise refinement
technique.
The stepwise refinement technique breaks the logic
design problem into a series of steps.
The process starts by converting the specifications of the
module into an abstract description of an algorithm containing
a few abstract statements.
In each step, one or several statements are decomposed

51. Detailed Design
51
2. State Modeling of Classes
In object-oriented design, class is not a functional
abstraction and cannot be viewed as only a collection of
functions (methods).
An object of a class has some state and many operations
on it.
To understand a class, the relationship between the state
and various operations and the effect of interaction of various
operations have to be understood.
Once the class is better understood, the algorithms for its

52. Detailed Design
52
2. State Modeling of Classes
A method to understand the behavior of a class is to view it
as a finite state automaton, which consists of states and
transitions between states.
When modeling an object, the state is the value of its
attributes, and an event is the performing of an operation
on the object.
 A state diagram relates events and states by showing how
the state changes when an event is performed.
A state diagram for an object will generally have an initial

53. Detailed Design
53
2. State Modeling of Classes
FSA model of a stack.