Long ago I worked for a software company which developed material and workflow analysis software for large cleaning and maintenance companies. One of their customers was a company responsible for cleaning and re-supplying aircraft between the flights at some busy airports. They needed software to enable supervisors to browse the task lists in real time, allowing operators to enter job assignments and track work progress.
When I got to the work, the client was already using the software created by the company I worked for. I took the initiative to talk with our client’s staff and raised their interest in further software development. We sketched out various functionalities the software might be developed to have in the future. Their interest towards the development matured and we agreed on a development project.
We decided to follow the Requirements Engineering software development model with this project. Requirements Engineering or RE involves examining which features and qualities are required of the software. Business-based requirements gathered from the client are combined with requirements gathered from the future users of the software in their own work environment.
Details of the requirements are written down at the time of collection. These include possible justifications for the requirements, observations, time and place, and from where or whom the requirement originated from. The requirements list is then edited until it’s non-contradictory and the suggested features are feasible to implement.
A negotiation is then held between the client to agree on the complete content of the requirements document. The document is extended if required, contradictions in the requirements are further reduced and edited for realism until the requirements document describes a feasible, cost-effective, sufficiently detailed plan to develop software that meets the client’s business needs.
In order to collect the requirements, our group of programmers agreed to visit the client company’s second airport, for which the company had planned to install a better version of our software. We used the opportunity to interview the maintenance operators, managers, and other staff. We examined their way of interacting with different systems and asked questions. Our group was able to present a long list of possible features based on our observations and the interviews.
We then had talks with the client to ensure that the suggestions and observations we collected could be used to create a project plan for the use of the programmers. After the plan was approved we used it to create the software specifications for the use of us programmers, describing all the technical details we needed in the style and language suitable for technical experts.
Using the software specifications document as our guide to code, we implemented exactly the required features in the software in the manner we had agreed of. Fulfilling the conditions of the specification document meant having fulfilled the conditions described in the requirements document, too. That, in turn, meant having fulfilled the business needs for which the software was developed for.
Effective communication with the client
The skills of talking and listening proved important in finding out what the client needed. A lot of good questions had to be asked, and that, in turn, relied on careful background work in one part, and improvisation on the other part. We had to involve ourselves in the customer’s wants and needs and think of what they required.
We had no standard solution for sale so we had no motivation to try to sell them anything like that. We made ourselves open to their perspective. We made use of our meetings to find out their current situation and what they preferred so as to plan a project which would satisfy all parties involved.
When the customer became more interested and engaged, we had to have a discussion about the project. The client was interested in improving their workflow management system. Some concrete suggestions were made such as real-time access to the detailed work lists with a mobile device, including user-friendly editing. Task lists or parts of them could be easily marked as scheduled, assigned, completed or requiring further action. The maintenance supervisors no longer needed to bring their reports back to the operations center on paper.
Our team was able to make clear, feasible suggestions with apparent business benefits. We took the initiative in making some of the new proposals, and the customer took initiative in others. We never could have figured out some of the suggested improvements by ourselves, so our uncomplicated and straightforward conversational style with the client turned out to be very valuable.
The mutual exchange of information might not immediately produce concrete, actionable solutions to the problems. To promote conversation, it is better to find people for whom talking and listening come naturally. Genuine positive attitudes towards others and the desire for mutually beneficial outcomes are particularly important. The Requirements Engineer is also required to have competence in some software processes to be able to assess what kinds of outcomes are reachable.
The bulk of the requirements are collected only after the client has approved of the collection project. When collecting the requirements, the Requirements Engineer and the team must be able to positively encourage the people to talk. The requirements gathering then becomes requirements eliciting rather than just collecting something which already exists.
New requirements are invented by eliciting people’s desire to talk and share and otherwise participate in the collection. Various eliciting techniques are available, including workshops and the use of prototypes. User participation is greatly helped by having the management approve some use of time for the collection and making it known. It also helps the users to know what a concrete and positive influence they have on the system being developed and their future work using the system.
Some of the wishes may be mutually contradictory and can not be implemented, so it is better not to elicit high expectations in the people involved. Managing the expectations becomes critical. A requirements collection meeting is the wrong time and place for sales, advertising, and unfounded promises.
Good requirement collection resembles ethnography, the study of people in their own environment with the goal to understand their environment’s social and practical structure and processes. The study just needs to be sped up quite a lot, for example with appropriate questions.
Eventually, the progress of the development project becomes apparent to all participants. It’s better for people not to overcommit on proposals and suggestions which have not been approved as part of the requirements or the software specifications.
Not all who take part in the requirements planning need to be natural conversationalists. A requirement planning expert with a less conversational role can focus on recording the suggestions, requirements and other observations and findings. They may also design some engaging activity and carry it out. People who have no role in the requirements elicitation may be present but they should not participate. The requirements experts who were present in the collection events will then proofread and fact-check the memos together.
Roles and expectations for the participants
Practical implementation of the requirement engineering process requires the process to be followed humanely. The experts taking the role of the requirements engineer also take responsibility for the process, they are given the power and resources and they will not the shift their responsibilities to others. The process is adjusted to enable the employees and other stakeholders to participate within their own field of expertise. The information gathered in this manner becomes the source material for the requirements document.
The client, being the project’s financier, is expected to seek outcomes which make sense to them from a business perspective. Knowing the business environment and the features and qualities of the systems and tools they work with they are in the unique position to express wishes which may be positively answered by means of software development. They may also need to expand or narrow down their options according to the facts found during the software development process and factors specific to their business.
Future users of the software are interviewed and observed for the collection of the requirements lists. It might help to inform the users of some of the design goals prior to the interviews. The users may have a lot of input on topics such as improved software usability or increased functionality if they have had an opportunity to prepare for the interviews.
In requirement engineering, approval is sought for the suggested software requirements from multiple parties. The client is enabled to ensure the economic sense of the project in their own way. The new software is ensured of receiving wide acceptance among its users by having the software tailored according to their real needs in the first place. The engineering team only approves of complete requirements documents which describe a feasible plan for the development project.
Requirements engineering is certainly one of the best methods to ensure that the users will accept the software, use it for it’s intended purpose and that the software meets the customer’s business needs.
LINKS
- Wikipedia, Requirements Engineering (eng), accessed 7.8.2018