Are We There Yet?
In my previous blog (http://www.batimes.com/articles/requirements-development-101.html), I described requirements development (RD) and its activities. After reading the blog, some of my customers inquired “just how long does it take to do proper requirements development?” Honestly, there is no set time to this question. However, I can categorize some environmental factors that can extend the time required for proper requirements development. You should add time to your RD schedule in the following situations:
- Skill level of the analyst and process maturity –
- if the project has less experienced analysts;
- if there are no standard RD activities or documentation in place;
- if there is no reuse of the requirements;
- if there are no peer reviews throughout the RD phase;
- if you don’t store requirements in a single repository.
- User involvement –
- if there is none or very little user involvement or
- if there are many types of users.
- Stakeholders’ response time –
- if the stakeholders are not co-located;
- if there are languages or cultural barriers;
- if key decision-makers with conflict resolution power are not identified.
- Project size and complexity –
- if you are building a new application versus rewriting a legacy application;
- if you are re-engineering your processes AND building the application at the same time;
- if you have external interfaces;
- if the developers or testers are not knowledgeable in the application being defined.
I always tell my customers to use historical data when determining the RD effort and adjust their time estimate by addressing the above environmental factors. If you don’t have historical data, then it’s never too late to start collecting some metrics from your current RD efforts. Unless you are following a strict waterfall methodology, I wouldn’t create a onetime estimate from my entire set of requirements, but instead create estimates for each incremental phase. Also, I set the expectation that with each incremental phase, the estimates will change, but they will also be more accurate because you will know the health of your project better as you execute through its life cycle.
For example, Agile projects have numerous, very small RD phases. Agile teams do “just enough” requirements definition before proceeding to development and testing. This allows for the users and stakeholders to rapidly provide feedback to the analyst, which results in improving the requirements development efforts with each iteration. The length of time of an increment doesn’t matter as long as the stakeholders and users understand the requirements for that specific iteration. If they don’t, then you will repeat the rework efforts of the past iterations.
Whenever a customer asks me “Are We There Yet?”, it leads me to believe that they want to speed through the requirements development phase – just to say they did it. It has been shown that spending more time on requirements can accelerate software development by decreasing rework activities. We all know that requirements issues are one of the major causes for project pain.
The Standish Group asked their survey participants about the reasons that cause their projects to be” challenged”. Below are the percentages reported by their CHAOS Report, they define “challenged” as “the project is completed and operational, but over-budget, over the time estimate, and with fewer features and functions than initially specified”:
|Project Challenged Factors||% of Responses|
|1. Lack of User Input||12.8%|
|2. Incomplete Requirements & Specifications||12.3%|
|3. Changing Requirements & Specifications||11.8%|
|4. Lack of Executive Support||7.5%|
|5. Technology Incompetence||7.0%|
|6. Lack of Resources||6.4%|
|7. Unrealistic Expectations||5.9%|
|8. Unclear Objectives||5.3%|
|9. Unrealistic Time Frames||4.3%|
|10. New Technology||3.7%|
This indicates that three of the biggest issues leading to project pain are due to poor requirements engineering. What this really means is that when the project was delivered, there was a difference between what the stakeholders and users needed or wanted, and what the developers built. Better software requirements can lessen this difference, which can provide numerous benefits to all the project members.
- Project Managers – Better requirements enable organizations to effectively decide which projects to fund because better requirements show a more precise estimation of business return on investment.
- Product Mangers – Once a project is selected, better requirements help in the assessment of effort and resources because the complexity of the requirements can be correlated to development and testing efforts.
- Analysts – All features may not not be able to be delivered, so better requirements allow the team to prioritize the features more effectively. This will make certain that the project executes the most important functionality.
- Design and development teams – Because requirements establish product design, better requirements facilitate the design and development team to more effectively select the right solution.
- QA teams – Better requirements allow the prioritization of features thus enabling the testers to focus on developing the important test cases first.
As we know, it is more expensive to fix defects later in the software development cycle than during requirements development. Consequently, your company’s profits can be influenced and correlated to requirements issues. Therefore, it is crucial to invest in better requirements activities rather than solely worrying about how long it takes to do proper requirements development. This estimation will improve with time once you’ve established a good requirements practice.
Don’t forget to leave your comments below.
Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.