This document summarizes the outcomes and process of a KJ analysis session. The session aimed to gain a better understanding of requirements processes and customer involvement. Key themes that emerged included the need for clearer definitions of different requirement types and levels, and determining where to find additional requirement details when needed. Participants voted to prioritize these issues and develop recommendations to address the lessons learned.

1. KJ Analysis
“Affinity on steroids.”
Outcomes:
 Shared understanding
 Relationships
 Priorities
Process steps:
1. Define the question to be asked of the data.
2. Reduce the data set to 30 or fewer items
through multiple rounds of simple voting.
3. Group related items.
4. Title the groups.
5. Group related groups.
6. Create headlines for the higher level groups.
7. Visually lay out the groups with all data items.
8. Show relationships between groups.
9. Vote for the most important title‐level groups.
10. Draw a conclusion from the diagram.
We don’t have a clear definition of
what a requirement is
No clear definition of what
the difference levels of
requirements are
There seems to be
a discrepancy on
how detailed the
rqmts need to be.
I can’t delineate
between BR’s and
MR’s.
It’s not clear
where a market
requirement stops
and an SR starts
I don’t understand what the customer
needs; we don’t understand what is
important to deliver
I like to be involved in the whole process
All roles should be
involved throughout the
entire process
VOCs are very valuable
Is seems like we are
spending a lot of time putting
the same data in multiple
places and coordinating to
ensure the data is in sync
The process shouldn’t impede the
progress of the project
We’re going to
need to do some
clarification of what is
design and what is a
requirements
We don’t have a
good definition of
what a
requirement is
It seems like different
RAs have a different view
of what a requirement
should be
With requirements at
a high level it is difficult
to come up with a
good estimate
Perhaps we should
have two different
levels of use cases
We don’t know what “good
enough” is
How do you define
success at the end
of each iteration
We have lost the
concept of critical
release
requirements
We aren’t validating what
we are building with the
customer
Need to get out of the
lab exercise of I know
what the answer is now
I need to go find a
customer to tell me they
have that problem
Need to know when
we come out the other
end, have we built the
feature that is necessary
for the customer.
You better think about
performance
requirements before you
start down the design
path
Need a better way
to bring customer
feedback in earlier in
the process
VOCs are very
valuable for
providing focus to
product issues
VOCS were very
valuable which gave
us a very good
process and means
to rank and prioritize
requirements
Get engineering and
test involved earlier on
before the rqmts are
finalized
The requirement
analyst needs to
own the rqmts all the
way through the
process.
It’s difficult to look at
requirements in
ReqPro so everyone
gives up
I like the ability to
add attributes (Req
Pro)
Requirements tools are
difficult to work with
A lot of things you test
for will not show up in
requirements for
instance failure modes
If you read only the
SRs it is difficult to
understand what the
hell it is supposed to
do.
Hundreds of hours have been spend on
requirements with very specific detail for
consistency. The gap we have is that how
are we going to do a consistent design
without that level of detail
If the requirements don’t
have the detail I need,
where do I get them?
When we took UI detail
out of the use case it
wasn’t clear what the
rqmt really meant
Where do we put this
extra UI information
It’s nice to have implementation details
as an example to understand what the
RA was thinking
UI Information is a good
way to communicate ideas
Anything so that people
aren’t waiting for other
people to get stuff done
We should not have
to have everything
written down and
signed off to hand it
over the wall
No good way ot
fimplementing and
managing features access
products
We need to find a
better way to illustrate
requirements on a
features basis
All requirements
need to be
coordinated across
products
The process shouldn’t
impede the progress of
the project
To be honest, it’s to
painful to do a change
I don’t know where to go to get the information I need
Theme: Gaining a better understanding of the
requirement processes and how customers should be
involved
Lessons Learned: Better defections is needed for the
levels of requirements and where to get requirement
details,

2. Anatomy of a KJ Diagram
Headline
Relationship
cause and effect or contradiction
Title
Raw statement
Title with most votesTitle with second most votes
Title with third most votes
Question to ask?
Summary answer.
Time/date
Place
Participants