Kebutuhan Perangkat Lunak Untuk Aplikasi Data Mining

In software development, the software requirements are the result of understandings of user requirements or the system owners to the developer. Based on these requirements, the developers are able to develop their software architecture. Based on software architecture, developers can construct a set of requirements. This reuse process shall give positive impacts to a better software product. This research uses a technique for generating software requirements for data mining based on data mining software architecture, especially a data mining application for analyzing social media. The contribution of this research is a proposal of a generic data mining requirements software that is expected to be reference for data mining application development. The proposal is evaluated to three different data mining applications that each consists of four typical requirements. These three applications are compared to our generated requirements. The results show that 50% of our requirements have been used in these applications or an average of 83.33% requirements from our proposal has contributed to these three applications. It shows that the technique used to generate software requirements based on software architecture is able to provide an alternative to develop new common requirements

Strengths and Weaknesses of Persona Creation Methods:Guidelines and Opportunities for Digital Innovations

Persona is a technique for enhancing user understanding and improving the user-centered design of digital products. Persona creation has traditionally been divided into Qualitative, Quantitative, and Mixed Methods approaches. However, no literature systematically contrasts the strengths and weaknesses of these approaches. We review the literature to map the strengths and weaknesses of these approaches and evaluate the potential of personas for the domain of digital innovation. We provide insights for better creation and use of personas by both researchers and practitioners, especially those that are new to personas, deploying personas in a new domain, or familiar with only one of the persona creation approaches

Non functional requirements (NFRs) traceability metamodel for agile development

Agile methodologies are well known for early and frequent releases. Besides, these methodologies also handle requirement changes well without causing delays. However, it has been noticed that the functional requirements changes can affect the non-functional requirements (NFRs) such as security and performance. It is also possible that the agile team is not even aware of these effects causing dysfunctional system. This issue could be addressed by offering traceability mechanism that helps to trace the effect of functional requirement changes on the non-functional requirements. Unfortunately, a few researchers have conducted studies regarding this issue. Thus, this study attempts to present a Traceability Process Model (TPM) to tackle the issue of tracing NFR especially security and performance. However, to materialize a full scale TPM, a metamodel is necessary. Therefore in this paper, we present a metamodel by integrating two existing metamodels. Then we validate the newly built metamodel with precision and recall methods. Lastly, we also develop a traceability tool that is based on the proposed metamodel

Probing for requirements knowledge to stimulate architectural thinking

Software requirements specifications (SRSs) often lack the detail needed to make informed architectural decisions. Architects therefore either make assumptions, which can lead to incorrect decisions, or conduct additional stakeholder interviews, resulting in potential project delays. We previously observed that software architects ask Probing Questions (PQs) to gather information crucial to architectural decision-making. Our goal is to equip Business Analysts with appropriate PQs so that they can ask these questions themselves. We report a new study with over 40 experienced architects to identify reusable PQs for five areas of functionality and organize them into structured flows. These PQflows can be used by Business Analysts to elicit and specify architecturally relevant information. Additionally, we leverage machine learning techniques to determine when a PQ-flow is appropriate for use in a project, and to annotate individual PQs with relevant information extracted from the existing SRS. We trained and evaluated our approach on over 8,000 individual requirements from 114 requirements specifications and also conducted a pilot study to validate its usefulness.</p

How to Create Personas: Three Persona Creation Methodologies with Implications for Practical Employment

Background: Personas are a technique for enhanced understanding of users and customers to improve the user-centered design of systems and products. Their creation can be categorized using three persona creation methodologies: Qualitative, Quantitative, and Mixed Methods. Despite the apparent differences in these methodologies, no previous review has systemically compared and contrasted the strengths and weaknesses of each of these methodologies for persona development. Method: This manuscript maps and navigates persona literature to identify the benefits and challenges of these three persona creation methodologies. Furthermore, the strategies and opportunities of the different methodologies are presented. Results: The results summarize the strengths and weaknesses of each of the three principal persona creation methodologies and offer suggestions of the benefits of their employment. Conclusion: In conclusion, we offer insights into the construction and usage of personas for practitioners and researchers, and we propose a framework to determine which persona creation methodology is most suitable for a given context. Keywords: Algorithmically-Generated Personas, Persona Analytics, Persona Science

How to Create Personas : Three Persona Creation Methodologies with Implications for Practical Employment

Background: Personas are a technique for enhanced understanding of users and customers to improve the user-centered design of systems and products. Their creation can be categorized using three persona creation methodologies: Qualitative, Quantitative, and Mixed Methods. Despite the apparent differences in these methodologies, no previous review has systemically compared and contrasted the strengths and weaknesses of each of these methodologies for persona development. Method: This manuscript maps and navigates persona literature to identify the benefits and challenges of these three persona creation methodologies. Furthermore, the strategies and opportunities of the different methodologies are presented. Results: The results summarize the strengths and weaknesses of each of the three principal persona creation methodologies and offer suggestions of the benefits of their employment. Conclusion: In conclusion, we offer insights into the construction and usage of personas for practitioners and researchers, and we propose a framework to determine which persona creation methodology is most suitable for a given context.© 2022 by the Association for Information Systems. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than the Association for Information Systems must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or fee. Request permission to publish from: AIS Administrative Office, P.O. Box 2712 Atlanta, GA, 30301-2712 Attn: Reprints, or via email from [email protected]=vertaisarvioitu|en=peerReviewed

Missing Requirements Information and its Impact on Software Architectures: A Case Study

[Context & motivation] In the development of large, software-intensive systems, the system’s requirements are seldom, if ever, concluded upon prior to commencing with systems architecture. Research shows that, in order to manage development and domain complexities, instances of requirements engineering (RE) and systems architecting (SA) processes tend to inter-weave. [Question/problem] However, missing requirements information can cause one to create (or recreate) the needed information during different SA activities. While backtracking in the software development process is known to be costly, the costs associated with missing requirements in the SA process have not been investigated empirically. [Principal ideas/results] We thus conducted a case study where we investigated to what extent requirements or requirements attributes’ information found missing during the SA process and impact of those missing information on SA in terms of effort. The study involved five architecting teams that involve final year undergraduate and graduate students enrolled in the university course on SA, working on architecting a system falls under “banking” domain. Our result shows that, architects did find requirements and requirements attributes’ information missing while architecting. Among requirements information, architects found that, system functionality information, constraints information and system interaction (users/systems) information are missing in requirements at higher percentages. Within requirements’ attributes, architects found requirements priority, dependency and rationale missing at higher percentages. It is also found that, out of total time spent on architecting the system, effort given to recreate missing requirements information is higher for group3 (21.5%), group1 (18%), and group2 (17%) other than group4 (12.37%) and group5(10.18%). [Contribution] The anticipated benefits of the findings are, it can motivate researchers to venture into other areas of software engineering (such as coding, testing, maintenance, etc.) from the view point of missing requirements information and its impact on those areas. This knowledge could help software practitioners to decide what kind of information need to take care of, during RE process, that could possibly ease SA process and later development phases. To the best of my knowledge, this is the first work which focuses on, to what extent requirements and requirements’ attributes information found missing during SA; characteristics and impact of those requirements missing information on SA process in terms of effort

How to Create Personas: Three Persona Creation Methodologies with Implications for Practical Employment

Background: Personas are a technique for enhanced understanding of users and customers to improve the user-centered design of systems and products. Their creation can be categorized using three persona creation methodologies: Qualitative, Quantitative, and Mixed Methods. Despite the apparent differences in these methodologies, no previous review has systemically compared and contrasted the strengths and weaknesses of each of these methodologies for persona development.Method: This manuscript maps and navigates persona literature to identify the benefits and challenges of these three persona creation methodologies. Furthermore, the strategies and opportunities of the different methodologies are presented.Results: The results summarize the strengths and weaknesses of each of the three principal persona creation methodologies and offer suggestions of the benefits of their employment.Conclusion: In conclusion, we offer insights into the construction and usage of personas for practitioners and researchers, and we propose a framework to determine which persona creation methodology is most suitable for a given context.</p