Practical challenges of requirements prioritization based on risk estimation

Herrmann, Andrea; Paech, Barbara

doi:10.1007/s10664-009-9105-0

Cited by 21 publications

(16 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Hence, it leads to requirement conflicts. These conflicts are solved in the requirement elicitation and analysis stage by analyzing the necessity of the requirements, prioritizing the critical requirement and compromising the set of requirements after the negotiation [7].…”

Section: Introductionmentioning

confidence: 99%

Evaluation of Capturing Architecturally Significant Requirements

Kumar

2017

Asian J Pharm Clin Res

View full text Add to dashboard Cite

Every software development organization strives for customer satisfaction. It is universally accepted that the success of software development lies in the clear understanding of the client requirements. During requirement elicitation and analysis stage, the system analyst identifies the functional and nonfunctional requirements from the customer. Security, usability, reliability, performance, scalability, and supportability are the significant quality attributes of a software system. These quality attributes are also referred as non-functional requirements. Only a few functional and quality attributes requirement help to identify and shape the software architecture. A software system's architecture is the set of prime design decisions made about the system. If the requirement influences the architectural design decision then, it is referred as architecturally significant requirement (ASR). Identifying and specifying all the possible ASR are important tasks in the requirement elicitation and analysis stage. In this research, general problems that are faced while capturing and specifying ASR in requirement elicitation and analysis is studied. Among the different requirement elicitation techniques, use case diagram has been identified and enhanced to solve the problem of capturing and specifying ASR during the requirement elicitation and analysis phase.

show abstract

Section: Introductionmentioning

confidence: 99%

Evaluation of Capturing Architecturally Significant Requirements

Kumar

2017

Asian J Pharm Clin Res

View full text Add to dashboard Cite

show abstract

“…In 2009, we published two initial pilot experiments about risk‐based requirements prioritization, which raised a list of fundamental research questions about risk estimation. Meanwhile, a series of six further experiments about the risk estimation of IT‐related risks have been executed in order to investigate these research questions.…”

Section: Introductionmentioning

confidence: 99%

The Quantitative Estimation of IT‐Related Risk Probabilities

Herrmann¹

2012

Risk Analysis

Self Cite

View full text Add to dashboard Cite

How well can people estimate IT-related risk? Although estimating risk is a fundamental activity in software management and risk is the basis for many decisions, little is known about how well IT-related risk can be estimated at all. Therefore, we executed a risk estimation experiment with 36 participants. They estimated the probabilities of IT-related risks and we investigated the effect of the following factors on the quality of the risk estimation: the estimator's age, work experience in computing, (self-reported) safety awareness and previous experience with this risk, the absolute value of the risk's probability, and the effect of knowing the estimates of the other participants (see: Delphi method). Our main findings are: risk probabilities are difficult to estimate. Younger and inexperienced estimators were not significantly worse than older and more experienced estimators, but the older and more experienced subjects better used the knowledge gained by knowing the other estimators' results. Persons with higher safety awareness tend to overestimate risk probabilities, but can better estimate ordinal ranks of risk probabilities. Previous own experience with a risk leads to an overestimation of its probability (unlike in other fields like medicine or disasters, where experience with a disease leads to more realistic probability estimates and nonexperience to an underestimation).

show abstract

“…One of the greater challenges in procuring or developing any information system is capturing the user requirements since requirements decisions are affected by incomplete and uncertain information (Herrmann & Paech, 2009). …”

Section: Chapter 1 Introductionmentioning

confidence: 99%