I was one of about 20 participants in Brian Berenbach’s session on Product Line Requirements Engineering on Day 1 of SPLC 2006. I was particularly interested in this session because I recently wrote a paper for the British Computer Society Requirements Engineering SIG on Requirements Engineering in Product Lines and wanted to see how closely Brian’s viewpoint matched up with my own.

Brian works for Siemens Corporate Research in the US and laced his talk with tips from plenty of practical experience. This is one of the additional benefits of attending sessions led by industry veterans – no offence Brian - as you might not hear about this type of thing otherwise. There were also plenty of exercises for us to apply the ideas presented – and also to act as ice-breakers for meeting other conference participants.

The session began with the observation that, in the industry, failure to adequately specify requirements is getting worse. This was attributed at least in part to:

• Pressure to get products to the market faster
• A lack of methods training in those specifying requirements

Since Product Lines help improve time-to-market – Brian quoted a figure of a 35% improvement - maybe they can help correct this trend.

Other issues that were noted during the session:

• When deciding what products / features should be in your Product Line (Scoping) don’t get trapped into reinventing last year’s products. The Product Line should be forward-looking.
• Requirements Engineering in Product Lines is harder than in one-of-a-kind software development. There are many reasons for this that arise because you are dealing with a set of systems, not just a single system.
• Communication differences – different product managers (with different domain experience) may speak in different terms. How do product managers gain a shared understanding of the Product Line? How do they communicate knowledge to their Product Line manager?
• Marketing / Sales must do things more formally than they would in a one-of-a-kind setting. This may cause friction!
• How do you organise when you have a central team building reusable assets and geographically-distributed teams developing locale-specific applications? How do you ensure that the benefits of product Lines can be realized when central functions have little control over distributed functions?

Brian, like us, is a keen advocate of Feature Modelling and there were a number of exercises in building feature models during the session – a little harder with pen and paper than with tool support. With respect to Feature Modelling Brian noted that:

• Feature Modelling is a must for managing the requirements elaboration process in a Product Line.
• In some domains it can be hard to discriminate between software, hardware and firmware requirements. Feature Modelling can help make it easier to understand precisely where a requirement should be fulfilled.
• It may be possible to come up with several conceptions of the Product Line. Feature Modelling can help tease out the differences between these alternative conceptions.
• Your test plan (and other non-code assets) can be derived automatically from the Product Line feature model.

In closing Brian noted a couple of outstanding areas:

• How to reverse-engineer your Product Line requirements from requirements for a single, seed product. (Bootstrapping your Product Line using an extractive approach.)

• How to ensure end-to-end traceability across the life cycle – Brian is looking at this problem in particular.

It’s perhaps worth noting that pure::variants has add-on modules for DOORS® and Borland® CaliberRM^TM that aim to address these two issues – although some work is obviously required as information necessary to capture the Product Line commonalities and variabilities is generally only available implicitly in existing requirements artefacts.

All in all an enjoyable and worthwhile session. Thanks to Brian and those who I collaborated with on the exercises.

A full report, including this tutorial report, will appear on the Software Acumen website shortly.