MID QUESTIONS AND ANSWERS -4SETS PDF BY : VENU GOPAL

Classical Waterfall Model:

The Waterfall Model was first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed fully before the next phase can begin. This type of
software development model is basically used for the project which is small and there are
no uncertain requirements. At the end of each phase, a review takes place to determine if
the project is on the right path and whether or not to continue or discard the project. In this
model software testing starts only after the development is complete. In waterfall model
phases do not overlap.

Advantages of waterfall model:

• This model is simple and easy to understand and use.
• It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and
• a review process.
• In this model phases are processed and completed one at a time. Phases do not
overlap.
• Waterfall model works well for smaller projects where requirements are very well
• understood.
Disadvantages of waterfall model:
• Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects. Poor model for long and
ongoing
projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing.
When to use the waterfall model:
• This model is used only when the requirements are very well known, clear
and fixed. Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are
available freely the project is short.
Very less customer interaction is involved during the development of the product. Once the
product is ready then only it can be demoted to the end users. Once the product is
developed and if any failure occurs then the cost of fixing such issues are very high, because
we need to update everywhere from document till the logic.

Software Requirements
• A requirement is a detailed, formal description of system functionalities. It specifies a
function that a system or component must be able to perform for customer satisfaction.
• IEEE defines a requirement as :
• “a condition of capability of a system required by customer to solve a problem or
achieve an objective.”
• “a capability that a product must possess or something a product must do in order to
ultimately satisfy customer need, contract, constraint, standard, specification or
other formally imposed documents.”
• “a documented representation of a condition or capability as in (1) or (2).”

1. Business Requirements:
• Understanding the business rules or the processes of organization is vital to software
development.
• Business requirements define the project goal and the expected business benefits for
doing
the project.
• The enterprise mission, values, priorities, and strategies must be known to understand the
business requirements that cover higher level data models and scope of the models.
• The business analyst is well versed in understanding the concept of business flow as well
as
the process being followed in the organization.
• The business analyst guides the client through the complex process that elicits the
requirements of their business.
2. User Requirements
• User requirements are the high-level abstract statements supplied by the customer, end
users, or other stakeholders.
• These requirements are translated into system requirements keeping in mind user’s views.
• These requirements are generally represented in some natural language with pictorial
representations or tables to understand the requirements.
• User requirements may be ambiguous or incomplete in description with less product
specification and little hardware/software configurations are stated in the user
requirements.
• There may be composite requirements with several complexities and confusions.
• In an ATM machine, user requirements allow users to withdraw and deposit cash.
3. System Requirements
• System requirements are the detailed and technical functionalities written in a systematic
manner that are implemented in the business process to achieve the goal of user
requirements.
• These are considered as a contract between the client and the development organization.
• System requirements are often expressed as documents in a structured manner using
technical representations.
• The system requirements consider customer ID, account type, bank name, consortium,
PIN,
communication link, hardware, and software. Also, an ATM will service one customer at a
time.
4. Functional Requirements
• Functional requirements are the behavior or functions that the system must support.
• These are the attributes that characterize what the software does to fulfil the needs of the
customer.
• These can be business rules, administrative tasks, transactions, cancellations,
authentication, authorization, external interfaces, legal or regulatory requirements, audit
tracking, certification, reporting requirements, and historical data.
5. Non-functional Requirements
• Non-functional requirements specify how a system must behave. These are qualities,
standards, constraints upon the systems services that are specified with respect to a
product, organization, and external environment.
• Non-functional requirements are related to functional requirements, i.e., how efficiently,
by
how much volume, how fast, at what quality, how safely, etc., a function is performed by a
particular system.
• The examples of non-functional requirements are reliability, maintainability, performance,
usability, security, scalability, capacity, availability, recoverability, serviceability,
manageability, integrity, and interoperability.
Example: ETransQ
• It is a web-based information system for suppliers, transporters, and agents to share a
common platform and help in gaining profit.
• Business requirements for ETransQ
• The aim of EtransQ is to shape an online information and knowledge-based system to be a
recognized, professional, innovative, and profitable service.
• The objectives of EtransQ are to
– provide the common platform for suppliers, transporters, and agents;
– provide an easy way to search for tenders and offers;
– build trust and relationships between consumers and service providers;
– provide easy and improved way of communication; and
– provide enough options to get the best deal available in the market.
• User and system requirements for ETransQ
• EtransQ system should provide a common platform for suppliers, agents, and transporters
to share knowledge that will help them to grow their business.
• The system requirements in this system are:
– The user should be able to communicate with other users connected with the
system irrespective of their physical location.
– The system should be flexible enough to provide personalized search results for
every registered user.
– The system should work in a secured manner.
– The information available should be genuine and reliable.
• Functional Requirements for ETransQ
EtransQ system provides
– registration,
– association,
– quick search,
– tendering,
– offering, and
– testimonial services to its user.
– etc.
Non-functional Requirements for ETransQ
• Availability
• Recoverability
• Extensibility
• Maintainability
• Privacy
• Security
• Compatibility
• Usability
• Stability
• Reusability
• Robustness

Design Methodologies:
A Design methodology provides the techniques and guidelines for the design process of a
system. There are different design processes for different design methodologies. The goal of
all
design methodologies is to produce a design for the solution of a system. A design process
consists of various design activities. The most popular design methodologies are:
1) Function Oriented Design
2) Object Oriented Design
1) Function Oriented Design:
The following are the salient features of a typical function-oriented design approach:
1. A system 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.
For example, consider a function create-new library-member which essentially creates the
record for a new member, assigns a unique membership number to him, and prints a bill
towards his membership charge. This function may consist of the following sub functions:
• Assign-membership-number
• Create-member-record
• Print-bill
Each of these sub-functions may be split into more detailed sub functions and so on.
2. The system state is centralized and shared among different functions, e.g. data such as
memberrecords is available for reference and updation to several functions such as:
• Create-new-member
• Delete-member
• Update-member-record

• Function-oriented techniques such as SA/SD group functions together if, as a group, they
constitute a higher-level function. On the other hand, object-oriented techniques group
functions together on the basis of the data they operate on. To illustrate the differences
between the object-oriented and the function-oriented design approaches, an example can
be considered.
Example: Fire-Alarm System
The owner of a large multi-stored building wants to have a computerized fire alarm system
for his
building. Smoke detectors and fire alarms would be placed in each room of the building. The
fire
alarm system would monitor the status of these smoke detectors. Whenever a fire condition
is
reported by any of the smoke detectors, the fire alarm system should determine the
location at which the fire condition is reported by any of the smoke detectors, the fire alarm
system should determine the location at which the fire condition has occurred and then
sound the alarms only in the neighbouring locations. The fire alarm system should also flash
an alarm message on the computer console. Fire fighting personnel man the console round
the clock. After a fire condition has been successfully handled, the fire alarm system should
support resetting the alarms by the fire fighting personnel.
Function-Oriented Approach:
/* Global data (system state) accessible by various functions */
BOOL detector_status[MAX_ROOMS];
int detector_locs[MAX_ROOMS];
BOOL alarm_status[MAX_ROOMS];
/* alarm activated when status is set */
int alarm_locs[MAX_ROOMS];
/* room number where alarm is located */
int neighbor-alarm[MAX_ROOMS][10];
/* each detector has at most 10 neighboring locations */
The functions which operate on the system state are:
interrogate_detectors();
get_detector_location();
determine_neighbor();
ring_alarm();
reset_alarm();
report_fire_location();

