On the interplay between inconsistency and incompleteness in multi-perspective requirements specifications

Partnering effects on user–developer conflict and role ambiguity in information system projects

“…User-developer conflict and role ambiguity often lead to difficulties in determining system requirements and missed requirements [8,42]. For example, an improper definition of roles could lead to missed requirements because project team members are not clear as to what tasks they should be doing [42,47].…”

“…Successfully constructing a system, therefore, requires effective control of relationships among these stakeholders to elicit their contributions and cooperation, while, at the same time, maintaining advancement toward the project's objectives [25,53]. Conflict between users and developers of the system and ambiguity in role definitions for ISD project team members are two frequently cited threats to effective collaboration among participants in the project [8,48,67], and thus are ranked as significant risk factors to achieving project success [42,68]. For example, role ambiguity is ranked as a significant risk factor by both IS project managers and users -''responsibility of each participant must be clearly determined otherwise there will be overlap, conflict, mismanagement and unsatisfactory outcomes from the project'' [42].…”

Handling Inconsistency In Distributed Software Requirements Specifications Based On Prioritized Merging

“…Negotiation is also considered as a useful way to resolving inconsistency during the requirements stage [35,40,41]. In this paper, we may also consider negotiation as a group decision making mechanism in our general framework.…”

“…Both the relative importance of requirements statements with regard to their supporting viewpoints and the priority of viewpoints have been paid attention in managing inconsistency in requirements engineering [35]. If we merge these different viewpoints as an overall viewpoint of the system-to-be, it is necessary to assign a relative priority to each requirements statement from an overall or global perspective.…”

“…Barragáns Martínez et al [35] defined a merging operator whose aim was to get the model which best reflects the combined knowledge of all the stakeholders (viewpoints) without first resolving inconsistencies and incompleteness. Although their methodology has envisioned two kinds of possible revision procedures to modify the original viewpoints, useful guidance on how to resolve these inconsistencies by using these revision procedures is not yet provided in [35]. These existing merging frameworks used in managing inconsistent viewpoints focused on tolerating inconsistency rather than resolving inconsistency in merged results.…”