risks and requirements

[keithray homepage.mac.com/keithray/blog/]

Agile Modeling can fit into two (or more) methods: Rational Unified Process,
and Extreme Programming. Both of those methods ALLOW business analysts to
be involved (RUP probably recommends it more strongly).

In Extreme Programming, rights and responsibilities are divided between "business"
and "developers". The "business" side has the business analysts, the QA testers,
domain experts, users, stakeholders, and so on. All wrapped up in the single
word "Customer" in XP lingo.

The "developer" side has the programmers, DBA, and so on. User interface
experts may be either side, depending on whether they do programming as well
as user interface design.

The two sides are clearly divided (but on the same team) to reduce risks:
if the business guys (who are not programmers) start telling telling the
developers how to do programming, they risk technical failure. If the programmers
tell the business guys what features should be implemented, there is a risk
that project will not meet business needs, and instead become a playground
for developers.

If you have business analysts in your team, it is the job of business analysts
to help a stakeholder come up with requirements. Some developers are also
skilled analysts, others are not.

> I'm being over-dramatic on purpose, but when you say
> that I "know what I want" I am here to tell you that I very frequently
do not
> know what I want. You might argue that it's in my head somewhere and it
just
> has to be brought out. OK, it might be. <she says with doubt in her voice>
But
> I am not going to be able to get it out by myself. That's just not going
to
> happen. And we cannot be mealy-mouthed about the fact that it is the
> developer's JOB, RESPONSIBLITY, to help me. If you agree with that statement,

> then this is what I meant when I said that I perceive a contradiction.


I find this "fear of requirements" interesting. I've been in software development
for close to 18 years, and this is first time I've ever met someone expressing
this sentiment.

When talking about what to ask the genie in the magic lamp, (which is what
software developers are) I've never seen anyone with a lack of ideas. They
may not know HOW to get what they want, but they always know enough of what
they want to say something. Things like...

"Wouldn't it be great if ...."
"Could you make it so that ..."
"I want this..."
"Our customers are doing this manually, and we want to sell them software
that does it for them..."
"This is what I do all day, I want it simpler and faster."
"Make it do this."
"Our competitor has product x, we need something like that."

The great thing about agile projects, is that you DON'T have to ALL the requirements
up-front, just enough to get started. Once you see the software working (minimally),
you can change your mind about the requirements that are not yet implemented
or have been implemented.

The business side is responsible for the requirements, because they are
responsible for running their business. To avoid this responsibility is to
let the developers run your business; unless the business is about making
tools for other software developers, it's unlikely that have the expertise
to satisfy your customers and make a profit.

Recommended reading:

"Exploring Requirements: Quality Before Design" by Gerald M. Weinberg
<http://www.amazon.com/exec/obidos/AS...ithraymacco-20>

"Planning Extreme Programming" by Kent Beck, Martin Fowler.
http://www.amazon.com/exec/obidos/AS...ithraymacco-20

[Dennis Bronstein]

<keithray homepage.mac.com/keithray/blog/> wrote in message
news:3e9056a9$1@tnews.web.devx.com...

> The two sides are clearly divided (but on the same team) to reduce risks:
> if the business guys (who are not programmers) start telling telling the
> developers how to do programming, they risk technical failure. If the
programmers
> tell the business guys what features should be implemented, there is a
risk
> that project will not meet business needs, and instead become a playground
> for developers.
>
> If you have business analysts in your team, it is the job of business
analysts
> to help a stakeholder come up with requirements. Some developers are also
> skilled analysts, others are not.

This is the part I don't get in this discussion. It's been pretty clear in
my experience as a developer that the only input developers should have into
requirements is giving an estimate of how long it will take to implement
them. Having developers help define requirements is like having end users
help design the system architecture.

> I find this "fear of requirements" interesting. I've been in software
development
> for close to 18 years, and this is first time I've ever met someone
expressing
> this sentiment.
>
> When talking about what to ask the genie in the magic lamp, (which is what
> software developers are) I've never seen anyone with a lack of ideas. They
> may not know HOW to get what they want, but they always know enough of
what
> they want to say something. Things like...
>
> "Wouldn't it be great if ...."
> "Could you make it so that ..."
> "I want this..."
> "Our customers are doing this manually, and we want to sell them software
> that does it for them..."
> "This is what I do all day, I want it simpler and faster."
> "Make it do this."
> "Our competitor has product x, we need something like that."

I agree. I have never worked with any end users/customers who didn't know
what they wanted. There have been times when they have had trouble
expressing it clearly - which is where a good business analyst really
helps - but they always know what they want the software to do.

> The business side is responsible for the requirements, because they are
> responsible for running their business. To avoid this responsibility is to
> let the developers run your business; unless the business is about making
> tools for other software developers, it's unlikely that have the expertise
> to satisfy your customers and make a profit.

Exactly.

[Mike Mitchell]

On Mon, 7 Apr 2003 08:43:39 -0600, "Dennis Bronstein"
<dbronstein@yahoo.com> wrote:

>This is the part I don't get in this discussion. It's been pretty clear in
>my experience as a developer that the only input developers should have into
>requirements is giving an estimate of how long it will take to implement
>them. Having developers help define requirements is like having end users
>help design the system architecture.

Developers should not even need to be consulted on the time
requirements! If the tasks required to produce a software application
were properly standardised, measurable, quantifiable and capable of
being verified, all designers would be able to consult a standard work
to determine how long a project should take.

Software production is far too much like the activity of World War One
fighter pilots, seat-of-the-pants being the fount of all decisions,
and every minute bringing new challenges and new dangers.

MM