Understanding information needs of agile teams to improve requirements communication

Requirements engineering (RE) plays an important role in software projects, but is rarely done properly – especially in agile projects, which rely more on face-to-face communication than on in-depth documentation.

Change happens often with agile development methods, and consequently agile teams are more likely to rely on informal communication than on formal specifications that may be laborious to specify and read.

Ideally, frequent communication ensures that all team members understand (or are at least aware of) the requirements without the need for documented requirements artifacts. In reality miscommunication and misunderstanding of requirements is common within agile projects.

Best practices associated with requirements engineering are often ignored in agile projects. The table below lists some common RE challenges that such agile projects face, along with their potential impact.

There are many different ways to “do” requirements engineering. Most of them are fairly heavy-weight processes, with a strong emphasis on documentation. The task-oriented requirements engineering framework (TORE) is no exception. TORE is designed to provide guidance for people involved in an RE process with regard to decisions to be made when determining requirements for an interactive (or an information) system.

Within the TORE framework, requirements are refined over different levels of abstraction, which typically leads to the creation of a large number of requirements artifacts that describe:

• project topics: general information about the project, the customer, and important dates;

• stakeholders, in the form of textual role descriptions and personas;

• project goals that the various stakeholders have in mind, using textual descriptions or goal models;

• tasks & business processes, in textual form;

• as-is situations of tasks and/or business processes, typically using a combination of UML and textual descriptions that motivate the need for a new system;

• to-be situations of tasks and/or business processes, including descriptions of the expected benefits of the new system;

• business data and rules that need to be considered in the to-be situations;

• the system context or the system’s environment, e.g. users and external systems;

• interactions with entities in the system’s environment;

• interaction data and rules, i.e. the data that will be exchanged during interactions with the environment and the rules that apply to those interactions;

• system functions that specify the input, internal behaviour, and output of the system’s (automated) functionalities;

• quality requirements, also known as non-functional requirements;

• technical constraints that limit the solution space beyond what is necessary.

This study looks at the relation between TORE artifacts and agile RE, and which of TORE’s best practices can be “ported” to agile RE.

The study has three objectives (side note: There’s actually a fourth one, but since it hasn’t been described in this article I’ll just pretend it doesn’t exist.).

1. Investigate whether and to what extent information specified in traditional RE artifacts is also specified in artifacts resulting from agile RE practices

Two of this paper’s authors have previously worked on a mapping analysis of agile RE practices and TORE artifacts (side note: It’s not described very clearly in the paper, it seems that the authors compare templates for agile “artifacts” with templates for TORE artifacts.). For this study, they created an updated and improved version of that analysis that’s based on a long-term empirical study on experiences from practitioners.

2. Gain more insights into challenges and investigate information needs of agile team members

For this part of the study, the authors first conducted interviews with four practitioners about RE-related agile practices, RE artifacts, and possible problems related to RE documentation and communication. Then, they conducted a survey on the importance of RE artifacts among 14 graduate students.

3. Develop communication and documentation guidelines

Finally, the authors drafted two possible solutions to improve agile RE. They used a survey to ask 11 practitioners about their agile RE practices, challenges, and their opinion on the two proposed solutions.

The study provides insight into the relation between traditional and agile requirements engineering, and shows areas where agile RE could improve.

The table below shows the result (side note: It’s a big table; don’t forget to scroll to the right!) of the updated mapping analysis of traditional RE artifacts and agile RE practices.

Information that appears explicitly in both TORE artifacts and corresponding agile RE templates is shown using ++. Information that is specified explicitly in TORE artifacts, but only implicitly (i.e. on a higher level) in agile RE templates is denoted using +.

The two authors have managed to map all TORE artifacts to agile RE practices, except for “Business data & rules” and “Interaction data & rules”. For most RE-related agile practices, the level of detail is limited compared to their corresponding TORE artifacts. For instance:

• Stakeholders are identified in the typical As a <type of user> I want to <perform some task> so that I can <achieve some goal> templates, but no further information is provided about them;

• User story templates make no mention of interaction, exceptional, and alternative flows;

• Quality requirements and descriptions of technical constraints do not appear explicitly in user story templates, although they might be mentioned as acceptance criteria.

While it’s possible that some of this information will be conveyed verbally, the authors’ literature reviews show that minimal documentation and ignorance of non-functional requirements often pose challenges to software projects (side note: These challenges were listed in the first table.).

The interviewees believe that user stories are the most important RE artifacts in agile projects. Much information is documented very succinctly or not at all, and is only discussed in face-to-face meetings.

However, it turns out that information about interactions actually is “documented”, but using clickable user interface mockups instead of traditional documents.

While the interviewees mention that communication of requirements generally works well in the project, the RE artifacts lack detail and the products show inconsistencies because UI-related information and decisions were not explicitly documented.

Usefulness of agile RE practices

The authors conducted two surveys about (the usefulness of) agile RE practices; one with students and one with practitioners.

The first survey shows that not all agile RE practices are equally useful:

• User stories and usage scenarios are primarily useful for architectural decisions.

• All practices are useful for interactions and visual UI design. For usability engineers, usage scenarios are the most important artifacts.

• None of the artifacts is very important for the creation of system test cases, although usage scenarios tend to be more useful than other artifacts.

According to the practitioners, the planning meeting and product backlog are the most important agile RE practices, followed by face-to-face communication, requirements prioritisation, sprint backlog, and user stories. Different roles tend to produce slightly different rankings, but the differences are too subtle to be really meaningful.

The six challenges that were faced most often by practitioners are:

1. Insufficient communication with customer(s) due to lack of documentation
2. Lack and rework due to neglecting of non-functional requirements
3. Lack and rework due to insufficient quality of documented requirements
4. Communication lapse due to unavailability of appropriate customer representative(s)

5. Insufficient requirements communication in teams due to lack of documentation and

6. Communication lapse due to sudden changes in the requirements

The authors proposed two solutions.

Solution 1: extended user story template

User stories are important artifacts in agile RE, but lack details about interactions, which are important for usability experts and testers.

The first solution therefore adds three extra items to the default user story template (As a <type of user> I want to <perform some task> so that I can <achieve some goal>): interactions, quality requirements, and technical constraints. A few simple notes or bullet points should be enough.

About 70% of the surveyed practitioners rated this solution as somewhat or very useful, as it makes sure that (especially inexperienced) people document all important information in a way that’s easy to read. None felt that this solution would not be useful.

Solution 2: RE checklist

Alternatively, knowledge about important information could be incorporated into a checklist that is used during face-to-face meetings, like backlog groomings, to ensure that interactions, quality requirements, and technical constraints are at least communicated verbally.

About half of the surveyed practitioners was enthusiastic to some degree about this solution. Again, no one felt that this solution would not be useful.