Challenges in balancing the amount of solution information in requirement specifications for embedded products

Requirements are traditionally viewed as being free of the details of an envisioned solution and specified using purely problem domain entities. Preventing premature design in the requirements permits the available design space not to be restricted too early which might inhibit innovative designs. In practice, on many industrial projects, separating the problem and solution domain entities can be difficult, and arguably there are benefits for not doing so. Many customers feel more confident describing their requirements, often as the difference between the existing products and their needs, some customers have such intimate knowledge of their products that their requirements tend to be very specific, and if the customer knows the exact solution needed that naturally will reduce the cost of the requirements elicitation as well as design activities. Practitioners are challenged to understand when having solution information in requirements is sensible and when it should be avoided. In this research challenge paper, we advocate that researchers should identify different contexts and corresponding criteria that practitioners can use to evaluate when requirements specifications may include design information. To understand the research challenge we present experiences from real projects and suggest possible factors that affect when design information may be viable in requirements specifications.