You are on page 1of 11

Musarrat Nawaz

Reg # 0771126
Assignment 3

Difference between JAD and QFD

JAD is not quality-centered, but QFD is "an overall concept that provides a means
more communication-focused. of translating customer requirements into the
JAD expects improving the appropriate technical requirements for each stage
communication processes will of product development and production
result in higher product quality
the customer must be able to QFD, the customer is seen solely as a source of
visualize the product as they are
inti initial requirements.
directly participating in it's
JAD is user centred design QFD is quality centred design

JAD need directly QFD doesn’t need direct communication with the
communication with user user.
To use JAD, the customer has to This isn’t necessarily true for QFD.
be able to visualize the software
since they participate directly
Joint Application Design is goal Quality Function Deployment (QFD) tries to
driven apply the concept of total quality management to
software development
QFD results in documented requirements

Both the JAD and QFD approaches use group session techniques, however they are only
a component of QFD. As with any group session approach, they both require facilitators
to make the team interactions successful. As well both concentrate on customer
involvement during the RE stages of the project
• Both are group session techniques
• Both require facilitators
• Both require the project team to work with the customer
• JAD differs from QFD in that it is not quality-centered, but more communication-
focused.JAD expects improving the communication processes will result in higher
product quality. QFD on the other hand, makes quality an explicit goal, rather
than a byproduct of the process.
• Unlike QFD, JAD is specifically designed for the development of large computer
systems. The goal of JAD is to involve all stakeholders in the design phase of the
product via highly structured and focused meetings. Typical participants in the
session include a facilitator, end users of the product, main developers, and

• In the preliminary phases of JAD, the requirements-engineering team is tasked

with fact finding and information gathering. Typically, the outputs of this phase,
as applied to security requirements elicitation, are security goals and artifacts. The
actual JAD session is then used to validate this information by establishing an
agreed-upon set of security requirements for the product.
• Allows key users to participate effectively
• When properly used, JAD can result in a more accurate statement of system
requirements, a better understanding of common goals, and a stronger
commitment to the success of the new system
• More expensive and can be cumbersome if the group is too large relative to the
size of the project
Guidelines for successful JAD
• Use experienced and skilled facilitators
• Get Executive sponsor’s commitment and support
• Get the right person to participate
• Set clear, well understood and obtainable goals
• Plan detailed agenda and stick with it
• Define deliverables clearly in advance
• Keep technical jargon to minimum
• Produce final document quickly

Roles in JAD
• Session Leader (Facilitator)
 Expert at and committed to the process
 Excel at group processes (forming, norming, storming, performing)
 Needs to be trained – first choice, not last
• Scribe
 Ensures comments, issues, facts, decisions, questions are recorded
(verbatim where possible)
 Excels at the tools – CASE, Word
 Active participant – seeking clarity on wording and meaning
• User Representatives
 Must have knowledge, authority, experience
 Good listener
• IT Representatives
 Good listener
 Contributes technical information
• Executive Sponsor
 Pays the bills
 Makes the final decisions on issues

• Selecting an Executive Sponsor

 Right personality
 Strong influence in the organization
 Must have authority to make decisions
 Not afraid to make decisions

• Selecting a Facilitator
o Must be impartial
o For system development project, the facilitator ideally comes from neither
the user area nor the programming department.
 Ex. IBM’s concept called the Development Center or place JAD
staff in a group separate from IS.
o Communicate well
o Lead groups

• Selecting a Scribe

 Good working knowledge of the business area

 Good analytical skills
 Expertise in JAD documentation tool
 Good notes taking skills
 Good technical writing skills
 Clear handwriting

• Selecting Participants
 Commitment is essential
 It’s a balancing act
 Want enough people to have full representation and decision power in all
areas but at the same time must keep the session small enough to be
 For systems development project, a suggested ratio is five users to two IS

• Selecting Observers
 Should not be involved in any of the decision making
 Allow them to answer questions, but nothing more.
 Muzzle them completely.

Five Phases of JAD

1. JAD Project Definition
2. Research
3. Preparation
4. The Session
5. The Final Document

When is JAD used

• According to Hathaway & Associates the JAD can be used in

 Requirements gathering
 Business rules
 Data Modeling
 Process Engineering
 Business Analysis
 Workflow Modeling
 Quick Fix Design
 Test Case Identification
 Test Planning
