Skip to main content
Log in

Advanced product planning: a comprehensive process for systemic definition of new product requirements

  • Original Article
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

This paper reports results of research into the definition of requirements for new consumer products––specifically, electro-mechanical products. The research dealt with the derivation of design requirements that are demonstrably aligned with stakeholder needs. The paper describes a comprehensive process that can enable product development teams to deal with statements of product requirements, as originally collected through market research activities, in a systematic and traceable manner from the early, fuzzy front end, stages of the design process. The process described has been based on principles of systems engineering. A case study from its application and evaluation drawn from the power sector is described in this paper. The case study demonstrates how the process can significantly improve product quality planning practices through revision of captured product requirements, analysis of stakeholder requirements and derivation of design requirements. The paper discusses benefits and issues from the use of the process by product development teams, and identifies areas for further research. Finally, the conclusions drawn from the reported research are presented.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13
Fig. 14
Fig. 15

Similar content being viewed by others

Notes

  1. ISO9000:2000 was the most recent revision of the ISO standards series during this research.

  2. Enterprises that wish to demonstrate compliance with the requirements of the revised ISO9001:2000, for the purposes of certification/registration, contractual, or other reasons, must provide evidence of the effective implementation of the quality management system.

  3. The term ‘methodology’ is used to refer to a compatible collection of assumptions and goals underlying methods, the methods, and the way the results of carrying the methods out are interpreted and evaluated [10, 16].

  4. IDEFØ is a method designed to model the decisions, actions, and activities of an organisation or system (NIST released IDEFØ as a standard for Function Modelling in FIPS Publication 183). Appendix A gives an overview of the IDEFØ notation.

  5. For the purposes of the reported research the functional basis proposed by Hirtz et al. [ 77 ] was used.

Abbreviations

AMS:

Allocation matrix of stakeholder attributes

FDM:

Functional requirements definition matrix

FMS:

Filtering matrix of stakeholder attributes

GCDM:

Global constraints definition matrix

IDEFØ:

Integrated computer aided manufacturing (ICAM) definition method

ImRs:

Importance requirements

IMSD:

Interrelationship matrix of stakeholder attributes and design requirements

IPD:

Integrated product development

MoRalTM :

Motivational rationale traceability matrix

PcRs:

Performance requirements

PR(s):

Product requirement(s)

PrRs:

Priority requirements

SA(s):

Stakeholder attribute(s)

SA(s)→ Cs :

Stakeholder attributes(s) pertaining to constraints

SA(s)→ FRs :

Stakeholder attribute(s) pertaining to functional requirements

SEI:

Systems engineering and integration

SMC:

Similarity matrix of stakeholder attributes pertaining to constraints

SMF:

Similarity matrix of stakeholder attributes pertaining to functional requirements

SN(s):

Stakeholder need(s)

SR(s):

Stakeholder requirement(s)

References

  1. Armstrong G, Kotler P (2000) Marketing: an introduction, 5th edn. Prentice-Hall, New Jersey

    Google Scholar 

  2. Garvin DA (1984) What does “Product Quality” really mean? Sloan Manage Rev, pp 25–41

  3. Hansen T (2001) Quality in the marketplace: a theoretical and empirical investigation. Eur Manage J 19(2):203–211

    Article  Google Scholar 

  4. Hoyle D (2000) Automotive quality systems handbook. Butterworth-Heinemann, Oxford

    Google Scholar 

  5. Juran JM, Godfrey AB (1998) Juran’s quality handbook, 5th edn. McGraw-Hill, New York

    Google Scholar 

  6. Kartha CP (2002) ISO9000:2000 quality management systems standards: TQM focus in the new revision. J Am Acad Bus, Cambridge

  7. Bray IK (2002) An introduction to requirements engineering. Pearson Education, Essex

    Google Scholar 

  8. Kotonya G, Sommerville I (1998) Requirements engineering: processes and techniques. Wiley, Chichester

    Google Scholar 

  9. Loucopoulos P, Karakostas V (1995) System requirements engineering. McGraw-Hill, Berkshire

    Google Scholar 

  10. Agouridas V (2007) Enhancing design research in the context of design education. Trans ASME J Mech Des 129:717–729

    Article  Google Scholar 

  11. Blaxter L, Hughes C, Tight M (2001) How to research, 2nd edn. Open University Press, UK

    Google Scholar 

  12. Gillham B (2000) Case study research methods: real world research. Continuum, London

    Google Scholar 

  13. Rosenman MA, Gero JS (1998) Purpose and function in design: from the socio-cultural to the techno-physical. Des Stud 19(2):161–186

    Google Scholar 

  14. Bucciarelli LL (1994) Designing engineers. Massachusetts Institute of Technology, Boston

  15. Jenkins M (1985) Research methodologies and MIS research. In: Mumford E, Hirschheim R (eds) Research methods in information systems. North Holland, Amsterdam, pp 103–117

    Google Scholar 

  16. Reich Y (1995) The study of design research methodology. Trans ASME J Mech Des 117:211–214

    Google Scholar 

  17. Konda S, Monarch I, Sargent P, Subrahmanian E (1992) Shared memory in design: a unifying theme for research and practice. Res Eng Des 4(1):23–42

    Article  Google Scholar 

  18. Antonsson EK (1987) Development and testing of hypotheses in engineering design research. ASME J Mech Transm Autom Des 109:153–154

    Google Scholar 

  19. Krishnan V, Ulrich KT (2001) Product development decisions: a review of the literature. Manage Sci 47(1):1–21

    Article  Google Scholar 

  20. Jagdev HS, Browne J (1998) The extended enterprise: a concept for manufacturing. Prod Plan Control 9:216–229

    Article  Google Scholar 

  21. Mello S (2001) Right process, right product. Res-Technol Manage 44(1):52–58

    MathSciNet  Google Scholar 

  22. Dement CW (2003) Strategic management and enterprise engineering: notes for the module of MECH5950, School of Mechanical Engineering, University of Leeds, Leeds

  23. Reinertsen DG (1997) Managing the design factory: a product developer’s toolkit. The Free Press, New York

    Google Scholar 

  24. Thomke S, Reinertsen DG (1998) Agile product development: managing development flexibility in uncertain environments. Calif Manage Rev 41(1):8–30

    Google Scholar 

  25. Kolarik WJ (1999) Creating quality: process design for results. McGraw-Hill, Singapore

    Google Scholar 

  26. Kidd PT (1994) Agile manufacturing: forging new frontiers. Addison-Wesley, Wokingham

    Google Scholar 

  27. Bruce M, Biemans WG (1995) Product development: meeting the challenge of the design-marketing interface. Wiley, Chichester

    Google Scholar 

  28. Cooper RG (2001) Winning at new products: accelerating the process from idea to launch, 3rd edn. Perseus, Cambridge

    Google Scholar 

  29. Andreasen MM, Hein L (1987) Integrated product development. IFS (Publications), Bedford

    Google Scholar 

  30. Ulrich KT, Eppinger SD (1995) Product design and development. McGraw-Hill, New York

    Google Scholar 

  31. Ulrich KT, Eppinger SD (2000) Product design and development, 2nd edn. McGraw-Hill, New York

    Google Scholar 

  32. Cagan J, Vogel CM (2002) Creating breakthrough products: innovation from product planning to program approval. Prentice-Hall, New Jersey

    Google Scholar 

  33. Senge PM (1992) The fifth discipline: the art and practice of the learning organisation. Century Business, London

    Google Scholar 

  34. Flood RL (1999) Rethinking the fifth discipline: learning within the unknowable. Routledge, Taylor & Francis, London

    Google Scholar 

  35. Wiese PR, John P (2003) Engineering design in the multi-discipline era: a systems approach. Professional Engineering, London

    Google Scholar 

  36. Prasad B (2002) Building blocks for a decision-based integrated product development and system realization process. Syst Eng J Int Council Syst Eng 5(2):123–144

    Google Scholar 

  37. Honour EC (2003) Toward an understanding of the value of systems engineering. In: 1st annual conference on systems integration

  38. Buede DM (2000) The engineering design of systems: models and methods. Wiley, New York

    Google Scholar 

  39. Blanchard BS, Fabrycky WJ (1998) Systems engineering and analysis, 3rd edn. Prentice-Hall, New Jersey

    Google Scholar 

  40. Sage AP (1992) Systems engineering. Wiley, New York

    Google Scholar 

  41. INCOSE (2003) What is systems engineering? http://www.incose.org. Accessed on April 2003

  42. Kossiakoff A, Sweet WN (2003) Systems engineering: principles and practice. Wiley, Hoboken

    Google Scholar 

  43. Stevens R, Brook P, Jackson K, Arnold S (1998) Systems engineering: coping with complexity. Prentice-Hall, Hertfordshire

    Google Scholar 

  44. Verma D, Fabrycky WJ (1997) Systematically identifying system engineering practices and methods. Trans Aerosp Electron Syst 33(2):587–595

    Article  Google Scholar 

  45. Tabor EC, Chappell A, Isherwood P, Stanton NA, Turnock P (2000) Exploring design and innovation. Brunel University, Egham

  46. Hamann RJ, Oort MJA (2001) Using a requirement management tool for verification management. Syst Eng, J Int Council Syst Eng 4(3):169–178

    Google Scholar 

  47. Shenhar AJ, Bonen Z (1997) The new taxonomy of systems: toward an adaptic systems engineering framwork. IEEE Trans Syst Man Cybern A Syst Hum 27(2):137–145

    Article  Google Scholar 

  48. Hooks IF, Farry KA (2001) Customer-centered products: creating successful products through smart requirements management. AMACOM, New York

    Google Scholar 

  49. Bruce M, Wooton A, Cooper R (2000) Creative product design: a practical guide to requirements capture management. Wiley, New York

    Google Scholar 

  50. Vollerthun A (2002) Design-to-market: integrating conceptual design and marketing. Syst Eng J Int Council Syst Eng 5(4):315–326

    Google Scholar 

  51. Bruce M, Bessant (2002) J Des Bus. Pearson Education, Essex

  52. Rosenman MA, Gero JS (1998) Purpose and function in design: from the socio-cultural to the techno-physical. Des Stud 19(2):161–186

    Google Scholar 

  53. Whyte JK, Salter AJ, Gann DM, Davies A (2003) Designing to compete: lessons from millennium product winners. Des Stud 24:395–409

    Google Scholar 

  54. Karkkainen H, Elfvengren K (2002) Role of careful customer needs assessment in product innovation management-empirical analysis. Int J Prod Econ 80:85–103

    Article  Google Scholar 

  55. Urban GL, Hauser JR (1993) Design and marketing of new products, 2nd edn. Prentice-Hall, New Jersey

    Google Scholar 

  56. Larsen RF, Buede DM (2002) Theoretical framework for the continuous early validation (CEaVa) method. Syst Eng J Int Council Syst Eng 5(3):223–241

    Google Scholar 

  57. Earl CF (2003) Book review: axiomatic design––advances and applications. Des Stud 24:391–392

    Google Scholar 

  58. Buren JV, Cook DA (1998) Experiences in the adoption of requirements engineering technologies. CrossTalk J Def Softw Eng, pp 3–10

  59. Schmidt R (1997) The implementation of simultaneous engineering in the stage of product concept development: a process orientated improvement of quality function deployment. Eur J Oper Res 100:293–314

    Article  MATH  Google Scholar 

  60. Young RR (2001) Effective requirements practices. Addison Wesley, Boston

    Google Scholar 

  61. Kirkman DP (2003) Requirement decomposition and traceability. Requirements Eng 3:107–114

    Article  Google Scholar 

  62. Haumer P, Jarke M, Pohl K, Weidenhaupt K (2000) Improving reviews of conceptual models by extended traceability to captured system usage. Interact Comput 13:77–95

    Article  Google Scholar 

  63. Suh NP (1990) The Principles of design. Oxford University Press, New York

    Google Scholar 

  64. Sutcliffe A (1995) Requirements rationales: integrating approaches to requirements analysis. In: Proceedings of DIS’95

  65. MacLean A, Young RM, Moran TP (1989) Design rationale: the argument behind the artifact. In: Proceedings of the SIGCHI conference on human factors in computing systems: wings for the mind

  66. Bracewell RH, Ahmed S, Wallace KMD (2004) Red and design folders, a way of capturing, storing and passing on knowledge generated during design projects. In: ASME design engineering technical conferences

  67. Pohl K (1996) PRO-ART: enabling requirements pre-traceability. In: Proceedings of ICRE’96

  68. Gotel O, Finkelstein A (1995) Contribution structures. In: Proceedings of the second IEEE international symposium on requirements engineering

  69. Yu ESK, Mylopoulos J (1994) Understanding “Why” in software process modelling, analysis, and design. In: Proceedings of the 16th international conference on software engineering

  70. Agouridas V, Winand H, McKay A, de Pennington P (2006) Early alignment of design requirements with stakeholder needs. Trans IMechE B J Eng Manuf 220(9):1483–1507

    Google Scholar 

  71. Agouridas V, Marshall A, McKay A, de Pennington P (2006) Establishing stakeholder needs for medical devices. In: Proceedings of the 2006 ASME design engineering technical conferences (IDETC/CIE), Philadelphia

  72. Checkland P (1999) Soft systems methodology: a 30-year retrospective. Wiley, England

    Google Scholar 

  73. Agouridas V, Baxter JE, McKay A, de Pennington A (2001) On defining product requirements: a case study in the UK health care sector. In: The proceedings of the 2001 ASME design engineering technical conferences (IDETC/CIE), Pittsburgh

  74. Thompson C (1999) Creativity vs. constraints: managing risk in research and development. J New Prod Dev Innov Manage 1(1)

  75. Agouridas V, McKay A, de Pennington P (2004) Consumer product development: a systems engineering approach to the derivation of design requirements from stakeholder needs. In: 14th annual international symposium of the international council on systems engineering (INCOSE)

  76. Agouridas V (2003) The derivation of design requirements from stakeholder needs. PhD thesis, University of Leeds

  77. Hirtz J, Stone RB, McAdams DA, Szykman S, Wood KL (2002) A functional basis for engineering design: reconciling and evolving previous efforts. Res Eng Des 13:65–82

    Google Scholar 

  78. Hooks I (1993) Writing good requirements. In: Proceedings of 3rd international symposium of the INCOSE

  79. Khurana A, Rosenthal SR (1998) Towards holistic “front ends” in new product development. J Prod Innov Manage, pp 1557–1574

  80. Ahmad M, Benson R (1999) Benchmarking in the process industries. Institution of Chemical Engineers, London

    Google Scholar 

  81. Benson R, McCabe JDJ (2004) From good manufacturing practice to good manufacturing performance. Pharm Eng 24(4):26–34

    MathSciNet  Google Scholar 

  82. Benson R (2005) From world class research to world class operations: the challenges. Pharmaceutical manufacturing survival in the 21st century. Institution of Mechanical Engineering, London

    Google Scholar 

  83. Ulrich KT, Ellison DJ (1999) Holistic customer requirements and the design-select decision. Manage Sci 45(5):641–651

    Article  Google Scholar 

  84. Arcidiacono G, Campatelli G, Lipson H (2001) A measure for design coupling. In: 13th international conference on engineering design (ICED’01)

  85. Frey DD, Jahangir E, Engelhard F (2000) Computing the information content of decoupled designs. Res Eng Des 12:90–102

    Article  Google Scholar 

  86. Whyte JK, Salter AJ, Gann DM, Davies A (2003) Designing to compete: lessons from millennium product winners. Des Stud 24:395–409

    Google Scholar 

  87. FIPS 183 (1993) Integration definition for function modeling (IDEF0), Computer Systems Laboratory of the US National Institute of Standards and Technology (NIST), USA

Download references

Acknowledgments

The authors would like to thank the reviewers whose comments improved significantly the quality of this paper. The authors are grateful to Andrew Wilson and the staff of Rolls-Royce plc, who contributed to, and facilitated, the completion of the reported case study. Thanks are also due to the late Charles W. Dement for his support in informing the problem definition of the case study and to Dr. Jim Baxter for his guidance during the early stages of it. The research was supported by the UK EPSRC (Engineering and Physical Sciences Research Council) through the MAPPSEE project (Managing Asynchronous Product and Process Structures in the Extended Enterprise, Grant No. GR/M56715) and the KIM Grand Challenge project (Knowledge and Information Management, Grant No. EP/C534220/1).

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Vassilis Agouridas.

Appendices

Appendix A: IDEFØ notation

The graphical language of IDEFØ uses boxes to represent activities and lines with arrows to link the activities where the arrows indicate the direction of flow. The flow lines represent real objects or information needed or produced by the activity. The side of the activity box to which a flow line may enter or leave objects depicts the meaning of the flow line, as shown in Fig. 16 [87].

Fig. 16
figure 16

Activity boxes, ICOMs (Inputs, Controls, Outputs, Mechanisms), and progressive decomposition of activities

Inputs enter an activity box on its left side, with outputs leaving from the right hand side. Therefore, the activity may be said to transform the received into a produced output. The flow lines that enter the top of an activity box represent a control or a constraint. A control describes the conditions and/or circumstances that govern the transformation. The flow line that enters the bottom of an activity box is known as a mechanism. This is the means by which an activity is carried out [87].

