Requirements Perspectives

re: Requirements Perspectives

JD Meier — Sat, 10 Mar 2007 07:13:23 GMT

Here's a scenario that ties it all together. A user wants to update their customer's records. The user doesn't think to ask you not to leak their personal info and to provide decent performance. They just expect it. With your Kano hat on, you'll explicitly surface these potential dissatisifers. Tech perspective says, use Windows authentication to improve security. HIPAA champ says protect your patient's PII (personally identifiable info). Biz analyst says, we just want to reliably process customer entries, in an accountable way ... Don't care how ... Don't care if our users enjoy the experience.

A common mistake I see in practice (er, malpractice), is a generalization of "customer." If I only bring my biz analyst to the table, I could have some serious usage dissat. If I bring my end user to the table, I can expect them to tell me their ideal user experience, but I can't always rely on them to think of business goals or constraints, or details like protecting customer records.

Assume you brought all the right reprsentation to the table, and you got your pool of requirements. How do you keep perspective across your team as they prioritize, slice and dice requirements? I use the perspectives in conversations, so teammates know when their acting on a business impact vs. a user experience vs. a tech decision vs. a MUST, non-optional industry constraint.

... and YES, trumping is VERY context-driven!

re: Requirements Frame

orcmid — Sat, 10 Mar 2007 04:12:59 GMT

I'm not sure how Kana qualities line up here. I would also like to see a concrete example (however disguised/mythical) so I could be certain how these are lined up.

I would think that what trumps what is highly situational. I can see that it is important to expose what the ranking is and what the conditions are.

Am I trying to make this deeper than it is? [Hey, got me thinking!]

re: Requirements Frame

James Waletzky — Sat, 10 Mar 2007 03:51:41 GMT

Kano satisfiers and dissatisfiers seem like a natural fit to this discussion, particularly when determining what makes a customer really happy.

I also like to categorize requirements on the functional/non-functional axes. Perhaps that is just another level in your frame. Spelling out the non-functional requirements give you a better indication of what quality really means for what you are building.