Question 1) Explain requirements elicitation techniques?

Answer 1) equirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through an effective
customer-developer partnership. It is needed to know what the users really need.

There are a number of requirements elicitation methods. Few of them are listed below –

Interviews
Brainstorming Sessions
Facilitated Application Specification Technique (FAST)
Quality Function Deployment (QFD)
Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst, developers,
users and the customer involved.

1. Interviews:

Objective of conducting an interview is to understand the customer’s expectations from the

software.
It is impossible to interview every stakeholder hence representatives from groups are selected based
on their expertise and credibility.

Interviews maybe be open ended or structured.

In open ended interviews there is no pre-set agenda. Context free questions may be asked to
understand the problem.
In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.

2. Brainstorming Sessions:
It is a group technique
It is intended to generate lots of new ideas hence providing a platform to share views
3. Facilitated Application Specification Technique:
It’s objective is to bridge the expectation gap – difference between what the developers think they
are supposed to build and what customers think they are going to get.

4. Quality Function Deployment:

In this technique customer satisfaction is of prime concern, hence it emphasizes on the
requirements which are valuable to the customer.

3 types of requirements are identified –

Normal requirements – In this the objective and goals of the proposed software are discussed with
the customer.

5. Use Case Approach:

This technique combines text and pictures to provide a better understanding of the requirements.
Question2) define FP analyais?

A Function Point (FP) is a unit of measurement to express the amount of business functionality, an
information system (as a product) provides to a user. FPs measure software size. They are widely
accepted as an industry standard for functional sizing.

For sizing software based on FP, several recognized standards and/or public specifications have
come into existence. As of 2013, these are −

ISO Standards
COSMIC

FiSMA

IFPUG

Mark-II

NESMA

Question 3) why consider formal methods?

Formal methods are techniques used to model complex systems as mathematical entities. By
building a mathematically rigorous model of a complex system, it is possible to verify the system's
properties in a more thorough fashion than empirical testing.

While Rigorous descriptions promise to improve system reliability, design time and
comprehensibility, they do so at the cost of an increased learning curve; the mathematical
disciplines used to formally describe computational systems are outside the domain of a traditional
engineering education. In addition, the metamodels used by most formal methods are often limited
in order to enhance provability. There is a notable tradeoff between the need for rigor and the
ability to model all behaviors.

Question 4) discuss cleanroom process?

The cleanroom software engineering process is a software development process intended to

produce software with a certifiable level of reliability. The cleanroom process was originally
developed by Harlan Mills and several of his colleagues including Alan Hevner at IBM. The focus of
the cleanroom process is on defect prevention, rather than defect removal. The name "cleanroom"
was chosen to invoke the cleanrooms used in the electronics industry to prevent the introduction of
defects during the fabrication of semiconductors. The cleanroom process first saw use in the mid to
late 1980s. Demonstration projects within the military began in the early 1990s.Recent work on the
cleanroom process has examined fusing cleanroom with the automated verification capabilities
provided by specifications expressed in CSP.

Question 5) Differentiate high-level and low-level design?

 HLD -- High Level Design (HLD) is the overall system design - covering the system architecture and
database design. It describes the relation between various modules and functions of the system.
data flow, flow charts and data structures are covered under HLD.

High Level Design gives the overall System Design in terms of Functional Architecture details and
Database design. This is very important for the ETL developers to understand the flow of the
system with function and database design wise. In this phase the design team, testers and
customers are plays a major role. Also it should have projects standards, the functional design
documents and the database design document also

LLD -- Low Level Design (LLD) is like detailing the HLD. It defines the actual logic for each and every
component of the system. Class diagrams with all the methods and relation between classes
comes under LLD. Programs specs are covered under LLD.

Low - Level Design (LLD) - This document is need to do during the detailed phase, the view of the
application developed during the high level design is broken down into separate modules and
programs for every program and then documented by program specifications.

1. What are the different design principle in software engineering for designing any software application?
Explain in details.

Once the requirements document for the software to be developed is available, the
software design phase begins. While the requirement specification activity deals
entirely with the problem domain, design is the first phase of transforming the
problem into a solution. In the design phase, the customer and business
requirements and technical considerations all come together to formulate a product
or a system.
The design process comprises a set of principles, concepts and practices, which allow
a software engineer to model the system or product that is to be built. This model,
known as design model, is assessed for quality and reviewed before a code is
generated and tests are conducted. The design model provides details about software
data structures, architecture, interfaces and components which are required to
implement the system. This chapter discusses the design elements that are required
to develop a software design model. It also discusses the design patterns and various
software design notations used to represent a software design.

