With every software development, business knowledge and business processes are recorded in the source code. However, in business departments, business knowledge and methodical expertise for business analysis are handled recklessly. The knowledge is thus permitted to migrate to the IT department where it remains.
It is particularly the case in larger firms whose original core business is not IT that software is not seen as a core competence set in the source code and business support for software development is not considered a critical contribution to project and business success.
Requirements engineers as interface between specialist departments and IT
For good software, knowledge of business departments must be integrated into the development process. This knowledge transfer sometimes works so well that those working in the IT department know more about the subject matter than those in the business department itself.
Requirements engineers function as a connection between the specialist and IT departments. Requirements engineers analyze IST processes – organizational and technical ones. They support the conception of software with their methods and, in the best case, with their technical and business knowledge.
When developing software, the department-spanning general context has to be considered. For this, the requirement engineer collects information, confirms the organizational and technical interfaces between the departments and collects necessary information for software development, which forms the basis of the technical documentation.
In the implementation phase, they take over technical management of the development teams and clarify the details with the customer. Their activities are, amongst others
- Moderation and facilitation of groups
- Documentation of processes and business rules
- Making technical knowledge and processes clear to colleagues in IT
- Conveying IT options to specialist departments
- Internal control of IT projects
Knowledge from specialist departments roams over to IT
Business departments are happy that the requirements engineers from the IT department are taking care of those tasks. The requirements engineering work, in which they usually lack routine, decreases. They overlook the following consequences:
- Business knowledge of dependencies in the overall process move to the IT department and are documented there.
- Responsibility for business knowledge automatically shifts to the IT department.
- Access to knowledge is not so easy any more.
- Loss or lack of structure of RE methodical knowledge strengthens the development of points 1 to 3.
Business expertise is now documented in collaboration tools, wikis, ALMs in the IT department or in the source code. Either way with limited access for the specialist department. Access to these tools is normally limited with rights concepts through the IT sector. Fewer people have access to the source code or they can neither read nor understand it. Additionally, colleagues from the business department do not often understand IT or business analyst language. There is the hurdle of reading the requirements engineers’ documents. Component diagrams, use case diagrams, BPMN processes with different, needs-based views, test cases and all the other useful helpers in software development will not be understood, cannot be put in the right perspective and used.
With the transfer of knowledge to the IT department and insufficient RE methodical expertise on the one hand, and the build up of knowledge on the other, it is increasingly difficult for the business department to familiarize itself with the themes and documents of the IT project and contribute their part to the success of the project and therefore of the business. The IT department, in comparison, work more and more independently on projects and only provide the specialist departments with information in exceptional cases or FYI.
This is because IT or the requirements engineers already have the knowledge and also because the specialist department can no longer be considered a competent partner at eye level. However, it is easy to overlook the detail of knowledge required for good software. This includes knowledge of current developments with customers, details of processes and their influence on the user experience (UX), etc.
Because software development is not a one-man show of individual people or teams, but rather thrives on good collaboration between people with different abilities, the above-described situation for software quality is probably not beneficial for software quality.
How might better collaboration between technical departments and IT look?
A solution for collaboration should be found. Customers, departments and IT sectors should work together as partners. With more methodical expertise for IT projects on the specialist side and more openness when using and accessing the technical documentation on the side of the IT department. Possible solutions can be diverse and individual.
Maybe it is already helpful to open access to IT department tools to business departments, if the department shows readiness to involve themselves in the methods and ways of specialist IT documentation.
The necessary knowledge can also be given to the departments so that they get a better understanding of the software development process. Then again, this is not solved for everyone with a “How to read use cases in 2h” event or an IREB course. It is about getting a feeling for the correct methods, at the right time as well as an understanding that software development requires an ongoing exchange. The development process is never straight, hence the additional loops, feedback rounds and conceptual corrections are part of the process. Even this requires practice and practical application.
Thirdly, maybe requirements engineers should be placed closer to the specialist department. By this, knowledge and responsibility for the professional standards might stay with the business department and the IT department could have a contact person on the technical side.
However, transparency and openness of information, and ongoing collaboration, remain a prerequisite prerequisite for the success of IT projects.
Find out more about René Busch at (link in German) http://www.requireminds.de