In the context of a software project or application, requirements management is the translation of the business goals and objectives into a realized, software-enabled business process. Requirements are really a complex chain of business, technical, functional, performance and security requirements that drive a complex chain of activities with a lot of involvement from roles across both the IT and business sides of the organization.

When the goal is to translate business goals/objectives into a realized software-enabled business process, you have to think about it from both a business and a technical perspective. From a business perspective, how necessary is this requirement? What is the priority? How clear are you about what the business is asking for? Does it work? Does it perform? Is it secure? Whether it is built with Java or .NET isn’t important to the business – it’s important to IT. You need to understand the business goals and objectives AND you have to care about the IT approach and impact. From an IT perspective, is the requirement complete, attainable and realistic? Can we get this done given our competency? Given the infrastructure we have in place? Given the application/technology at play? And, most importantly, is it verifiable – how can I prove we’ve realized this requirement?

The challenge lies in the huge number of requirements, the many levels of requirements (depth), the inter-relationships between requirements (breadth). The magic is in getting the right set of requirements defined to the right level of detail, from both the business and technical perspectives, in order to understand the complete requirement. We believe this is a strategic control point in the requirements management process – if you don’t get it right, even if you do everything else perfectly, you will fail in the end if you have not delivered against the requirements.

The first strategic control point when addressing requirements management is to elicit the requirements and understand what the business is asking for. How do you translate the business goals and objectives into what is feasible and possible, realizable and implementable from an IT perspective? A picture is worth a thousand words in terms of articulating how things link together.

In addition, many requirements management systems are standalone –they are not connected downstream to the systems you use to build them. And, as you move forward with a project, things are almost always fluid – you can’t just take a snapshot of a requirement at the beginning and assume it won’t change during the lifecycle of the application So, the second strategic control point is to ensure that the requirements are connected in a closed loop system throughout the process with the downstream execution activities through development, testing and verification of functionality, service levels, security, scalability and delivery. How do you validate you’ve met the requirement?

We believe it starts upstream with what the business is asking for in aggregate, the demand and the portfolio decisions. Then, when you decide to execute an application project, you move to that first strategic control point of requirements definition and elicitation. Moving into the second strategic control point, you need a highly integrated process with comprehensive asset sharing. To manage full-blown requirements, you need to manage multiple requirements types, requirements dependencies through a hierarchy and provide traceability between requirements types such as functional, performance, security, business and technical requirements types, between requirements and test cycles, test cases, test results and defects, across test cycles and across project. Being able to trace is an inherent part of the system/solution which enables a fundamentally different approach to requirements-led development and validation. Traceability is critical so that when I change a requirement, or a new requirement comes along, or you run a test or get a test result or find a defect, the ability to connect back and close that loop to the requirement is paramount. And now, when you make your release decision, it’s not about how many tests you’ve run or how many defects you’ve have found – it’s about whether or not I’ve have validated the highest priority, highest risk requirements for the business.

Being able to see your testing progress/status across each requirement and to see whether the tests have been successfully executed or not, which requirements have been tested, whether or not they passed, what is left to test and how much time you have left provides information and decision-making capabilities that are unprecedented and which provide an increased confidence in the quality and readiness of an application to move into production.

With this critical trending information, you can also start to see the effectiveness of your quality processes – how many defects are you capturing, how well have you covered requirements from one cycle to the next; how well are you able to find and fix them as quickly as possible. These are significant process improvements you make in your quality processes and with key linkages all the way through an integrated process and through different test cycles, you have a new level of visibility for better decision-making than would be available via standalone requirements management systems. That seems like a pretty strategic control point to me!

Tracy