aspose file tools*
The moose likes Agile and Other Processes and the fly likes Requirement management (Instability, incongruence) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Requirement management (Instability, incongruence)" Watch "Requirement management (Instability, incongruence)" New topic
Author

Requirement management (Instability, incongruence)

Handel JU
Greenhorn

Joined: Oct 22, 2004
Posts: 1
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.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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 of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
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


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Requirement management (Instability, incongruence)
 
Similar Threads
How Groovy should be used with big projects?
Role of a Architect
Hierarchical Designations in IT Industry
Requirements Elicitation - Templates wanted
Whats are drawbacks of Agile methodology?