SET -2
Characteristics of Software:
1. Software has logical properties rather than physical:
i) Software has no physical shape, no volume, no colour, and no odour but s/w
products can be measured, estimated and their performance can be calculated.
ii) It logically consists of several programs connected through interfaces which
are again programs that can be managed and implemented through
programming languages.
iii) The entire s/w product follows “divide and conquer” policy for its design and
implementation.
2. S/W is produced in an engineering manner rather than in a classical manner:
i) The engineering mechanism provides some organized activities or tasks with
their defined approaches for s/w production.
ii) Some general activities are feasibility study, analysis, design, coding, testing,
and deployment.
iii) It is not possible to produce s/w in a manufacturing manner because this
would be a more complex process to manage and develop software.
3. S/W is mobile to change:
i) S/W is too much flexible product that it can easily be changed. These changes
may arise due to the changing requirements of the user and technological
advancements.
ii) Functionality can be modified, platform can be changed, new features can be
incorporated, and software can further be migrated onto different platform.
Due to changes, though quality remains the same, the products become very
complex.
4. S/W becomes obsolete but does not wear out or die:
i) S/W becomes obsolete due to increasing requirements of the users and
rapidly changing technologies and do not wear out as they do not have any
physical properties. H/W products can wear out due to environmental
maladies and high failure rate.
ii) The detection and correction of defects is a very difficult process in S/W,
which causes S/W to become very costly.
iii) S/W does not die but it can be made to retire after reengineering of the
existing S/W milestones and the product becomes alive again.
5. S/W has certain operating environment, end user, and customer:
i) Some s/w products are platform independent while others are platform
specific. They are 3 levels of end users, i.e., top-level, middle-level and
lower-level employees in an organization.
ii) Some s/w products are user specific like games, embedded M/C’s and so on.
6. S/W development is a labour-intensive task:
i) Requirements are collected from the users and customers.
ii) The s/w is designed and finally implemented in some programming language
and on some platform, quality is tested and reused parts are verified and so
on which follows all engineering steps.
iii) Therefore, s/w is costlier when compared with H/W.

1. Coupling: Coupling between two modules is a measure of the degree of

interdependence or interaction between the two modules. A module having high cohesion
and low coupling is said to be functionally independent of other modules. If two modules
interchange large amounts of data, then they are highly interdependent. The degree of
coupling between two modules depends on their interface complexity. The interface
complexity is basically determined by the number of types of parameters that are
interchanged while invoking the functions of the module. Module coupling can be Tightly or
Loosely coupled based on the dependencies.

Classification of Coupling: Even if there are no techniques to precisely and quantitatively

estimate the coupling between two modules, classification of the different types of coupling
will help to quantitatively estimate the degree of coupling between two modules. Six types
of coupling can occur between any two modules. This is shown in the figure given below:
i) 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. This data item should be problem related and not used for the control
purpose.
ii) 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.
iii) 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.
iv) External Coupling: It occurs when two modules share an externally imposed data format,
communication protocol, or device interface. All the modules share the same I/O device or
the
external environment.
v) Common coupling: Two modules are common coupled, if they share data through some
global
data items.
vi) Content coupling: Content coupling exists between two modules, if they share code, e.g.
a branch
from one module into another module.

BASIC CONCEPTS OF USER INTERFACE DESIGN

What Are The Best Practices When Designing an Interface
Here everything depends on fully knowing your users, including
understanding their goals, skills, preferences, and their
tendencies. This is important as once you know your user its make it
easier to choose the right interface elements / practices from the list
below:-
• First keep the interface simple. The best interfaces are those
that are almost ‘invisible’ to those using them. They avoid all
unnecessary elements and are clear in the language they use
on all the labels, and in their message.
• Be sure to create consistency and use the common UI
elements that are expected. The use of the common
elements in your UI is vital as your users will feel more
comfortable and are thus able to use the site more efficiently.
One vital part of this is the ‘rule’ that once a user learns how to
do something, they can transfer that ‘skill’ to other screens and
parts of the site.
• Choose your page layout carefully. It is vital to consider the
spatial relationships between items on the page and structure
all the elements based their importance. Carefully placing the
items will help draw attention to the most important pieces of
information and interactive elements and increases the
scanning speed on the page as well as its readability.
• Use Colour to direct attention. The careful use of colours and
texture can help you direct attention toward, and as
importantly redirect attention away, from less important items,
thus helping users to interact more efficiently.
• Similary, you can use typography to create hierarchy and
improve clarity. It is vital to carefully consider the use of
typefaces. The different sizes, fonts, and arrangement of the
text can increase legibility and readability.
• Communicate what is happening. Users are easily confused
and can lose heart when dealing with complicated (or for that
matter simple) interfaces, so it is vital to keep your users of
where they are in any interactive process. By using the various
UI elements you can communicate the user’s status and thus
reduce frustration. One vital point here is that you can show
the user the steps they can take to get over any problems that
they are experiencing.
 • Always display the defaults. With some careful planning you
can anticipate what your users want to do when they get to
your site, and can thus use the best defaults in the interactive
elements on the screen. Doing so reduces the burden on the
user, increases efficiency and also improves user
satisfaction. This is vital when it comes to form design as here
you have an ideal opportunity to populate fields with pre-
chosen data.
By using the above you can be sure to design a screen using the very
best User Interface and thus improve the experience your users
have.

Prototype Model:
The basic idea in Prototype model is that instead of freezing the requirements before a
design or coding can proceed, a throwaway prototype is built to understand the
requirements. This
prototype is developed based on the currently known requirements. Prototype model is a
software
development model. By using this prototype, the client can get an “actual feel” of the
system, since
the interactions with prototype can enable the client to better understand the requirements
of the
21 desired system. Prototyping is an attractive idea for complicated and large systems for
which there is no manual process or existing system to help determining the requirements.
The prototypes are usually not complete systems and many of the details are not built in the
prototype. The goal is to provide a system with overall functionality.
Diagram of Prototype model:

Advantages of Prototype model:

Users are actively involved in the development Since in this methodology a working model
of the system is provided, the users get a better understanding of the system being
developed.
Errors can be detected much earlier.
Quicker user feedback is available leading to better solutions.
Missing functionality can be identified easily Confusing or difficult functions can be
identified in each and every iteration, Requirements validation, Quick implementation of
incomplete but functional and application model.
Disadvantages of Prototype model:
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
• Incomplete application may result in not using of that application. Incomplete or
inadequate problem analysis.
When to use Prototype model:
• Prototype model should be used when the desired system needs to have a lot of
interaction
with the end users.
• Typically, online systems, web interfaces have a very high amount of interaction with end
users, are best suited for Prototype model. It might take a while for a system to be built that
allows ease of use and needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.

Software Design Process

It exists between Requirements engineering and programming. 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. The external design
considers the architectural aspects related to business, technology, major data stores, and
structure of the product.
High Level Design (Physical Design) - The high-level design breaks the ‘single entitymultiple
component’ concept of architectural design(conceptual view) 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.
Characteristics of good software design:
The quality of a software design can be characterized by the application domain. For
example real
time software will focus more on efficiency and reliability issues whereas academic
automation s/w
will concentrate on understandability and usability issues. A designer always tries to
produce a good
design. The desirable characteristics that a good s/w design should have are as follows:
1. Correctness: A design is said to be correct if it is correctly produced according to the
stated
requirements of customers in the SRS. It should fulfil all the functional features, satisfy
constraints, and follow the guidelines. A correct design is more likely to produce accurate
outcomes.
2. Efficiency: It is concerned with performance related issues; for example, optimal
utilization
of resources. The design should consume less memory and processor time. Software design
and its implementation should be as fast as requires by the user.
3. Understandability: It should be easy to understand what the module is, how it is
connected to
other modules, what data structure is used, and its flow of information. Documentation of a
design can also make it more understandable. An understandable design will make the
maintenance and implementation tasks easier.
4. Maintainability: A difficult and complex design would take a larger time to be understood
and
modified. Therefore, the design should be easy to be modified, should include new features,
should not have unnecessary parts, and it should be easy to migrate it onto another
platform.
5. Simplicity: A simple design will improve understandability and maintainability. Introducing
a
simple design is rare because a design follows certain steps and criteria. Still designers
always
think to “keep it simple” rather than “make it complex”.
6. Completeness: It means that the design includes all the specifications of the SRS. A
complete
design may not necessarily be correct. But a correct design can be complete.
7. Verifiability: The design should be able to be verified against the requirements documents
and programs. Interfaces between the modules are necessary for integration and function
prototyping.
8. Portability: The external design mainly focuses on the interface, business, and technology
architectures. These architectures must be able to move a design to another environment.
This
may be required when the system is to be migrated onto different platforms.
9. Modularity: A modular design will be easy to understand and modify. Once a modular
system
is designed, it allows easy development and repairing of required modules independently.
10. Reliability: This factor depends on the measurement of completeness, consistency, and
robustness in the software design. Nowadays, most people depend and rely on S/W to
always
work and yield correct results. If there is any unreliable part of software, it can cause major
dangers.
11. Reusability: The software design should be standard and generic so that it can be used
for
mass production of quality products with small cycle time and reduced cost. The object
code,
classes, design patterns, packages, etc., are the reusable parts of software.

USER INTERFACE TYPES

User interfaces may be of three types- command line interface, graphic user interface and
menu-driven interface. Each type of user interface with its merits and demerits are
explained below:
Command line interface (CLI) - This type of user interfaces allows the user to interact
directly with the computer by typing commands. Typing commands is not that easy because
you just can’t type anything, you have to type very specific words, so that computer is able
to understand.
Advantages of using command line interface are:

• It is faster than the other types of user interfaces.

• It is cheaper to use as a lesser resolution screen can be used.
• Lesser memory (RAM) is used.
• Lesser CPU processing time is needed.
• It doesn’t need Windows to run.
Disadvantages of using command line interface are:

• It can be challenging to use for people who don’t know the specific commands to
operate it.
 • A lot of commands have to be learned to use this interface.
• One needs to be very specific and careful when typing the commands. Even a single
spelling mistake may lead to instruction failure.
• Graphic user interface - A graphical user interface (GUI) is the most common type of
user interface in use today. It is a very 'friendly' way for people to interact with the
computer because it makes use of pictures, graphics and icons - hence why it is
called 'graphical'.
• A GUI (pronounced gooey) is also known as a WIMP interface because it makes use
of:

• Windows - a rectangular area on the screen where the commonly used applications
run

• Icons - a picture or symbol which is used to represent a software application or

hardware device

• Menus - a list of options from which the user can choose what they require

• Pointers - a symbol such as an arrow which moves around the screen as you move
your mouse. It helps you to select objects.

All modern operating systems have at least one type of GUI. For example Microsoft
Windows is a GUI, Apple Macintosh has another. Linux has a number of Graphical User
Interfaces available.

Many programs that run in Windows are known as WYSIWYG - this stands for What You See
Is What You Get. In the early days of word-processors, you typed your essay or letter on the
screen, but it could look completely different on the printer. A GUI normally tries to ensure
that whatever you create on the screen will be very similar to what appears on the printer
or World Wide Web.

Advantages of graphic user interface are:

• This type of user interface is easy to use, especially for a beginner.

• It is easy to explore and find your way around the system using a WIMP/ GUI
interface
• You do not have to learn complicated commands.
• There are usually a reasonable 'help' system included with WIMP interfaces
Disadvantages of graphic user interface are:

• GUIs take up a much larger amount of hard disk space than other interfaces.
• They need significantly more memory (RAM) to run than other interface types.
• They use more processing power than other types of interface.
• They can be slow for experienced programmers to use. These people often find CLI
interfaces much faster to use.
• You get the benefits of WYSIWYG.
 • They let you exchange data between different software applications
Menu-Driven Interface - This type of interface lets you interact with a computer or
device by working your way through a series of screens or menus. Think about your iPod or
mobile phone, they both use a menu driven interface. You are presented with a menu, you
make a choice and then the next menu appears on the screen. You make another choice
and so on. Cashpoint machines (ATMs) are another good example of a menu driven
interface.
Menu driven interfaces can also be verbal rather than visual. Have you ever made a
telephone call and been asked to 'press 1 for abc, press 2 for def, press 3 for ghi'?
Most of the software that you use has menu interfaces. You can use many features of the
software by working your way through the menu options. Have a look at the menus in your
word processor or spreadsheet package and see how many different choices you are given.
A well designed menu interface is simple to use, you just follow the instructions and make
your choices.
Advantages of menu-driven interface are:

• It is extremely easy to use. Someone who has never seen the interface before can
work out what to do.
• There are no commands to learn or remember.
• Step-by-step options are given so that the user doesn't have to remember anything.
• Even if you don't know what to do, you can usually guess your way around the
options.
• Menu interfaces don't have to be visual, they can be spoken - good for telephones or
for visually impaired people.
• They don't need huge amounts of processing power or memory.
• It is fairly easy for the software programmer to create the same menus in different
languages.
Disadvantages of menu-driven interface are:
• A poorly designed menu interface may be slow to use.
• It can be irritating if there are too many menu screens to work through - users get
annoyed or bored if it takes too long.
• You often can't go to the exact place you want right at the start. You have to work
your way through the menu screens even if you know where you want to get to.
• The menu can take up a large part of the screen so you have to keep flicking back
and forwards between applications.
• If the menu is poorly designed it might be hard to read e.g. writing is too small for
people with poor sight, colors might clash and be difficult to read, font style might be
hard to read.
SRS
• SRS is needed for a variety of reasons:
• Customers and users rely more on and better understand a written formal document
than some technical specification.
• It provides basis for later stages of software development, viz., design, coding, testing,
standard compliances, delivery, and maintenance.
• It acts as the reference document for the validation and verification of the work
products and final software.
• It is treated as an agreement on the features incorporated in the final system of
project between customer and the supplier.
• A good quality SRS ensures high quality software product.
• A high quality SRS reduces development effort (schedule, cost, and resources) because
unclear requirements always lead to unsuccessful projects.
Characteristics of the SRS
• Correctness
• Unambiguity
• Completeness
• Consistency
• Should be ranked for importance and/or stability
• Verifiability
• Modifiability
• Testability
• Validity
• Traceability
• Components of an SRS
• The main focus for specifying requirements is to cover all the specific levels of details that
will be required for the subsequent phases of software development and these are agreed
upon by the client.
• The specific aspects that the requirement document deals with are as follows:
• Functional requirements
• Performance requirements
• Design constraints (hardware and software)
• External interface requirements
Functional Requirements
– Functional requirements describe the behavior of the system that it is supposed to
have in the software product.
– They specify the functions that will accept inputs, perform processing on these inputs,
and produce outputs.
– Functions should include descriptions of the validity checks on the input and output
data, parameters affected by the operation and formulas, and other operations that
must be used to transform the inputs into corresponding outputs.
– For example, an ATM machine should not process transaction if the input amount is
greater than the available balance. Thus, each functional requirement is specified
with valid/invalid inputs and outputs and their influences.
Performance Requirements
– This component of the SRS specifies the performance characteristics or the
non-functional aspects of the software system.
– The performance outcomes depend on the operation of the functional requirements.
– Performance requirements are classified as
• Static requirements: These are fixed and they do not impose constraint on
the execution of the system.
• Dynamic requirements: specify constraints on the execution behavior of the
system. These typically include system efficiency, response time,
throughput, system priorities, fault recovery, integrity, and availability
constraints on the system.
Design Constraints
• There are certain design constraints that can be imposed by other standards, hardware
limitations, and software constraints at the client’s environment.
• These constraints may be related to the standards compliances and policies, hardware
constraints (e.g., resource limits, operating environment, etc.), and software constraints.
• The hardware constraints limit the execution of software on which they operate.
• Software constraints impose restrictions on software operation and maintenance.
External Interface Requirements
• The external interface specification covers all the interactions of the software with people,
hardware, and other software.
• The working environment of the user and the interface features in the software must be
specified in the SRS.
• The external interface requirement should specify the interface with other software.
• It includes the interface with the operating system and other applications.
Structure of an SRS
• The structure of the SRS describes the organization of the software requirement
document.
• The best way to specify requirements is to use predefined requirements specification
templates.
• The specific requirement subsection of the SRS should contain all of the software
requirements to a level of detail sufficient to enable designers to design a system to satisfy
those requirements, and testers to test that the system satisfies those requirements.
• It includes functional requirements, performance requirements, design constraints, and
external interface requirements.
Definition - What does Client/Server Architecture mean?
Client/server architecture is a computing model in which the server hosts, delivers
and manages most of the resources and services to be consumed by the client. This
type of architecture has one or more client computers connected to a central server
over a network or Internet connection. This system shares computing resources.

