The client: work with him and not for him. Communicate Requirements in Software Projects.

In this article, an analysis will be made of the communication of requirements between a client entity and the team, and in the team there may be someone directly responsible for collecting the client’s needs, commonly called Business Analyst (BA), or Engineer of Requirements (ER). Three possible ways of communicating the requirements are mentioned:

  • The communication of the needs by the Client to the BA / ER;
  • The communication of the requirements collected by the BA / ER to the Client for validation;
  • Communication of the requirements collected by the BA / ER to the development team.

Criteria for success / failure

Once a project has been completed, lessons learned sessions will be held. Has the project been successful or unsuccessful? For the organization, the definition of success / failure can be based on the criteria:

  • Product / prototype / service with quality;
  • Customer was satisfied;
  • Customer returns;
  • Product / prototype / reliable service;
  • Profit;
  • Organization / top management was satisfied;
  • Good reputation for the organization.

More than realizing whether the project was successful or unsuccessful, it is also important to understand the circumstances that led to this success / failure. To this end, the annual report CHAOS Report of the Standish Group [1] is a reference that defines the success factors of a project. From the point of view of requirements analysis, the factor at the top of this report is customer involvement. This relates mainly to communication, having the client “close” to the development team and involving him in the whole process. Involvement is related to the success of the project in that, if the client is aware of the project, he knows exactly the outcome that will be delivered to him and can communicate in a timely manner any changes he may wish to make.

The client must have space to listen and to be heard, he should be treated as a partner (working with him and not for him).


“Involvement” is high on the CHAOS Report list because of the expectations management during the project. Managing customer expectations is to ensure that the assumptions made by the client in a software project are realistic and consistent with software delivery. Since the requirements process is a primary channel between the client and the team, can there be a relationship between expectations management and the way the requirements are communicated? And how do you define requirements communication to enhance project success?


“A problem well stated is a problem half solved.”

Charles F. Kettering


A requirement depicts a condition or ability that is necessary to satisfy a purpose or need. The communication of needs, through the definition of requirements, is of high importance for developing the solution that the team has proposed. The requirements are transversal to any engineering project, be it software, electronic, mechanical, civil, etc. projects. Each engineering project must include requirements tasks, whether related to survey, documentation, negotiation, validation, communication, among others [2]. Communication (verbal or written, formal or informal) is the medium for passing information between the client and the development team. One of the most critical requirements problems is that it depends heavily on the interpretation of who raises or documents them. The research on problems in requirements refers us to the following illustration:


Fonte img: projectcartoon

  1. As the client explained
  2. As the analyst specified
  3. As the programmer developed
  4. As the client really wanted!

“The most important single aspect of software development is to be clear about what you are trying to build.”
Bjarne Stroustrup


 The communication of needs by the Client to the BA/ER

The Business Analysis Body of Knowledge (BABoK) [3], from IIBA®, a reference guide for requirements, categorizes requirements in:

  • Business (Business Requirements);
  • Stakeholders (Stakeholders Requirements;
  •  Solution (Solution Requirements).

BABoK, as well as the Guide to the Software Engineering Body of Knowledge  (SWEBoK), present the following requirements-gathering techniques:

  • Brainstorming
  • Documentary analysis
  • Focus Groups
  • Interface Analysis
  • Interviews
  • Observation
  • Prototyping
  • Requirements workshops
  • Questionnaires

All of these techniques have advantages and disadvantages, and are more suitable in certain circumstances than others (they will not be described here, given the number of techniques, so BABoK describes these situations in detail for each technique in its “Techniques” chapter) , so the process of (communication of) the requirements to be adopted depends on the specificity of each project. It should be taken into account who participates, how many participate, the processes to be supported, among others. For example, an interview is advantageous in the sense of direct contact, allowing for more personal responses, as well as the observation of gestures or tone of voice. On the other hand, if the number of participants is high, then the most advantageous option is to conduct questionnaires. If the idea focuses heavily on flows and sequential tasks, process observation is most appropriate.

The communication of the requirements collected by the BA/ER to the Client for validation

The next step in the BA / ER task is to record what was raised in the previous customer-> BA / RE interaction. This record is given the name of documentation of the requirements, and refers to a set of documentary information that will serve as evidence in the “contract” concluded between client and team. Documentation of requirements serves two purposes. 1. Validation of requirements with the client; 2. Pass the information to the development team for the implementation of the solution (the last two “ways” mentioned at the beginning of this article). This latter purpose, not constituting a client-team communication, is not analyzed in depth in this article.

Documentation of more customer-oriented requirements follows more high-level formats and no more technical information. The most significant examples are: UML diagrams (use cases and activities), user stories, prototyping (via wireframes or mockups).

It is on the set of documented requirements that the second possible “way” reported in this article, the BA / RE -> customer communication is based. In this case, the communication is not associated to the survey of requirements and needs, but to validate the information that was collected in the previous interactions. This type of communication is of great relevance in the aforementioned client involvement, since the form (as well as the frequency) as this interaction is carried out has direct implications in the management of customer expectations. Here, BABoK and SWEBoK also propose identical techniques for the validation of requirements, and, unlike the previous interaction, the BA / ER can use complementarily:

  • Requirements revision (Structured Walkthrough)
  • Prototyping
  • Performance indicators
  • Risk analysis

It should be noted that there are no great advantages in communicating too technical requirements to the customer, since this “language” is not always perceivable by the customer. The more technical documentation should be directed to the development team, where the communication of the requirements is done in a perspective of “passing of knowledge” acquired in previous interactions (client-> BA / RE-> client). The most significant examples are: UML diagrams (classes, components, deployment, sequence), user stories when accompanied by technical details and acceptance tests, technical user stories (e.g., stories that directly derive from implementation issues or architecture of the solution and not of functionalities).

It is important to know…

The maturity of the processes adopted within the scope of requirements (or any other) is always reflected in the organizational efficiency of these processes in a project. Regarding the criteria presented at the beginning of this article, the way the processes are executed has direct implications on product / prototype / service presentation with quality and reliability, top organization / management satisfaction and profit. However, the specificities of each project do not suggest the implementation of a single process (“one size fits all”), but rather take into account a set of criteria to “model” the requirements process according to the context in which it operates.

On the other hand, the requirements process must include interactions with clients, through verbal or written communication, formal or informal. Good communication with the client can not be seen only from a “good practice” perspective. It should be an integral part of the organizational vision, with a view to the efficiency of the requirements process, since the management of expectations has implications, not only in the success of the project, in relation to customer satisfaction and loyalty, but also in the reputation and notoriety of the organization.


[1]         Standish Group, “CHAOS Report 2014,” 2014.

[2]         J. M. Fernandes and R. J. Machado, Requirements in Engineering Projects. Springer International Publishing, 2016.

[3]         IIBA, A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0. 2009.



Nuno Santos | Researcher D.I.A EPMQ “Engineering Process Maturity and Quality” @CCG

  • Researcher and Analyst at CCG: Center for Computer Graphics at D.I.A EPMQ and SEMAG Group, Nuno Santos holds a degree in Information Technologies and Systems. Currently attends the PhD TSI (PDTSI) at the University of Minho, with the thesis “Adoption of Logical Architectures in Agile Methods”. “Certification of Competency in Business Analysis – CCBA®” is also in the process of being certified. His research interests focus on business process management, business modeling, requirements analysis, and software architectures.