Requirements Tools, Repositories, and Management

Few excellent requirements tools are available to BAs. As vendors learn about the needs of BAs, more flexible requirements tools will be developed. Vendors must be aware of the requirements components and the importance of traceability and impact analysis. A requirements tool that does not allow an analyst to break down requirements to their lowest level or link them together is no more useful than a simple drawing tool or word processor.

A repository is a place (physical or conceptual) where “things” are stored. A requirements repository is the place where project requirements will be stored. They should be stored in a permanent repository for reuse on future projects.

Requirements may be stored only in the minds of the project team members.

They can be communicated verbally and never written down. This is not recommended because relying on people’s memories is dangerous. Document requirements in any location or format available. The requirements repository may be a series of flip charts hanging in the project room. It may include index cards with user stories. The repository may be a directory on a server which contains many files (Microsoft Word documents, Excel spreadsheets, Visio diagrams, etc.). An organization may use virtual or shared document management software. On the most formal end of the spectrum, there are commercially available requirements repositories that manage and maintain requirements in very sophisticated database management systems (e.g., IBM Rational Requisite Pro®, IBM/Telelogic DOORS®).

Summary of key points

Every business analysis project requires the use of analysis techniques. An analysis technique provides a structured, thinking approach to help the BA understand a business problem, opportunity, and requirements from different perspectives and different angles. BAs should be able to use many techniques and know when each technique will be most effective.

• The core requirements components of data, process, business rules, and external agents must always be considered. There are analysis techniques that focus on one particular component (e.g., data modeling) and techniques that identify multiple components at the same time (e.g., use cases).

• BAs must be aware of the difference between business requirements, solution requirements (functional and non-functional), and technical requirements or specifications.

• BAs use analysis techniques not only to understand the business needs but also to communicate them to all of the project stakeholders.

• Business stakeholders must feel confident that the analyst understands their true needs and will represent them accurately to the solution team.

• The solution team stakeholders need clear direction on software functionality to be built.

• The SQA and testing team need an understanding of the proposed solution so that they can design effective tests.

• BAs should work with their PMs to determine the formality of requirements packages and milestones for stakeholder approvals.