Client/server architecture may also be referred to as a networking computing model

because all the requests and services are delivered over a network.

Client/server architecture is a producer-consumer computing architecture where the server

acts as the producer and the client as a consumer. The server houses and provides high-
end, computing-intensive services to the client on demand. These services can include
applications access, storage, file sharing, printer access and/or direct access to the server’s
raw computing power.

Client/server architecture works when the client computer sends a resource or process
request to the server over the network connection, which is then processed and delivered to
the client. A server computer can manage several clients simultaneously, whereas one client
can be connected to several servers at a time, each providing a different set of services. In
its simplest form, the Internet is also based on client/server architecture where the Web
server serves many simultaneous users with Web page and or website data

Difference between Two tier and three tier

below we will concentrate on the difference between Two-Tier and Three-Tier Architecture, what all
advantages and disadvantages they have.

Two-Tier Architecture: The two-tier is based on Client Server architecture. The two-tier
architecture is like client server application. The direct communication takes place between client
and server. There is no intermediate between client and server. Because of tight coupling a 2 tiered
application will run faster.

The above figure shows the architecture of two-tier. Here the direct communication happens
between client and server, there is no intermediate layer between client and server. The Two-tier
architecture is divided into two parts:

Client Application (Client Tier)

Database (Data Tier)
On client application side the code is written for saving the data in database server. Client sends the
request to server and it process the request & send back with data. The main problem of two tier
architecture is the server cannot respond multiple request same time, as a result it cause a data
integrity issue. When the developers are not disciplined, the display logic, business logic and
database logic are muddled up and/or duplicated in a 2tier client server system.
Advantages:
1. Easy to maintain and modification is bit easy.
2. Communication is faster.

Disadvantages:
1. In two tier architecture application performance will be degrade upon increasing the users.
2. Cost-ineffective.

Three-Tier Architecture : Three-tier architecture typically comprise a presentation tier, a business or

data access tier, and a data tier. Three layers in the three tier architecture are as follows:

• Client layer
• Business layer
• Data layer
Client layer: Represents Web browser, a Java or other application, Applet, WAP phone etc. The
client tier makes requests to the Web server who will be serving the request by either returning
static content if it is present in the Web server or forwards the request to either Servlet or JSP in the
application server for either static or dynamic content.
Business layer: This layer provides the business services. This tier contains the business logic and
the business data. All the business logic like validation of data, calculations, data insertion etc. Are
centralized into this tier as opposed to 2-tier systems where the business logic is scattered between
the front end and the backend. The benefit of having a centralized business tier is that same
business logic can support different types of clients like browser, WAP (Wireless Application
Protocol) client, other standalone applications written in Java, C++, C# etc. This acts as an interface
between Client layer and Data Access Layer. This layer is also called the intermediary layer helps to
make communication faster between client and data layer.
Data layer: This layer is the external resource such as a database, ERP system, Mainframe system
etc. responsible for storing the data. This tier is also known as Data Tier. Data Access Layer contains
methods to connect with database or other data source and to perform insert, update, delete, get
data from data source based on our input data. Following diagram representing the 3-tier
architecture.
Advantages
1. High performance, lightweight persistent objects.
2. Scalability – Each tier can scale horizontally.
3. Performance – Because the Presentation tier can cache requests, network utilization is
minimized, and the load is reduced on the Application and Data tiers.
4. Better Re-usability.
5. Improve Data Integrity.
6. Improved Security – Client is not direct access to database.
7. Forced separation of user interface logic and business logic.
8. Business logic sits on small number of centralized machines (may be just one).
9. Easy to maintain, to manage, to scale, loosely coupled etc.

Disadvantages
1. Increase Complexity/Effort