Jaa

Requirements Perspectives

  • Artikkeli

Here's a simple set of perspectives I use for rationalizing requirements:

  • User
  • Business
  • Expert / Technical
  • Industry/Standards

Believe it or not, simply identifying these perspective helps a lot.  You'd be surprised how many debates happen simply because nobody explicitly identified the source or perspective of the requirement.  You'd also be surprised how quickly this helps you make more deliberate decisions and understand what you trade. 

How does this help?  Your business goals might be a n orders per hour.  Meanwhile, your user wants sub-second response time.  Well, that's what your users want, but what will they tolerate?  Can your business afford the resources for an idealistic experience?  Design is always about trade-offs.

In practice, I generally see industry/standards trump business trump expert/technical, trump user.  Unfortunately, a lot of software has unconsciously catered to the expert/tech/business at the expense of it's users -- making a lousy experience.  On the flip side, some software has catered to users at the expense of the business or industry goals.   See the dilema? 

You can make a difference.  If you build software, know the perspectives, know the goals, and know the scenarios.  In some contexts, some tech/expert reccomendations simply do not make sense.  Know what you're optimizing.  In some scenarios, industry/standards reign, while in others user experience is king.  Make sure you have the right representation at the table.  Don't ask your patient to prescribe the medicine, or your doctor to rate the taste.

Comments

  • Anonymous
    March 09, 2007
    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.

  • Anonymous
    March 09, 2007
    The comment has been removed

  • Anonymous
    March 09, 2007
    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!