Requirements Tools and such

Tools, Tools Tools…

As part of my role, I have to be aware of different competitors’ takes on how to manage requirements. As I go through all of these solutions online and I look at their videos and their marketing materials, the same thing always comes to my mind:

This is all really good marketing material.

A great marketing fact, is that many companies are using Microsoft Word and Excel for their requirements. This includes newer companies as well as companies that have been around a long time. And that’s where the opportunity lies for any requirements marketing project - documents and spreadsheets are just not capable of managing requirements in our complex environment. I’ve done several presentations on that fact myself – it’s a real issue that needs to be addressed.

But here are some things to think about when you’re looking at engineering tools in general, including the requirements tools:

  • How easy is it going to be for the practitioners to adopt this?
  • How intuitive is the tool out of the box?
  • What features of the tool do my practitioners need to use right now?
  • What are the practitioners doing now that they need to continue to do when they start using this tool?
  • What are the practitioners doing now that they need to change and do better when they use the new tool?

Most tools have the ability to synchronize with other tools. That synchronization may be by copying data from one tool to another, or it may be by creating dynamic links to the corresponding data in the other tool. And either case, the ability to share data between a work flow process and a requirements tool is very important because projects begin and end with some kind of requirements, whether they are created by the end users or by stakeholders or by developers fleshing out requirements identified during the workflow process.

Along the same lines of thought, a requirement isn’t a valid requirement unless it can be tested, so the ability to link any requirement or series of requirements to a test case is critical for any requirements tool. While some requirements tools have the ability to create test cases within the requirements tool itself, the questions which then arise are,

  • Can this test case within this requirements tool be identified separately from the requirements?
  • Can it link to its own work item and/or be associated with a defect?
  • Can this test case be linked to an automation tool and then collect that data that’s gathered from that automated test and incorporate it back into this manual tool?

Let’s talk about training for a few minutes. If we go back to our first question – How easy is it going to be for the practitioners to adopt this tool, we can follow that up with a related question …

How many people attend Word or Excel training?

I guess there are still Word and/or Excel classes somewhere. For the most part, however, people just start using Word and Excel out of the box to do the things they want to do because the tools are designed for that. Yes, there are probably hundreds of things that word and Excel can do that are amazing and the only way to now about those things is from a training class, but really, who uses those hundreds of things? So that’s kind of the baseline for how we expect to use tools - out of the box - for the things we just want to do now, and we don’t really want to sit through training to do it.

So, let’s translate that concept over to implementing a new requirements tool. Obviously, if your practitioners have a mindset of “I already know how to use Word and Excel and what I’m doing is working fine”, the process of migrating work over to a requirements tool must be smooth and painless. It must also be accomplished with minimal training required. Let’s think about our example of Word and Excel though - as we said, most people use a small fraction of the available features that Word and Excel provide out of the box. Thus, when it comes to requirements elicitation and management, we need to think about what it is that people must be able to do immediately, and those are the things that must be so easy to do in the new tool that it does not require training. What are some of those things? Well, what are people doing with Word and Excel now? Writing, reviewing and editing documents and spreadsheets.

The complexities of requirements management are not going to decrease moving forward. As we continue to demand more from the products we consume, our requirements for those products will become more and more integrated with how the work is done and tested. The IBM Engineering Lifecycle Management tools provide a fully integrated SDLC solution that can also integrate with other popular tools to provide an end-to-end view of all the pieces and parts of our most complex projects.

Connect with me on LinkedIn - Wade Towles - Senior Account Technical Leader - IBM | LinkedIn
My Engineering Tools Demos on YouTube - Engineering Tools Demos - YouTube