A Broad, Quantitative Model for Making Early Requirements Decisions

Feather, Martin S.; Cornford, Steven L.; Hicks, K.; Kiper, James D.

doi:10.1109/ms.2008.29

Cited by 23 publications

(15 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The idea to analyze this kind of data is similar to quality spectrum analysis [2], but comparative analysis mentioned in introduction is not proposed in the article [15]. In DDP (defect detection prevention) [16], [17], the relationships among requirements, risks and their mitigations are visualized. Although this visualization shows a macro-view of quality requirements, trade-offs between risks and their mitigation costs are mainly focused.…”

Section: Related Workmentioning

confidence: 99%

Improving Reliability of Spectrum Analysis for Software Quality Requirements Using TCM

Kaiya

Tanigawa

Suzuki

et al. 2010

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

SUMMARYQuality requirements are scattered over a requirements specification, thus it is hard to measure and trace such quality requirements to validate the specification against stakeholders' needs. We proposed a technique called "spectrum analysis for quality requirements" which enabled analysts to sort a requirements specification to measure and track quality requirements in the specification. In the same way as a spectrum in optics, a quality spectrum of a specification shows a quantitative feature of the specification with respect to quality. Therefore, we can compare a specification of a system to another one with respect to quality. As a result, we can validate such a specification because we can check whether the specification has common quality features and know its specific features against specifications of existing similar systems. However, our first spectrum analysis for quality requirements required a lot of effort and knowledge of a problem domain and it was hard to reuse such knowledge to reduce the effort. We thus introduce domain knowledge called term-characteristic map (TCM) to reuse the knowledge for our quality spectrum analysis. Through several experiments, we evaluate our spectrum analysis, and main finding are as follows. First, we confirmed specifications of similar systems have similar quality spectra. Second, results of spectrum analysis using TCM are objective, i.e., different analysts can generate almost the same spectra when they analyze the same specification.

show abstract

Section: Related Workmentioning

confidence: 99%

Improving Reliability of Spectrum Analysis for Software Quality Requirements Using TCM

Kaiya

Tanigawa

Suzuki

et al. 2010

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

show abstract

“…For each security control in cSC, the algorithm checks whether Z3 finds a solution when the security control is disabled. If no solution is found, the considered security control is necessary and is added to the list reqSC of required security controls (lines [6][7][8]. Otherwise, the algorithm checks whether Z3 finds a solution when the security control is enabled.…”

Section: Algorithmmentioning

confidence: 99%

“…Different requirements-based decision techniques [8,15,43] have been proposed in the literature. Feather et al [8] propose a model to make strategic decisions in the early project phases, based on the coarse quantification of risk and its interactions with requirements and mitigations.…”

Section: Related Workmentioning

confidence: 99%

Automating trade-off analysis of security requirements

et al. 2015

View full text Add to dashboard Cite

A key aspect of engineering secure systems is identifying adequate security requirements to protect critical assets from harm. However, security requirements may compete with other requirements such as cost and usability. For this reason, they may only be satisfied partially and must be traded off against other requirements to achieve ''good-enough security''. This paper proposes a novel approach to automate security requirements analysis in order to determine maximum achievable satisfaction level for security requirements and identify trade-offs between security and other requirements. We also propose a pruning algorithm to reduce the search space size in the analysis. We represent security concerns and requirements using asset, threat, and goal models, initially proposed in our previous work. To deal with uncertainty and partial requirements, satisfaction security concerns are quantified by leveraging the notion of composite indicators, which are computed through metric functions based on range normalisation. An SMT solver (Z3) interprets the models and automates the execution of our analyses. We illustrate and evaluate our approach by applying it to a substantive example of a service-based application for exchanging emails.

show abstract

“…In order to ease the difficulty involved with requirements setting in the outsourcing environment, the organization could use a model such as the one proposed in [8] to pre-select their requirements. The model uses a risk-based requirements model to determine the earliest requirements of the project, and then allows for change during further evaluation and implementation.…”

Section: Outsourcingmentioning

confidence: 99%

“…The model uses a risk-based requirements model to determine the earliest requirements of the project, and then allows for change during further evaluation and implementation. The approach used a defect detection and prevention (DDP) approach, which is derived from a hardware manufacturing discipline, but may also be applied to software development or other production tasks [8]. In particular, this approach heads off expectation/reality mismatches like those discussed above, including mismatches in capabilities and requirements, mismatches in stakeholder perceptions regarding priorities and comparative value of a given task or requirement, and a consideration of other potential roadblocks to success.…”

Section: Outsourcingmentioning

confidence: 99%