Overview
This is a first post of series about Requirements Management and engineering practices. This post will talk about the importance of requirements management within a product development project, when the project could be for a new consumer product, a web site, a system or a software application. Also, I’ll write about the methodologies and the best practices in a different projects types and sizes allover application lifecycle management (ALM) phases.
Next posts will be written in case someone will request it, just keep your comment with the topic or suggest the new one.
- Popular Requirements Management Tools Review
- Requirements Management Best Practices
- Manage Requirements with Team Foundation Server (TFS)
- Generica solution for Requirements Management
Introduction
First of all, let’s answer the main question, why it is so important to manage project requirements? I think the best answer for this question is to make parallel with chess game, when the win in game equals to successful project. Before the game starts, professional chess players work hard on the game strategy.
Strategy it is a general thought process used to plan a game of chess. Strategy is more concerned with distant future moves than the calculation of tactics for the next move. The tactics in a chess game is a term used to describe a short-term sequence of moves involving threats and counter threats.
Source: Glossary of Chess Terminology by David Hayes.
In development projects requirements management is the strategy and the tactics of the Application Lifecycle Management. Next image demonstrates the requirements management role in the software quality lever.
- This data from Boehm: Software Engineering Economics.
- The picture was taken from the “Maximize the business value of the software” presentation from Borland.
The common problems of requirements management and engineering
It is two main factors that define the success of the requirements engineering and management process, methodology and the tools. It is very important that the tool we are evaluating supports the organization methodology and vice versa. Organizations spending a lot of money to evaluate and to buy the tools that promise to improve the process with build-in methodologies, features and regulation standards, but they don't analyze is the organization can adopt those changes.
Commonly, the requirement management tools are very difficult for organization adoption and integration into the application lifecycle. From my experience with the customers in 70% of cases, the end result of most popular tools like Requisite Pro and Doors has proven unsuccessful. Let’s see the common reasons for the failure.
- The price is the general limitation; it breaks the concept of data transparency and collaboration. The tool may the best tool in the world, but not for the $3 - 6,000 a seat price tag. The budget limits the access of consumers to the information inside the professional system.
- Complexity of the tools causes to any business analyst or project manager to stay out of the loop. The best work environment for this kind of consumers is to work directly on the document and to edit features as unstructured data with reach formatting and not on hierarchical tree of requirements. This fact breaks the chain; the next paragraph will show the effect of different not synchronized work environments.
- Microsoft Word into the requirements management tools, but not vice versa. Commonly requirements management tools provides a good enough way to import requirements from Word Document to the hierarchical structure. This process has side effects like conversion of Visio objects to the pictures, formatting and the other data looses. But in all of the cases there is no way to synchronize the requirements with the source document, the only way is to do this manually. As a result the information collaboration between the document workers like business analysts, consumers, etc is damaged.
- Multiplicity of professional tools at ALM is a real problem, the integration between the tools is not nature, all project information not available from the single user interface and no way to analyze and manipulate with full project information. For example, if the document management system not integrated with the requirement management tools the configuration and the changes management become to be the hard manual work.
Requirement Management tools evaluating tips
- First of all I'm really recommend to use consulting services from the start of tools evaluating process to the methodology definition and the tool adoption, good consultant's experience will save you a lot of time and money.
- Try to sign site license contract with the software vendor, if this option not relevant for your organization the recommended price tag for seat license should be around $200 - $400.
- Check the tool integration and bidirectional synchronization of requirements within the Microsoft Word documents. Generica product is the leader in providing solution for this market.
- Try to buy one generic and customizable product for full application lifecycle management. Team Foundation Server with Visual Studio Team client from Microsoft is a good sample.
- Check the features of the product, it should contain the most important features, like traceability, data control and analyze features.
- Test product's technical characteristics like scalability, performance, security, etc.
Hope this post was useful and helps to choose the best product for your organization.