CH 3

Unit 2 – Software Analysis and Process
REQUIREMENTS GATHERING AND ANALYSIS

1. Explain requirement gathering & analysis process in brief. OR Explain requirement gathering
in detail.(W-2017,W-2016)
 The analyst starts requirement gathering by collecting information that is useful to develop
system.
 It is very difficult to gather information from a number of people and documents and to clear
understanding of a problem.
 Availability of working model helps in gathering the requirement.
Studying the existing documentation

 Analyst studies existing documents related to system to get the requirement.
 These documents are about the basic purpose, the stakeholders etc.
Interview
 All different categories of users are interviewed to gather different functionalities required by
them.
 For example, the requirements analysis of library automation software, the analyst interviews
the library members, the librarian, and the accountants.
Task analysis
 Software provides a set of service is also called a task. For each task, the analyst tries to create
the different steps necessary to the service in guidance with the users.
 For example, for the issue book service, the steps may be:
 Authenticate user
 maximum number of books that this user can borrow has been reached
 check whether the book has been reserved
 Post the book issue details in the user’s record and finally print out a book issue slip.
Scenario analysis
 A task can have many scenarios of operation.
 For different types of scenarios of a task, the behavior of the system can be different.
 For example, the different scenarios for the book issue task of a library automation software
may be:
 Book issue service is successfully performed and the book issue slip is printed
 The book is reserved and cannot be issued to the member
 The maximum number of books issued by the member then book cannot be issued to the
member
1 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Form Analysis
 The different forms are analyzed to determine the data input to the system and the data that
are output from the system.
 Example: Student course Registration form
REQUIREMENTS ANALYSIS
 After requirements gathering is completed the analyst analyzes the gathered requirements to
clearly understand the customer requirements.
 The main purpose of the requirement analysis is to clear understanding of the product to be
developed, removing 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 data input to the system and what data output by the system?
 What are the complexities while solving the problem?
 If there is external software or hardware with the developed software, then what data
interchange formats with the external system?
 When the analyst detects inconsistencies or incompleteness in the gathered requirements, he
resolves them by carrying out discussions with the customers.
SOFTWARE REQUIREMENTS SPECIFICATION

2. What is SRS? Write characteristics of good SRS document in brief. OR List out the
characteristics and explain the importance of SRS document.(S-2018,S-2017,W-2016)
 After the analyst has gathered all the required information of the software to be developed and
remove incompleteness and inconsistencies, from the specification he starts to systematically
organize the requirements in the form of an SRS document.
 SRS document contains all the user requirements.
CHARACTERISTICS OF A GOOD SRS DOCUMENT

Correct
 An SRS is correct if every requirement included in the SRS, required in the final system.
 Correctness ensures that what is specified is done correctly.
Unambiguous
 An SRS is unambiguous if every requirement included in the SRS has one and only one meaning.
 Requirements are often written in natural language.

Complete
 The SRS is complete if it includes: All requirements, whether relating to functionality,

performance, design, attributes, or external interfaces.
 Definition of the response of the software in all situations.
 It is important to specify the response to both valid and invalid input values.
Consistent
 A consistent requirement does not conflict with other requirements in the requirement
specification.
 It does not duplicate.
Ranked for importance
 SRS is ranked for importance if, SRS has an identifier to indicate the importance of the
requirement.
 All the requirements that relate to a software product are not equally important.
 Some requirements are necessary while others may be desirable.
Verifiable
 A requirement is verifiable if there exists some process with which a person or machine can
check that the software product meets the requirement.
Modifiable
 The SRS is modifiable if, its structure and style are such that any changes to the requirement
can be made easily, completely, and consistently.
Structured
 The SRS is structured if, it is moduled, and easy to understand and modify.
 Over the time customer requirements changes, requirement specification also changes.
 In order to make modification to SRS it is necessary that SRS should be well structured.
Traceable
 A traceable requirement has a unique identity or number.
3. Explain Functional Requirement and non-functional requirement OR Differentiate between

functional and non-functional requirements.(S-2018,S-2017,S-2016,W-2015)
REQUIREMENTS SPECIFICATION TYPES
 Requirement specification activity is translating the gathered information during the analysis
