Joint Application Design (JAD)

Joint Application Design (JAD) A structured process in which users, managers, and analysts
work together for several days in a series of intensive meetings to specify or review system
requirements.

The main idea behind JAD is to bring together the key users, managers, and systems analysts
involved in the analysis of a current system.

The primary purpose of using JAD in the analysis phase is to collect systems requirements
simultaneously from the key people involved with the system.

JAD sessions are usually conducted at a location other than the place where the people involved
normally work. The idea behind such a practice is to keep participants away from as many
distractions as possible so that they can concentrate on systems analysis.

A JAD may last anywhere from four hours to an entire week and may consist of several sessions.

A JAD employs thousands of dollars of corporate resources, the most expensive of which is the
time of the people involved.

The typical participants in a JAD and their roles:

JAD session leader:

 S/he organizes and runs the JAD.

 S/he is trained in group management and facilitation as well as in systems analysis.
 S/he sets the agenda and sees that it is met;
 S/he remains neutral on issues and does not contribute ideas or opinions, but rather
concentrates on keeping the group on the agenda, resolving conflicts and disagreements, and
soliciting (manage) all ideas.

Users:

 The key users of the system under consideration are vital participants in a JAD.
 They are the only ones who have a clear understanding of what it means to use the system on
a daily basis.

Page 1 of 5
Managers:

 Managers of the work groups who use the system in question provide insight into new
organizational directions,
 Motivations for and organizational impacts of systems, and support for requirements
determined during the JAD.

Sponsor:

 As a major undertaking due to its expense, a JAD must be sponsored by someone at a

relatively high level in the company.
 If the sponsor attends any sessions, it is usually only at the very beginning or the end.

Systems analysts:

 Attend the JAD, although their actual participation may be limited.

 Analysts are there to learn from users and managers, not to run or dominate the process.

Scribe:

 Takes notes during the JAD sessions. This is usually done on a laptop
 Notes may be taken using a word processor, or notes and diagrams may be entered directly
into a CASE tool.

IS staff:

information systems (IS) staff includes: programmers, database analysts, IS planners, and data
center personnel, may attend to learn from the discussion and possibly contribute their ideas on
the technical feasibility of proposed ideas or the technical limitations of current systems.

Ref to pg.39, for a typical room layout for a JAD.

Advantage of JAD

 JAD allows you to resolve difficulties more simply and produce better, error-free software.
 The joint collaboration between the company and the clients lowers all risks.
 JAD reduces costs and time needed for project development.
 Well-defined requirements improve system quality.

Page 2 of 5
 Due to the close communication, progress is faster.
 JAD encourages the team to push each other to work faster and deliver on time.

Disadvantage of JAD

 Different opinions within the team make it difficult to align goals and maintain focus
 Depending on the size of the project, JAD may require a significant time commitment.

Using Prototyping During Requirements Determination:

Prototyping: An iterative process of systems development in which requirements are converted

to a working system that is continually revised through close collaboration between an analyst
and users.

Prototyping will enable you to quickly convert basic requirements into a working, though
limited, version of the desired information system.

The prototype will then be viewed and tested by the user.

Types of prototyping

Evolutionary Prototyping:

In evolutionary prototyping, you begin by modeling parts of the target system and, if the
prototyping process is successful, you evolve the rest of the system from those parts. The
prototype can then serve as the basis for the production system in a process.

Systems must be designed to support scalability, multiuser support, and multiplatform support.
Few of these design specifications will be coded into a prototype.

Throwaway Prototyping:

With throwaway prototyping, there is never any intention to convert the prototype into a working
system. The prototype is developed quickly to demonstrate some aspect of a system design that
is unclear or to help users decide among different features or interface characteristics.

Once the uncertainty the prototype was created to address has been reduced, the prototype can be
discarded, and the principles learned from its creation and testing can then become part of the
requirements determination.

Page 3 of 5
Radical Methods for Determining System Requirements

Business Process Reengineering (BPR) - The overall process by which current methods are
replaced with radically new methods (refer to pg.48).

Identifying Processes to Reengineer

A first step in any Business Process Reengineering (BPR) effort relates to understanding what
processes to change.

To do this, you must first understand which processes represent the key business processes for
the organization.

Key business processes are the structured set of measurable activities designed to produce a
specific output for a particular customer or market.

The important aspect of this definition is that key processes are focused on some type of
organizational outcome, e.g. creation of a product or delivery of a service.

Key business processes are also customer focused, would include all activities used to design,
build, deliver, support, and service a particular product for a particular customer.

- Disruptive technologies: Once key business processes and activities have been identified,
information technologies must be applied to radically improve business processes.
- Induction: the process of reasoning from the specific to the general, which means that
managers must learn the power of new technologies and think of innovative (using new
methods or ideas) ways to alter the way work is done.

Requirements Management Tools

Requirements management tools are typically designed to work with many of the standards now
available for requirements specification such as the Unified Modeling Language 2.0, System
modeling language, Business process modeling notation etc.

Requirements management tools is best to traditional, planning based systems development

approaches.

They do not work well with agile methodologies which tend to employ different approaches to
requirements gathering.
Page 4 of 5
Requirements Determination Using Agile Methodologies

Three techniques are presented in this section.

 The first is continual user involvement in the development process, a technique that works
especially well with small and dedicated development teams.
 The second approach is a JAD-like process called Agile Usage-Centered Design.
 The third approach is the Planning Game, which was developed as part of eXtreme
Programming.
Further reading student: (pg 51-56)

Page 5 of 5