1. JAD session: Joint application development:JAD (Joint Application Development) is a methodology
that involves the client or end user in the design and development of an application, through a
succession of collaborative workshops called JAD sessions
The purpose of JAD is to bring together the technical/creative team and the business
community in a structured workshop setting to extract consensus based software
requirements.
1 It brings together business area people (users) and IT (Information Technology)
professionals in a highly focused workshop.
2 JAD participants typically include:
oFacilitator – facilitates discussions, enforces rules
oEnd users – 3 to 5, attend all sessions
oDevelopers – 2 or 3, question for clarity
oTie Breaker – senior manager. Breaks end user ties, usually doesn’t attend
oObservers – 2 or 3, do not speak
oSubject Matter Experts – limited number for understanding business & technology
3 Advantages:
oShortening of the time.
oImproves the quality of the final product by focusing on the up-front portion of the
development lifecycle.
oReducing the likelihood of errors that are expensive to correct later on.
4 A JAD session is a scheduled, formal workshop to create deliverables to the desired level of
completeness in the shortest reasonable time.
RAD :Rapid application development (R.A.D) is a software development methodology that uses
minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is
interleaved with writing the software itself. The lack of extensive pre-planning generally allows software
to be written much faster, and makes it easier to change requirements.
Rapid Application Development (RAD) is a process that speeds the delivery of
functionality to end-users by segmenting software into pieces for delivery rather than
delivering all of the software functionality in one large implementation.
It is an iterative process utilizing a spiral methodology and is also customer driven following
an evolutionary process using continuous application engineering in a time-boxed fashion
with a dedicated professional team. The goal of the iterative approach is to reduce the time
between requests and delivery of Business Application Software. Some of the primary
characteristics of RAD projects are:
There is a strict deadline for basic functionality
Projects can be released in increments
Techniques such as time-boxing, dedicated teams and focus sessions are used
Business users are involved throughout the project and JAD is used
Total project time is usually 3 - 6 months

2. BRD stands for Business requirement document what
business
analysts prepare based on client requirement.
Functional requirement document is mainly technical
document or a high level design what project managers
prepare.
BRD explains the "What" aspect of the Requirements i.e what is required?
FRD explains the "How"aspect of the Requirements i.e "How" the "What" can be achieved.
BRD is Business requirements doc, this is usually high level needs that the client expects to be
handled by the solution. These are typically defined by the client but could also be defined by the
BA. In my company we have written some BRDs.
FRD is the Functional Requirements doc. These are requirements that are written based on the
BRD. Through the traceability the FRD can be traced to one or more BRD and vice versa.
FRD is something that must be testable. There is a fine line that you do not get into too much of
the how (design) in an FRD. But a testor should be able to look at a FRD and be able to figure
out how to test that requirement.
BRS is Business Requirement document
It contains brief description about the application
Frs is Functional Requirement Specification
It contains all the functionalities in detail
FRD: It contains modules in depth, with the help of
wireframes, process flow, UML, screenshots or whatever it
needs to explain to client
How would you transform business requirements to functional requirements?
while preparing Business requirements documents you mention why you need to bulit a system, i.e.
problem statement. What you need to do while creating functional requirements is you have to specify
is, solution of the problem. Specify thorugly business problem and explain solution for the same.
Business requirement documents does not necessarrily contains solution part, functional requirement
may contain it how end user wants the system to perform. Dont forget to add non-functional
requirements same doc.
Following is the instance of Business Requirement, Functional Requirement and Non-Functional
Requirement.

3. Business Requirements :- sales order is made against customers purchase order. Sales order is given for
approval to upper authority
Functional requirement:- Sales order shall be made with reference from Purchase order and it should be
approved from upper authority.
Non-Functional Requirement:- Sales order should be in proper format (Specify format) and six copy of
sales order should be printed from printer in 1 minute.
Systems Development Life Cycle (SDLC)
The systems development life cycle (SDLC) is a conceptual model used in project
management that describes the stages involved in an information system
development project, from an initial feasibility study through maintenance of the
completed application.
Various SDLC methodologies have been developed to guide the processes involved,
including the waterfall model (which was the original SDLC method); rapid
application development (RAD); joint application development (JAD); the fountain
model; the spiral model; build and fix; and synchronize-and-stabilize. Often,
several models are combined into some sort of hybrid methodology.
Documentation is crucial regardless of the type of model chosen or devised for any
application, and is usually done in parallel with the development process. Some
methods work better for specific types of projects, but in the final analysis, the
most important factor for the success of a project may be how closely the particular
plan was followed.

4. Use Cases
Use cases model a dialogue between an actor and the system. They represent the
functionality provided by the system; that is, what capabilities will be provided to
an actor by the system. The collection of use cases for a system constitute all the
defined ways the system may be used.
The formal definition for a use case is: A use case is a sequence of transactions
performed by a system that yields a measurable result of values
for a particular actor.
The following questions may be used to help identify the use cases for a system:
What are the tasks of each actor?
Will any actor create, store, change, remove, or read information in the
system?
What use case will create, store, change, remove, or read this information?
Will any actor need to inform the system about sudden, external changes?
Does any actor need to be informed about certain occurrences in the system?
What use cases will support and maintain the system?
Can all functional requirements be performed by the use cases?

5. ACTIVITY DIAGRAMS
Similar to a flow chart, Activity Diagrams describe the sequencing of activities. They
are actually a variant of the State Diagram. Like State Diagrams, the starting point
is indicated with a large black dot. The horizontal black lines indicate where the
object may take one of several different paths of action. Activity Diagrams are
especially useful for objects which contain a lot of complex logic that you wish to
clearly present.
SEQUENCE DIAGRAMS
Interaction Diagrams show how groups of objects collaborate in some behavior.
Sequence Diagrams are the most common type of Interaction Diagram, and show an
instance of an object and the ‘life’ of that object. In addition, the interaction between
objects is shown.
Positive Test Case: To check if the application or system behaves as expected or as designed, when any
operation is performed.
Negative Test Case: Perform an unusual activity that is not defined nor that lets the system behave in a
regular manner, and check what happens with the application.