Basic of Software Design

Software design is a phase in software engineering, in which a blueprint is developed
to serve as a base for constructing the software system. IEEE defines software design
as 'both a process of defining, the architecture, components, interfaces, and other
characteristics of a system or component and the result of that process.'
In the design phase, many critical and strategic decisions are made to achieve the
desired functionality and quality of the system. These decisions are taken into
account to successfully develop the software and carry out its maintenance in a way
that the quality of the end product is improved.
 Principles of Software Design
Developing design is a cumbersome process as most expansive errors are often
introduced in this phase. Moreover, if these errors get unnoticed till later phases, it
becomes more difficult to correct them. Therefore, a number of principles are
followed while designing the software. These principles act as a framework for the
designers to follow a good design practice.

Some of the commonly followed design principles are as following.

1. Software design should correspond to the analysis model: Often a design element
corresponds to many requirements, therefore, we must know how the design model satisfies
all the requirements represented by the analysis model.
2. Choose the right programming paradigm: A programming paradigm describes the
structure of the software system. Depending on the nature and type of application, different
programming paradigms such as procedure oriented, object-oriented, and prototyping
paradigms can be used. The paradigm should be chosen keeping constraints in mind such as
time, availability of resources and nature of user's requirements.
3. Software design should be uniform and integrated: Software design is considered
uniform and integrated, if the interfaces are properly defined among the design components.
For this, rules, format, and styles are established before the design team starts designing the
software.
4. Software design should be flexible: Software design should be flexible enough to adapt
changes easily. To achieve the flexibility, the basic design concepts such as abstraction,
refinement, and modularity should be applied effectively.
5. Software design should ensure minimal conceptual (semantic) errors: The
design team must ensure that major conceptual errors of design such as ambiguousness and
inconsistency are addressed in advance before dealing with the syntactical errors present in
the design model.
6. Software design should be structured to degrade gently: Software should be
designed to handle unusual changes and circumstances, and if the need arises for
termination, it must do so in a proper manner so that functionality of the software is not
affected.
7. Software design should represent correspondence between the software and
real-world problem: The software design should be structured in such away that it always
relates with the real-world problem.
8. Software reuse: Software engineers believe on the phrase: 'do not reinvent the
wheel'. Therefore, software components should be designed in such a way that they can be
effectively reused to increase the productivity.
9. Designing for testability: A common practice that has been followed is to keep the testing
phase separate from the design and implementation phases. That is, first the software is
developed (designed and implemented) and then handed over to the testers who
subsequently determine whether the software is fit for distribution and subsequent use by
the customer. However, it has become apparent that the process of separating testing is
seriously flawed, as if any type of design or implementation errors are found after
implementation, then the entire or a substantial part of the software requires to be redone.
Thus, the test engineers should be involved from the initial stages. For example, they should
be involved with analysts to prepare tests for determining whether the user requirements are
being met.
10. Prototyping: Prototyping should be used when the requirements are not completely
defined in the beginning. The user interacts with the developer to expand and refine the
requirements as the development proceeds. Using prototyping, a quick 'mock-up' of the
system can be developed. This mock-up can be used as a effective means to give the users a
feel of what the system will look like and demonstrate functions that will be included in the
developed system. Prototyping also helps in reducing risks of designing software that is not
in accordance with the customer's requirements.
Note that design principles are often constrained by the existing hardware
configuration, the implementation language, the existing file and data structures,
and the existing organizational practices. Also, the evolution of each software design
should be meticulously designed for future evaluations, references and maintenance.

Software Design Concepts

Every software process is characterized by basic concepts along with certain practices
or methods. Methods represent the manner through which the concepts are applied.
As new technology replaces older technology, many changes occur in the methods
that are used to apply the concepts for the development of software. However, the
fundamental concepts underlining the software design process remain the same,
some of which are described here.

2Define Test-scenario, Test-Case, RTM, QTC and Defect report?

A Test Scenario is defined as any functionality that can be tested. It is also

