Ways to contributeContribute to the RE Magazine Search Authors
13
Comments
Issues
Close
Close
1Write an articleMore Information
2Place an advertisementMore Information
3Sponsor the magazineMore Information

RE in Agile Projects: Survey Results

Results of research project announced in a previous issue.

2 Comments
Written by Gareth Rogers
Estimated Reading Time: 13 minutes, 0 second
Advertise with usAdvertisement
Best for System & Software Development

objectiF RPM – Requirements Engineering and Agile Development

www.microTOOL.de
Best for System & Software Development

objectiF RPM – Requirements Engineering and Agile Development

www.microTOOL.de

Though Requirements Engineering (RE) and Agile are sometimes perceived to be conflicting approaches to software development, the recent emergence of the term Agile RE suggests that a hybrid approach is possible, with traditional RE methods reused within iterative Agile lifecycles. This paper describes empirical research into Agile RE to better understand just how this works in practice and to provide guidelines on precisely which RE methods can be most successfully applied in this way.

Eight requirements problems –software development issues relating to the topic of requirements – were identified in the literature, and together with 14 of the most common requirements elicitation and analysis methods were used as the basis for a survey of current RE practice within Agile projects. Based on completed questionnaires by respondents from across industry, the research showed that many of the identified requirements problems are indeed recognised as challenges within Agile projects. While some issues such as changing requirements and over-specification were shown to be well addressed in Agile approaches, other problems such as hidden stakeholder needs and missing, ambiguous or inaccurate requirements continue to present important challenges.

The research provided evidence that the use of many RE methods within Agile projects is already widespread and is not in practice seen to be in conflict with Agile principles. The use of some other methods, such as questionnaires, goal models and state machines, for example, appeared in the results to be less well established.

Finally the results were reviewed with an expert panel and nine guidelines for the application of RE methods in scaled Agile projects are presented here. These recommend an increased awareness of key requirement challenges and are supported by evidence gathered from current practice.

Aims and Objectives

Discussing requirements in the traditional terms of the analysis phase and specification document often leads to the entrenched views of the Agile versus waterfall debate. This study therefore first set out to establish a common language between the different approaches, before then gathering data from current practice as to which RE methods are currently in use within Agile projects. The specific research objectives were therefore:

  1. Identify a set of core requirements problems (i.e. software development issues relating to requirements), independent of any particular development approach, which may provide a common ground between Agile and traditional approaches.
  2. Identify a set of standard RE methods with potential for reuse within Agile.
  3. Gather data from current practice in commerce and industry.
  4. Formulate guidelines during an expert review phase.

Results of the Literature Search

From a survey of the literature eight of the most frequently discussed requirement problems were identified in fulfilment of objective 1:

  1. Missing requirements
  2. Hidden stakeholder needs
  3. Inadequate or ambiguous requirements
  4. Conflicting requirements
  5. Lack of measurability or testability of requirements
  6. Onward communication of requirements
  7. Changing requirements
  8. Over-specified requirements

Concerning RE methods, those in the categories of requirements elicitation and analysis were found to offer more potential for reuse in Agile projects than other RE topics such as requirements management, whose methods are typically closely linked with a particular development lifecycle. Fourteen RE methods were therefore identified:

Elicitation Methods:

  • Workshops and/or interviews
  • Storyboards and scenarios
  • Mock-ups and prototypes
  • Background studies and system archaeology
  • Questionnaires or surveys
  • Creativity techniques Brainstorming or brainstorming paradox

Analysis Methods:

  • Context or problem diagrams
  • Use cases and/or use case diagrams
  • Conceptual data models (ERD's, class diagrams, etc.)
  • Business process or activity modelling
  • Sequence or event trace diagrams
  • State models or machines
  • Goals model or AND/OR trees
  • Special analysis of non-functional requirements

Key Sources:

  • Van Lamsweerde (2009) [7]
  • Robertson & Robertson (2012) [5]
  • Pressman (2005) [4]
  • Pohl & Rupp (2011) [3]
  • Faulk (1995) [1]
  • Leffingwell (2010) [2]

Research Method

A questionnaire was designed asking participants in Agile projects whether the above problems were recognised in practice and to what extent they were currently addressed. Respondents were also asked to report which, if any, of the identified methods were found to be useful in their Agile projects. The questionnaire was distributed electronically to a broad range of RE and Agile practitioners using relevant internet forums and communities. The results of the questionnaire were reviewed by an expert panel, with the ultimate goal of deriving guidelines as per the research aim.

Results of Primary Research

The survey was published in the IREB Magazine (Issue 2015-02, http://re-magazine.ireb.org/issues/2015-2-bridging-the-impossible/re-in-agile-projects-a-survey/), with links then posted in both Agile and Business Analysis Linked In forums. By the cut-off date in July a total of 43 completed responses had been received. The results for each question are displayed graphically below, with a brief analysis at the end of each section. Further interpretation of the results is provided in the Expert Review and Conclusion sections.

Section A: You and your project

Respondents were first asked to provide information about their role and type of Agile project:

A1: Which of the following best describes your role in the project?
A1: Which of the following best describes your role in the project?
A2: Which Agile method best describes your project? – Multiple selections allowed
A2: Which Agile method best describes your project? – Multiple selections allowed
A3: How large is your Agile project team?
A3: How large is your Agile project team?
A4: Which of the following additional scaling factors apply in your Agile project? – Multiple selections allowed
A4: Which of the following additional scaling factors apply in your Agile project? – Multiple selections allowed

Thus it can be seen that while respondents were predominantly from an RE background, a number of Agile specialists also participated. Scrum was seen to be clearly the most popular Agile method, though in a majority of projects one or more scaling factors (i.e. factors requiring a scaling of the pure Scrum approach as described, for example, in the Scrum Guide [Schwaber & Sutherland, 2011] [6]) were also found to be present.

Section B: Requirements Problems

B1: To what extent were missing requirements a problem in your Agile project?
B1: To what extent were missing requirements a problem in your Agile project?
B2: To what extent were hidden stakeholder needs a problem in your Agile project?
B2: To what extent were hidden stakeholder needs a problem in your Agile project?
B3: To what extent were inadequate or ambiguous requirements a problem in your Agile project?
B3: To what extent were inadequate or ambiguous requirements a problem in your Agile project?
B4: To what extent were conflicting requirements a problem in your Agile project?
B4: To what extent were conflicting requirements a problem in your Agile project?
B5: To what extent was a lack of measurability or testing a problem in your Agile project?
B5: To what extent was a lack of measurability or testing a problem in your Agile project?
B6: To what extent was the onward communication of requirements a problem in your Agile project?
B6: To what extent was the onward communication of requirements a problem in your Agile project?
B7: To what extent were changing requirements a problem in your Agile project?
B7: To what extent were changing requirements a problem in your Agile project?
B8: To what extent were over-specified requirements a problem in your Agile project?
B8: To what extent were over-specified requirements a problem in your Agile project?

The results appear to show that requirements problems are, broadly speaking, recognised within Agile projects. The extent to which these problems are addressed varied: respondents reported fewer errors as a result of issues such as changing requirements, communication of requirements to developers and over-specification, while other problems such as missing, ambiguous or inaccurate requirements and hidden stakeholder needs continued to present important challenges.

Section C1: RE Elicitation Methods

C1: Workshops and/or interviews were of use in gathering requirements in our project
C1: Workshops and/or interviews were of use in gathering requirements in our project
C2: Storyboards and/or scenarios were of use in gathering requirements in our project
C2: Storyboards and/or scenarios were of use in gathering requirements in our project
C3: Mockups and/or prototypes were of use in gathering requirements in our project
C3: Mockups and/or prototypes were of use in gathering requirements in our project
C4: Background studies and/or archaeology were of use in gathering requirements in our project
C4: Background studies and/or archaeology were of use in gathering requirements in our project
C5: Questionnaires were of use in gathering requirements in our project
C5: Questionnaires were of use in gathering requirements in our project
C6: Creativity techniques such as brainstorming were of use in gathering requirements in our project
C6: Creativity techniques such as brainstorming were of use in gathering requirements in our project

Particularly positive responses were received for workshops and interviews (C1), storyboards and scenarios (C2), and mockups and prototypes (C3). This is perhaps not surprising: intuitively, storyboards and scenarios match well to the Agile technique of user stories, while prototyping has a similar emphasis on an iterative, ‘working code’-based approach. Workshops and interviews can also be understood to be focusing on direct customer communication, though a distinction can be drawn here between the communication within an Agile team and a more systematic interviewing of the wider stakeholder community. The most negative responses were received to question C5 on questionnaires. One explanation for this might be that this technique is perceived as too slow and document-intensive for Agile.

Section C2: RE Analysis Methods

C7: Context or problem diagrams were of use in analysing and representing requirements in our project
C7: Context or problem diagrams were of use in analysing and representing requirements in our project
C8: Use cases were of use in analysing and representing requirements in our project
C8: Use cases were of use in analysing and representing requirements in our project
C9: Conceptual data modelling were of use in analysing and representing requirements in our project
C9: Conceptual data modelling were of use in analysing and representing requirements in our project
C10: Business process models were of use in analysing and representing requirements in our project
C10: Business process models were of use in analysing and representing requirements in our project
C11: Sequence or event trace diagrams were of use in analysing and representing requirements in our project
C11: Sequence or event trace diagrams were of use in analysing and representing requirements in our project
C12: State models or machines were of use in analysing and representing requirements in our project
C12: State models or machines were of use in analysing and representing requirements in our project
C13: Goal models were of use in analysing and representing requirements in our project
C13: Goal models were of use in analysing and representing requirements in our project
C14: Special attention was given to the analysis of non-functional requirements in our project
C14: Special attention was given to the analysis of non-functional requirements in our project

In general the results show that many anaylsis methods are used in Agile projects (49% of responses show agreement as opposed to 37% disagreement), though a consistent pattern for the general applicability of particular methods is hard to discern. Taking as a measure the number of responses expressing agreement (somewhat or strongly) as compared to the number expressing disagreement, the following analysis methods were most favoured:

  • Context or problem diagrams (28 agree compared to 8 disagree – C7)
  • Use cases (29/10 – C8)
  • Conceptual data modelling (21/13 – C9)
  • Business process modelling (24/13 – C10)
  • Analysis of non-functional requirements (23/13 – C14)

More negative results were seen for:

  • Sequence or event trace diagrams (16/22 – C11)
  • State models or machines (17/20 – C12)
  • Goal models (9/26 – C13)

Whether such results are because the methods are not useful in Agile projects, or whether there is simply a lack of knowledge or training, is not clear.

Expert Review

Based on the above results, the supporting background research and the experiences of the individuals involved, a review process was carried out with a small panel of RE and Agile experts. The results of this review – which added a degree of interpretation above and beyond the direct analysis of the research data – were formulated as nine guidelines for the use of RE within Agile projects:

  1. Agile methods, and Scrum in particular, typically prescribe small, cross-functional teams e.g. 7-9 team members. In more complex, scaled project environments, however, Agile does not preclude the use of larger teams including specialist BA or REng roles.
  2. Establishing real business needs and communicating these as software requirements to the developers remains as challenging a task within complex, Agile projects as it was previously in traditional approaches. Those responsible for this task within Agile projects should in particular be aware of – and take actions to avoid – the following requirement problems:

    • Missing requirements
    • Hidden needs
    • Inadequate or ambiguous requirements
    • Conflicting requirements
    • Lack of measurability or testability of requirements
  3. Agile approaches do not preclude the use of additional software engineering methods; RE methods in particular can play an important role in complementing core Agile methods. Though exactly how (e.g. over what scope), and when (i.e. in the project lifecycle) they are applied may vary, many RE methods for the elicitation, analysis and modelling of requirements are already being used in Agile projects. These include:

    • Interviews and workshops
    • Storyboards and scenarios
    • Mockups and prototypes
    • Background studies and system archaeology
    • Creativity techniques e.g. brainstorming
    • Techniques for the analysis of non-functional requirements
    • Context diagrams
    • Use cases and use case models
    • Conceptual data models (ERD’s, class diagrams, etc.)
    • Process models (business process models, activity diagrams, etc.)
  4. RE provides methods formalising the approach taken to identifying stakeholders and to the elicitation of requirements in workshops and interviews. A more systematic application of such techniques before the start of development can help to identify hidden needs in complex, Agile projects.
  5. There is a perception that in Agile approaches user stories replace all other forms of requirements: this is incorrect and increases the chances that the resulting requirements are ambiguous or inaccurate.
  6. RE modelling methods (e.g. of data, process or behaviour) support both completeness in the analysis as well as providing views of the problem that can be shared and corroborated amongst project members. Knowledge of these techniques, and their systematic application throughout development iterations, can help address the identified requirements problems in complex, Agile projects.
  7. Special attention needs to be given to non-functional requirements in Agile projects, where the focus would otherwise be on users' functional stories. This starts with a thorough analysis of non-functional aspects of the system such as usability, reliability, performance and portability.
  8. Context diagrams can play an important role in Agile projects by providing an overview of project scope beyond the confines of particular development iterations (or sprints).
  9. Business process models can play an important role in Agile projects by providing a coherent view of end-to-end processes, thus helping to place individual features (ie. backlog items) in a broader project context.

Conclusions

The research has provided evidence that many of the software development issues that the discipline of RE seeks to address – termed here ‘requirements problems’ – continue to be recognised as challenges within Agile projects. While some problems such as changing requirements and over-specification were reported as less prevalent under Agile, others, including hidden stakeholder needs and missing, ambiguous or inaccurate requirements, continue to be found with regularity.

The research has also found evidence that the use of many RE methods within Agile projects is widespread and is not, in practice, seen to be in conflict with Agile principles. The use of some other methods, such as questionnaires, goal models and state machines, appeared in these results to be less well established.

Based on the quantity of data gathered and the lack of project context provided, it would be hard to draw definite conclusions as to exactly how and when specific RE methods should be applied in Agile projects. Nevertheless following a review of both the research results and the underlying research topics, nine general guidelines for the application of RE methods within Agile projects were formulated (see previous section).

Afterword

This research has examined the premise that RE and Agile may be combined within a hybrid approach, which we may call Agile RE. By considering RE and Agile as collections of individual methods and techniques, the evidence of this research suggests that pragmatic approaches can be found that usefully combine elements of both.

As a final thought, however, one might additionally ask: is RE perhaps something more than the sum of its individual parts? That RE and Agile were once perceived to be in conflict may not only due to the incorrect assumption that RE is strictly tied to a waterfall process model, but rather on the more fundamental difference between an engineered, top-down approach to system development and the ideas of emergence (emerging requirements, emerging architecture) that underpin Agile. To understand not only if a technique, such as data or process modelling, is applicable, but exactly how (over what scope, at what granularity?) and when it should be applied, further examination of these questions may be required.

Acknowledgements

Many thanks to Kim Lauenroth and Thorsten Weyer for their participation in the expert review process, and to all those who took the time to respond to the survey.

References and Literature

  • [1] Faulk, S.R. (1995) 'Software requirements: a tutorial', Software Engineering – Tutorial Volume for The Open University.
  • [2] Leffingwell, D. (2010) Agile software requirements: lean requirements practices for teams, programs, and the enterprise, Addison-Wesley Professional.
  • [3] Pohl, K. and Rupp, C. (2011) Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam-Foundation Level-IREB compliant, Rocky Nook.
  • [4] Pressman, R.S. (2005) Software engineering: a practitioner's approach, 6th Edition edn. Software Myths page 13, Palgrave Macmillan.
  • [5] Robertson, S. and Robertson, J. (2012) Mastering the requirements process: getting requirements right, Addison-Wesley.
  • [6] Schwaber, K. and Sutherland, J. (2011) 'The Scrum Guide', Scrum Alliance, [Online]. Available at scrum.org (Accessed 01/09/2015).
  • [7] Van Lamsweerde, A. (ed) (2009) Requirements engineering: from system goals to UML models to software specifications, 1st edn. John Wiley & Sons.


Give feedback


Feedback-

From Paul Miller

Great article, we need more survey based research like this.

How can the Agile approach claim that changing requirements are shown to be well addressed in the face of the contradiction that hidden, missing and ambiguous requirements are raised as important challenges to the Agile approach. Each of those challenges represent changing requirements at some point in time as well as an impact and cost. So how can it be claimed that change is well addressed? Maybe more time spent up front carefully eliciting & analysing functional and the often overlooked (missed perhaps?) non functional requirements would help.

From Gareth Rogers – Author

Thanks Paul.

The survey sample is of course quite small, but the message that requirements problems have not simply gone away in Agile projects is certainly one which chimes with my own experience. Yes, I agree - Agile interpretations that advise against upfront thinking or that focus exclusively on functional, user-focused requirements (e.g. user stories) need to be looked at carefully again and would often be well-served by common sense RE principles!

Sponsors