COTS tenders and integration requirements

Lauesen, Søren

doi:10.1109/icre.2004.1335674

Cited by 20 publications

(19 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A requirementcomponent mismatch is a difference in functional feature or non-functional quality attributes from a given component and a desired requirement. On one hand, some studies see requirement negotiation as an approach to resolve the mismatches [2,8,8,9,14,15]. In these cases, the component is fixed beforehand and requirements are the target of changes [8].…”

Section: Requirements-components Mismatches Resolution Processmentioning

confidence: 99%

“…Rolland proposed a goal-oriented approach for considering mismatches at the business level and then defined goal matching as the conceptual framework for resolving them [8]. Other approaches focused on lower level but highly challenging requirement problems, with integration requirements in call-for-tender processes [15].…”

Section: Requirements-components Mismatches Resolution Processmentioning

confidence: 99%

See 1 more Smart Citation

Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components

Ánh

Cruzes

Conradi

et al. 2012

Requirements Engineering: Foundation for Software Quality

View full text Add to dashboard Cite

Abstract. [Context and motivation]There is considerable flexibility in requirements specifications (both functional and non-functional), as well as in the features of available OSS components. This allows a collaborative matching and negotiation process between stakeholders such as: customers, software contractors and OSS communities, regarding desired requirements versus available and thus reusable OSS components.[Problem] However, inconclusive research exists on such cooperative processes. Not much empirical data exists supporting the conduction of such research based on observation of industrial OSS adoption projects. This paper investigates how functional and non-functional requirement mismatches are handled in practice.[Results] We found two common approaches to handle functional mismatches. The main resolution approach is to get the components changed by the development team, OSS community or commercial vendor. The other resolution approach is to influence requirements, often by postponing requirements. Overall, non-functional requirements are satisfactorily achieved by using OSS components. Last but not least, we found that the customer involvement could enhance functional mismatch resolution while OSS community involvement could improve nonfunctional mismatch resolution.[Contribution] Our data suggests that the selecting components should be done iteratively with close collaboration with stakeholders. Improvement in requirement mismatch resolution to requirements could be achieved by careful consideration of mismatches size, requirements flexibility and components quality.

show abstract

Section: Requirements-components Mismatches Resolution Processmentioning

confidence: 99%

Section: Requirements-components Mismatches Resolution Processmentioning

confidence: 99%

Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components

Ánh

Cruzes

Conradi

et al. 2012

Requirements Engineering: Foundation for Software Quality

View full text Add to dashboard Cite

show abstract

“…An effective RE process must deal with situations where formalized description of both functional and nonfunctional requirements may not be available [27]. In software procurement and development projects "open-target requirements" are recommended since it is hard to specify requirements in detail upfront [28]. In such context the customers specify their demands and expectations and the vendor responds with how they can meet the demands.…”

Section: A Inevitability Of Infrcmentioning

confidence: 99%

Managing Requirements Change the Informal Way: When Saying ‘No’ is Not an Option

Hussain¹,

Zowghi²,

Clear³

et al. 2016

2016 IEEE 24th International Requirements Engineering Conference (RE)

View full text Add to dashboard Cite

Abstract-Software has always been considered as malleable.Changes to software requirements are inevitable during the development process. Despite many software engineering advances over several decades, requirements changes are a source of project risk, particularly when businesses and technologies are evolving rapidly. Although effectively managing requirements changes is a critical aspect of software engineering, conceptions of requirements change in the literature and approaches to their management in practice still seem rudimentary. The overall goal of this study is to better understand the process of requirements change management. We present findings from an exploratory case study of requirements change management in a globally distributed setting. In this context we noted a contrast with the traditional models of requirements change. In theory, change control policies and formal processes are considered as a natural strategy to deal with requirements changes. Yet we observed that "informal requirements changes" (InfRc) were pervasive and unavoidable. Our results reveal an equally 'natural' informal change management process that is required to handle InfRc in parallel. We present a novel model of requirements change which, we argue, better represents the phenomenon and more realistically incorporates both the informal and formal types of change.

show abstract

“…Research in this area focuses on easing management tasks and improving analysis techniques. For example, researchers have proposed a number of prioritization [105], visualization [63,93], and analysis [122,139] techniques to help managers select an optimal combination of requirements to implement -or to help project managers identify acceptable off-the-shelf solutions [91,126]. Other researchers are investigating how to improve our ability to estimate the cost [33] of implementing the selected requirements, or the impact of new or modified requirements [88].…”

Section: State Of the Art Of Re Researchmentioning

confidence: 99%

Research Directions in Requirements Engineering

Cheng

Atlee

2007

Future of Software Engineering (FOSE '07)

457

263

View full text Add to dashboard Cite

This paper reviews the current state of the art of requirements engineering (RE) research and identifies RE research challenges for future systems. First, the paper overviews the highlights of RE research over the past two decades; the research is considered with respect to requirements technologie, including notations and methodologies, developed to address specific RE tasks, such as elicitation, modeling, and analysis. Such a review enables us to identify mature areas of research, as well as areas that warrant further investigation. Next, we identify several research challenges posed by emerging systems for the future. In order to help delineate the scope of future RE research directions, we then identify several strategies for performing RE research. (The spectrum of research strategies ranges from empirical research to paradigm shifts.) Finally, within the context of these RE research strategies, we identify "hot areas" of research that address RE needs for emerging systems of the future.

show abstract

COTS tenders and integration requirements

Cited by 20 publications

References 16 publications

Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components

Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components

Managing Requirements Change the Informal Way: When Saying ‘No’ is Not an Option

Research Directions in Requirements Engineering

Contact Info

Product

Resources

About