Introduction

The importance of capturing user requirements in the design of engineered systems is widely recognised, especially in the design of technical systems, where requirements elicitation processes are used to identify user and stakeholder needs, and consequently elicit, analyse, specify, and validate system requirements. Researchers agree that the requirements elicitation phase greatly influences the quality of the system requirements, and, ultimately, its success.

However, the extant literature reports systems failures caused by numerous factors. These may include both practictioners' knowledge and experience in selecting the appropriate technique, but overall the requirements engineering process lacks a methodology and practice-based approach able to support the elicitation of reliable and validated requirements.

This research aimed to address this gap, and had a two-fold objective:

• First, to advance a methodology and applied approach to derive validate requirements able to fully incorporate the stakeholders’ needs and reflect needs from the customer, business, and regulatory perspectives.

• Second, to test the methodology and approach to a case study. The case study involved the elicitation of validated practice-based needs and requirements for design methods and tools.

(1) A methodology and qualitative-driven approach

The design of the proposed approach derived from considering the still open challenges throughout the requirements engineering process, and tackling them. This involved a three-stage qualitative-driven approach to capture expert knowledge throughout the engineering process of requirements elicitation (as shown in the picture below).

1. The initial Exploratory stage collects information around a business need related to a knowledge-intensive activity. This stage employs any method/technique able to promote divergent thinking (e.g., interviews, brainstorming workshops, knowledge elicitation methods, etc)

2. The core Investigation stage uses an extended version of the Delphi method to support the iterative and incremental elicitation, analysis, and revision of the gathered qualitative data.

3. The outcome of the previous stage is a prioritised requirements list that is validated in this third, Validation, stage.

(2) Validated practice-based needs and requirements

This methodological approach was successfully tested in a case study. The test case regarded the elicitation of requirements for intelligent design systems. Design methods and tools are critical to the performance of engineering design and so the product development processes of which design is a part.

However, despite the large volume of literature and available design tools, few such tools are widely adopted by industry. In part, this can be attributed to the fact that, although design tools are often built on sound scientific foundations and evaluated through industry case studies, their development processes have limited cognisance of the needs and requirements of design practitioners.

Critically, the rounds of requirements assessment and reassessment of the Investigation stage ensured the elicitation of more detailed, reliable, and valid requirements that were validated by a group of experts in engineering design configuration.

The results provided:

• Functional requirements for intelligent design systems

• Functional requirements for BoM description capability (in all cases, for a given design)

• Functional requirements for generic BoM description capability (in all cases, for a given product family)

• Human Factors requirements for user/designer capabilities

The example below shows the list of derived functional requirements for intelligent design systems.

Integration of these requirements in StrEmbed and PartFind

Stakeholders' needs were fed back into the process of development of our software tools, StrEmbed and PartFind, in a variety of ways, and some examples of how this was done, with reference to particular requirements described above, and to our engineering design scenarios, are below.

• StrEmbed users can "view a given BoM both in its detail and in context" easily by moving between tabs, each of which corresponds to a particular BoM. Moreover, common parts and sub-assemblies can be identified by activating their check boxes before moving between tabs. This allows users to compare the position of items in the assembly structure, for example.

• The ability to export whole, multi-BoM projects to Excel in StrEmbed "[a]ssists in evaluating whether [any] changes undertaken are major/minor in terms of [cost, design and time]" by allowing downstream analysis, for example with the Witness software, as described in this scenario.

• PartFind is able to "suggest a design solution for given design requirements ... based on previous designs" by allowing shape-based queries that offer the user alternative products according to (a) topological similarity and (b) manufacturing category. This functionality has the potential to "[help] avoid/reduce part proliferation" by allowing users to replace parts with existing alternatives in an organisation's database, for example, instead of requiring complete redesign.

• The BoM transformation (see this scenario) and reconciliation functionality (see this and this scenario) provided in StrEmbed can help to "[guide users] toward appropriate methods for particular tasks within an overarching design process" by giving confidence that both modifications made to BoMs and pre-existing discrepancies between BoMs are accounted for and can be easily inspected.