• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Requirement management (Instability, incongruence)

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

Questions:

(1) If you are facing constantly requirement change (instability), How do you deal with it?

(2) what you will do to reconcile the difference if you find that the users and your perceived requirements differ?

(3) If you find significant difference between the level of information that the project team including analysts and users required to complete the job and the level that team process during requirement elicitation, how do you deal with it?

(4)If you find significant difference between the necessary level of agreement and understanding (in your opinion) needed during requirement elicitation and the actual level currently the project team shares, how do you deal with it?

Thanks a lot.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Handel JU:
(1) If you are facing constantly requirement change (instability), How do you deal with it?

By getting all parties to commit to shorter but stable periods within which no requirement changes are accepted and letting any requirement changes happen in between two such periods, a.k.a. iterations.

Originally posted by Handel JU:
(2) what you will do to reconcile the difference if you find that the users and your perceived requirements differ?

Update the requirements to match our improved understanding of the user's wants and needs? Maybe you're looking for a slightly different type of an answer...?

Originally posted by Handel JU:
(3) If you find significant difference between the level of information that the project team including analysts and users required to complete the job and the level that team process during requirement elicitation, how do you deal with it?

I didn't quite get what you're asking here?

Originally posted by Handel JU:
(4)If you find significant difference between the necessary level of agreement and understanding (in your opinion) needed during requirement elicitation and the actual level currently the project team shares, how do you deal with it?

Make the whole team communicate. The agreement and understanding will not improve by having someone from each side sit down and negotiate. Yes, they may achieve an agreement but the team is hardly committed to that agreement if they don't feel that they have actively participated in it.


By the way, are these questions from some kind of a project management exam?
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Constant requirements change is the norm. Accept this as reality. Many traditional methods are in denial of this and put change preventions, oops I mean change management, processes in place. This is an artificial and ineffective way to deal with the issue. See http://www.agilemodeling.com/essays/agileRequirements.htm#ChangeManagement.

If there is a difference between what the developers think need to be built and what the stakeholders think should be built then you need to communicate with them more to determine what should be done. In the end it's their money, not yours, so they're the ones that should call the shots. See http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm for a discussion of rights and responsibilities.

If you don't have sufficient stakeholder participation then go to senior management and fight for it. Anything else is incompetent, IMHO. If the time of your stakeholders is so valuable that they can't work with your team, cancel the project and divert its resources to help those people because clearly this would be a better thing to do. Whenever I point this out to senior management I've gotten the access that I need to my users, EVERY SINGLE TIME. I hear a lot of people complain about not having access to stakeholders, and I hear a lot of pathetic excuses for why this happens, but I rarely hear about people actually deciding to deal with the problem effectively.

- Scott
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Great answers, I may just add some spin ...

For #1, try not to plan too far ahead. Any investment you make in planning, analyzing, designing things that later change is spoilage. I used to chide management about the difference between precision and accuracy. We had very precise plans that were completely wrong after the first day. Why invest in making them? BTW: I don't have that complaint any more. Try to find "barely sufficient" planning for the next iteration.

For #2, rapid iterations of delivered software may still be too long. Look at how you gather and express requirements. Can you move from ambiguous asynchronous e-mail to interactive paper prototyping and acceptance test authoring? More precision in requirements doesn't have to mean heavy, document-laden processes, maybe just asking better questions.

For #3 & 4, a mismatch of what's delivered to what's needed sounds like waterfall-style handoffs. See if you can turn the whole thing into a more continuous process. We try to have our customer (proxy), QA and developers in close touch from start to finish. We're not happy with the degree of collaboration yet - it takes some real discipline to keep developers from going into heads down coding.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic