Skip to main content
Log in

Portraying the practice of decision-making in requirements engineering: a case of large scale bespoke development

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

Abstract

Complex decision-making is a prominent aspect of requirements engineering (RE) and the need for improved decision support for RE decision-makers has been identified by a number of authors in the research literature. A first step toward better decision support in requirements engineering is to understand multifaceted decision situations of decision-makers. In this paper, the focus is on RE decision-making in large scale bespoke development. The decision situation of RE decision-makers on a subsystem level has been studied at a systems engineering company and is depicted in this paper. These situations are described in terms of, e.g., RE decision matters, RE decision-making activities, and RE decision processes. Factors that affect RE decision-makers are also identified.

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.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6

Similar content being viewed by others

References

  1. Aurum A, Wohlin C (2003) The fundamental nature of requirements engineering activities as a decision-making process. Inf Softw Technol 45:945–954. doi:10.1016/S0950-5849(03)00096-X

    Article  Google Scholar 

  2. Evans R, Park S, Alberts H (1997) Decisions not requirements: decision-centered engineering of computer-based systems. In: Workshop on engineering of computer-based systems, ECBS ‘97, Monterey, pp. 435–442, 24–28 March 1997

  3. Regnell B, Paech B, Aurum C, Wohlin C, Dutoit A, Natt och, Dag J (2001) Requirements means decision!—research issues for understanding and supporting decision making in requirements engineering. In: 1st Swedish conference on software engineering research and practice, SERP’01, Ronneby, pp. 49–52

  4. Ngo-The A, Ruhe G (2005) Decision support in requirements engineering. In: Aurum A, Wohlin C (eds) Engineering and managing software requirements. Springer, Berlin, pp 267–286

    Chapter  Google Scholar 

  5. Ruhe G (2003) Software engineering decision support: methodology and applications. In Tonfoni G, Jain L (eds.) Innovations in decision support systems, advanced knowledge international. Adelaide, South Australia, Australia, pp 143–174

  6. Orasanu J, Connolly T (1993) The reinvention of decision making. In: Klein GA et al (eds) Decision making in action: models and methods. Ablex Publishing, Norwood, pp 3–20

    Google Scholar 

  7. Alenljung B (2008) Envisioning a future decision support system for requirements engineering: a holistic and human-centred perspective. Doctoral Thesis, Department of Computer and Information Science, Linköping University, Sweden, Dissertation No. 1155. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva–10564

  8. Mintzberg H, Raisinghani D, Théorêt A (1976) The structure of “unstructured” decision processes. Adm Sci Q 21:246–275. doi:10.2307/2392045

    Article  Google Scholar 

  9. Power DJ (2002) Decision support systems: Concepts and resources for managers, Quorum Books, Westport, Connecticut

  10. Macaulay LA (1996) Requirements engineering. Springer, London

    MATH  Google Scholar 

  11. Anthony RN (1965) Planning and control systems: A framework for analysis. Harvard University, Boston

    Google Scholar 

  12. Patton MQ (2002) Qualitative research & evaluation methods, 3rd edn. Sage Publications, Thousand Oaks, California

    Google Scholar 

  13. Strauss A, Corbin J (1998) Basics of qualitative research: techniques and procedures for developing grounded theory, 2nd edn. SAGE publication, Thousand Oaks

    Google Scholar 

  14. Holtzblatt K, Jones S (1993) Contextual inquiry: a participatory technique for system design. In: Schuler D, Namioka A (eds) Participatory design: principles and practices. Lawrence Erlbaum, Hillsdale, pp 177–210

    Google Scholar 

  15. Denzin NK (1978) The research act: a theoretical introduction to sociological methods, 2nd edn. McGraw-Hill, New York

    Google Scholar 

  16. Goldkuhl G, Cronholm S (2003) Multi-grounded theory: adding theoretical grounding to grounded theory. In: The 2nd European Conference on research methods in business and management (ECRM 2003), Reading, 20–21 March 2003

  17. Lincoln YS, Guba EG (1985) Naturalistic inquiry. SAGE Publications, Newbury Park

    Google Scholar 

  18. Alenljung B, Persson A (2004) Supporting requirement-based decision-making in the software engineering process: a position paper. In: Proceedings of the 10th International workshop on requirements engineering: foundation for software quality, REFSQ 2004, Riga, pp 63–68, 7–8 June 2004

  19. Alenljung B, Persson A (2005a) Decision-making activities in the requirements engineering decision processes: a case study. In: Proceeding of the 14th International Conference on information systems development, ISD 2005, Karlstad, 15–17 August 2005

  20. Alenljung B, Persson A (2005b) Decision-making from the decision-maker’s perspective: a framework for analysing decision situations. In: Proceedings of the 4th International Conference on business informatics research, BIR 2005, Skövde, pp. 13–22, 3–4 October 2005

  21. Alenljung B, Persson A (2005c) Factors that affect requirements engineers in their decision situations: a case study. In: Proceedings of the 11th International workshop on requirements engineering: foundation for software quality (REFSQ’05), Porto, 13–14 June 2005

  22. Simon H (1960) The new science of management decision. Harper, New York

    Google Scholar 

  23. Gorry GA, Scott Morton MS (1971) A framework for management information systems. Sloan Manage Rev 13(1):55–70

    Google Scholar 

  24. Fayol H (Revised by I Gray) (1984) General and industrial management. Pitman Publishing, London (First published in French 1916, translated into English 1949)

  25. Holsapple CW, Whinston AB (1996) Decision support systems: a knowledge-based approach. West Publishing Company, Minneapolis/St. Paul

    Google Scholar 

  26. Reisberg D (2006) Cognition: exploring the science of the mind, 3rd edn. W·W. Norton & Company, New York

    Google Scholar 

  27. Klein M, Methlie LB (1990) Expert systems a decision support approach: with applications in management and finance. Addison-Wesley, Wokingham

    Google Scholar 

  28. Pfeffer J (1992) Managing with power: Politics and influences in organizations. Harvard Business School Press, Boston

    Google Scholar 

  29. Browne M (1993) Organizational decision making and information. Ablex Publishing, Norwood

    Google Scholar 

  30. Payne JW, Bettman JR (1988) Adaptive strategy selection in decision making. J Exp Psychol 14(3):534–552

    Google Scholar 

  31. Sweller J, van Merriënboer JJG, Paas F (1998) Cognitive architecture and instructional design. Educ Psychol Rev 10(3):251–296. doi:10.1023/A:1022193728205

    Article  Google Scholar 

  32. Gulliksen J, Göransson B (2002) Användarcentrerad systemdesign [user-centred system design]. Studentlitteratur, Lund, Sweden (in Swedish)

    Google Scholar 

  33. Schneider W (1993) Att köra över människors inneboende autopilot [To run over the inherent autopilot of humans] (in Swedish). In: Lennerlöf L (ed) Människor, datateknik, arbetsliv [Humans, computer technology, working life], C.E. Fritzes, Stockholm, Sweden, pp. 99–114

  34. Barber P (1988) Applied cognitive psychology: an information-processing framework. Methuen & Co, London

    Google Scholar 

  35. Sandblad B, Lind M, Nygren E (1991) Kognitiva arbetsmiljöproblem och gränssnittsdesign [Cognitive work environment problems and interface design]. Report no. 20, Uppsala University, Center for Human–Computer Studies (CMD) (in Swedish)

  36. Zachary WW, Ryder JM (1997) Decision support systems: integrating decision aiding and decision training. In: Helander M et al (eds) Handbook of human–computer interaction, 2nd edn. Elsevier Science B·V, Amsterdam, pp 1235–1258

    Google Scholar 

  37. Fisher CW, Kingma BR (2001) Criticality of data quality as exemplified in two disasters. Inf Manage 39:109–116. doi:10.1016/S0378-7206(01)00083-0

    Article  Google Scholar 

  38. Miner JB (1992) Industrial–organizational psychology. McGraw-Hill, New York

    Google Scholar 

  39. Staw BM (1997) The escalation of commitment: an update and appraisal. In: Shapira Z (ed) Organizational decision making. Cambridge University Press, Cambridge, pp 191–215

    Google Scholar 

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Beatrice Alenljung.

Appendix: Quotations

Appendix: Quotations

  • Q1: “Well, yes, in principle there are a lot of investigations. If we find something ambiguous in the system requirements, then we have to talk to the customer to find out what they really mean. I think that the major part of my work is about making investigations.” (Requirements engineer)

  • Q2: “You specify what requirements that belong to which subsystem, so that all subsystem managers and requirements engineers for the subsystems know which requirements they should fulfil. […] You have to read it [i.e. the system requirement specification] through a number of times and try to figure it out. This sounds like our responsibility. What you do next is to ponder. What is implemented so far? What does the structure look like? How can we include this functionality in the existing set of requirements and construction? Will some discrepancy appear? Can there be problems further on? You simply have to sit down and think about how it is intended to work.” (Requirements engineer)

  • Q3: “But there it is also really important that you… that you have a common picture of what is the difficulties in the project. So that you really find out what is really important with this.” (Focus group participant)

  • Q4: “Some solve problems by discussing with others and finding themselves a contact net and solve it that way. Others may sit in their room and go through… maybe read through this requirements specification on the level above from the first page to the last page…” (Requirements engineer)

  • Q5: “You write quite a lot about what the product is going to look like. […] so you have to by yourself construct your system at a high level of abstraction to a large extent, as I see it. […] Of course, we get help from others and do a lot of investigation, but basically it is the one who writes the requirements that puts it all together to a system.” (Requirements engineer)

  • Q6: “But I think that it is important to have communication all the time with the different concerned instances then. What is important and what is less important? Try to make sure that you get what the customer wants and concentrate on that, instead of making up requirements cases on your own.” (Subsystem test manager)

  • Q7: “This is the main way to mediate information between subsystems, that you are called to a check meeting.” (Requirements engineer)

  • Q8: “I make a lot of decisions. But at the same time, since we check everything and like that, so are all things such as what you write and how you write, and things like that, for other persons eyes too, so to say. You are not alone when you make decisions about how to write, and things like that. Early in a project so, if it actually is a job for the requirements engineer can be questioned, but the requirements engineer together with the subproject leader and some others, to divide the project into pieces. In which order should we write the requirements? In which order should we implement the requirement? How do we divide the requirements in the different subsystems, for example?” (Requirements engineer)

  • Q9: “We have decided upon which use cases are needed. Which relationships should be there between them? […] Decide which actors there are. Between the subsystems, you call the other subsystems actors.” (Requirements engineer)

  • Q10: “Then there is also on what level the requirements should be. That also demands a lot of experience. When you talk about use cases, you usually say that they can be on the bottom level, the surface level and up in the sky.” (Requirements engineer)

  • Q11: “Well, you have a constant decision. It is the level of details. What should I write as a requirement and what should I not write as a requirement. […] It is a constant judgement. What do you include? What do you not include? How detailed you should be? This also then, all the beautiful empty rhetoric that all such requirements lecturers who talk about that you should describe the borders of the system with your requirements and not inside the system. […] But this is a great guiding principle, so to say. However, when you are really sitting and writing something, then some requirements are not possible to write without some knowledge about how it works inside. […] It is easy to say at such requirements lectures, that you should put requirements on the border and not how the system looks inside. However, you don’t land there in reality. You always have such small decisions all the time, so to say. What should I include? What should I not include? Is this the construction? How closely do I describe it?” (Requirements engineer)

  • Q12: “Well, which requirements are essential on the whole for the main functions? Which requirements are essential now? Have some understanding of the order of priority, when to do what. And it is also a priority how deep I should go. Because you cannot go equally deep and think about… for every requirement. You have to get a feeling for what should I spend my time on.” (System engineer manager)

  • Q13: “It is this that is the difficulty, to have this balance. When should we do deep investigations and when should we not do them. It is this that is the difficulty. […] It is difficult to know when to do a lot of work and when you should chance a bit. Because you have to chance a bit.” (Focus group participant)

  • Q14: “The first, the most important judgement, this we therefore do from the very beginning. It is to set some limit for how far you should investigate something. What level of ambition you should have and this is just a judgement that you just… It becomes easier and easier with experience. […] Good enough, this judgement I personally found very difficult.” (Requirements engineer)

  • Q15: “… both the requirements work and the requirements engineers are a service function in some way in the project, I think. All the time… you have to stay alert of what is happening around you and answering questions and…” (Requirements engineer)

  • Q16: “… in an investigation all possible things can be included, such as spreadsheets in Excel and advanced mathematical models. You try to model as well as possible how this will be in reality when it is implemented, so we often make such very advanced models and simulation tools.” (System engineer manager)

  • Q17: “Will this affect, so to speak, how the system behaves externally? How will this affect what the customer experiences? As a rule, it is the first question you put to yourself. Do we need this requirement at all or can the software engineers do as they want?” (Requirements engineer)

  • Q18: [Characteristics of a good investigation:] “Well, it is that there is a background and that it is exhaustive and that there is a background and the cause to why you want to do this. That it is clarified and explained what they want… you to do. The thing that perhaps, what you can think is most difficult to do; it is in the end a cost estimation. What does it cost to implement the whole?” (System engineer manager)

  • Q19: “Well, it depends on what proposal it is. Sometimes such a proposal arrived with an internal investigation, that you have decided in advance to do an investigation and then you make a check in that case. […] The reasons for doing it, profitability. Who will be concerned? When will it be implemented and…” (System engineer manager)

  • Q20: “… you receive some problem and then in some form of forum… either with e-mail or that you meet and discuss… You try to find out how the system should behave and how you easiest solve it in order to get there.” (Requirements engineer)

  • Q21: “… it can, for example, be a missing requirement. It ought to be a requirement of something and this is noted almost as an incorrect requirement. That you make a proposal on a new requirement and then, at the next check occasion, you bring it up for judgment and add it or change it or whatever you do. You decide how to manage it any way.” (System engineer manager)

  • Q22: “I mean, the system must be connected, so that to the degree it affects other requirements you have to try bring in that too, so to say. We don’t sit and tick it off against all other requirements, but… Instead, it is more concerned with our knowledge in the head, so to say. That you know, okay, but then this will not be good and how is this related to that and…” (Requirements engineer)

  • Q23: “Thanks to that we have this splendid [requirements management tool] and database system and that, as I said earlier, you become aware of when you are making some clear, nice little change that is like this… This is actually a requirement atom that is in seven other different projects and in some way an approval must be gained from all these seven projects and all these seven project has to discuss whether or not they will apply this change or if they will not apply this change, and if they can afford to implement this change, in which phase they are in…” (Requirements engineer)

  • Q24: “It can be an unfortunate language blunder that makes the requirement difficult to understand, well, then you just update and correct it. On the other hand, it can be something that represents a large reconstruction. Then we have to raise ourselves to a suitable level before it is decided.” (System engineer manager)

  • Q25: “There are persons where I work that seriously say that this is only blah-blah, we shouldn’t do this.” (Focus group participant)

  • Q26: “… it has not always been so attractive for the software engineers to go to that job. […] And then, we have recruited externally directly to this role.” (System engineer manager)

  • Q27: “Many of those who have become requirements engineers have come to [the company] and they have not worked as an engineer before and they have not worked in the organisation before. And then you perhaps don’t have the ability to… have enough authority in your role and you can only gain this authority by showing that you know what you are doing, thus by knowledge. Then I also think that many of them [i.e. the requirements engineers] have always been half a step behind and then it is really hard to catch up and be half a step ahead instead.” (System engineer manager)

  • Q28: [Interviewee A:] “But to go a course to learn about requirements, it doesn’t exist today.” [Interviewee B:] “No, and not how you should act in these complex situations then, so to say, when they demand some things, create requirement on new things.” [Interviewee A:] “It is because they think that requirements engineering isn’t anything to invest in.” [Interviewee B:] “It is not a competence.” (A discussion between focus group participants)

  • Q29: “And don’t tell us too much, but just tell us exactly what we need to know. Don’t tell us more than we want to know. […] everyone wants the “box” that is the border and they want help with some things, but concerning other things they don’t want anybody else to interfere.” (Focus group participant)

  • Q30: [Interviewee A:] “Is there much prestige between groups?” [Interviewee B:] “Yes, but if you make changes in the organisation, it will be that every new organisation is responsible for their part. No one in the new organisation wants to be just a resource pool, instead you want to have responsibility of a subsystem.” (Discussion between focus group participants)

  • Q31: “There are some, we talk subsystems now, which attract more problems, because there are subsystems that are unwilling to make changes. Even if something would fit better into another subsystem, it is often this more reasonable subsystem that takes on the responsibility to do this.” (Focus group participant)

  • Q32: “… these territories again, you aren’t allowed to talk about things in that subsystem for example. Then they feel attacked in some way for some reason.” (Software engineer)

  • Q33: “You cannot participate from the customer phase, but at least in the system phase, in the analysis and everything. How you divide? Why the system looks the way it does? There should be people from all other subsystems that take part and not just get it served later on. – Here you are. – What is this? – This is all you need to know.” (Focus group participant)

  • Q34: “The requirements are made very messy. It is several different persons who have written the requirements. It feels like that there is no uniting trend, main thread in the whole. Everyone has had their own style.” (Requirements engineer)

  • Q35: “A lack here is then that we requirements engineers in the subsystems did not take part in the earlier contacts with the customer, when the customer requirements were specified. The first would be to steer it so that we can get a bit more clearly with regard to the requirements and secondly to understand what the requirements actually meant and what the requirements refer to. […] Assumptions that we don’t know of, that cause our interpretation to be something that the customer doesn’t agree to.” (Requirements engineer)

  • Q36: “Well, this means that the requirements engineers will always be a step behind or a half step behind. […] is why people do so both from construction and from system management, it is that you want to make sure that you have understood it. You don’t want to go a detour via something [i.e. requirements engineers] that you are afraid will distort the information.” (System engineer manager)

  • Q37: “Well, actually you ask how much time it takes to process our problem reports and is it such things that currently don’t work, so to say […] I mean, it can take a half year before everyone has said want they want to say and changed their minds ten times and it can take a very long time before our problem reports are put straight. It is not because it involves a thousand hours of effective work. Instead, there are very few hours of effective work, so to say. However, it takes time and there are a bunch of people that have a bunch of opinions in the beginning and then, after a while, there is some project manager that says, well, we don’t have money for this. We will not change this. It can take a long time.” (Requirements engineer)

  • Q38: “We make decisions, we don’t document them and we disseminate them to the wrong people. We can be much better there.” (Focus group participant)

  • Q39: “… some details float around in the organisation and are really important. We forget large technical problems that are like ticking bombs. We should have dealt with them immediately.” (System engineer manager)

  • Q40: “We have a whole bunch of requirements that nobody thinks about until we are going to verify them […] It should have been more critical maybe. To inform people that they are actually requirements.” (Requirements engineer)

  • Q41: “… this [requirements management tool], it is a high threshold to start working with it. Many people don’t like that. It is a matter of experience actually, partly to start thinking… to think in some structured way of thinking. You aren’t used to that either. So there is a large threshold to… with this. It is a bit troubling. However, it is actually so that the tool doesn’t really… You are used to clicking and things like that, so to speak, and always get a lot of feedback of where you are and what you are doing. Such things aren’t afforded by this tool, instead you have your little prompter and your small boxes to write in. You have difficulty to see the whole picture, so to speak.” (Software engineer)

  • Q42: “… how the requirements tool was used 3 or 4 years ago… and this led to documents that, to us who didn’t write them, were totally illegible.” (System engineer manager)

  • Q43: “Because an intuitive and easy-to-use tool that… I think it would have a quicker penetration in an organisation, than if you have a cumbersome tool that is difficult to use […] which purposely trips you up so that you get really tired. […] However, the very basis of having requirements management in database form, that I think is completely obvious.” (System engineer manager)

  • Q44: “Well, I don’t experience it as very intuitive or so, even if it of course has a lot of powerful functions. I would like it to be intuitive on a level such as in Access.” (System engineer manager)

  • Q45: “There are a lot of tools for requirements engineering and there is nothing wrong in that. However, one gets a lot of aid to do many errors quickly if one uses a tool in a wrong way.” (System engineer manager)

  • Q46: “So that I feel, I go very much on feeling. I have to do that. Check with her [the cognitive scientist] if it is up the creek.” (Requirements engineer)

  • Q47: “… what I think is missing is to take care of… acclimatisation of the tasks.” (Requirements engineer)

  • Q48: “It is always a problem when people are fresh out of university. They need time to be trained. You probably often underestimate that. It takes… to become very skilled in your discipline it takes several years before you have become experienced. Then, there is also a high turnover of staff.” (Subsystem test manager)

  • Q49: “… finally the time runs away. The deadline when everything has to be delivered is approaching. Then the construction has to start prematurely. […] in this unit, there are happy software engineers working on hearsay. […] That one say how it should work and someone builds based on that.” (Subsystem manager and software engineer, i.e. one person with two roles)

  • Q50: “However, it is always frustrating for those who write the requirements as well as for those who carry out the verification, since as a software engineer it is highly beneficial if the requirements are wrong. […] They aren’t seen as something that facilitate the work, but an obstacle that… that messes up things.” (Subsystem manager and software engineer, i.e. one person with two roles)

  • Q51: “You see a lot of trees, but you cannot see the forest.” (System engineer manager)

  • Q52: “They complain that they cannot see how things are related to each other. No, damn, it is not strange since there is no document that specifies how it is tied together. Instead, each person specifies his/her own function.” (Requirements engineer)

  • Q53: “Then the decision part, then it is this that I mentioned before that you have to have all dependencies in your head. This is a decision which I find difficult. To decide upon requirements changes.” (Requirements engineer)

  • Q54: “Well, you cannot write everything in the requirements. […] Don’t forget to check this and think about… stay alert and watch this… Because it isn’t possible, so to say… There is nowhere else.” (Requirements engineer)

  • Q55: “Like me, for example, that started to work with requirements. I would have needed formal education in; What are requirements? At what level should I land on? That… that I believe is rather important, that you know what a requirement is. How should you avoid being affected by others to write requirements that shouldn’t be written, that shouldn’t need to be written? How can I know that my requirement isn’t too fuzzy, so it could be misinterpreted and actually not be valuable? And that my requirements aren’t too detailed so I steer the construction in a direction that isn’t optimal. An important thing is not to write requirements that aren’t possible to verify.” (Requirements engineer)

  • Q56: “That coincides with how it looks today, as a snapshot of our reality.”

  • Q57: “My experience is that this reuse thing, especially code, is so to say a buzz word. It… you can look for a long time until you find something that fits pretty well, but most often it ends anyway in writing something new. I seldom see that you have used a component in different projects. Though, often you can take ideas, but the code must most often be rewritten.”

  • Q58: [Concerning the “empty box” of the search and screen routines of management of requirements changes:] “… that a change proposal arrives on it, often it is not large things, so that it is not worth throwing away what you already have made and search for something else new. So, from that point of view it agrees pretty well.”

  • Q59: “When it comes to changes, it is often an economical analysis that you do. Is this worth doing?”

  • Q60: [Concerning evaluation/choice routine, judgement and bargaining modes:] “Well, there are advantages and disadvantages with this of course, but I think this is the way it is.”

  • Q61: [Concerning the lists of decision matters:] “All these are questions that they put on themselves, clearly. However, what is interesting is if something is missing. I cannot think of anything right now.”

  • Q62: “However, I don’t feel this to be a work of low status, so to say. Instead, I would say that that they have high status, those who work with… It is they who make the decisions about how it should be done. And they are most often very knowledgeable. You rarely come across someone who is inexperienced and doesn’t know anything, so to say.”

  • Q63: “Between different subsystems, I believe it [i.e. prestige] is, more or less. Some more, others less.”

  • Q64: “… this, that the requirements are written in different ways by different persons, it has happened to me, which makes them difficult to interpret or that they haven’t been possible to verify…”

  • Q65: “A requirements engineer is often viewed as an administrative, non-technical person or role and they do not take part when technical decisions are discussed and things like that. So, I think it is correct that they aren’t involved [i.e. in discussions].”

  • Q66: “I would say that if they, who write the requirements, could communicate better then they [i.e. the requirements decisions] would land in the implementation phase and in the test phase at the same time. […] I think that the requirements engineers have a possibility to disseminate information to so many people as possible when the requirements have been updated, so that they reach everybody at the same time.”

  • Q67: “They can rather easily manage this part, the system people I mean. However, in other projects that I have taken part in, this is a large problem, where you don’t know how the system actually works.”

  • Q68: “Well, I think this also varies a lot. Because one has met persons who clearly have no idea of what requirements they write. At the same time, you have seen requirements engineers who are very skilled and have technical knowledge of how everything works. I think this is something that varies.”

Rights and permissions

Reprints and permissions

About this article

Cite this article

Alenljung, B., Persson, A. Portraying the practice of decision-making in requirements engineering: a case of large scale bespoke development. Requirements Eng 13, 257–279 (2008). https://doi.org/10.1007/s00766-008-0068-2

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-008-0068-2

Keywords

Navigation