RE: user requirements vs business requirement

16 May 2005 - 11:03am
8 years ago
6 replies
3136 reads
Sanchez, Mario
2005

Billie Mandel wrote:
> My question: How have you (or have you at all) gone about defining
> "business requirements" gathering as opposed to "user requirements"
> gathering, and how have you defined that line/divided the work between
> IxD and product management?

No matter how much you talk about User-Centered Design, it only really makes sense within the framework of Value-Centered Design:
http://www.boxesandarrows.com/archives/searching_for_the_center_of_design.php
http://www.boxesandarrows.com/archives/images/090803_mcmullin/mcmullin_090803.gif

What you're really talking about here is 3 sets of steps combined into one process:
1. Identifying business requirements (cost, roi, strategy, etc)
2. Identifying user requirements (needs, features, utility, usability, etc)
3. Bringing 1&2 as the full requirements set to design an appropriate business solution.

Product Management is definitely charged with #1. The IxD community (and various of the related disciplines) are charged with #2. Both of the above, plus the technologists / implementation folks all need to have a voice in #3. The individuals who actually do the work may vary based on size & maturity of the organization, though.

Mario Sanchez

Comments

16 May 2005 - 8:20pm
Dave Cronin
2005

Billie Mandel wrote:
> My question: How have you (or have you at all) gone about defining
> "business requirements" gathering as opposed to "user requirements"
> gathering, and how have you defined that line/divided the work between
> IxD and product management?

We typically uncover Business Requirements through discussions with stakeholders at the outset of a project. We consider them to be the providence of Product Management, Marketing and Sales, but they are a critical input to our activities. They should to be defined by people responsible for the profitability and business outcome of a product, but we ultimately subject them to analysis in light of user research.

Mario Sanchez wrote:
> What you're really talking about here is 3 sets of steps combined into one process:
> 1. Identifying business requirements (cost, roi, strategy, etc)
> 2. Identifying user requirements (needs, features, utility, usability, etc)
> 3. Bringing 1&2 as the full requirements set to design an appropriate business solution.
>
> Product Management is definitely charged with #1. The IxD community (and various of the
> related disciplines) are charged with #2. Both of the above, plus the technologists / implementation
> folks all need to have a voice in #3. The individuals who actually do the work may vary based on size
> & maturity of the organization, though.

This is a nice clear articulation.

In most cases, business requirements ought to be the starting point of a product design or redesign effort and IxD work should be aiming to satisfy business goals as it defines the product.

The one catch is that it is frequently the case that after doing user research and analysis, it becomes clear that some business goals are not achievable.

Off the top of my head, examples include a product that would appear to be viable through market research, but can't be delivered at a given price point, or one where the targeted consumers may not own techology infrastructure to support the product, or something that isn't feasible given development constraints (e.g. we could make a bundle if we could deliver a product that "allows non-programmers to write code", but it has to ship in 6 months).

Maybe this is what Mario is suggesting with #3. Ultimately, after Product Mgmt has defined Business Requirements and IxD has defined User Requirements (and validated Biz Reqs), Product, IxD and Dev all get together and reconcile what the product must accomplish.

-dave

19 May 2005 - 4:37am
Narey, Kevin
2004

I've been interested in this requirements issue for a while and want to add
another dimension to this if possible. In traditional methods(ie one's that
have been around for say 15+ years) there has been a 'requirements
specification' in the form of a written document, passed around a project
like a peace-pipe in the hope that some of it sticks. There-in lies the real
issue. The audience of that document is too wide to be able to communicate
what the requirements are and therefore it's value is greatly diminished. A
good example of this is in this document. Your user requirements probably
fall into the 'non-functional' requirements mentioned, although
non-functionals are often seen as business requirements:

http://www.volere.co.uk/template.pdf

This type of communication is representative of how my (traditional) company
has dealt with requirements for many years, until they realised that it was
not only cumbersome, but suffered accutely from exclusive language written
by analysts not understanding their audience. The main problem is the lack
of visual cues and can easily be solved by having the prototype (or UI
Conceptual Model) as the bringing together of all of those requirements;
ultimately becoming the requirements deliverable sign-off. It enables all
types of requirements to be visualised, rationalised and validated through
it's usage and testing. If supporting documentation is needed, such as the
description of workflows and scenarios and the project can afford that, then
great. I've found that the controlled gathering of requirements through
visualisation is very powerful due to it being a common visual language.

The bottom line for me is that real caution needs to be exercised when
putting granularity into requirements. I've seen much time wasted on
projects trying to understand which bucket a requirement falls into. To me,
the business and the user etc are two highly inter-related components in one
product/solution entity and should be treated as such. I understand,
however, that this method cannot necessarily be applied in all instances and
that some 'savvy' customers demand granularity in requirements.

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

20 May 2005 - 4:00am
Narey, Kevin
2004

> The methodology that nicely addresses all this is "use cases".......
Addressing the type of communication issue posted by Kevin Narey. Squashing
it, in fact.

I couldn't disagree more.

I have never once worked with anyone or in an organisation where use cases
were written to the point where everybody understood what was going on. That
to me makes them a second (by a country mile) to a well considered UI Model
or Prototype. You cannot easily validate your design by testing use cases on
users.

Use Cases have become a programming ideology that if written perfectly they
would surely be of significant value. They are never, ever (IMO) written
perfectly - show me a set of perfect use cases if you can and I'll humbly
submit. If you put the same amount of effort into building a prototype, then
every stakeholder understands what is going to be built and can modify and
rationalise scenarios and workflows according to business cases through that
prototype.

Use cases are a language that *all* stakeholders must learn - a totally
unreasonable burden on most users especially when they are not given any
visual cue as to what the scenario is. If they can see or visualise a model
that satisfies their goals, there is less problem with interpretation.

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

20 May 2005 - 5:42am
Petteri Hiisilä
2004

Sanchez, Mario wrote:
> No matter how much you talk about User-Centered Design, it only really makes sense within the framework of Value-Centered Design:
> http://www.boxesandarrows.com/archives/searching_for_the_center_of_design.php

I like the term "Return on Experience". Even executives might understand
that kind of language :)

Of course it's still not measurable in dollars, but at least it's
another way to explain the difference between a good digital product and
a bad digital product. Some products have better ROE than others. High
ROE generates customer loyalty, which generates continuity and growth
for the business.

Best,
Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"I was told there's a miracle for each day that I try"
- John Petrucci

19 May 2005 - 12:23pm
Juan Lanus
2005

Billie Mandel asked:
> My question: How have you (or have you at all) gone about defining
> "business requirements" gathering as opposed to "user requirements"
> gathering ... (trimmed)

Mario Sánchez wrote:
> What you're really talking about here is 3 sets of steps combined into one process:
> 1. Identifying business requirements (cost, roi, strategy, etc)
> 2. Identifying user requirements (needs, features, utility, usability, etc)
> 3. Bringing 1&2 as the full requirements set to design an appropriate business solution.

Hi all,
As I see it, and without having much experience, both business
requirements and user requirements are user requirements.
It is a matter of the distance you are looking at the picture.
A close look is fore user reqs. A close look with a magnifier glass is
for software detail.
Far looks can be deparrtament-wide, or enterprise-wide.
The word "users" somehow leads us mentally to the guy who is driving
the keyboard or wheatever. This is right, that's what a user is.
As of requeriments, instead of "users" I prefer "stakeholders". This
immediatly brings up everybody, including the teller, all management
levels, the company owner and the gov regulations agencies. In case
you can't talk to users then you synthesize them thru "personas".

The methodology that nicely addresses all this is "use cases". Not
some UML geeky oval diagrams but the textual sort.
Use cases are documents created and agreed upon by both users
(stakeholders) and designers. Recall that stakeholders are them all.
The great advantage of use cases is that they can be read by anybody,
down to and including software developers. Addressing the type of
communication issue posted by Kevin Narey. Squashing it, in fact.

Billie's original issue is addressed by use cases too, by meens of
their granularity.
One of the best ideas that come with use-case methodology is the
"blackboxing" of the to-be-designed system or device. It's implemented
by regarding the SUD ("System under development") as a black box. It's
logical: you can't talk about it's inner parts if it does not exist
yet. The use case describe what the users need to do with the SUD and
it's responses, but not what happens inside it (this is design, the
following step).
So back to Billie, requeriments are "business " when the blackbox is
the company, and "user" when the blackbox is one computer program.

You might want to see these links: the seminal article and *the* book
which includes a sound communication of the idea and a very useful
how-to tutorial too.
http://alistair.cockburn.us/crystal/articles/sucwg/structuringucswithgoals.htm
http://www.amazon.com/exec/obidos/tg/detail/-/0201702258/
--
Juan Lanus
TECNOSOL
Argentina

20 May 2005 - 7:54am
Juan Lanus
2005

On 5/20/05, Narey, Kevin <Kevin.Narey at gedas.co.uk> wrote:
> Use cases are a language that *all* stakeholders must learn
You mean use cases written in plain English as apposed to UML
diagrams? If you mean those diagrams then we couldnt agree more.
Yes the other kind, textual use cases, is sort of a language. And yes,
those involved have to learn something, IMO not much.

Kevin also wrote:
> ... a well considered UI Model or Prototype.
> You cannot easily validate your design by testing use cases on users.
> prototype ... then every stakeholder understands what is going to be built ...
Use cases are not about UI design but for capturing functional requeriments.
A prototype sounds like an almost finished desing to be seen by the press.
While in the step of capturing reqs it seems to be better not to think
design at all because of the danger of getting trapped. There is
literature about paper mockups as prototypes because paper mockups
don't seem so "finished".

Use cases address the task of finding out how the prototype has to
behave, it'a a previous step.
For example see Lada Gorlenko's posting. She writes about "Business
Usability Needs (BUN) and Roles and Goals (R&G)".
This sounds to me planning before doing, the cure to sooo many
troubled IT projects.

You are quite right in that writing excellent use cases is not easy,
it seems to require a lot of work. I write mediocre use cases,
sometimes with some sloppyness to shorten times I find that they are
anyway very useful.
At some point in the path from not having it to yes having a nice
product an effort has to be done. Everybody agrees that the sooner,
the better.
The worst scenario is coming out with the finished thing and hearing
"Gee, this has to be changed a lot!" and finding out information you
should have known in advance.
Use cases are the methodology for collecting such information.

In my dreams I foresee a tool that given a use case set could
synthetise a working prototype.

Regards
--
Juan Lanus
TECNOSOL
Argentina

Syndicate content Get the feed