1. Identify all stakeholders and clarify executive goal.
2. Scope out the general requirements (project mission and product features) from
each of the users' perspectives (business abstract).
3. Reconcile each user's view of the product with the executive goal into one
summary (project abstract).
4. Define the interaction of the product with users, other products or systems, and
the organization (context diagram).
5. Concur on business justification, time box, and cost box for project
(preliminary business plan).
6. Define the ways in which the users will interact or use the new product (use
cases). Collect samples of desired inputs and outputs from users. Stick to business
processes first, then drill down for data needed and known ("knows and does" list)
7. Prioritize the use cases by collective user preference and risk (Delphi
8. Validate and review the use case scenarios.
9. Organize the use cases, constraint, assumptions, and other requirements into a
rigorous Software Requirements Specification (SRS).
10. Design (with technical help) the screen and report layouts. Prototypes are
handy for this.

• Could require more than one JAD sessions
• Strong, opinionated users could dominate
• Not suitable for highly computational systems
Requires key users to attend

• Reduces cost and saves time
• Simultaneous input from key users
• Conflicts and discrepancies can be identified
• A sense of system ownership
• Suits projects with tight timelines and schedules
• Improved System quality and productivity
Enhanced communication and relationship between business users and IT professionals

Quality Function Deployment (QFD)

QFD is uses the method of 'House of Quality’, which is centered, around a matrix that
shows the relationship between the customer requirements and the proposed product
features. In QFD the customer requirements provide a central theme and are used as a
basis for setting targets for the design and implementation. QFD is split into 4 iterative
phases in software engineering: product planning, design planning, process planning,
production planning. For phase 1, the steps of putting the planning matrix together are:
• State the product requirements in customer terms.
• List the 'product features' across the top row of the matrix.
• Develop the 'relationship matrix'.
• Add the market evaluation.
• Produce a comparison of the final product control characteristics against the
performance of the competition.
• Use the analysis from step 5 and the customer importance rating from step 4 to
identify the selling points for the proposed product.
• QFD team identifies the actual measurable targets, which must be achieved.
• Select product control characteristics that are to be deployed through the
remainder of the QFD process.

Difference between JAD and PD

PD has a strong usability focus
Limitations of PD

• It’s good for in-house design but

it faces significantly greater challenges
and obstacles in the development of
mass-produced off-the-shelf software
applications and systems.
• existing organizational structures may
not support development practices

PD also is concerned with handling issues that

arise within the workplace such as employee -
management communication and power
JAD is a structured process PD is learning by doing
JAD represents a movement PD represents a movement toward more
toward more collaborative technical practices to
practices to enhance the viability enhance the viability of given social goals
of given goals.
Users are information source in Users are critical role in PD

JAD vs. PD

• Similarities
 Support direct communication between designer and user
 User centered design
Participatory Design (PD) is a set of diverse ways of thinking, planning, and acting
through which people make their work, technologies, and social institutions more
responsive to human needs.

The Purpose of PD
• Give users a voice in the design process
• Enable technical and non-technical participants to participate equally
• Provide an opportunity for developers to meet, work with and understand their
• Provide a forum for identifying issues
• Provide an opportunity to get or enhance user buy-in
• Increase the productivity
Communication in PD
User's Present Work New System Technological

Abstract 1 2 3
knowledge Relevant structures of users’ present Visions and design proposals Overview of
work UNDN technological
UNDN options
Concrete 4 5 6
experience Concrete experience with users’ present Concrete experience with new Concrete experience
work system with technology
UHDN UN options

PD in North America
• PD is not widely used in North America
 Organization Structure
 Culture
 High initial costs and time
• ETHICS (Effective Technical and Human Implementation of Computer-based
 12 steps approach covers the whole life of a development project
• Specify Work Mission
• Describe Present Work Activities and Needs
• Consider Job Satisfaction
• Decide what needs to change
• Set Efficiency, Effectiveness and Job Satisfaction Objectives
• Consider Organizational Options
• Reorganize: Principles for good organizational design
• Choose a Computer System
• Train Staff
• Redesign Jobs
• Implementation
• Evaluation

Research in the 1990s on how to facilitate a participatory design process in which end-
users can influence the system focus on user involvement in the actual design process.
Guidelines for PD (1)
• Respect the users of technology, view every participant in a PD project as an
expert in what they do, as a stakeholder whose voice needs to be heard.
• Recognize that workers are a prime source of innovation
• View systems as networks of people, practices, and technology embedded in
particular organizational contexts.
• Understand the organization and the relevant work on its own terms, in its own
• Be conscious of one's own role in PD processes; try to be a "reflective
• Address problems that exist and arise in the workplace, articulated by or in
collaboration with the affected parties, rather than attributed from the outside.
• Find concrete ways to improve the working lives of co-participants
• Ensure you have a thorough knowledge of the problem domain—what systems
are currently in use and what are the workplace issues?
• Ensure you have considered at least one potential solution. You may or may not
present this solution during the workshop.
• Prepare scenarios.
• Prepare an agenda. Ensure that you understand clearly the purpose of each agenda
item, and the techniques you will use to achieve it.
• Confirm attendees and ensure all participants are notified of dates and times. If
appropriate, send out a short kit explaining what will happen in the workshop.
• Book an appropriate room—participants must be comfortable during the
workshop. Ensure the room has flipchart, sufficient table space, and a whiteboard.
• Ensure you have all materials required—Butcher's paper, pens, sticky notes.

The current goals of PD are twofold: to engage people at all organizational levels in
the discussion of existing user practices and, to involve users in the subsequent design
of technological systems and workplace environments.
PD for mass product design
• Problem
 The development team is only responsible for implementing the design
• Resolution
 Users participate in product definition and product development
 Developers participate in creating the product definition

PD for mass product design – challenges

• Motivating the Developers to work with users

• Identifying Appropriate Users
• Obtaining and Motivating Users
• Properly Utilizing Potential users

Conclusion of PD

• Support to articulate the product concept

• Support analyze the problem situation from users
• Support communication between people
• Identify quality attributes of efficiency, effectiveness and satisfaction

Difference between JAD and RAD

RAD is more concerned with speed

RAD is more tools dependent

RAD results in the completed system

RAD is more technical centred

What is RAD?
Rapid Application Development
RAD is a way of developing a system by completing an initial working part of the
system, and then incrementally adding to it every few months. Instead of waiting to finish
the entire system, the system owners can put the system into use earlier. Development
tools such as visual programming and computer-assisted software engineering help with
RAD. Comparing these two is a bit of a mismatch since SQFD really only applies to the
requirements engineering stage. While building a working prototype is sometimes part of
a requirements engineering effort, RAD results in the completed system, while SQFD
results in documented requirements. Even applying Betts' application of QFD to software
so that it does cover the complete software development life cycle, there are more
differences than similarities
• RAD is a way to deliver systems very fast
 The longer a project, the greater its likelihood of failure
• It is a lightweight approach
• Uses proven technology effectively
• Make the solution fit within the capabilities of the tools (hammer?)
• RAD is not Quick and Dirty with a thin veneer of discipline
• RAD operates where the 80 / 20 rule applies
• RAD can’t be used in all situations
• RAD (rapid application development) is a concept that products can be developed
faster and of higher quality through:
• Gathering requirements using workshops or focus groups
• Prototyping and early, iterative user testing of designs
• The re-use of software components
• A rigidly paced schedule that defers design improvements to the next product
• Less formality in reviews and other team communication

When to use RAD?

• Business objectives are well defined and narrow
• Data for the project already exists
• Decisions can be made by a small number of people
• The project team is small (6 or less)
• The technical architecture is defined and clear and the key technology
components are in place and tested
• Technical requirements are reasonable and well within the capabilities of the
technology being used.

People – Hybrid Teams

• Team size: about 6
• Spend on their training
• Includes full-time user
• Co-locate if possible
• Multi-talented developers: fulfill all roles

• JAD and JRP as necessary
• Frequent tangible working results (echoes of XP?)
• Evolutionary Prototyping
• RAD is agnostic about techniques as long as they are proven and focused

• RAD usually assumes that the requirements phase is done as usual (Cross)
• Timeboxing – visibility (McConnell 96)
• Based on the Boehm Spiral lifecycle (Cross)
• Customer sees results regularly
• Compress the tasks and deliver often

• CASE tools
• From Excelerator to Rose
• Round trip tools
• Version control
• Visual prototyping
• Team scheduling – collaboration
• Automated testing
• Code generation
• RAD is a way to deliver systems very fast
 The longer a project, the greater its likelihood of failure
• It is a lightweight approach
• Uses proven technology effectively
• Make the solution fit within the capabilities of the tools (hammer?)
• RAD is not Quick and Dirty with a thin veneer of discipline
• RAD operates where the 80 / 20 rule applies
• RAD can’t be used in all situations
RAD (rapid application development) is a concept that products can be developed faster
and of higher quality through:
• Gathering requirements using workshops or focus groups
• Prototyping and early, iterative user testing of designs
• The re-use of software components
• A rigidly paced schedule that defers design improvements to the next product
• Less formality in reviews and other team communication
Pros and Cons of RAD
• Pros
 Good systems fast
 Good use of proven technology
• Cons
 Lacking rigor, leading to systems that do not scale
 Raise expectations to unreasonable levels
• Similarities
 Users and designers are working together