Base4NFDI-Toolkit for Requirements Analysis Strategy

Base4NFDI–Toolkit for Requirements Analysis Strategy Version 1.0, 2025 Authors: Jana Plomin, Susanna Kuper This toolkit provides a structured framework for conducting requirements analysis within Base4NFDI. It assists service managers and working groups in identifying user needs, evaluating existing services, and documenting findings in a transparent and systematic manner. By integrating established methods and relevant supporting materials, it facilitates the formulation of clear, actionable requirements. Its purpose is to ensure a coherent transition from requirements analysis to subsequent development and implementation phases. 1 Table of Contents 1. Introduction ....................................................................................................................... 2 2. Planning Requirements Analysis ........................................................................................ 3 3. Strategic Relevance of Requirements Analysis .................................................................. 6 4. Requirements Analysis in the context of Base4NFDI .......................................................... 7 5. Methods .............................................................................................................................. 9 5.1 Focus Group ....................................................................................................................10 5.2 Survey .............................................................................................................................12 5.3 Qualitative Interview ........................................................................................................14 5.4 Observation .....................................................................................................................15 5.5 User Stories .....................................................................................................................17 5.6 Personas .........................................................................................................................19 6. About this Guide and Further Resources ...........................................................................21 2 1. Introduction The requirements analysis is a systematic process for collecting and evaluating information about the needs, expectations, and requirements of a specific target group or market segments. It helps assess the current state of products or services and understand what gaps exist as well as what opportunities for improvement or development of new solutions are available. This toolkit is intended for service managers and working groups within the NFDI who are responsible for planning and implementing requirements analyses. It is particularly useful if you need a structured yet practical approach to identify user needs, prioritise development tasks, and ensure that services are aligned with actual community demands. The identification of requirements is a comprehensive process that requires a targeted inclusion of various types of information. There are numerous methods that can be utilized to gather relevant information for the requirements analysis phase. For more information, refer to the Methods chapter. Conducting a thorough requirements analysis is a critical step in the successful planning and execution of projects. It lays the foundation for informed decision-making and ensures that business and user needs are clearly understood from the outset. The following key benefits highlight how requirements analysis contributes to improved project outcomes, organizational efficiency, and long-term adaptability in dynamic research landscapes: ● Clear Understanding of User Needs: Requirements analysis identifies precise user expectations, ensuring that solutions are aligned with actual demand rather than assumptions. ● Strategic Planning: By translating user needs into actionable insights, the analysis supports targeted planning and implementation, increasing the likelihood of project success. ● Efficiency Gains: Insights from requirements analysis help streamline workflows, reduce redundancies, and enable more effective resource allocation. ● Informed Prioritization: The process provides a structured basis for prioritizing development efforts and innovation, focusing attention on high-impact areas. ● Adaptability to Market Changes: In fast-moving environments, requirements analysis ensures organizations can respond quickly and effectively to shifts in user behavior and market conditions. In fast-moving environments, requirements analysis provides the flexibility to adjust services when user expectations, technologies, or funding conditions evolve. By revisiting and updating requirements regularly, organizations can respond quickly and avoid misaligned developments. The objective of this document is to present a comprehensive concept—a curated collection of methods and best practices—designed to ensure the efficient execution of requirements analysis. 3 It aims to provide service managers with the necessary insights and practical guidelines to thoroughly understand the subject of requirements analysis and tailor the analysis processes specifically to their services. Furthermore, it aims to provide an overview of how requirements analysis is addressed within Base4NFDI. Considering the limited timeframe of three months for conducting the requirements analysis, it is neither expected nor necessary to implement every single step described in this document. Instead, service managers are encouraged to focus on those elements that are most relevant for their specific service. In doing so, it is considered good practice to consult Base4NFDI for support and guidance throughout the process. This document is practice-oriented and offers actionable information as well as supporting materials, such as checklists, to facilitate the planning and execution of the requirements analysis. Through this resource, readers are empowered to identify requirements and ultimately achieve a smoother transition from requirements analysis to the development of products or services. 2. Planning Requirements Analysis Planning a requirements analysis is a critical step to ensure that a service or product truly meets the needs of its intended user groups. This process should be carefully structured, welldocumented, and supported by appropriate methodologies that capture the diversity and complexity of the target community. First, it is essential to clearly identify the relevant user groups. These may include end-users, such as researchers, data managers, or technical personnel. Understanding who the stakeholders are and analyzing their demographic, psychographic, and behavioural characteristics provides a solid foundation for the entire requirements analysis. If you want to define user groups and their needs more clearly, consider applying the Persona methodology, as outlined in the Base4NFDI - Persona Creation Kit and in the Methods chapter. When planning the analysis, it is also important to take into account requirements for digital accessibility from the very beginning. Early consideration helps ensure that services are inclusive and usable for all target groups. The Base4NFDI – Guidelines on Application of Web Accessibility provide a structured and supportive reference to help teams incorporate accessibility throughout the lifecycle of basic services, from planning and design to development, testing, and maintenance. Requirements analysis encompasses various techniques and methodologies used to gather and validate requirements for functionality, performance, and usability. These methods may include user interviews, focus groups, surveys, workshops, user stories, personas as well as analysis of existing documentation and market research. By leveraging these diverse approaches, organizations can gain a holistic understanding of what users expect and need from a product or service. Whenever possible, existing surveys or workshop results should be reviewed and integrated to build on prior knowledge and avoid duplication of effort. 4 To determine the appropriate methods for analyzing the requirements, it is essential to consider the available resources and expertise, as well as the known parameters and existing sources of information and data. Further guidance is provided in the Methods chapter. The following table provides a structured set of guiding questions to support the selection of suitable methods for data collection during the requirements analysis phase. Checklist Category Guiding Questions Define the Key Questions - Which core issues should be explored in the analysis? - Are reliable and recent data already available on some topics? - What additional information needs to be gathered? - Should the questions be analyzed from specific stakeholder viewpoints (e.g., domain experts, service providers, users)? - Is it relevant to contrast different perspectives? Clarify Framework Conditions - What time and budget constraints apply to the analysis? - Does the team have the necessary skills to carry out certain methods? - For which approaches might external support or additional training be necessary? - At what stage should data protection and legal aspects (e.g., GDPR compliance, consent, data storage) be considered to avoid delays or complications later in the process? Select Appropriate Methods - Which methods are most effective for gathering the required data? - Can a single method help answer several questions at once? - Are the available resources and conditions sufficient to apply the chosen methods effectively? Table 1: Checklist for Selecting Appropriate Methods in Requirements Analysis, adapted from: University of Freiburg: Bedarfsanalyse - Palliative Care Basics Documenting the entire process is essential. This includes not only the findings but also a transparent record of the methods used. Such documentation ensures that the analysis is reproducible, understandable to stakeholders, and serves as a reference for future iterations. Requirements should be documented in a way that makes them not only traceable, but also actionable and testable throughout the project lifecycle. A comprehensive requirements analysis typically consists of phases such as: ● Goal setting: Clarification of the questions that are to be answered with the requirements analysis. ● Identification of the target group: This involves determining who the users or stakeholders are and analyzing their characteristics and needs. ● Collection of information: Relevant data should be gathered on existing problems, user expectations, and potential areas for improvement. This may include surveys and/or interviews. 5 ● Documentation and evaluation of results: Findings should be summarized, for example in a clear report that highlights key insights and recommendations. Personas or scenarios can be used to illustrate specific user requirements. ● Validation of needs: The identified needs should be verified through feedback from the target group or by conducting further testing to ensure their accuracy and relevance. In each of these phases, different methods may be relevant depending on the project’s scope, resources, and context. A detailed overview linking each phase to its specific objectives, typical activities, and suitable methods can be found in the Methods chapter. In the information-gathering phase of requirements analysis, it is particularly important to gain a deep understanding of existing workflows, user practices, and underlying problems. Simply asking users about their wishes and translating these into requirements can be misleading, since users often know what they want but not necessarily what they truly need. Studying work practices and developing an understanding of the goals, challenges, and pain points that shape them makes it possible to distinguish between superficial desires and genuine needs. This understanding is crucial for prioritizing requirements, as not all requests can be implemented due to constraints such as time, budget, or technical feasibility. A solid knowledge of the work context makes it possible to evaluate which requirements deliver the greatest value, address the most pressing issues, or align most closely with strategic goals. In practice, the requirements analysis should also assess how current services address existing needs and where there are gaps that could be filled by the proposed basic service. It is vital to consider potential overlaps, inconsistencies, or dependencies between different services, as these can impact the feasibility and integration of a new service within the consortium’s overall architecture. This aspect is closely connected to service and software evaluation, for which further guidance is provided in the Service Evaluation Guide. Where possible, collaboration with relevant contacts in the consortia is encouraged to gather comprehensive information. This includes working with Section Liaison Officers, CoSpokespersons, or Service Stewards to access existing survey data and ensure alignment with ongoing initiatives. In summary, planning a requirements analysis demands a structured approach, methodological diversity, thorough documentation, and ongoing validation to ensure that the outcomes truly reflect the needs of the intended user communities. A well-prepared requirements analysis does not end with data collection and documentation. Its results form the basis for strategic decisions about how services are developed, tested, and maintained. The next step is to understand how development models influence the way requirements are handled throughout the project lifecycle. This strategic perspective ensures that requirements remain relevant, actionable, and aligned with the broader objectives of Base4NFDI. 6 3. Strategic Relevance of Requirements Analysis Requirements analysis is not only a methodological process but also a strategic one. The way requirements are identified, documented, and validated is strongly influenced by the selected development model and the overarching goals of the project. A well-defined strategy helps ensure that the analysis process is not only efficient and structured but also aligned with real user needs, technical feasibility, and long-term sustainability. One particularly valuable strategic approach is User-Centered Design (UCD). UCD provides a structured, iterative process that emphasizes early and continuous user involvement to ensure that requirements are grounded in real-world contexts. This approach is especially useful in environments with: ● High user diversity or complexity of interaction (e.g., research infrastructures) ● Initially vague or evolving requirements ● A need for high usability and acceptance, as in many Base4NFDI service contexts UCD typically involves methods such as: ● Contextual interviews and observations ● Persona development ● User journeys and user stories ● Iterative feedback through lowand high-fidelity prototypes ● Usability Testing By applying these techniques, project teams can transform qualitative user insights into actionable and testable requirements. This not only increases the relevance of the final service but also improves stakeholder alignment and reduces the risk of misaligned expectations. UCD also supports the selection of appropriate methods for the requirements analysis phase. For instance, if direct access to users is available, interviews and workshops may be prioritized. If time or access is limited, existing user data, persona templates, or indirect feedback mechanisms may be used instead. Requirements analysis remains a crucial element across all development models—not only within user-centered approaches. In more traditional, sequential models such as the Waterfall model, requirements are typically defined at the very beginning of the project and serve as a fixed foundation for all subsequent phases. Requirements are expected to remain stable, and any changes later in the process may be costly or disruptive. This structured approach is therefore suited for projects with wellunderstood goals and limited scope for change. In contrast, agile frameworks such as Scrum incorporate requirements analysis continuously throughout the project lifecycle. Requirements are revisited and refined in short, iterative cycles 7 (e.g., sprints), enabling teams to respond flexibly to new insights, shifting priorities, or evolving user needs. This flexibility enables more responsive and adaptive development, particularly in dynamic environments where stakeholder input and user feedback are essential. Instead of a one-time requirements phase, agile methods rely on a living backlog that evolves together with the product. Hybrid and incremental models, such as the Spiral Model or the V-Model, combine elements of both sequential and iterative approaches. These models typically begin with an initial set of high-level requirements, which are then revisited and validated in structured phases as the project progresses. Each cycle or increment provides an opportunity to test assumptions, assess risks, and refine the solution based on partial implementations or stakeholder feedback. This phased structure allows for greater adaptability than purely sequential models while maintaining a degree of control and predictability. Regardless of the model applied, the strategic planning and execution of requirements analysis ensures that services remain aligned with user needs, project goals, and real-world conditions. While development models shape how, when, and to what extent requirements are handled, their relevance and impact remain central to every successful project. In the context of the Base4NFDI project, a selection of objectives and activities related to requirements analysis are already predefined. The following section provides an overview of these predefined elements and outlines how the requirements analysis should be approached. 4. Requirements Analysis in the context of Base4NFDI The requirements analysis will be guided by a dual strategy that combines both bottom-up and top-down perspectives. This in-depth analysis ensures that insights from individual services as well as overarching strategic considerations are taken into account. It enables the identification of concrete needs at the operational level while aligning them with broader goals and shared challenges across consortia. a) Assessment of Existing Services and Community Expectations by the Individual Service (Bottom-up perspective) The requirements analysis is done from the bottom up, by having the services in the consortia present their needs for solutions to common issues to the NFDI sections and their working groups. This includes identifying what works well, what gaps remain, and which user needs may still be unmet. It is also important to clarify expectations: What do users and stakeholders expect from a basic service in this area? Do existing services require additional support for their users that could be addressed by a basic service? The analysis should also take into account any issues or gaps that have already been identified by the sections or working groups, to avoid duplication and ensure alignment. 8 Additionally, the results of the baseline survey can be utilized. This survey will be distributed during the initial phase among the consortia when they vote on new services. To access the survey results, please contact the respective service steward. b) Cross-Consortium Synthesis of Commonalities (Top-down perspective) In a second step, all services across the consortia that are related to the topic should be systematically brought together to explore potential commonalities, overlaps, and shared requirements. Particular attention should be given to architectural dependencies, inconsistencies, and blind spots, as these can pose risks to the successful implementation of a basic service. It is essential to evaluate whether the proposed basic service can integrate well within the existing technical and organizational architecture of the respective consortia. This reflection should consider compatibility, scalability, and the potential for long-term maintenance and interoperability. The TA1 team can actively support the requirements analysis e.g. by facilitating coordination, offering practical formats such as persona workshops, landscape analysis or community meetings, and assisting with the documentation process. Service Stewards contribute by engaging with consortia and their user communities, helping to gather input from relevant sections and working groups. In addition, Section Liaison Officers, Section Co-Spokespersons, and Service Stewards should be consulted about previous data collection efforts. If relevant, existing data should be reused or built upon. The following elements must be documented and submitted within three months after the official start of the analysis: ● Summary of requirements from the consortia regarding the proposed basic service ● Overview of expectations collected from the relevant NFDI section(s) and working group(s) o Indication of which requirements are addressed by the proposed solution o If applicable, description of methodology used (e.g. surveys, interviews, workshops) ● Clear definition of target groups and use cases o Description of specific benefits for each target group This draft is not intended to be a final, unchangeable product. Rather, it serves as an initial version that may be refined as the project progresses—if the chosen development approach requires it. Requirements are expected to evolve and may need to be revisited, for example during Piloting and Testing in the Initialisation phase or in later Base phases. The choice of development model (see Chapter Strategic Relevance of Requirements Analysis) will influence how often and in what way these updates take place. To promote transparency and facilitate further community engagement, it is recommended to openly publish collected data and results, for example via repositories such as Zenodo. 15 Tip ▪ In early project phases, it can be insightful to interview users with “extreme” positions, such as strong advocates or strong opponents of an existing legacy system. ▪ “W” questions (who, what, when, where, why) help encourage users to talk about their motivations and attitudes, from which certain decisions or behaviors can be inferred. Figure 3 – Summary of the Process Flow of a Qualitative Interview Qualitative Interview Checklist ☐ A standardized interview guide for conducting user interviews has been prepared. ☐ The interview questions are open-ended and neutral to elicit as much information as possible about users’ motivations, backgrounds, and attitudes. ☐ The interview results have been documented, at minimum in the form of notes. 5.4 Observation Observation Short Description Observation is a research technique in which the requirements analyst directly studies users as they perform their tasks in real-world settings. By watching how work is actually carried out, the analyst can uncover details and challenges that might not be captured through interviews or surveys. 16 Purpose in Requirements Analysis Observation reveals actual user behavior, workflows, and pain points that users may not be able to articulate in interviews or surveys. It is especially useful for identifying hidden or unspoken requirements. When to Use ● When validating assumptions about user workflows. ● For understanding context of use and environmental factors. ● To identify usability problems. Minimum Typical Optimum Participants: Number 1–2 users per observed role or process 3–5 users per observed role or process to capture variation Participants: Type Representative end users of the process A mix of end users, key stakeholders, and occasional “extreme” users (those with unusual workflows, heavy use, or unique challenges) Responsibility for Implementation One trained observer with skills in note-taking and analytical documentation Observer plus a secondary notetaker; optional subject matter expert to clarify observed tasks in real time Tip ▪ Observation is most effective when combined with follow-up questions or interviews (Contextual Inquiry) to clarify ambiguous actions or decisions. ▪ Prepare an observation guide to ensure key aspects are consistently recorded. ▪ Use diagrams, workflow sketches, or photographs (with permission) to document complex tasks. ▪ Minimize interference—observe naturally occurring work rather than staged demonstrations. 17 Figure 4 – Summary of the Process Flow of an Observation Study Observation Checklist ☐ An observation guide with key focus areas and points of interest has been prepared. ☐ Appropriate tools for documenting observations (e.g., notebook, audio recorder, camera, workflow diagram templates) are ready and tested. ☐ Participants have been informed about the purpose and scope of the observation, including confidentiality and data usage. 5.5 User Stories User Stories Short Description A user story is a short, simple description of a feature or functionality from the perspective of the end user or customer. It captures user needs and requirements in plain language and serves as a foundation for development. Purpose in Requirements Analysis In requirements analysis, user stories help translate user needs into clear, actionable requirements that guide development and prioritization. When to Use ● In agile projects to define features iteratively. ● To clarify requirements for design and development teams. ● To facilitate discussion and prioritization. Minimum Typical Optimum 18 User Stories: Number 1–2 stakeholders or user representatives per functionality area 3–5 representatives to capture multiple perspectives User Stories: Type Key end users or customers of the system/service A balanced mix of different user types or personas representing various use cases Responsibility for Implementation Product owner, business analyst, or requirements engineer with input from end users Collaborative workshop with facilitator, product owner, and cross-functional team members Tip ▪ Follow the standard format: As a [role], I want [goal] so that [benefit]. ▪ Keep stories small and focused; split larger stories into multiple smaller ones. ▪ Use common tools such as Jira, Trello, GitLab, or spreadsheets to document user stories and link them to related epics or tasks. ▪ For smaller projects, simple text-based formats (e.g., Markdown tables or shared documents) are often sufficient and transparent. ▪ Validate each story with actual users to confirm relevance and accuracy. ▪ Link stories to acceptance criteria to make them testable. Figure 5 – Summary of the Process Flow of User Stories User Stories Checklist ☐ Each story follows a consistent format that includes the user role, desired action, and underlying benefit or reason. 19 ☐ Stories are specific enough to guide development but not overly detailed to restrict solution design. ☐ Stories have been reviewed with stakeholders and prioritized according to project goals. If you need further assistance in creating user stories for your project, this Base4NFDI – User Story Guide, may be a helpful starting point. 5.6 Personas Personas Short Description Personas are fictional, archetypical user profiles created to represent the needs, behaviors, and goals of a target audience. They are based on research and data from actual users and help teams develop a deeper understanding of their user base. A persona typically includes: ● Name ● Demographic details (e.g., age, gender, occupation) ● Goals and motivations ● Challenges and pain points ● Behaviors and preferences Purpose in Requirements Analysis Personas help maintain a user-centered perspective throughout the project by making target groups tangible and relatable for all stakeholders. They ensure that requirements are elicited with specific, relatable user archetypes in mind, which helps prevent the project from drifting toward purely technical or internal priorities. When to Use ● At the start of a project to align understanding of target users. ● To guide decision-making during requirements gathering and design. ● To ensure consistent focus on user needs. Minimum Typical Optimum Personas: Number 1–3 personas for small projects 3–7 personas to cover major user groups without overcomplicating the process 20 Personas: Type Representations of the most important user group(s) A balanced mix covering primary, secondary, and edge-case users Responsibility for Implementation UX designer, business analyst, or requirements engineer Collaborative creation by a crossfunctional team with contributions from research, design, and domain experts Tip ▪ Base personas on real data from interviews, surveys, or observations, not on assumptions. ▪ Keep them concise and easy to reference—ideally one page per persona. ▪ Include visual elements (e.g., photo, icons) to make them memorable. ▪ Revisit and refine personas as new user insights emerge during the project. Figure 6 – Summary of the Process Flow of Personas Personas Checklist ☐ Personas are grounded in validated user research – based on real data, not assumptions. ☐ Each persona clearly captures key demographics, goals, motivations, and pain points – enough detail to guide decisions. ☐ Personas are regularly updated to reflect evolving user needs, and all requirements and design decisions are validated against them to ensure alignment. If you need further assistance in creating personas for your project, this guide, Base4NFDI - Persona Creation Kit, may be a helpful starting point. 21 6. About this Guide and Further Resources About this Guide This guide was developed by the Task Area 1 team as a practical toolkit that combines established methods with recommendations tailored to the NFDI context. It provides concrete guidance on how to plan and conduct a requirements analysis and supports service teams in preparing their deliverable D.TA1.1 Requirements Analysis. The guide was authored by Jana Plomin and Susanna Kuper, both members of the TA1 team with responsibility for requirements analysis. They offer methodological support and facilitate workshops on personas, user stories, and value propositions canvas. Contact Jana Plomin jana.plomi[email protected]hofer.de References and Resources The following resources and documents are cited or referenced throughout this guide and provide additional information: Arndt, S., Ganske, A., Lehmenkühler, D., & Wittenhorst, T. (2025). Service Evaluation Guide (1.0). Zenodo. https://doi.org/10.5281/zenodo.15720404 Kuper, S., & Plomin, J. (2025). Base4NFDI – User Story Guide (Version 1). Zenodo. https://doi.org/10.5281/zenodo.14998462 Manske, A., Plomin, J., Lorenz, A.-L. & Kuper, S. (2025). Base4NFDI - Persona Creation Kit. Zenodo. Base4NFDI - Persona Creation Kit Müller, E., Goebel, S., Couné, B. (2017). Bedarfsanalyse Palliative Care Basics. Albert-LudwigsUniversität Freiburg. https://www.wb.uni-freiburg.de/inhalte/pdfs/ohprojekt/epact/bedarfsanalyse-palliative-care-basics Neelam Vishen, Chen, T., & Kuper, S. (2025). Base4NFDI– Guidelines on Application of Web Accessibility (Version 1). Zenodo. https://doi.org/10.5281/zenodo.15719661 Wittenhorst, T., Ganske, A., & Lehmenkühler, D. (2025). Base4NFDI – Requirements for Completion of Initialisation Phase (Version v2). Zenodo. https://doi.org/10.5281/zenodo.15020379