An IDEFØ model is an ordered collection of diagrams, related in a precise manner to form a coherent model of the subject. The activity that represents the simplest ‘Diagram’ form of an activity model is called a ‘context diagram’. Only a single activity is shown in a context diagram. IDEFØ uses top-down decomposition to break-up complex activities into smaller which can be more readily understood. Multiple activities are shown in a ‘decomposition diagram’. A decomposition diagram represents all the sub-activities of a larger activity (it is in this manner that the larger activity is said to be ‘decomposed’). This results in a hierarchical structure of the activities from a single root activity, as shown in Fig. 16. Sometimes it is desirable to reduce clutter on a diagram by suppressing ICOMs at the decomposition levels of an activity. In this case, arrows may be tunnelled (i.e. adding parentheses “()” to the head of the ICOM arrow) to imply that the flow applies to all the offspring of the activity [87].

Appendix B: IDEFØ activity model

1.1 B.1. Graphical representation of the IDEFØ activity model developed

Figures 17, 18, 19, 20, and 21 give graphical representations, of the activity model developed for the purposes of this research using the IDEFØ notation. It should be noted that not all of the described control flows are shown in Figs. 17, 18, 19, 20, and 21 due to tunnelling. The subject of the activity model is the systematic definition of product intent in the form of design requirements (i.e. functional requirements and constraints) that are traceable to the stakeholder needs and requirements from which they were derived. The purpose of the model, for this paper, is to define the activities that are necessary for the systematic derivation of design requirements from stakeholder needs.