called Test Condition or Test Possibility. As a tester, you may put
yourself in the end user’s shoes and figure out the real-world scenarios and
use cases of the Application Under Test.

Requirement Traceability Matrix or RTM captures all requirements

proposed by the client or software development team and their traceability
in a single document delivered at the conclusion of the life-cycle.

In other words, it is a document that maps and traces user requirement with
test cases. The main purpose of Requirement Traceability Matrix is to see
that all test cases are covered so that no functionality should miss while
doing Software testing
A test case in software engineering is a set of conditions or variables under which a tester will
determine whether an application or software system is working correctly or not. The mechanism for
determining whether a software program or system has passed or failed such a test is known as a
test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be
a heuristic. It may take many test cases to determine that a software program or system is considered
sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly
when written. Written test cases are usually collected into test suites.

"(1) A set of test inputs, execution conditions, and expected results developed for a particular
objective, such as to exercise a particular program path or to verify compliance with a specific
requirement.

"(2) (IEEE Std 829-1983) Documentation specifying inputs, predicted results, and a set of execution
conditions for a test item."

Defect
A Software DEFECT / BUG is a condition in a software product which
does not meet a software requirement (as stated in the requirement
specifications) or end-user expectation (which may not be specified but is
reasonable). In other words, a defect is an error in coding or logic that
causes a program to malfunction or to produce incorrect/unexpected
results.

 A program that contains a large number of bugs is said to be buggy.

 Reports detailing bugs in software are known as bug reports. (See Defect
Report)
 Applications for tracking bugs are known as bug tracking tools.
 The process of finding the cause of bugs is known as debugging.
 The process of intentionally injecting bugs in a software program, to
estimate test coverage by monitoring the detection of those bugs, is
known as bebugging.

3Discuss type of Formal Specifications?

A formal software specification is a specification expressed in a language whose

vocabulary, syntax and semantics are formally defined. This need for
a formaldefinition means that the specification languages must be based on
mathematical concepts whose properties are well understood.Critical systems
development usually involves a plan-based software process that is based on the waterfall
model of development discussed in Chapter 4. Both the system requirements and the
system design are expressed in detail and carefully analysed and checked before
implementation begins. If a formal specification of Chapter 27 Formal Specification 4 ©Ian
Sommerville 2009 the software is developed, this usually comes after the system
requirements have been specified but before the detailed system design. There is a tight
feedback loop between the detailed requirements specification and the formal specification.
 As I discuss later, one of the main benefits of formal specification is its ability to uncover
problems and ambiguities in the system requirements. The involvement of the client
decreases and the involvement of the contractor increases as more detail is added to the
system specification. In the early stages of the process, the specification should be
‘customer-oriented’. You should write the specification so that the client can understand it,
and you should make as few assumptions as possible about the software design. However,
the final stage of the process, which is the construction of a complete, consistent and
precise specification, is principally intended for the software contractor. It precisely specifies
the details of the system implementation. You may use a formal language at this stage to
avoid ambiguity in the software specification. Figure 27.1 shows the stages of software
specification and its interface with the design process. The specification stages shown in
Figure 27.1 are not independent nor are they necessarily developed in the sequence shown.
Figure 27.2 shows specification and design activities may be carried out in parallel streams.
There is a two-way relationship between each stage in the process. Information is fed from
the specification to the design process and vice versa. As you develop the specification in
detail, your understanding of that specification increases. Creating a formal specification
forces you to make a detailed systems analysis that usually reveals errors and
inconsistencies in the informal requirements specification. This error detection is probably
the most Figure 27.1 Specification and design Increasing contractor involvement Decreasing
client involvement Specification Design User requirements definition System requirements
specification Architectural design Formal specification High-level design Figure 27.2 Formal
specification in the software process System requirements specification Formal specification
High-level design User requirements definition System modelling.

4What are the benefits and limitations of Formal Specifications?

Uses
Given such a specification, it is possible to use formal verification techniques to demonstrate that
a system design is correct with respect to its specification. This allows incorrect system designs
to be revised before any major investments have been made into an actual implementation.
Another approach is to use probably correct refinement steps to transform a specification into a
design, which is ultimately transformed into an implementation that is correct by construction.
It is important to note that a formal specification is not an implementation, but rather it may be
used to develop an implementation. Formal specifications describe what a system should do,
not how the system should do it.
A good specification must have some of the following attributes: adequate, internally consistent,
unambiguous, complete, satisfied, minimal[3]
A good specification will have:[3]

 Constructability, manageability and evolvability

 Usability
 Communicability
 Powerful and efficient analysis