phase into a document that defines a set of requirements.
 Requirements are further classified into two types:
1. Functional requirements
2. Nonfunctional requirements

Functional Requirements.(Define Functional Requirement S-2017,S-2016)

 Any requirement which specifies what the system should do.
 A functional requirement will describe a particular behavior of function of the system when
certain condition are met, for example:” send email when new customer sign up” or “ open a
new account”.
 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.

Select withdraw cash
Display ac-
count type
options
Enter option
Prompt for
amount to
be
withdrawn
Enter amount
Enter Print Insufficie-

amount in receipt nt balance
multiple in account
of 100
First 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 work.
 For example, the receipt printing work during withdrawal of money from an ATM is called a
useful? 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 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.
Non functional requirements

 Any requirement that specifies how the system perform a certain function
 A non functional requirement will describe how a system should behave and what limits there
are on its functionality.
 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 (Explain design process S-2015)

 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.
CLASSIFICATION OF DESIGN ACTIVITIES

 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

4. Write a short note on “classification of design methodologies”. (S-2017,W-2015)
 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
Function oriented design (Top-Down approach)

 A function oriented design is viewed as something that performs a set of functions.
 Starting at this high-level view of the system, each function is successively refined into more
detailed functions. Each of these sub-functions may be split into more detailed sub-functions
and so on.
 It can be further divided in two categories.
Structured Analysis
 It is used to transform a textual problem description into graphical form.

 It examines the detail structure of the system.
 It defines the processes and data flow among these processes.
 In structured analysis functional requirements specified in SRS are decomposed and analysis of
data flow is represented diagrammatically by DFD.

Structured Design
 During Structured design all functions identified during analysis mapped to module structure
and that is useful for implementation.
 The aim of structured design is to transform the results of the structured analysis (i.e. DFD) into
a structure chart. The structure chart is tree like diagram a popular way to represent the control
hierarchy in a high level design.
Object oriented design
5. List advantages of object oriented design. OR Explain Object Oriented design(S-2016)

 In the Object oriented design approach the system is viewed as collection of objects (i.e.
entities).
 Object Oriented Design supports following object oriented concepts such as Abstraction,
Information Hiding, Functional Independence, and Modularity.
 Design is the initial step in moving towards from the problem domain to the solution domain. A
detailed design includes specification of all the classes with its attributes, detailed interface.
The purpose of design is to specify a working solution that can be easily translated into a
programming language code.
 UML modeling and Use Case are used in object oriented designing.
COHESION
6. Explain Cohesion with its classification.(S-2018,S-2016,W-2015,S-2015) OR Explain Cohesion &
Coupling in Software Engineering.(W-2017,S-2017,W-2016)
 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.
 The classification of cohesion are given beloved:
coincidental Logical Temporal procedural communicational sequential Functional
Low High

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
7. Explain Coupling with diagram.(S-2018,S-2016,W-2015,S-2015)
 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.
 The classification of cohesion are given beloved:
Data Stamp Control Common Content

Low High
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
8. Explain E-R Diagram.(W-2017,S-2016,S-2015)
 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 (Explain Data objects and Data Attributes)S-2018

 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.

 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.
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'.
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.

9. Define cardinality and modality. OR What is Cardinality(S-2018,W-2017,S-2017,W-2015,S-

2015)
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)

10. What is DFD? Explain its symbol with one suitable example. OR Explain primitive symbols of
DFD and identify its important shortcomings. OR What is the significance of DFD in software
engineering? Explain in brief.(S-2018,W-2017,S-2017,W-2016,W-2015,S-2015)
 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 (Explain Symbols used in data flow diagram. OR Draw Symbols Used in
DFD.)S-2018,S-2016
 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.
 Function: A function is represented using a circle. This symbol is called a process or a bubble.
 Data flow: A directed arc or an arrow is used as a data flow symbol. A data flow represents the
data flow occurring between two processes or between an external entity and a process in the
direction of the data flow arrow.
External entity Process Output
Data flow
Data store
 Data store: A data store is represented using two parallel lines. It represents a logical file. It