Fig. 17
figure 17

IDEFØ diagram of activity “A–0: Derive design requirements from stakeholder needs (Context)”

Fig. 18
figure 18

IDEFØ diagram of the decomposition of activity “A0: Derive design requirements from stakeholder needs”

Fig. 19
figure 19

IDEFØ diagram of the decomposition of activity “A2: Analyse Stakeholder Requirements”

Fig. 20
figure 20

IDEFØ diagram of the decomposition of activity “A23: Articulate Stakeholder Attributes”

Fig. 21
figure 21

IDEFØ diagram of the decomposition of activity “A3: Derive design requirements”

1.2 B.2. Alphabetical list of inputs and outputs, controls and mechanisms of the IDEFØ activity model developed

Tables 4, 5, 6 give, in alphabetical order, the descriptions of ICOMs (inputs, controls, outputs and mechanisms) of the activity model. It has to be noted that the techniques and matrices used to support the systematic derivation of design requirements from stakeholder needs are shown as mechanisms.

Table 4 Alphabetical list of inputs and outputs of the developed activity model
Table 5 Alphabetical list of controls of the developed activity model
Table 6 Alphabetical list of mechanisms of the developed activity model

Rights and permissions

Reprints and permissions

About this article

Cite this article

Agouridas, V., McKay, A., Winand, H. et al. Advanced product planning: a comprehensive process for systemic definition of new product requirements. Requirements Eng 13, 19–48 (2008). https://doi.org/10.1007/s00766-007-0055-z

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-007-0055-z

Keywords

Navigation