BZPEERReading, trust and collaboration for research
Menu

Discover

GraphFollow connections around a paper, topic or saved view.

Workspaces

HomePick up where your research flow left off.InboxHandle requests, replies and notifications from one place.CollectionsCurate reading lists, evidence sets and shareable dossiers.ResearchSee your private provenance graph, trail and imports.CollaborationMove from discovery into focused discussion rooms.PublishDraft, preview and publish full-text research articles.

Network

ExpertsFind specialists worth following or asking for help.CommunitiesJoin research circles organized around shared work.PartnersSee external organizations active around the same topics.

Opportunities

ListingsBrowse roles, calls and collaborations with clearer fit signals.

Account

Log inReturn to your reading and collaboration workspace.Create accountStart saving work, following people and joining teams.
Log inCreate account

Researcher profile

Daniela Damian

Daniela Damian contributes to research discovery and scholarly infrastructure.

ResearcherAffiliation not importedOpen to collaborate
Software Engineering

Trust snapshot

Quick read

Trust 19 - UnverifiedVerification L1Unclaimed author
5works
0followers
1topics
4close collaborators

Actions

Decide how to stay connected

Follow researcher0

Identity and collaboration

How to connect with this researcher

Claiming links this public author record to a researcher profile and unlocks direct collaboration workflows.

Log in to claim

Direct collaboration

Open a focused conversation when the fit is right

Claim this author entity first to unlock direct invitations.

Research graph

See the researcher in context

Open full explorer

Inspect adjacent work, topics, institutions and collaborators without jumping out to a separate graph page.

Building this graph slice

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

5 published item(s)

preprint2022arXiv

A Case Study of Building Shared Understanding of Non-Functional Requirements in a Remote Software Organization

Building a shared understanding of non-functional requirements (NFRs) is a known but understudied challenge in requirements engineering, especially in organizations that adopt continuous software engineering (CSE) practices. During the peak of the COVID-19 pandemic, many CSE organizations complied with working remotely due to the imposed health restrictions; some continued to work remotely while implementing business processes to facilitate team communication and productivity. In remote CSE organizations, managing NFRs becomes more challenging due to the limitations to team communication coupled with the incentive to deliver products quickly. While previous research has identified the factors that lead to a lack of shared understanding of NFRs in CSE, we still have a significant gap in understanding how CSE organizations, particularly in remote work, build a shared understanding of NFRs in their software development. We conduct a three-month ethnography-informed case study of a remote CSE organization. Through thematic analysis of our qualitative data from interviews and observations, we identify a number of practices in developing a shared understanding of NFRs. The collaborative workspace the organization uses for remote interaction is Gather, which simulates physical workspaces, and which our findings suggest allows for informal communications instrumental for building shared understanding. As actionable insights, we discuss our findings in light of proactive practices that represent opportunities for software organizations to invest in building a shared understanding of NFRs in their development.

0 citations0 reviewsNo code linkedOpen access
preprint2022arXiv

A Community Strategy Framework -- How to obtain Influence on Requirements in Meritocratic Open Source Software Communities?

Context: In the Requirements Engineering (RE) process of an Open Source Software (OSS) community, an involved firm is a stakeholder among many. Conflicting agendas may create miss-alignment with the firm's internal requirements strategy. In communities with meritocratic governance or with aspects thereof, a firm has the opportunity to affect the RE process in line with their own agenda by gaining influence through active and symbiotic engagements. Objective: The focus of this study has been to identify what aspects that firms should consider when they assess their need of influencing the RE process in an OSS community, as well as what engagement practices that should be considered in order to gain this influence. Method: Using a design science approach, 21 interviews with 18 industry professionals from 12 different software-intensive firms were conducted to explore, design and validate an artifact for the problem context. Results: A Community Strategy Framework (CSF) is presented to help firms create community strategies that describe if and why they need influence on the RE process in a specific (meritocratic) OSS community, and how the firm could gain it. The framework consists of aspects and engagement practices. The aspects help determine how important an OSS project and its community is from business and technical perspectives. A community perspective is used when considering the feasibility and potential in gaining influence. The engagement practices are intended as a tool-box for how a firm can engage with a community in order to build influence needed. Conclusion: It is concluded from interview-based validation that the proposed CSF may provide support for firms in creating and tailoring community strategies and help them to focus resources on communities that matter and gain the influence needed on their respective RE processes.

0 citations0 reviewsNo code linkedOpen access
preprint2022arXiv

A method for analyzing stakeholders' influence on an open source software ecosystem's requirements engineering process

For a firm in an open source software (OSS) ecosystem, the requirements engineering (RE) process is rather multifaceted. Apart from its typical RE process, there is a competing process, external to the firm and inherent to the firm's ecosystem. When trying to impose an agenda in competition with other firms, and aiming to align internal product planning with the ecosystem's RE process, firms need to consider who and how influential the other stakeholders are, and what their agendas are. The aim of the presented research is to help firms identify and analyze stakeholders in OSS ecosystems, in terms of their influence and interactions, to create awareness of their agendas, their collaborators, and how they invest their resources. To arrive at a solution artifact, we applied a design science research approach where we base artifact design on the literature and earlier work. A stakeholder influence analysis (SIA) method is proposed and demonstrated in terms of applicability and utility through a case study on the Apache Hadoop OSS ecosystem. SIA uses social network constructs to measure the stakeholders' influence and interactions and considers the special characteristics of OSS RE to help firms structure their stakeholder analysis processes in relation to an OSS ecosystem. SIA adds a strategic aspect to the stakeholder analysis process by addressing the concepts of influence and interactions, which are important to consider while acting in collaborative and meritocratic RE cultures of OSS ecosystems.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

GDPR Compliance in the Context of Continuous Integration

The enactment of the General Data Protection Regulation (GDPR) in 2018 forced any organization that collects and/or processes EU-based personal data to comply with stringent privacy regulations. Software organizations have struggled to achieve GDPR compliance both before and after the GDPR deadline. While some studies have relied on surveys or interviews to find general implications of the GDPR, there is a lack of in-depth studies that investigate compliance practices and compliance challenges of software organizations. In particular, there is no information on small and medium enterprises (SMEs), which represent the majority of organizations in the EU, nor on organizations that practice continuous integration. Using design science methodology, we conducted an in-depth study over the span of 20 months regarding GDPR compliance practices and challenges in collaboration with a small, startup organization. We first identified our collaborator's business problems and then iteratively developed two artifacts to address those problems: a set of operationalized GDPR principles, and an automated GDPR tool that tests those GDPR-derived privacy requirements. This design science approach resulted in four implications for research and for practice. For example, our research reveals that GDPR regulations can be partially operationalized and tested through automated means, which improves compliance practices, but more research is needed to create more efficient and effective means to disseminate and manage GDPR knowledge among software developers.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

The Lack of Shared Understanding of Non-Functional Requirements in Continuous Software Engineering: Accidental or Essential?

Building shared understanding of requirements is key to ensuring downstream software activities are efficient and effective. However, in continuous software engineering (CSE) some lack of shared understanding is an expected, and essential, part of a rapid feedback learning cycle. At the same time, there is a key trade-off with avoidable costs, such as rework, that come from accidental gaps in shared understanding. This trade-off is even more challenging for non-functional requirements (NFRs), which have significant implications for product success. Comprehending and managing NFRs is especially difficult in small, agile organizations. How such organizations manage shared understanding of NFRs in CSE is understudied. We conducted a case study of three small organizations scaling up CSE to further understand and identify factors that contribute to lack of shared understanding of NFRs, and its relationship to rework. Our in-depth analysis identified 41 NFR-related software tasks as rework due to a lack of shared understanding of NFRs. Of these 41 tasks 78% were due to avoidable (accidental) lack of shared understanding of NFRs. Using a mixed-methods approach we identify factors that contribute to lack of shared understanding of NFRs, such as the lack of domain knowledge, rapid pace of change, and cross-organizational communication problems. We also identify recommended strategies to mitigate lack of shared understanding through more effective management of requirements knowledge in such organizations. We conclude by discussing the complex relationship between shared understanding of requirements, rework and, CSE.

0 citations0 reviewsNo code linkedOpen access