represents data structure or a physical file on disk. Each data store is connected to a process.
The direction of the data flow arrows shows whether data is being read from or written into a
data store.

 Output: The output symbol is as shown in figure. The output symbol is used when a hard copy
is produced.
DEVELOP DFD MODEL OF SYSTEM

 A DFD model of a system graphically depicts the transformation of the data input to the system
to the final result through a hierarchy of levels.
 The top level DFD is called the level 0 DFD or the context diagram.
 A DFD starts with the most abstract definition of the system (lowest level) and at each higher
level DFD, more details are successively introduced.
 To develop a higher-level DFD model, processes are decomposed into their sub-processes and
the data flow among these sub-processes is identified.
 To develop the data flow model of a system, first the most abstract representation of the
problem is to be worked out. The most abstract representation of the problem is also called the
context diagram. After, developing the context diagram, the higher-level DFDs have to be
developed.
Context Diagram (Level 0)

 The context diagram is the most abstract data flow representation of a system. It represents
the entire system as a single bubble. This bubble is labeled according to the main function of
the system.
 The various external entities with which the system interacts and the data flow occurring
between the system and the external entities are also represented. The data input to the
system and the data output from the system are represented as incoming and outgoing arrows.
These data flow arrows should be annotated with the corresponding data names.
 The context diagram is also called as the level 0 DFD.
Level 0
Level 1

 Include all entities and data stores that are directly connected by data flow to the one process
you are breaking down.
 Show all other data stores that are shared by the processes in this breakdown.
 Decomposition at further level 1 DFD have processes with label 1.0, 2.0, 3.0,… and so on.
Advantages of DFD Model :( Write advantages and disadvantages of DFD.) W-2015
 It is beneficial for communication existing system knowledge to the users.

 DFD can provide a detailed representation of system components
 DFD are easier to understand by technical and non technical audiences
Shortcoming (Disadvantage) of DFD Model
 DFDs for large system can be become complex, difficult to understand and time consuming.
 Data flow can become confusing to programmer if it is not well defined.
 DFD does not specify exactly in which order processes are executed. There are multiple possible
ways to execute processes. So several alternate presentations can be possible.
 In DFD which inputs are consumed and which outputs are produced are not specified.
 DFD does not provide clear view about decomposition of any process to its sub-process.

SCENARIO BASED MODELING

UNIFIED MODELING LANGUAGE (UML)
CLASS DIAGRAM:
11. Explain Class Diagram.(W-2017,S-2016)
It describes the structure of system by showing the system’s classes , their attributes ,
operations (or methods), and the relationships among objects.
The purpose of the class diagram can be summarized as –

 Analysis and design of the static view of an application
 Describe responsibilities of a system
12. Explain Use Case Diagram. OR What is Use Case diagram.(S-2018,W-2017,S-2016,W-2015,S-
2015)
 UML, as the name implies, is a modeling language.
 It provides a set of notations (e.g. rectangles, lines, ellipses) to create a visual model of the
system.
 UML has its own syntax (symbols and sentence formation rules) and semantics (meanings of
symbols and sentences).
WRITING USE CASES

 While developing software, it is essential for the development team to consider user
satisfaction as a top priority to make the software successful. For this, the development team
needs to understand how users will interact with the system.

 This information helps the team to carefully identify each user requirements and then create a
meaningful and relevant analysis model and design model. For this, the software engineer
creates scenarios in the form of use-cases to describe the system from the users' view.
 Use cases describe the tasks in which the users will use the software under a specific set of
conditions.
 Each use-case provides one or more scenarios in order to understand how a system should
interact with another system. Use cases do not provide descriptions about the implementation
of software.
 Use-cases are represented with the help of a use-case diagram, which indicate the relationships
among actors and use cases within a system.
 A use-case diagram describes what exists outside the system (actors) and what should be
performed by the system (use-cases). The notations used to represent a use-case diagram are
listed in Table.
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.
Communication Indicates the interaction between the actor and the system.
link
Use link Indicates that one of the use-case uses the behavior described by another use-
case.

 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
