A recent analysis of enterprise software initiatives and of commercially available requirements management tools determined that 91% of participants used word processing programs to define and document system requirements. Many people believe that a simple list is sufficient to identify and communicate requirements to the development/implementation team. Still, from a practical perspective, it’s important to point out that Word Process applications were not designed for documenting and tracing requirements.
Also, large word processing documents are not easily reviewed, shared, or amended across the cross-functional teams of business and technology users involved in a project roll-out. This approach also results in extreme version control issues and ideas and suggesting being overlooked. Reviewing large text-based documents often results in missing requirements or defects not detected. In addition, using documents, feedback from stakeholders rarely occurs until the individuals are affected, which can be as late as during testing or development.
To be effective, requirements development should be incremental, iterative, and collaborative. Stakeholders should be able to review requirements as they are developed and make comments when they feel that the requirements do not address their needs. Comments should be documented and tracked. Organizations should use a collaborative tool to define requirements and not a word processing application that was never designed to develop or manage requirements.
With projects needing collaboration and interaction to succeed — and requirements needing to be created, collected, and easily applied — the notion of using large text-based documents is simply flawed. Nevertheless, it doesn’t stop companies for compiling single gigantic text documents, and then being frustrated with poor results and dissatisfied users.
Rather, the focus for effective requirements management needs to shift from document-centric to data-centric. Requirements should be managed in bundles that can be accessed, reviewed, and enhanced online. These bundled requirements should be more than just text. They should reference a wealth of data, including graphics, stakeholder comments and clarifications, and information on regulations, competitive offerings, company policies, and business rules. To access this data, stakeholders and developers should be able to use flexible search capabilities and hierarchical links of structured information.
Failure to use the right tool for defining requirements will result in an unhappy business community because of issues such as:
- Missing or Incomplete Requirements – It is always best to elicit, analyze, and specify requirements in a structured fashion. It is very difficult to accomplish this using a general-purpose tool such as Word or Excel. Failure to gather requirements in a structured fashion often leads to incomplete requirements, which is one of the major reasons for project failure according to a study by The Standish Group.
- Misunderstood Requirements – Good requirements are generally documented with more that text. Supplemental requirement documentation may include graphic illustrations, discussions, business process models, videos, and links or references to other documents. It is difficult if not impossible to capture this type of information in Word or Excel. Requirements are often misunderstood when they are not elaborated with additional types of information.
- Lack of Support for Requirements – Buy-in and active stakeholder support is essential for developing good requirements as the foundation for software development and testing. People are reluctant to buy into a gigantic text based document which they did not author. These large text documents are intimidating and overwhelming for most people; people provide a cursory review and reluctantly accept them, but do not buy in to them. A collaborative tool works significantly better than a large text based document to get stakeholder participation and buy-in.
- Incorrect Requirements– Requirements documents that are created using a general purpose tool such as Excel or Word usually are usually stored on the author’s computer, and are not accessible by others in real-time. This makes it difficult to share, discuss, validate, and track changes, which frequently leads to incorrect requirements. When word documents are distributed, the author loses control and almost always has a version control problem. Redistributing different versions of the same word document is error prone, awkward, and simply not practical for large teams. Requirement teams should be able to view, edit, and comment on requirements in real time.
- Lost Requirements – It is easy for requirements to drop through the cracks when using general purpose tools such as Word or Excel. Critical requirements can be lost when the author forgets, is reassigned, or leaves the organization. The collaborative tools need to provide a comprehensive trackability.
- Inability to Support Iterative Development – Many organizations are using agile or other forms of iterative development. Many of these methods require prioritization of requirements and organization of the requirements into a bundle that fits a development iteration. It is simply impractical to try to accomplish this with Word. The iterations are very short and the team must know what the requirements are before the iteration begins. This requires a data driven approach to requirements versus a document driven approach as the requirements are maintained in backlog, sized and prioritized. Using the sizing and priorities, requirements are identified and planned for development iterations.