Characterizing Architecturally Significant Requirements

Chen, Lianping; Babar, Muhammad Ali; Nuseibeh, Bashar

doi:10.1109/ms.2012.174

Cited by 112 publications

(58 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The following section describes various methods for capturing ASR. Chen et al [15] conducted an empirical study to characterize ASR. ASR is difficult to define and express.…”

Section: Kumarmentioning

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

“…The following section describes various methods for capturing ASR. Chen et al [15] conducted an empirical study to characterize ASR. ASR is difficult to define and express.…”

Section: Kumarmentioning

confidence: 99%

Evaluation of Capturing Architecturally Significant Requirements

Kumar

2017

Asian J Pharm Clin Res

View full text Add to dashboard Cite

show abstract

“…Not intending to be exhaustive and just getting some recent works, these studies are concerned with many distinct topics in SE, such as software development for medical devices ), requirements engineering (Chen et al 2013), software processes (Guo and Seaman 2008;Rodríguez et al 2012;Abrantes and Travassos 2013), pair programming (Rodríguez et al 2012), defect reporting (Bettenburg et al 2008), exploratory testing (Pfahl et al 2014), model-based testing (Dias Neto andTravassos 2008), effort estimation (Basten and Mellis 2011;Vaz 2013), component-based software engineering (Conradi et al 2005;Ji et al 2008), global software development (Humayun et al 2013) and technology transfer (Diebold and Vetrò 2014) among many others.…”

Section: Surveys In Software Engineeringmentioning

confidence: 99%

“…the basic element of analysis from each survey (Hopkins 1982), can be typically established as: de Mello et al Journal of Software Engineering Research and Development (2015) 3:8an organization Diebold and Vetrò 2014) a software project (Conradi et al 2005;Ji et al 2008;Basten and Mellis 2011) an individual (Dias Neto and Travassos 2008;Guo and Seaman 2008;Betenburg 2008;Abrantes and Travassos 2013;Bettenburg et al 2008;Rodríguez et al 2012;Chen et al 2013;Vaz 2013;Humayun et al 2013;Pfahl et al 2014). …”

Section: Surveys In Software Engineeringmentioning

confidence: 99%

Investigating probabilistic sampling approaches for large-scale surveys in software engineering

Mello

Silva

Travassos

2015

J Softw Eng Res Dev

View full text Add to dashboard Cite

Background: Establishing representative samples for Software Engineering surveys is still considered a challenge. Specialized literature often presents limitations on interpreting surveys' results, mainly due to the use of sampling frames established by convenience and non-probabilistic criteria for sampling from them. In this sense, we argue that a strategy to support the systematic establishment of sampling frames from an adequate source of sampling can contribute to improve this scenario. Method: A conceptual framework for supporting large scale sampling in Software Engineering surveys has been organized after performing a set of experiences on designing such strategies and gathering evidence regarding their benefits. The use of this conceptual framework based on a sampling strategy developed for supporting the replication of a survey on characteristics of agility and agile practices in software processes is depicted in this paper. Result: A professional social network (Linkedln) was established as the source of sampling and its groups of interest as the units for searching members to be recruited. It allowed to deal with a sampling frame composed by more than 110,000 members (prospective subjects) distributed over 19 groups of interest. Then, through the similarity levels observed among these groups, eight strata were organized and 7745 members were invited, from which 291 have confirmed participation and answered the questionnaire. Conclusion: The heterogeneity and number of participants in this replication contributed to improve the strength of original survey's results. Therefore, we believe the sharing of this experience, the instruments and plan can be helpful for those researchers and practitioners interested on executing large scale surveys in Software Engineering.

show abstract

“…Imp.) (9,9,9) One variable is absolutely more important than the other 2 Immediate values between scales (1,2,3) 4 (3,4,5) 6 (5,6,7) 8 (7,8,9) If Criteria 1 (C1) is Weakly Important than Criteria 2 (C2) then it takes the fuzzy triangular scale as (2,3,4) and pairwise comparison C2 to C1 will take the reciprocal value as (1/2, 1/3, 1/4).…”

Section: Fuzzy Ahp (Fahp) Equationsmentioning

confidence: 99%

“…ASR determine and influence the formation of a system architecture [4]. ASR determination requires knowledge of the solution space which is less known by the requirements engineer.…”

Section: Introductionmentioning

confidence: 99%

Fuzzy AHP based design decision for Product Line architecture

Halim

Deris

Zaki

2014

2014 8th. Malaysian Software Engineering Conference (MySEC)

View full text Add to dashboard Cite

Product line architecture (PLA)is one of the important assets in Software Product Line (SPL). In PLA there are numerous variation points and variants in which software engineers can decide and select as the best or suitable enough design decision for the PLA. Therefore it's crucial for SPL to have an explicit architecture design decision representation to enable the important knowledge to be reused in several similar applications in the product line.Though there are many proposals towards incorporating design decision in SPL, however it is still lacking in dealing with multiple criteria and fuzziness of the PLA design decision. In this paper, we propose to overcome this problem by incorporating Fuzzy Analytical Hierarchical Process (FAHP) in the design decision. Our approach considers the use of architecturally significant requirements, which is the quality attributes in the design decision. We demonstrate our approach using the case study of Autonomous Mobile Robot Product Line (AMRPL). The findingstend to show a potential use of FAHP in the design decision.

show abstract

Characterizing Architecturally Significant Requirements

Cited by 112 publications

References 8 publications

Evaluation of Capturing Architecturally Significant Requirements

Evaluation of Capturing Architecturally Significant Requirements

Investigating probabilistic sampling approaches for large-scale surveys in software engineering

Fuzzy AHP based design decision for Product Line architecture

Contact Info

Product

Resources

About