Resolving requirement conflicts through non-functional decomposition

Poort, Eltjo

doi:10.1109/wicsa.2004.1310698

Cited by 22 publications

(20 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Poort and de With [15] grouped functional requirements based on nonfunctional requirements; this means finding all primary function requirements that share similar nonfunctional requirements and grouping them together. Then two types of conflicts are defined: grouping conflicts which caused by differences in grouping of functions and in-group conflicts that have conflicting requirements within one function group.…”

Section: Types Of Requirements Conflictmentioning

confidence: 99%

See 1 more Smart Citation

Software Requirements Conflict Identification: Review and Recommendations

Aldekhail¹,

Chikh²,

Ziani³

2016

ijacsa

View full text Add to dashboard Cite

Abstract-Successful development of software systems requires a set of complete, consistent and clear requirements. A wide range of different stakeholders with various needs and backgrounds participate in the requirements engineering process. Accordingly, it is difficult to completely satisfy the requirements of each and every stakeholder. It is the requirements engineer's job to trade-off stakeholders' needs with the project resources and constraints. Many studies assert that failure in understanding and managing requirements in general, and requirement conflicts in particular, are one of the main problems of exceeding cost and allocated time which in turn results in project failure. This paper aims at investigating the different reasons of requirements conflicts and the different types of requirements conflicts. It providing an overview of existing research works on identifying conflicts; and discussing their limitations in order to yield suggestions for improvement. Objective: To provide an overview of existing research studies on identifying software requirements conflict and identifying limitations and areas for improvement. Method: A comparative literature was conducted by assessing 20 studies dated from 2001 to 2014.

show abstract

Section: Types Of Requirements Conflictmentioning

confidence: 99%

“…Poort and de With [15] presented a non-functional decomposition (NFD) model that gives a new classification for requirements. Primary functional requirements and supplementary requirements which is classified as secondary functional requirements, quality attribute requirements and implementation requirements.…”

Section: ) Manualmentioning

confidence: 99%

Software Requirements Conflict Identification: Review and Recommendations

Aldekhail¹,

Chikh²,

Ziani³

2016

ijacsa

View full text Add to dashboard Cite

show abstract

“…Examples are QUARCC [18] and NFD [19], which are methods to identify and resolve quality requirements conflicts.…”

Section: Related Workmentioning

confidence: 99%

Experience of pragmatically combining RE methods for performance requirements in industry

Wohlrab

Gooijer

Koziolek

et al. 2014

2014 IEEE 22nd International Requirements Engineering Conference (RE)

View full text Add to dashboard Cite

To meet end-user performance expectations, precise performance requirements are needed during development and testing, e.g., to conduct detailed performance and load tests. However, in practice, several factors complicate performance requirements elicitation: lacking skills in performance requirements engineering, outdated or unavailable functional specifications and architecture models, the specification of the system's context, lack of experience to collect good performance requirements in an industrial setting with very limited time, etc. From the small set of available non-functional requirements engineering methods, no method exists that alone leads to precise and complete performance requirements with feasible effort and which has been reported to work in an industrial setting. In this paper, we present our experiences in combining existing requirements engineering methods into a performance requirements method called PROPRE. It has been designed to require no up-to-date system documentation and to be applicable with limited time and effort. We have successfully applied PROPRE in an industrial case study from the process automation domain. Our lessons learned show that the stakeholders gathered good performance requirements which now improve performance testing.

show abstract

“…For example, Poort and De With argue that requirements conflicts they encounter in practice necessarily "arise from limitations in the solution domain" (Poort and de With, 2004). Along the same line, Kozaczynski observes that "in practice key requirements are not fully understood until the architecture is baselined" (Kozaczynski, 2002).…”

Section: Problem Vs Solution: a False Dichotomy?mentioning

confidence: 99%