Feature request

Feature request

Version: 2024-01-25

At anDREa, we greatly value your input on enhancing our platform and identifying features that can elevate your experience. In the following, we'll walk you through the process of managing and responding to feature requests. Your suggestions are integral to our commitment to continuous improvement, and we appreciate your engagement in shaping the evolution of the myDRE platform.

We use an agile development methodology, which breaks the work into small increments and short time-frames (sprints).



Below, we'll go over the steps of how we develop things and handle requests for new features.

1. Submission of the request

This is the starting point of the Feature Request:
  1. Please describe your wish or request in a ticket on support.mydre.org and discuss this with your local Research Support team member
  2. Explain how the requested feature would benefit you or your organisation
  3. Clearly articulate the problem or limitation you are having with the current myDRE portal
  4. Explain how the absence of the requested feature impacts your workflow or user experience
  5. If applicable provide specific examples or scenarios where new feature would be beneficial
  6. Indicate whether you believe other users / workspaces/ organisations would also benefit from this feature
  7. If applicable convey the urgency of the feature request and explain any time-sensitive factors that make this implementation crucial
  8. If the feature involves integration with other tools or systems, provide details about the integration requirements
  9. If you have technical expertise, include any technical specifications or requirements for the feature
  10. Attach relevant documents, screenshots, or mockups that illustrate your request
  11. Express your willingness to participate in testing the feature before its official release
By including these details in your feature request, you provide anDREa with a comprehensive understanding of your needs and help us make informed decisions about prioritisation and implementation

2. Evaluation

Each Feature Request is then evaluated by the following steps:

a) Collection and categorization

All incoming feature requests are collected and categorized based on common themes or functionalities in the Innovation Lab department accessible for all Support Team members. The requests may be tagged with relevant information such as the urgency, impact, and the number of users requesting the feature.

b) Prioritization

Incoming requests may be prioritized by all organisations before anDREa will internally evaluate the requests. We include the following factors in prioritization:
  1. Impact op Activation - new clients, new user (groups / types)
  2. Impact op Retention - existing clients and users
  3. Impact op Referral
  4. Dependencies
  5. anDREa's development capacity
If requested features are in line but cannot be delivered due to anDREa having insufficient capacity to deliver these features earlier, anDREa is open to discuss what is possible with temporarily hiring extra development capacity.

c) Communication

The status of the requested feature is kept up-to-date in the tickets submitted in the ticketing system. These are accessible to all Support team members in the Innovation lab department on support.mydre.org. Features that have been placed on anDREa roadmap are regularly discussed during biweekly Support team meetings. If required, anDREa support will request to be in contact directly with the users requesting the feature in order to understand their requirements better and include them in beta testing.

3. Added to Backlog

Once prioritized and discussed internally, features will be denied (=not placed on the road-map) or will be added to anDREa's development backlog and placed on the road-map.

4. Development

 The development team will start working on the technical implementation of the requested feature once requirements are clear. 

Please note that we do not make firm commitments to specific timelines for the release of new features. The development of features involves a thorough and iterative process to ensure their functionality, security, and seamless integration into our product.

5. Testing

Testing is conducted in the testing, acceptance and production environment to ensure that the new feature is working as expected and does not introduce bugs. Users and Support team members may be asked to participate in testing.

6. Release

Finally, if the feature passes the testing phase, it is deployed to production for users to use.

Feature release is communicated in biweekly Support team meetings. The feature is released to the production environment and available to all users. If applicable, documentation around the new feature is published in Knowledge Base on support.mydre.org. The status of the Feature Request is updated in the support ticket found in the Innovation Labs department and in the road-map overview. 

More information

  1. Roadmap - anDREa's future development plan
  2. anDREa Service Level Agreement
  3. anDREa standard services
  4. anDREa optional services
  5. Outside SLA features
  6. Software lifecycle

    • Related Articles

    • anDREa feature development plan

      Roadmap Version: 2022-09-02 Update: 2024-02-23 anDREa is committed to transparency and the best interest of the research ecosystem. We are and will always be developing by, for, and with stakeholders in the research ecosystem. The following ...

    • Outside SLA Request

      First version: 2021-05-21 Last updated: 2024-01-25 Introduction The purpose of this document is to outline the process for requesting outside-SLA features to be used in or in conjunction with a Workspace. Typical examples are: Common Share Serverless ...

    • Features and Improvements - planned and actual release

      Version: 2023-10-15 *The table is auto update and reflects the latest anDREa is committed to transparency and the best interest of the research ecosystem. We are and will always be developing by, for, and with stakeholders in the research ecosystem. ...

    • A.8.32 Change management

      Version: 3.0 Valid until: 2025-04-12 Classification: Low Version Management Version Author(s) Change(s) Date approved 1.0 Stefan van Aalst Edward Robinson Sarang Kulkarni Johanna Hakonen Initiation document 2022-07-07 1.1 Edward Robinson ...

    • A.16.1.5 Response to information security incidents

      Version: 3.0 Valid until: 2025-04-10 Classification: Low Version Management Version Author(s) Change(s) Date approved 1.0 Stefan van Aalst Edward Robinson Sarang Kulkarni Initiation document 2022-07-13 1.1 Edward Robinson Additions/changes as part of ...