Chitika

Wednesday, January 12, 2005

analyzing the Requirement Gathering process

When I tried to analyze what's the best suited way for our company to perform the Requirement Gathering process, I've come across to the following resources:
- Wikipedia on Requirement Gathering
- Requirement Analysis, an article by Karanjeet Bali

Both resources have helped me a lot in performing with the definition of the Requirement Gathering process, the challenge of effective Requirement Gathering process, and how to improve on them. Specifically, the article by Karanjeet Bali has helped me to identify many quality dimensions which can be selected as the criterias for most commonly found projects.

A few points which have caught my attention:
- Most of the people conducting the Requirement Gathering process do not always have the required knowledge to understand the business process properly.
- Not all of the requirement documents I've seen have all of the following characteristics (which are considered "must-have"): clear, complete, correct, not ambiguous, testable, traceable, prioritized, and not vague.
- Not all of the requirements which have been signed off early in the project are being tracked properly throughout the project lifetime, thus any changes in functionality, scope and priority cannot be tracked.
- Since cost and time are two properties of a project agreement which are very hard to negotiate, hence only by setting priorities on each functionality/feature of the system based on user's requirements we can negotiate better whenever there's any change in the requirement itself (either its functionality, scope, and/or priority).

One of the hardest part of the process improvement is finding a way to leverage the knowledge base of our Requirement Gathering team. Since we handled many projects from many industries, it'd be hard for us to always be prepared prior to the Requirement Gathering process.

In the mean time, I'm trying to find myself some time to read Alistair Cockburn's publications, mostly related to effectively written use cases.

Further Reading:
Writing Effective Use Cases
Managing Software Requirements: A Use Case Approach, Second Edition
Agile Software Development
Crystal Clear : A Human-Powered Methodology for Small Teams

No comments:

Post a Comment