level of requirements that reach developers
Alexey Krivitsky
I'd like to ask you what is the level of requirements that reach your
development teams?
Is it :
1- high level business requirements
(defined in end-user terms)
2- software requirements defined in software terms
(requirements are preprocessed by system analysts)
3- high-level development tasks
(system analysts or architects have processed the requirements and
turned them into software architecture terms)
4- low-level development tasks
(high-level tasks have been already broken down into assignable
pieces that can be worked on by single developers)
My personal feeling is that the lower the requirements level, the less
creativity can be gained from developer's work. Any comments?
Example:
I got a change request reported by the client
"On the UI we need to remove the control X and substitute it with a control Y"
There is no problem explained under this requirement, so they should
not expect me to be creative solving their issue, I am quite limited
in thinking.
If the change request had been stated like:
"International user should not see the tax info block because it makes
sense for local users only" then I would have known the real user's
problem and were free to come up with any solution and could have even
found more similar problems.
// Alexey
Vasiliy Keretsman
> 1- high level business requirements
> (defined in end-user terms)
> 2- software requirements defined in software terms
> (requirements are preprocessed by system analysts)
Roughly speaking we have some sort of mixture of 1 and 2.
Firstly we get stories defined in high-level requirements from the
end-user point of view. But of course they are a bit more informative
than "On the UI we need to remove the control X and substitute it with
a control Y" :)
It helps us to understand the business value of the request.
During the estimation session or further discussions we clearify the
requirements and come up with more software specific details, which
are added to the story. In my opinion it is quite enough in our
situation.
> 3- high-level development tasks
> (system analysts or architects have processed the requirements and
> turned them into software architecture terms)
> 4- low-level development tasks
> (high-level tasks have been already broken down into assignable
> pieces that can be worked on by single developers)
3 and 4 are responsibilities of the team or the person who implements
the story.
> My personal feeling is that the lower the requirements level, the less
> creativity can be gained from developer's work. Any comments?
Agree with that. From my experience having only development tasks is
quite limited. In general it looks ok. I can manage with it and
perhaps i would be able to complete the task faster and with
reasonable quality. But it does not mean i couldn't do it better if i
had had the whole picture. Often during implementation a developer
comes up with better solution than that described in the low-level
requirements.
Cheers
Vasya
Andrey Borovik
I think that that's more complicated question than you think. In your
gradation you assume that the person which is responsible for
decomposition of the high-level requirements is quite skilled. But
what about if this is just a product manager which don't know a lot
about the domain.
I've encountered situations where you need to know the high-level
requirements more than the detailed one. The product was developed in
India by the team of anecdote type Indian programmers, it looks nice
and works. But don't look inside. Now you have the requirements from
the customer (not the end-user) just add this two new fields into the
Database, put this value then look through all the source code and
fine where it used in calculations and changed all the formula from A
to C+D*F. If you do that you;ll not be able to comprehend does your
solution fill the high level requirements of the end-user.
That's why I always ask the following question on the interview to the
Architect or Team Lead level persons.
A customer has asked you to write a toUpper function. The only
requirement you have is:
· It must return 'A' when given an input of 'a'.
What questions do you need to ask to flesh out the requirements? Or
just what do you need to do, or just what do you think about such a
situation.
And of course that's not about the creativity. You could be creative
if you have corresponding qualification to be creative and you are
writing the software from the scratch. Or doing somethinf you are
familiar with. In other case sometimes you need to be a little bit
more consistent when collecting requirements or changes and this
"non-Agile work" :)
--
Med Vennlig Hilsen
Andrey Borovik,
Country Manager Ukraine
Scandinavian House AS
Værftsgt. 1 c
N-1511 Moss, Norway
Alexander Aizikovsky
On Mar 16, 6:58 am, "Andrey Borovik" <andrey.boro...@gmail.com> wrote:
>... In your
> gradation you assume that the person which is responsible for
> decomposition of the high-level requirements is quite skilled.
What about a team to be responsible, rather than a person?
It would be nice to replace the term 'high-level requirements' with
'understanding of user's goals'.
'Requirements' sounds like piece of paper or some other artifact. It
may be and in many cases is a source of good understanding for
developers. But its existence by itself does not guarantee correct
implementation.
> .. But
> what about if this is just a product manager which don't know a lot
> about the domain.
If you have a choice, don't hire him or don't work him. :)
If there is no choice for you, find somebody who can help: your boss,
his boss. It's always about people.
> ...In other case sometimes you need to be a little bit
> more consistent when collecting requirements or changes and this
> "non-Agile work" :)
The work itself is neither agile nor "non-agile". It just needs to be
done.
Team's approach maybe more or less formal. If your hypothetical
requirements come to developers in a document, there is not much they
can do other than trying to be 'creative': make some assumptions and
choose the one that looks the most appropriate to the developers.
With customer-on-site or a good product manager (business
analyst, ...) there is a better chance for the developers to
understand what's actually needed.
To my mind you gave real life examples which justify applicability of
the agile approach to communication with the customer.
Cheers,
Alex