Comments on: Dimension: Requirements or Business Demands

By: Doing better » Dimension: Requirements or Business Demands « Peter Bakker’s Sketches

Sun, 27 Jul 2008 08:38:17 +0000

[...] Tags: Governance, RM, Stakeholders On the “Doing better” is an article posted about Dimension: Requirements or Business Demands: Changing or unknown requirements can be a huge source of problems for a development team. [...]

By: Peter Bakker

Peter Bakker — Mon, 17 Mar 2008 20:09:38 +0000

Austin,
For me the biggest requirements challenge is that the stakeholders should be responsible for managing their own requirements and they shouldn’t trust a temporarily project team to do it for them. A project team by nature will focus on the design and build stages of the system lifecycle and put other requirements important to the other lifecycle stages on a lower priority to meet their own deadlines. When a project team starts building there is too little time to keep managing new or changing requirements and redesign or rebuild stuff…
In theory most projects do have some external (outside the project) steering committee or governance body but in practice they most of the times do not take their responsibility but they do trust the project team fully as long as the team meets its deadlines. Stakeholders must and should be able to validate their requirements continuously and not only just before and after the design and building stages.

On my site I ended the post with the reference to this article with:
When do the stakeholders see that they must take responsibility to manage their own requirements during the total lifecycle of a system and they must do that from an outside-in view (looking to the system from its context)? And that if they need tools for requirements management it must be community-enabling social networking tools….

By: Austin Hastings

Austin Hastings — Mon, 17 Mar 2008 17:59:21 +0000

Peter,

It has never occurred to me to think of understanding requirements as a challenge. I think in general that whenever I have seen requirements being managed, the team “just knew” what the requirements were and were not. Maybe that was because of good training, or because they hired a SME for the requirements gathering phase.

On the other hand, all those RQM tool vendors offer training, so it’s probably not totally intuitive. So how can we characterize the “amount” or “intensity” of the requirements challenge? Is it worse to not know what you want to manage, or if the stakeholders don’t agree on priority?

Are there other characteristics of requirements challenges? What about social identifiers?

By: Agile Cases

Agile Cases — Mon, 17 Mar 2008 11:57:33 +0000

Doing better » Dimension: Requirements or Business Demands

On the “Doing better” is an article posted about Dimension: Requirements or Business Demands:
Changing or unknown requirements can be a huge source of problems for a development team. Fortunately, configuration management is designed to su…

By: Peter Bakker

Peter Bakker — Mon, 17 Mar 2008 11:30:47 +0000

The most confusing part about requirements and requirements management is the unclear definition of the term “requirement”. Some people are saying everything that constraints a system is a requirement other do use smaller scopes, like stating that requirements only should be in the problem space or that requirements are the implementation of rules (whatever they mean by rules).
So how can you manage if it is not clear what you want or should manage?

Managing stuff like rules, principles, interests and requirements in order to make a success of projects is a social issue and not a technical one. If the stakeholders are not willing to pursue the same goals and don’t have empathy for each others concerns then no process, method or tool will help to solve the problem of the failing projects…