Dec 6, 2008

Has Requirement gathering actually evolved?

Reactions: 
Technologies have evolved, Softwares have become smarter, the development  time is now minimal for IT applications. But the Software Development Life cycle has  still not Shortened. The amount of time consumed in requirements has increased over the period from 24% to  45%.
Here are the problems that I see : 

1. There isn't any defined set of methodologies for Business Analyst. The Best practices are not defined, the 'must haves' are not defined. 
2. There is no way to  validate requirements, code can be tested and many testing tools have evolved  to help in testing. But the  point is requirements that are elicited are often not validated.
3. The quality folks are often not involved from Day 1, the requirements are so  textual that the business imperatives are often lost in English. The use cases are either too  short or to descriptive and the business often has no clue that what this 100  page document is for. 
4. The use case best practices are for  designer and developers to understand  not for business stakeholders to  validate. 
5. New methodologies and best practices like design patterns have made software development  more robust and quick, but requirement Analysis  still remains  unchanged.
6. Though use case are good to capture detail  requirement, but methodologies to capture the business process/requirements have still not evolved. 
7. Parallel  Methodologies like agile are too much implementation oriented and pay less emphasis on requirements and companies find it difficult to use them for big projects.
8. Business Analyst are often not trained in handling difficult stakeholder, 'Business' accountability and availability is missing. 
9. And the worse, I have seen many companies where the  Business Analyst  is  not involved  through out the project and developers/designers keep on reinventing the wheel again and again. Blame is one the service provider for not able to convince the client, the project manager who often feels insecure  by BAs presence as SME and fears loosing control of the team .
Lack of collaboration, poor Project Management leads to more investment in rework rather than in innovation .

The Quality of your requirements  is a function of how good the Business Analyst is. Templates and Quality guideline will not help in making the sure that the requirements are up to the point but only to adhere to the quality checklist of your organization.
So how to  make sure that the Business Analysis as a field get some its own set of best practices ?
Let us all share our individual best practices that we have gained from our project experience.




0 comments: