Requirements Practices with Jama

On March 22, 2013 Dr. Andreas Birk and Gerald Heller provided a webinar on well established tool based requirements management (RM) practices. Using the tool Jama as an example they visualized how

  • requirements are structured systematically
  • requirements are managed continuously
  • requirements and tests contribute to product success

The focus of the talk was the optimal interworking of tool and requirements practices. What needs to be done to fully utilize the potential of an RM tool? How can the tool help to broaden the RM practices in an organization.

Slides of the webinar are available on Slideshare: Structuring requirements with Jama

RM Tools – What Are They Anyway?

There is time for a new class of requirements tools. Those do not only support classical requirements management, but also requirements activities, that help to improve the collective understanding of requirements through illustration and collaboration and therefore ultimately serve to build better products.

There are quite a few requirements management (RM) tools out in the market. Did you ever wonder what qualifies them as an RM tool? This question is of specific interest, when you are in the process of selecting a requirements management tool for your organization.

A good starting point for the evaluation of tools is to get insights about your driving needs.

  • What should the tool do for you?

Sometimes, I simply hear “support the RM process”. In other situations I get statements like:

    • ease the documentation burden
    • provide access to requirements for all stakeholder
    • speed-up requirements discussions

The latter situation is better, because it is always helpful working towards your own goals. What is it that you want to accomplish? If you know this, then you get a clear guidance what are the most important features of any given tool for you.
The statement “support the RM process” is more tricky and interesting to explore.

What is Requirements Management?

At first glance one might think, that’s not a big deal because RM is defined. We only need to look at the published definition, check the associated activities and voilà we have something we can compare tool features against. But when you dig into the details about RM you might get puzzled. Definitions about RM aren’t so clear and consistent. When Andreas Birk and I did a recent research about RM definitions we found out, that definitions substantially differ. Below are some prominent examples for Requirements Management:

Karl Wiegers, In search for excellent requirements, 2004:

Manage versions of requirements documents
Adopt and enforce a change control process
Store requirement attributes
Track the status of each requirement
Trace requirements into designs, code, and tests

BABoK Guide, Version 2.0

The activities, that control requirements development,
including requirements change control,
requirements attributes definition, and
requirements traceability

IREB CPRE Foundation Level, May 2009

Adding Attributes to Requirements
Creating Views of Requirements
Prioritizing Requirements
Tracing Requirements
Requirements Versioning
Dealing with Change Requests

Already from these three examples we can see that there is a floating boundary between support of requirements development and requirements management. So, where do we go from here? A good approach is to distill commonalities from the definitions and construct a criteria list:

Requirements management should support all activities to

    • define and structure requirements
    • discuss requirements
    • prioritize requirements
    • maintain status on requirements
    • track changes of requirements
    • version requirements
    • trace relationships between requirements and other development artefacts
    • communicate about requirements

That provides a great start. We now have some objective criteria to check whether a tool can call itself a requirements management tool. Comment: Will Microsoft Word qualify as RM tool?

But, we aren’t done – these are just the basics.

Beyond Basic Requirements Management

When we look at the feature lists of prominent “RM Tools” we will notice, that vendors typically provide a much richer set of features. There are several reasons for that. On one side rich feature sets are business differentiators. If product A provides “killer features” that other products don’t have, it will have some competitive advantage for the company who sells A.
On the other side a rich feature set for RM may also be rooted in the nature of the requirements management process. Being a central part of product development, requirements management has many interfaces to adjacent processes and tools.

Tool vendors have the option to either provide interfaces to the adjacent processes or incorporate support for these adjacent processes directly in the tool.

Especially products, that are out in the market for quite some time, often show the latter approach. In recent years the term “Application Lifecycle Management” (ALM) became prominent. It is used in situations where a tool provides support for several (or all) phases in the application lifecycle.
While this may suit some companies it imposes challenges too. Often companies have already deployed tools in adjacent areas and are then forced to evaluate what tool solution should be used going forward.

Therefore, ALM in a single tool may only be beneficial for some companies.

New Trend: Visualization and Collaboration

Another trend I observe, is that tools provide more support for the early phases of requirements engineering. In these phases requirements aren’t that clear, but are under constant development. That’s why Carnegie Mellons Software Engineering Institute (SEI) summarizes these activities as “Requirements Development”. There is constant morphing between wishes, ideas, requirements and solution prototyping. To support these activities tools should provide support for

    • ideation
    • conceptualization
    • joint understanding
    • collaboration