One of the main reasons there is interest in formal specifications is that they will provide an
ability to perform proofs on software implementations.[2] These proofs may be used to validate a
specification, verify correctness of design, or to prove that a program satisfies a specification.[2
 Limitations
A design (or implementation) cannot ever be declared “correct” on its own. It can only ever be
“correct with respect to a given specification”. Whether the formal specification correctly
describes the problem to be solved is a separate issue. It is also a difficult issue to address,
since it ultimately concerns the problem constructing abstracted formal representations of an
informal concrete problem domain, and such an abstraction step is not amenable to formal proof.
However, it is possible to validate a specification by proving “challenge” theorems concerning
properties that the specification is expected to exhibit. If correct, these theorems reinforce the
specifier's understanding of the specification and its relationship with the underlying problem
domain. If not, the specification probably needs to be changed to better reflect the domain
understanding of those involved with producing (and implementing) the specification.
Formal methods of software development are not widely used in industry. Most companies do
not consider it cost-effective to apply them in their software development processes.[4]This may
be for a variety of reasons, some of which are:

 Time
o High initial start up cost with low measurable returns
 Flexibility
o A lot of software companies use agile methodologies that focus on flexibility. Doing a
formal specification of the whole system up front is often perceived as being the opposite
of flexible. However, there is some research into the benefits of using formal
specifications with "agile" development[5]
 Complexity
o They require a high level of mathematical expertise and the analytical skills to
understand and apply them effectively[5]
o A solution to this would be to develop tools and models that allow for these techniques to
be implemented but hide the underlying mathematics[2][5]
 Limited scope[3]
o They do not capture properties of interest for all stakeholders in the project[3]
o They do not do a good job of specifying user interfaces and user interaction[4]
 Not cost-effective
o This is not entirely true, by limiting their use to only core parts of critical systems they
have shown to be cost-effective[4]
Other limitations:[3]

 Isolation
 Low-level ontologies
 Poor guidance
 Poor separation of concerns
 Poor tool feedback

1. We are bank industry, and very keen to opt the software application for the growth of
our business. The following are the main requirements: Account opening, Transactions,
Demand Draft, Loan and Fixed deposit Prepare SRS for above requirements in details.

1. Introduction
This document gives detailed functional and nonfunctional
requirements for the bank management system. This product will
support online banking transaction. The purpose of this document is
that the requirements mentioned in it should be utilized by software
developer to implement the system.

1.1 Purpose

Online banking system provides is specifically developed for internet

banking for Balance Enquiry, Funds Transfer to another account in
the same bank, Request for cheque book/change of address/stop
payment of cheques, Mini statements (Viewing Monthly and annual
statements).
The Traditional way of maintaining details of a user in a bank was to
enter the details and record them. Every time the user need to perform
some transactions he has to go to bank and perform the necessary
actions, which may not be so feasible all the time. It may be a hard-
hitting task for the users and the bankers too. The project gives real
life understanding of Internet banking and activities performed by
various roles in the supply chain. Here, we provide an automation for
banking system through Internet. Internet banking system project
captures
activities performed by different roles in real life banking which
provides enhanced techniques for maintaining the required in-
formation up-to-date, which results in efficiency. The project gives
real life understanding of Internet banking and activities performed by
various roles in the supply chain.

1.2 Scope
This Product will automate of banking transaction process.This
Project investigates the entry threshold for providing a new
transaction service channel via the real options approach, where
the entry threshold is established by using an Internet banking
system designed for the use of normal users(individuals),
Industrialists, Entrepreneurs, Educational Institutions(Financial
sections), Organizations and Academicians under transaction rate
uncertainty.

1.3 Overview
The system provides easy solution to banks.
Overview: The SRS will include two sections, namely:
Overall Description: This section will describe major components of
the system, interconnections, and external interfaces.
Specific Requirements: This section will describe the functions of
actors, their roles in the system and the constraints faced by sys- tem.
2. General description
2.1 Product Perspective:

The client will have client interface in which he can interact with the
banking sys- tem. It is a web based interface which will be the web
page of the banking application. Starting a page is displayed asking
the type of customer he is whether ordinary or a corporate
customer. Then the page is redirected to login page where the user can
enter the login details. If the login particulars are valid then the user is
taken to a home page where he has the entire transaction list that he
can perform with the bank. All the above activities come under the
client interface.
The administrator will have an administrative in- terface which
is a GUI so that he can view the entire system. He will also have a
login page where he can enter the login particulars so that he
can perform all his actions. This administrative interface provides
different environment such that he can maintain data- base & provide
backups for the information in the database. He can register the users
by providing them with username, password & by creating account
in the database. He can view the cheque book request & perform
action to issue the cheque books to the clients.
2.2 Software Interface:
Front End Client:
The system is a web based application clients are requiring using
modern web browser such as Mozilla Firefox 1.5, PHP.
* Web Server:
The web application will be hosted on one of the apache server.
* Back End:
We use backend as MY SQL.

3. Functional Specifications
This section provides the functional overview of the product. The
project will require the PHP as a front end and at the back end the
database MYSQL will be running. Various functional modules that
can be implemented by the product will be

1. Login
2. Validation
3. Get balance information
4. Withdrawal of money
5. Transfer Money
6. Customer info.
3.1 Login:
Customer logins by entering customer name & a login pin.
3.2 Validation:
When a customer enters the ATM card, its validity must be ensured.
Then customer is allowed to enter the valid PIN. The validation can
be for following conditions
Validation for lost or stolen card
When card is already reported as lost or stolen
then the message “Lost/Stolen card!!!”.
Validation for card’s expiry date
If the card inserted by the customer has crossed the expiry date then
the system will prompt
“Expired Card”.
Validation for PIN
After validating the card, the validity of PIN must be ensured. If
he/she fails to enter valid code for three times then the card will not
be returned to him. That means the account can be locked. The
counter for number of logins must be maintained
Get balance information:
This system must be networked to the bank’s computer. The updated
database of every customer is maintained with bank. Hence the
balance information of every account is available in the database and
can be displayed to the customer.
3.3 Payment of Money:
A customer is allowed to enter the amount which he/she wishes to
withdraw. If the entered amount is less than the available balance and
if after withdraw if the minimum required balance is maintained then
allow the transaction.
3.4 Transfer of Money:
The customer can deposit or transfer the desired amount of money.
3.5 Transaction Report:
The bank statement showing credit and debit information
of corresponding account must be printed by the machine.
3.6 Technical Issues
This product will work on client-server architecture. It will require an
internet server and which will be able to run PHP applications. The
product should support some commonly used browsers such as
Internet Explorer, Mozilla Firefox.
4. Interface Requirements
4.1 GUI
This is interface must be highly intuitive or interactive because there
will not be an assistance for the user who is operating the System. At
most of the places help desk should be provided for users
convenience. The screens appearing should be designed in such a
manner that it can draw User attaraction towards the new plans for the
customers.
Also the pin and password confidentiality should be maintained,
This can be done by using asterisks at the password panel.
Proper security messages should be displayed at most of the places.

4.2 Hardware Interface

Various interfaces for the product could be
1. Touch screen/Monitor
2. Keypad
3. Continuous battery backup
4. Printer which can produce the hard copy.
5. Interface that connects the device to bank’s computer.
6. An interface that can count currency notes.
4.3 Software Interface
1. Any windows operating system.
2. The PHP must be installed. For the database handling MYSQL
must be installed. These products are open source products.
3. The final application must be packaged in a set up program, so that
the products can be easily installed on machines. This application
must be networked to corresponding banks.
5. Performance Requirements
The system should be compatible enough to hold the general traffic .
It should not get hang or show some other problems arising out due to
large no of concurrent users . The system should be fast enough to
meet the customer The high and low temperature should not affect the
performance of the device. An uninterrupted transaction must be
performed.
6.Constraints
* The information of all the users must be stored in a database that is
accessible by the On- line
Banking System.
* The Online Banking System is connected to the computer and is
running all 24hours a day.

* The users access the Online Banking System from any

computer that has Internet browsing capabilities and an Internet
connection.
*The users must have their correct usernames and passwords to enter
into the Online Banking System.