Pay through Pay through

credit card library pay card
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
13. What is activity diagram? Explain activity diagram with suitable example. OR What is the
significance of Activity diagram in software engineering? Explain in brief.(S-2018,W-2017,W-
2016,W-2015, S-2015)
 An activity diagram basically a flow chart to represent the flow from one activity to another
activity
 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.

Basic Activity Diagram Symbols and Notations
Action states
 Action states represent the actions of objects. You can draw an action state using a rectangle
with rounded corners.
Action Flow
 Action flow arrows illustrate the relationships among action states.
Initial State
 A filled circle followed by an arrow represents the initial action state.
Final State
 An arrow pointing to a filled circle nested inside another circle represents the final action state.
Branching
 A diamond represents a decision with alternate paths. The outgoing alternates should be
labeled with a condition or guard expression. You can also label one of the paths "else."
 For example, activity diagram of ATM machine:


Synchronization
 A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking
and joining.
Swimlanes
 Swimlanes group related activities into one column
ARCHITECTURAL DESIGN DECISIONS

Design and implementation
 Software design and implementation is the stage in the software engineering process at which
an executable software system is developed.
 Software design is a creative activity in which you identify software components and their
relationships, based on a customer’s requirements.
 Implementation is the process of realizing the design as a program.

Software Architecture
 The design process for identifying the sub-systems making up a system and the framework for
sub-system control and communication is architectural design.
 The output of this design process is a description of the software architecture.
Architectural design decisions

 Architectural design is a creative process so the process differs depending on the type of system
being developed.
 However, a number of common decisions span all design processes and these decisions affect
the non-functional characteristics of the system.
 Is there a generic application architecture that can be used?
 How will the system be distributed?
 What architectural styles are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed into modules?
 How should the architecture be documented?
ARCHITECTURAL VIEWS
 What views or look are useful when designing and documenting a system’s architecture?
 What notations should be used for describing architectural models?
 Each architectural model only shows one view or look of the system.
 It might show how a system is decomposed into modules, how the run-time processes interact
or the different ways in which system components are distributed across a network.
 For both design and documentation, you usually need to present multiple views of the software
architecture.
4 + 1 view model of software architecture

1. A logical view, which shows the key concepts of the system as objects and classes.
2. A process view, which shows how, at run-time, the system, is composed of interacting
processes.
3. A development view, which shows how the software is decomposed for development. Means
it shows the breakdown of software into modules.
4. A physical view, which shows the system hardware and how software components are
distributed across the processors in the system.

ARCHITECTURAL PATTERNS
15. Discuss Architecture Patterns(S-2018)
 Patterns are a means of representing, sharing and reusing knowledge.
 An architectural pattern is a stylized description of good design practice, which has been tried
and tested in different environments.
 Patterns should include information about when they are and when they are not useful.
MVC (Model-View-Controller) Pattern

 The system is structured into three logical components that interact with each other. The
Model component manages the system data and associated operations on that data. The View
component manages how the data is presented to the user. The Controller component
manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to
the View and the Model.
 Used when there are multiple ways to view and interact with data.
 Allows the data to change independently of its representation and vice versa.
Layered architecture Pattern

 Organizes the system into layers with related functionality associated with each layer. A layer
provides services to the layer above it so the lowest-level layers represent core services that are
likely to be used throughout the system.

16. Explain Client Server Architecture with Diagram.(W-2017,S-2016,W-2015,S-2015)

Client-server :
 In client–server architecture, the functionality of the system is organized into services,
with each service delivered from a separate server. Clients are users of these services
and access servers to make use of them.
 Used when data in a shared database has to be accessed from a range of locations.
Because servers can be replicated, may also be used when the load on a system is
variable.
 The principal advantage of this model is that servers can be distributed across a
network. General functionality (e.g., a printing service) can be available to all clients
and does not need to be implemented by all services.