When requirements aren’t that clear often visualizations help to move forward. In recent years more and more tools offer visualization features for requirements representation. This may range from support for rich media formats like pictures and movies, to support for sketches, storyboards, mockups and finally to support for modeling activities with varying degree of formal notations.
An optimal complement to visualization concepts are collaboration features. Requirements engineering demands interaction between stakeholders. Fortunately the trend to social media software has also spread to the requirements tools market. Use of social media functionality improves requirements understanding and reduces the risk building the wrong product. This is a great advance in requirements engineering.

In summary, I believe that there is time for a new class of requirements tools. Those do not only support classical requirements management, but also requirements activities, that help to improve the collective understanding of requirements through illustration and collaboration and therefore ultimately serve to build better products.

Watch out for these type of tools when selecting a requirements tool.

Software Product Management Survey

Have you ever wondered how your product management practices stack up against others in the software industry?

Well, here’s an opportunity to find out: the International Software Product Management Association (ISPMA, http://ispma.org ) is for the first time conducting a survey to find out about software product management practices in the real world – and you are invited to participate.

To complete the survey, please go to the URL http://bit.ly/spm-survey and answer the questions about your organization, your product, and your product management practices. Filling out the survey will require about 20 – 25 minutes of your time and you’ll receive the following benefits:

  • Immediately after filling out the survey, you will get access to an overview document on state-of-the-art software product management. This document is a compilation of the most frequently cited scientific publications in the field of software product management.
  • Once the survey has been closed and evaluated, you’ll receive a personalized evaluation that shows your results in comparison with results of the entire survey panel. This way, you can compare yourself with the state-of-practice and you get insights into how practice varies from one organization to another. This will help you to further evolve your own approach to software product management.

The survey is conducted by Andrey Maglyas from Lappeenranta University of Technology (LUT, http://www.lut.fi/ ), Finland and Dr. Samuel Fricker from Blekinge Institute of Technology (BTH, http://www.bth.se/ ), Sweden with support from the International Software Product Management Association (ISPMA, http://ispma.org ).

The survey will close on 25.12.2012 and we plan to complete the survey evaluation in early 2013.

Who Owns the Requirements

When it comes to the question of who owns the requirements the answer is sometimes surprising.

Depending on the titles used in an organization we may hear requirements analyst, business analyst or product manager. Others might name development manager, solution manager or system analyst. While all these people have to say a lot about requirements the product manager should have overall responsibility for the requirements.

Why that? Well, it is the product manager who is ultimately responsible for the business success of the product. He provides product direction and sets the goals for product releases. Through his direct connection to customers and the market he knows best what customer problems are and understands current offerings of competitors. Therefore he is optimally equipped to guide the business team.

Unfortunately, in most organizations the product manager is a poorly defined role. Often product managers get many things to work on, typically too many to be effective. A recent study clearly indicates that product managers work too often on tactical tasks, like customer escalations and supporting sales inquiries.

Successful organizations understand that product management must be balanced between tactical and strategic tasks. However due to the lack of a common understanding of all these tasks it is often a time consuming ineffective effort. Tools that provide an overview of all product management activities accelerate this work substantially.

In October 2010 I gave a presentation at the German “Requirements days” in Munich where I presented some of the fundamental activities in software product management.

Interestingly I got quite some feedback from people, who see a need for clarification specifically in organizations who move towards agile. The simple approach that a product manager equates to a product owner in Scrum doesn’t work out well. On the other extreme product managers might position agile product development to effect only the development organization. They continue to work as before not realizing the full potential of agile development.

Independent whether a software organization works agile or traditional a framework of software product management activities will enable them to improve its effectiveness. That’s why the International Software Product Management Association (ISPMA) pushes towards a certification of software product management.

If this topic is of interest to you, then get in contact with me and/or download the presentation.

Testing History

Recently I came across the website www.testingreferences.com whose author Joris Meerts did a great job in collecting a history of testing. In addition, he  provides a pretty extensive listing on

  • Testing web sites
  • Testing blogs
  • Testing videos (educational)
  • Testing literature

I am sure you will love this site. As the list is pretty long I will tell you my personal shortlist here: