Requirements

A vital part of the distributed software development is gathering and handling requirements. Thus how new requirements of DHIS2 are handled in HISP has been looked at.

‘You can’t sit by yourself and assume what users need; you have to be there, with users, participatory design.’

— HISP project coordinator

When you make generic software, you can’t sit in a laboratory and assume what people need. HISP has experienced that the only way to make things work is to spend time in the countries together with the users. That is how they made DHIS2 work. You have to go to a country and solve a concrete problem and constantly keep in mind that this should be possible for others to use. A lot of systems deliver exactly what you want and aren’t editable. Instead, DHIS2 is a skeleton or a toolbox that supports data gathering, processing, calculations and visualization.

New requirements usually occur by themselves when developers, implementers and users work with the software. There is no active process of looking explicitly for requirements as they occur either way. When you spend a longer period of time in a country, you get a lot of ideas and suggestions for improvements.

A strategy used when developing new features from the requirements into DHIS is to release often. HISP rather release often with something half-done and get users to test it and give them feedback on the feature and continue to work on it. Releasing every quarter is a good strategy, because if something goes wrong, three months aren’t too long to wait for the feature to be fixed.

Users often want DHIS2 to function the same way their former bespoke software did, but that is not always possible.

‘For example they say: We want this feature, can you do that? Yes, we can do it, but it is going to cost time, and time equals money.’

— Implementer A

Because of the way things are done in HISP, you don’t always get exactly what you want. It is important to make sure the users understand that.

‘That’s the way it works: You get a lot for free, but if you want something specific, you either have to do it yourself or pay.’

— Implementer A

One approach is to convince the users that they don’t need what they think they need, that what they need actually already exist in DHIS2, and then it is more about making their requirements fit to the existing DHIS2. Other times users’ requirements don’t fit the existing data model in DHIS2, then the approach becomes lowering their expectations and trying to give them something similar instead.

Users don’t always understand what a requirement is or how to phrase it in a way that will make sense for developers. Therefore a big part of being an implementer is to translate and filter users’ requirements to something meaningful for the developers, but also to make sure that users understand that things they believe is easy to get, can be really complex to achieve.

The requirements are usually shared with the developers through mail, or by making a blueprint2, sometimes they get implemented, sometimes they don’t, it all depends on the developers and it is important to be aware of the fact that HISP is not like a corporate organization, where you tell what you need, and then it gets implemented.

‘From my experience, sometimes from distance it’s difficult or they do not prioritize, because with the DHIS there are so many messages.’

— Implementer B

Mediating requirements on mail isn’t always effective and it happens that implementers don’t get answers from developers. Having face-to-face meetings with the project coordinator and the developers has proved to be a more effective approach of getting the requirements implemented.

A user’s requirement isn’t always prioritized. Developers have to decide on what requirements are prioritized. If the requirement is not critical enough, it is likely to be less prioritized. When releasing every quarter, the developers can’t be sure that every country gets what it wants. The developers try to use the network for what it is worth to be in sync with what the countries want; it is important that DHIS2 maintains its relevance. But there will always be some that are disappointed, because some requirements are prioritized over others. Developers have their own plans for the builds and can’t take in all requirements.

‘We can’t bring each and every little thing into the global, we have to make sure that it is in the interest of the global community.’

— Core developer

When a requirement is received, it is analyzed and discussed by the developers. Then decisions are made on whether the requirement should be implemented or not. If the decision is to implement the requirement the approach is to take one step back from the requirement.

‘If the users say this is my requirements, I want you to do stuff like this, we just go half way and when that halfway is completed we try to make sure that the users can go the last steps themselves.’

— Core developer

By doing that, the developers can assure that the feature becomes generic and can be used in other cases with similar requirements.

2_{A blueprint is a specification of a requirement. It describes the feature and tracks its} implementation status and who’s involved.

‘In the back of your head you do this thinking and crosschecking, but otherwise we don’t. We don’t even have a requirement document.’

— Core developer

A thing worth mentioning is that there is no structured way of looking at earlier requirements to see how they are affected by the implementation of new requirements other than what developers can remember themselves.

An issue is when larger organizations fund a lot of the development. Then they will have more influence on the requirements and it can almost look like they have taken over the whole development department. As DHIS grows, more organizations will come and pay and balancing between what requirements to prioritize will be difficult.