2 marks QUE-ANS
1. List UML diagrams (S-2018)
Activity diagram
Use case diagram
Class diagram
2. Justify: high cohesion and low coupling is better for any software development.(W-2015)
Low Coupling
Coupling refers to the relationship of a module with another module. A module is said to be
highly coupled with another module if changes to it will result to changes to the other module.
And a module is said to be loosely coupled if a module is independent of any other modules.
This can be achieved by having a stable interface that effectively hides the implementation of
another module.
The Benefits of low coupling are
 maintainability – changes are confined in a single module
 testability – modules involved in unit testing can be limited to a minimum
 readability – classes that need to be analyzed are kept at a minimum
High Cohesion
Cohesion refers to the measure of how strongly-related the functions of a module are. Low
cohesion refers to modules that have different unrelated responsibilities. High cohesion refers
to modules that have functions that are similar in many aspects.
The benefits of high cohesion are
 Readability – (closely) related functions are contained in a single module
 Maintainability – debugging tends to be contained in a single module
 Reusability – classes that have concentrated functionalities are not polluted with
useless functions
3. Define SRS. List out content of SRS.(W-2017,S-2015)
A Software Requirements Specification (SRS) is a document that describes the nature of a

project, software or application.

Content of SRS :
 Introduction
 Overall description
 System features
 External interface requirements
 Non functional requirements
4. Define SDLC. Explain feasibility analysis in detail.(W-2017)

Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality software’s. The SDLC aims to produce a high-quality software that
meets or exceeds customer expectations, reaches completion within times and cost estimates.
A feasibility study is quite important phase in which high management decides on the feasibility
report that whether or not the proposed system is worthwhile.
Operational Feasibility
Technical Feasibility
Economic Feasibility
The main aim of the feasibility study is not thinking how to solve problem, back to determine
whether the problem is work solving.
5. Develop Data Flow Diagram for Institute Management System.

0 level DFD
1 Level DFD

2 Level DFD

CH 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 3

Uploaded by

Copyright:

Available Formats

Unit 2 – Software Analysis and Process

REQUIREMENTS GATHERING AND ANALYSIS

Studying the existing documentation

1 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

SOFTWARE REQUIREMENTS SPECIFICATION

CHARACTERISTICS OF A GOOD SRS DOCUMENT

2 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

 The SRS is complete if it includes: All requirements, whether relating to functionality,

3. Explain Functional Requirement and non-functional requirement OR Differentiate between

3 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Functional Requirements.(Define Functional Requirement S-2017,S-2016)

4 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Select withdraw cash

Enter Print Insufficie-

First identify the high level function of the system.

5 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Non functional requirements

DESIGN PROCESS (Explain design process S-2015)

CLASSIFICATION OF DESIGN ACTIVITIES

6 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

CLASSIFICATION OF DESIGN METHODOLOGIES

Function oriented design (Top-Down approach)

 It is used to transform a textual problem description into graphical form.

7 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Object oriented design

5. List advantages of object oriented design. OR Explain Object Oriented design(S-2016)

coincidental Logical Temporal procedural communicational sequential Functional

8 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

9 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Data Stamp Control Common Content

10 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Data object (Explain Data objects and Data Attributes)S-2018

11 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

12 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

9. Define cardinality and modality. OR What is Cardinality(S-2018,W-2017,S-2017,W-2015,S-

13 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

DATA FLOW DIAGRAM (DFD)

External entity Process Output

14 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

DEVELOP DFD MODEL OF SYSTEM

Context Diagram (Level 0)

15 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Advantages of DFD Model :( Write advantages and disadvantages of DFD.) W-2015

 It is beneficial for communication existing system knowledge to the users.

Shortcoming (Disadvantage) of DFD Model

16 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

SCENARIO BASED MODELING

The purpose of the class diagram can be summarized as –

WRITING USE CASES

17 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

18 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

19 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Pay through Pay through

20 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Basic Activity Diagram Symbols and Notations

 For example, activity diagram of ATM machine:

21 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

22 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

ARCHITECTURAL DESIGN DECISIONS

23 Dept: CE FSD (3341603) Prof. Piyush R. Bhut

Architectural design decisions

4 + 1 view model of software architecture

24 Dept: CE FSD (3341603) Prof. Piyush R. Bhut