Developers Like Requirements Specifications; Project Managers Don’t and a Possibly Transcendent Hawthorne Effect
Authors: Daniel Isaacs and Daniel M. Berry
ABSTRACT
This paper reports the results of a case study conducted in July 2010 of one industrial software development project to determine how the project’s lack of any explicit requirements gathering process affected the project’s development and the product that it produced. The study reveals that the lack of any requirements gathering process led to missing functions in the product, reduced productivity among the project’s members, and poor cost estimation. This lack converted a potentially profitable project into a liability. In the end, the project members completed the product, but much time was wasted. A requirements specification could have saved this time.
Conducting the case study resulted in an increased awareness among the study’s subjects, i.e., the project’s management and members, that a requirements engineering process was needed. This awareness led to a Hawthorne effect, in which the project management and members improved their requirements process. The next project conducted by the project management was begun with an explicit requirements gathering process. This improved process continued through at least May 2011, 11 months after completion of the study.
I. INTRODUCTION
In the traditional software development lifecycle (SDLC), requirements engineering (RE) is arguably one of the most important stages. The role of RE has been described in literature as very important to identify stakeholders, detect problems, explore different solutions, and to decide what to implement [1].
Many believe that software development problems can be prevented with good RE practices [1]-[3]. However, what happens when a project goes straight to the development phase, having identified few requirements?
This paper presents the findings from a case study of one project by one organization to integrate into its suite of products a product from another organization that the first organization acquired. The goal of the study is to provide some insight on how the lack of RE in a software development project affected the quality of the developed software product. The paper reports the findings of a questionnaire filled in by the project’s members. The questionnaire asked project members for their views on various RE topics relevant to the project that they were involved in. Section II of the rest of this paper describes related empirical work addressing the importance of RE. The background of the company, its challenges in RE, the study motivation, and the case study design are described in Section III. The findings of the case study are presented in Section IV and are discussed in greater detail in Section V. The paper concludes with final thoughts about the case study in Section VI.
This paper conflates “requirements” with “requirements specification” as did the members of the project examined in the case study. They use the terms interchangeably, and “lacking requirements” means “lacking both requirements and a requirements specification”.
II. RELATED CASE STUDY WORK
Through surveys and interviews of 76 stakeholders, including project managers, requirements analysts, customers, and quality assurers, Hofmann and Lehner [2] tried to identify the RE practices that clearly contribute to the success of a software project. They studied 15 RE teams in nine development organizations in telecommunications and banking. Among their conclusions were that:
- the most successful teams expended an effort on requirements specifications that was twice that expended by the least successful teams, and
- the most successful teams did RE for a greater portion of the lifecycles of their software than did the least successful teams.
From these conclusions, Hofmann and Lehner made specific recommendations of best practices.
A full-day workshop was conducted in 2005 on the theme that upfront RE pays off in an improved development, software, or both. Each workshop presentation described a case study of the development of a real-life or substantial research software in which thorough RE was done before development began [4]. A 1.5-hour summary of this workshop was presented at a panel titled “To do or not to do: If the RE payoff is so good, why aren’t more companies doing it?” at the 2005 International Requirements Engineering Conference [5].
Damian et al. [3], [6], [7] report, in three separate papers, the results of a 30-month, three-stage, explanatory case study, using questionnaires, interviews, and document inspection, of the RE process at the Australian Centre for Unisys Software (ACUS). During the study, the Centre was doing a concerted RE process improvement following a Capability Maturity Model (CMM) [8] assessment, and, the RE process improvement did indeed improve the Centre’s software development. The studies conclude that an effective RE process from the beginning of a development improves the entire SDLC by improving the effectiveness of other processes in the SDLC, and ultimately, it improves the quality of the product developed during the SDLC.
III. CASE STUDY DESCRIPTION
This section describes all the details of the case study.
A. The Company
This case study of RE practices was conducted at Company X. Founded in 1981, X has around 600 employees in 26 offices around the world, and of these from 225 to 250 are in the Ontario office. Its revenues in Fiscal 2011 from about 20 product suites and about 100 bundleable services was US$99.2 million. Its average software development project in Ontario: had three to five developers and one quality
assurer, took 18 months, ranging from 12 to 24 months, generated 2.8 MB of delivered source code, and followed a so-called agile [9] SDLC. When issues arose during development, extreme programming [10] was encouraged.
While X claims to follow an agile SDLC, it evidently did not take care to carefully follow the steps that ensured wide distribution of requirements knowledge in the absence of requirements documentation. Therefore, it seems to the authors that the usual SDLC was a very lightweight version of agile methods.
Recently, X acquired another Canadian company called Y. Y’s main product is called PY. X acquired Y mainly to incorporate PY’s functionality into its own products. The case study is about the project to implement PY’s functionality as one of X’s products, PX. X could not just use PY directly because X does not support the technology used to run PY.
The X project to build PX, hereinafter called “the project”, began on March 2008. The project started with a team of 16, but was down at the time of the study to seven developers and one quality assurer. Eight developers had quit in a span of nine months. Besides the first author (FA), there were seven members on the team. These seven members included six developers, including the FA, and one quality assurer. The project was scheduled to last 18 months, but it required 24 months.
The FA is speaking from personal experience in describing the project. Therefore, this paper uses first person plural, i.e., “we”, “us”, “our”, etc., to include the FA among the personnel of the project. The second author, the FA’s academic supervisor, is not included among the people called
“we”.
B. Limitation of Method
The FA’s presence on the project team opens the possibility of personal bias in the reporting. However, the FA has tried to mitigate this bias by the use of a questionnaire of the other seven project members to gather information from which his conclusions are drawn. Nevertheless, the FA did the data analysis. On the other hand, the second author agrees with the results of the analysis.
The reader should remember that this paper reports a case study, which is a description of one company’s experience with one of its projects. The conclusions of this paper, while valid for the experience, cannot be generalized beyond that. We hope that others with similar experiences will report them so that generalization can occur from repeated occurrences of similar experiences.
C. Challenges in Requirements
One significant challenges we faced when we started the project was our lack of knowledge of PY’s domain. This lack was worsened by the fact that PY’s developers, project management, and end users were geographically separated from the PX development team. Furthermore,
when Y became part of X, all the PY developers, who knew everything about PY, quit rather than become X employees. Therefore, the X employees on the PX development team were entirely on their own to develop PX.
The initial stages of development can be summarized:
- X’s project management communicated to the PX project members that their job was to duplicate the functionality of PY.
- PY’s functionality had to be migrated to a different technology, in order to incorporate the functionality into X’s suite of software.
- PX’s requirements were communicated as a one-sentence requirements specification “Mimic this Webpage.” while pointing to the Webpage implemented by PY.
- PY’s functionality was not defined or documented anywhere. Information sufficient for a smooth development was not provided. As a result, the developers did not fully understand what was required to build PY.
- The implementation of PX relied heavily on each developer’s own interpretation, a serious problem since each developer’s interpretation was different from those of the others.
D. Study Motivation
There is evidence that RE increases productivity, improves cost estimation, reduces defects, and has many other benefits [2], [3]. However, in many industrial environments, including at X, RE is completely ignored [2], [4], [5], [11]. Consequently, the FA was inspired to conduct an empirical study of the impact of missing RE in a software development product.
E. Design of the Case Study
This section describes the design of the case study, including the use of a questionnaire to collect the data, the questions in the questionnaire, and the reasons for the brevity of the questionnaire.
1) Data Collection Procedure: The FA invited all seven other project members to fill in a questionnaire about their attitudes towards RE in the project. All seven project members returned filled in questionnaires. The questionnaire was an adaptation of that used by Damian et al. [7].
2) The Questionnaire: Figure 1 shows the complete questionnaire. Many a question of the questionnaire is answered with a 5-point Likert scale that is given directly below the question. If a question with a Likert scale is ended with a “Why?” or if a question has no Likert scale, then an openended textual answer is expected.1
Figure 1. The QuestionnaireÂ
Section A: General Feedback about the Lack of Requirements
Q1. How important do you feel requirements are?
A: Far B: More C: About D: Less E: Far More the Same Less
Q2. How do you feel that the lack of requirements influenced your work?
Q3. Based on your experience on this project, would you spend more or less time in the requirements phase of the
development? Why?
A: Far B: More C: About D: Less E: Far More the Same Less
Section B: Definition of the problem, and the possible benefits from understanding the problem
Q4. In your design, coding, testing, or documentation activities, how important was it to understand the features and
technical requirements?
Q5. In contrast to previous experiences, has there been more or less rework during development (but before deployment):
A: Far B: More C: About D: Less E: Far More the Same Less
Q6. How do you believe the lack of requirements improved or deteriorated: (a) productivity and (b) product quality.
Section C: Estimation
Q7. Did the lack of requirements affect your cost estimation process?
A: Strongly B: Agree C: No D: Disagree E: Strongly
Agree Effect Disagree
Q8. When thinking about your estimates, if any, can you think of reasons for discrepancies? With respect to (a) Design,
(b) Implementation, (c) Testing and (d) Documentation.
Q9. How could you have improved your estimations?
Figure 1. The Questionnaire
The questionnaire was designed to be short and easy to answer in order to encourage more and complete responses from busy employees who were behind schedule in their current project to develop PX. The fact that all of the project members (other than the FA who could not be expected to fill in his own questionnaire) responded and responded fully says that this decision was not wrong. In any case, the respondent were the FA’s co-workers in the project. Therefore, the FA could and did ask his co-workers followup questions to clarify their answers and to understand their real meanings.
IV. CASE STUDY FINDINGS
A. General Feedback about the Lack of Requirements
Answers to Q1 showed that even though requirements were largely missing in the project, all seven project members thought that requirements were at least important, while five of these seven, thought that requirements are far more important.
Answers to Q2 showed that the lack of requirements influenced their work in many ways. In project members’ own words: “It would have been easier to put all of the components together.”, “… too much guessing regarding expected results”, “not enough time to develop good test cases, which made testing not being complete enough”, “It hampered my work creating unexpected results.”, and “We had to go back and rewrite sections of the code, causing project timelines to increase.”
Answers to Q3 showed that six of the seven project members thought that they should have spent more time on the requirements phase, with two of these six saying “Far More” instead of just “More”. In these project members’ own words: “RE provides a better understanding of what exactly needs to be done.”, “RE gives a crystal clear understanding of what the user is looking for and what he/she wants to achieve from this project.”, and “RE would have prevented many different problems and miscommunications with management.” Only one developer of the seven project members thought that he should have spent far less time on the requirements phase (See Section V.A).
B. Definition of the Problem, and the Possible Benefits from Understanding the Problem
In Q4, the four phases of the X’s SDLC (SDLC), designing, coding, testing, and documentation, were investigated. For each phase, each respondent had to choose one of five possible degrees of importance, from “Very Important” through “Not Important At All”. Figure 2 shows the number of responses per degree of importance for each phase. In this chart, each degree of importance is represented by a
bar with a different pattern. For the designing phase, six of the project members thought that understanding the problem is very important, while one agreed that it is important. For the coding phase, all of the project members agreed that understanding the problem is very important. For the testing phase, three project members thought that understanding the problem is important, while another three, including the tester, thought that it is very important. Only one project member thought that understanding the problem is not important at all for the testing phase. For the documentation phase, each answer had at least one vote, with each of
“Indeterminate” and “Very Important” having two votes.
Figure 2. Importance to Different Phases of the SDLC of Understanding Requirements
Answers to Q5 showed that six out of seven project members thought the amount of rework done in the current project was about the same or more than in previous projects, in which they did not do any RE, as well. Three of these six project members thought that there was more work in the current project. Only one project member, a developer, thought there was far less rework than in previous projects.
In their answers to Q6, regarding the lack-of-requirements effect on productivity, project members said: “Productivity was negatively affected by the amount of work that had to be redone.”, “Lack of RE negatively impacted productivity.”, and “Lack of information always results in unexpected results.” Regarding the lack-of-requirements effect on product quality, project members said: “It deteriorated product quality because you have to keep changing the design and code as the requirements change.” and “It reduced the initial product quality, however the later product is still of good quality, but it took much longer to get to this point due to
the lack of proper requirements.”
C. Estimating Effort, Cost, and Development Time
Answers to Q7 showed that the lack of requirements affected the effort, cost, and development time estimation process negatively. In particular, five of the seven project members strongly agreed that the lack of requirements affected their estimation, while two agreed that the lack made a difference.
In response to Q8, about discrepancies in estimations for the design phase, one project member said: “The design had to be reworked several times due to new discoveries and additional requirements.” For discrepancies in implementation, one project member said that: “The implementation had to be restarted due to the changes in design.” For testing, one project member said: “It was usually a set back since there was no proper understanding of what the system was required to do.” For the documentation phase, one project
member said that: “It was very late as it had to be started late in the project.”
In response to Q9, one project member said that in order for the developers to improve their estimations, they would need to: “Have a list of requirements and a design document about how to code the project.” Others said: “More clear guidelines and expectations would have helped, and additional overview of the work that was needed to be done.”, and “With additional time, I would have known of various functional requirements before the development had begun.”
V. DISCUSSION
This section draws conclusions from the data.
A. General Feedback about the Lack of Requirements
The evidence in this study indicates that even if project managers do not believe in RE, many developers and quality assurers do. Most developers agree that requirements are far more important. In fact, all project members agree that RE improves understanding of details, dependencies and complexities. Nonetheless, disbelief in the requirements phase does not happen by accident. The authors believe that project management tends to skip the requirements phase because of the pressure from senior management to be the
first on the market.
In fact, based on the FA’s experiences at X and on informal discussions with his fellow employees, the FA concluded that while the project developers liked requirement specifications, the project’s managers did not. In this project, project management associates knowledge with power and job stability. Each project manager believes that if he is the only one that knows an important something, he will be needed at all times and be indispensable. A requirements specification would expose this knowledge early and make it available to everyone on the project. Thus, a requirements specification was very low on the list of any project manager’s desires.
In the absence of well defined requirements, productivity was hampered. The resulting guessing what needs to be done produces uncertainty, which leads to errors. The resulting rewriting wastes time. In any scenario, not knowing what to do is not good.
For Q1 and Q2, there is a risk that a project member overstates his thoughts because he desires to give an answer that will be perceived as correct. In order to mitigate this risk, Q3 was designed as a corroborating question in order to see how requirements affected each project member’s work. Additionally, Q3 elicits discussion about problems that arose in the project and how RE would have helped.
As mentioned, one developer thought he would have spent less time in the requirements phase. The relatively junior developer offered as a reason: “I would still need to spend a lot of time in the designing phase.” After the FA talked with the developer, it was clear to the FA that the developer was talking about the phase occurring after requirements specification but before coding. As is typical with junior developers, this developer seems to value more discovering the variables, properties, and methods of the different objects that PX needs than taking the time to understand what is required of PX.
B. Definition of the Problem, and the Possible Benefits from Understanding the Problem
When asked for the importance of understanding features and requirements in the different phases of the SDLC, the project members seem to believe that understanding features and requirements is relevant for most phases but documentation. Based on what the FA knows about the project there are several possible explanations. One is that developers were not forced to document their work. As
a result, they do not value this phase at all. Another is that documentation is done after development. As a result, understanding features and requirements is not important to the documentation phase. This conclusion is strange given that a requirements document, if produced, should inform more than just requirements. Furthermore, documentation can be used as a basis for test cases and the user’s manual. Nonetheless, understanding what to do on design and coding seems extremely relevant since rework is lessened, the effectiveness of communication increases, and developers are able to make better decisions.
The fact that the amount of rework on this project was about the same as on other projects reveals that developing software without understanding its features and requirements is the norm at X. Project management had apparently not learned from previous experiences, thus strenghthening the FA’s conclusion that project management did not like requirements specifications. Regardless, the reality is that the time, effort, and cost of doing some tasks twice, or more, due to the lack of understanding of requirements, is always a setback.
Regarding productivity, it can be said that the development team was actually quite productive when measured purely by lines of code produced per hour, i.e., gross productivity. Nonetheless, at times, the development team produced the wrong results, making its net productivity considerable lower than its gross productivity, as thrown out lines of code are subtracted from the numerator, and the rework time is added to the denominator.
However, the work was not well distributed. Some developers were the sole owners of their components. In addition, the development team had no meetings to propagate knowledge. As a result, when a project member went on vacation or on a sick day, productivity was seriously hurt.
Initially, organized RE did not happen. Consequently, the development team did not understand the product. The developers and testers were determining requirements on the fly as they were coding or writing test cases, and each was deciding somewhat independently. As a result, the product quality was affected negatively. Over time, the development team was able to gather enough knowledge to develop the product. Consequently, the overall product quality was acceptable in the end. Nonetheless, the product was finished later than expected and later than required.
C. Estimating Effort, Cost, and Development Time
The development team clearly indicated that they believed that having requirements can improve software development and project management estimations. When asked why discrepancies might exist between estimations and actual, project members’ opinions were very similar. The most common complaint was that the work had to be restarted due to missing specifications.
Discrepancies occur when the team does not work together from the beginning. However, when working as a team, the estimates are typically fairly accurate since everyone knows how long each piece should take. When asked how developers would have improved their estimations the message is clear: the team needs a better understanding of the requirements and their scope.
D. The Middle Stages
Several problems happened because of the lack of requirements and communication between project management and developers.
Developers used a variety of techniques to develop the product. However, most developers were new in the company, and were not introduced to the company standard technique (CST). As a result, project management scheduled a meeting to inform all developers that they had to redevelop their code using the CST instead. The main argument for using the CST is that with each developer using a different technique, if anyone leaves the project, it is difficult for another to continue the leaver’s work, thus increasing the risk of a failed project. In contrast, with a mandated CST, continuity of the project in the face of departures was assured. Changing the project to use the CST delayed the project for one month.
The Quality Assurance (QA) Team started to test the product. They would compare the old product against our newly created product. If the new system was missing some functionality or behaved different from the old system, the QA team would open a ticket in the bug-tracking application BTA. However, the interaction between the QA team and the development team had some issues. Only one member from the QA team was available for testing. Historically, X does not invest too many resources in testing any of its developed software. Furthermore, after the development team spent nine months, October 2008-July 2009, sharing knowledge with one member from the QA team, he was moved to another project. Consequently, the development team had to start from scratch with a new member from the QA team. Therefore, testing was delayed until the new member could understand the product. By the end of June 2010, the QA team had logged 681 issues. After reviewing only the first 100 issues, it became clear that already 37 of
them were the result of missing requirements.
The senior management team that approves X’s companywide development of new products had a hard time approving this project for continuation. The main reason was that they thought the application was not robust enough because of all the issues that were registered in BTA.
There were other issues such as: several developers’ having spent a month working on some functionality, when another developer said: “You should use these libraries.” Suddenly, the one-month struggle was over in five minutes. Also, sometimes, when developers fixed one problem, other functionalities of the application stopped working.
E. The Positives
There are some positive aspects to developing a product with an understanding of few to no requirements. In our case, we had the old system that we had to replicate. Consequently, we could see how the old user interface looks and duplicate it, with our new components. Therefore, we did not waste any time trying to come up with an interface, which saved time.
The old system’s relational database is IBM’s DB2. In the beginning stages, this fact was a problem, because no one in the team had DB2 expertise. However, knowing DB2 was not necessary, since the old system writes the queries into a log file. As a result, we had all the necessary queries to load into the UI components to get the database to perform the different actions such as edit, save, and submit.
F. The Final Stages
In the final stages of the development, even though the developers were able to play with the old system, requirements were still missing. For example, if some fields were filled, other fields were automatically marked as required. The forms are so complex that this marking is not easy to notice. Consequently, a lot of tickets were opened about these kinds of issues.
After working for two years on the same Webpages, developers started to miss details. Usually, other users, new developers, or clients saw details that people involved in the project for years could not see. It was embarrassing to us when clients noticed the new product lacked a basic functionality the old product had. Nonetheless, the development team learned all about the danger of tacit assumptions borne of expertise and how important ignorance is for spotting them [12].
Near the end of the project, we tried to make things right. We tried to follow more of a truly agile SDLC [9]. Every Monday, we would go through a list of bugs and missing requirements, and try to fix them by Friday. Also, the development team would review a list of requirements from users, and try to incorporate the ones that were feasible. Finally, on Friday, we would deploy the changes enacted
since Monday. The QA team reviewed them and communicated the results to project management and the development team. On Monday, we would start all over again.
Although the project started to move at a faster pace, at this point it was too late. The project’s management lost credibility with senior management. In fact, one day, the project’s management said the project was changed from something profitable to a liability. Project members also suffered, as no one got salary raises and no one was promoted to higher positions, raises and promotions being
the key rewards within X for an employee’s having done well.
With all this adversity and stress, several developers quit the company. The developers were doing all they could to produce results, but they felt that their work was not appreciated. The responses show that the developers felt that had there been a good RE process in place, the team would have achieved its goals on time. In that circumstance, perhaps most of the team would still be working for X;
at the very least, the FA would still be there. Thus, the lack of requirements affects not only project timelines and customers, but also the personal lives of the team members.
G. The Road to Improvement
How could we have improved the course of this project? Hoffman and Lehner [2] state that there are three factors that contribute to project success: knowledge, resources, and process.
It is important to have the experience and expertise on a team to achieve effectiveness. However, there’s always a dilemma with knowledge. Hoffman and Lehner identified the thin spread of application domain knowledge as one of the most salient problems in software projects [2]. As mentioned above, at least within this project in X, project management associated knowledge with power and job stability, each project manager believing that if he is the one that knows everything, he will be indispensable. Moreover,
each such manager believes that no other employee has this special knowledge that he has. As a result, after eighteen months, project management gathered the development team to discuss about the concepts they thought needed to be understood to complete the project. However, by this point, most of the team had figured out a way to understand the concepts, which made the meeting meaningless. Such a meeting would have been invaluable much earlier into the project and would have saved a lot of time, tickets, and grief.
Guinan, Cooprider, and Faraj [13] report an average RE team size of 5.6 members in the 66 projects they studied. It is safe to say that the more people allocated to well-defined RE, the higher are the chances for the project to succeed. In our case, the team was small. Consequently, it is unrealistic to have five or six people devoted to only RE. However, if project management had had all project members thoroughly exercise the legacy product prior to starting development, the entire team would have understood what the new product had to do. In this case, 100% of the team would do RE, and then it would do implementation based on its own understanding
of the requirements.
Our RE process got to the point at which project members could account for stakeholders’ learning curves and for any requirements negotiation. Also, our architecture was able to support most of the requested changes, even if the requirements were always changing. In fact, project members easily expanded the forms to comply with recent changes and new standards that the Canadian and United States governments had instituted for software in PX’s domain.
H. Hawthorne Effect: An Impact on Future Projects
The conduct of the survey had an unexpected and surprising Hawthorne effect. “The Hawthorne effect is a form of reactivity whereby subjects improve or modify an aspect of their behavior being experimentally measured simply in response to the fact that they are being studied . . . ” [14].
About a month after completion of the survey for this study in July 2010, the project management in charge of PX was given the responsibility to lead a new project for a new client. As of September 2010, this new project was still in its early stages. Nonetheless, the FA already noticed changes in project members and management. Conducting the case study among the project members resulted in awareness that changes in the RE practices were needed. In a project member’s own words: “Moving forward, we need clearly
defined requirements since they would have saved more time and efforts in terms of reducing the back and forth communication in the development and testing stage.”
This new project presented an opportunity for project members and management to do things differently. Project management was taking full advantage of the opportunity. In this new project, the client has been required to write a business requirements document which describes: business requirements, business policies and regulations, nonfunctional requirements, business data models, and much more. Knowledge was not withheld anymore, as the business requirements document is frequently updated and distributed
across developers. Additionally, developers were invited to listen to telephone conferences project management has with the client. The new client was expected to fully cooperate with the fields and search criteria that will be shown in the user interface. At times, it was hard to believe that this was the same project management that developed PX. Evidently, the questionnaire made project members aware of RE. Thus, the FA’s case study seems to have induced a sustained after-the-fact Hawthorne effect.
The FA has checked with his former teammates on the PX project and has determined that as of the date of this writing in May 2011, some ten months after the conclusion of the survey, the improved RE process continues.2 One of the former teammates that the FA asked said “We are trying to deliver a product but the client kept changing it. . . but it [the process] is still improved.” So far, there appears to be fewer defects, but the “product is still not finished so it’s hard to tell.” As for completing by the deadline, they are
still “on track because of some padding we have been giving ourselves. We are doing a better job on this one.” Finally, the customer seems to be satisfied, “They have been pretty happy with what they’ve been seeing so far.”
Perhaps, a good way to get an organization to improve its RE process, particularly when it has none is to conduct a survey like that used for this case study in the middle of a challenged project, when it is apparent to all how challenged it is, even if no one admits out loud that it is challenged!
VI. CONCLUSIONS
This paper reports the results of a case study that investigated how the lack of requirements affected one software development process. Data from the study show that the lack of requirements understanding and a requirements specification had a direct impact on design, coding, testing, cost estimation, and project management.
That a product can be developed with little or no RE follows from the fact that we were able to develop the product without any serious RE. Nonetheless, the road was very painful. Ignoring RE makes answering questions such as: “When will it be finished?” or “Will it meet the customers’ expectations?” hard to answer. What remains constant is that RE can make the whole process better.
Getting industry to regularly do strong RE for its development is a cultural change that will take years. Convincing senior and project management the value of RE is not an easy task. Perhaps, just getting people to vocalize the unmentioned, but clear difficulties they face and making people aware of other possibilities can help speed up the cultural change.
REFERENCES
[1] B. Nuseibeh and S. Easterbrook, “Requirements engineering: A roadmap,” in Proceedings of the Conference on The Future
of Software Engineering, ser. ICSE ’00, 2000, pp. 35-46.
[2] H. F. Hofmann and F. Lehner, “Requirements engineering as a success factor in software projects,” IEEE Software, vol. 18, no. 4, pp. 58-66, 2001.
[3] D. Damian and J. Chisan, “An empirical study of the complex relationships between requirements engineering processes and
other processes that lead to payoffs in productivity, quality, and risk management,” IEEE Transactions on Software Engineering,
vol. 32, no. 7, pp. 433-453, 2006.
[4] requirements-engineering.org, “RE Day 2005 Website,” Viewed 10 August 2010, http://www.requirements-engineering.org/REday05/.
[5] D. M. Berry, D. Damian, A. Finkelstein, D. Gause, R. Hall, and A. Wassyng, “To do or not to do: If the requirements engineering payoff is so good, why aren’t more companies doing it?” in Proceedings of the IEEE International Conference on Requirements Engineering (RE), 2005, p. 447, www.requirements-engineering.org/REnotDonePanelRE05/.
[6] D. Damian, D. Zowghi, L. Vaidyanathasamy, and Y. Pal, “An industrial case study of immediate benefits of requirements engineering process improvement at the australian center for unisys software,” Empirical Software Engineering, vol. 9, no. 1-2, pp. 45-75, 2004.
[7] D. Damian, J. Chisan, L. Vaidyanathasamy, and Y. Pal, “Requirements engineering and downstream software development:
Findings from a case study,” Empirical Software Engineering, vol. 10, no. 3, pp. 255-283, 2005.
[8] M. C. Paulk, B. Curtis, M. B. Chrissis, and C. V. Weber, “Capability maturity model, version 1.1,” IEEE Software, vol. 10, no. 4, pp. 18-27, 1993.
[9] Agile Alliance, “Principles: The agile alliance,” 2001, http://www.agilealliance.org/.
[10] K. Beck, Extreme Programming Explained: Embrace Change. Addison-Wesley Pub Co., 1999.
[11] P. Morris, M. Masera, and M. Wilikens, “Requirements engineering and industrial uptake,” in Proceedings of the Third International Conference on Requirements Engineering (ICRE’98), 1998, pp. 130-137.
[12] D. M. Berry, “The importance of ignorance in requirements engineering,” Journal of Systems and Software, vol. 28, no. 2,
pp. 179-184, 1995.
[13] P. J. Guinan, J. G. Cooprider, and S. Faraj, “Enabling software development team performance during requirements definition:
A behavioral versus technical approach,” Information Systems Research, vol. 9, no. 2, pp. 101-125, 1998.
[14] Wikipedia, “Hawthorne effect,” Viewed 25 May 2011, http://en.wikipedia.org/wiki/Hawthorne effect.