Identifikasi Karakteristik Kualitas Menggunakan Pendekatan TCM Berbasis Kebutuhan Fungsional

Defining quality requirements is an important activity in the development of software because quality requirements describe how well the software can be implemented. In this study will propose an approach to make improvements the specification of quality characteristics software using a spectrum analysis by utilizing the TCM (Term-Characteristic Mapping) method, in this method also utilize algorithms RabinKarp used to perform mapping between the list of term with functional requirements written in the software requirement specification documents. for testing phase its used 167 term of quality and 22 subcategories quality characteristics and uses two software requirement specification documents that will appear the quality characteristics. Results from this study is a list of quality characteristics that appear along with the value of its appearance in the functional requirements are analyzed.Keywords—quality requirements, TCM, RabinKarp, quality characteristic

NL-based automated software requirements elicitation and specification

This paper presents a novel approach to automate the process of software requirements elicitation and specification. The software requirements elicitation is perhaps the most important phase of software development as a small error at this stage can result in absurd software designs and implementations. The automation of the initial phase (such as requirement elicitation) phase can also contribute to a long standing challenge of automated software development. The presented approach is based on Semantic of Business Vocabulary and Rules (SBVR), an OMG’s recent standard. We have also developed a prototype tool SR-Elicitor (an Eclipse plugin), which can be used by software engineers to record and automatically transform the natural language software requirements to SBVR software requirements specification. The major contribution of the presented research is to demonstrate the potential of SBVR based approach, implemented in a prototype tool, proposed to improve the process of requirements elicitation and specification

Requirement patterns: an approach for streamlining requirements engineering in software product families

Reusable structure is essential in all reuse-based software development processes. This provides a solid foundation for seamless management of reusable artefacts especially in software product line engineering (SPLE). One of the potential benefits provided by a well-defined structure is systematic reuse of these artefacts. Requirements pattern approach provides guidelines for requirement engineers to reuse and specify requirements. Although a plethora of research on requirements pattern have been reported in the literature, no research available focuses on requirement engineering (RE) activities of SPLE. In this paper, we present an anatomy of software requirement pattern (SRP) for SPLE with a structured example from e-learning domain. To enable practitioners, understand the concept of requirement pattern more, we present a meta-model for the SRP concepts and their relationships. In addition, we describe how the requirement pattern approach, streamlines RE activities, design for and with reuse in both domain and application engineering processes of SPLE. The requirement pattern approach thus helps in achieving systematic requirements reuse (RR) and generation of structured software requirement specification (SRS) for individual applications

Object-Oriented Analysis: A Decision-Driven Approach

Recently, many object-oriented analysis and design approaches (OOADs) have been proposed. This research boom may be attributed to the success of applying object-oriented programming (OOP) in embedded systems and systems software. However, object-oriented analysis (OOA) does not seem as successful as object-oriented design (OOD) or OOP [3]. Whereas the extant OOADs claim to perform systems analysis, this goal is seldom fulfilled [3]. Systems analysis consists of two kinds of activities: requirement analysis (problem analysis) and requirement specification (product description) [1]. During therequirement analysis, analysts aim to understand the problem and identify all possible constraints on the problem\u27s solution through observations, interviews, and discussions with experts in the problem domain. The requirement analysis activity analyzes the requirement space of a problem domain. Here, the requirement space is defined as the range of all possible user needs and constraints in a problem domain. Requirement specification, on the other hand, is intended to resolve conflicting views, to eliminate inconsistencies and ambiguities, and to document some particular requirement which describes the expected behavior of the future system. As Hoydalsvik et al [3] indicate, the extant OOADs are target-system oriented. A target-system oriented OOA aims to construct an object -oriented system and represents the requirement in a way more consistent with the design issues than with the users\u27 perception of the problem domain. In other words, it concentrates on a solution and not on understanding the problem. Finding objects and classes is the prevalent trend in the pure OOA. However, as Rubin et al [5] note, there are several problems in searching for objects: 1) The availability of a written requirement specification is usually assumed. Assuming a narrative specification is accessible, an OOAD searches for nouns as objects and for verbs as methods. This approach ignores that a written specification is barely available; even if it is available, ambiguities of text, synonyms, and homonyms are not unusual, 2) there is a strong bias toward the tangible aspects of a problem, and 3) it tends to incorporate all tangible objects of the analysis results. In order to address these shortcomings, an OOA approach should include a systematic procedure to understand the problem and the organization before finding the objects. Decision making is a major activity of an organization [6]. This article proposes a decision-driven OOA approach, which consists of a set of well-organized guidelines and procedures, focuses on the understanding of organizations through the analysis of decision making, and helps derive requirement specification in the form of object models. In particular, this article aims to address the following issues: •What decision making model is more appropriate for understanding the organization? •What aspects of decision making should be captured for understanding the organization? •What steps should an OOA approach have? •What mechanisms can help verify and validate the process of OOA?We will briefly review several OOADs in the next section. The proposed approach will be discussed in the following sectio

Towards Model Driven Architecture in Health Care Information System Development

Failed software projects are often the result of an unsystematic transfer of business requirements to the implementation. This deficit led to the specification of the Model Driven Architecture (MDA). It claims a consistent use of conceptual models for the software development process from requirement analysis to technical specification of software. The MDA reduces the gap between the business level and the information technology (IT) level by defining a methodological framework to link these levels (Business-IT alignment). We will present the use of an MDA in health care domain. For this purpose, we show how the paradigm of MDA can be configured to implement medical application software based on a telemedical IT platform (telehealth platform). Additionally to the conceptual structure of the developed approach and the domain-specific alignment, lessons learned from the experiences gathered during design process will be formulated as assistance for similar projects and substantiated with an exemplary application

Requirements patterns structure for specifying and reusing software product line requirements

A well-defined structure is essential in all software development, thus providing an avenue for smooth execution of the processes involved during various software development phases. One of the potential benefits provided by a well-defined structure is systematic reuse of software artifacts. Requirements pattern approach provides guidelines and modality that enables a systematic way of specifying and documenting requirements, which in turn supports a systematic reuse. Although there is a great deal of research concerning requirements pattern in the literature, the research focuses are not on requirement engineering (RE) activities of SPLE. In this paper, we proposed a software requirement pattern (SRP) structure based on RePa Requirements Pattern Template, which was adapted to best suit RE activities in SPLE. With this requirement pattern structure, RE activities such as elicitation and identification of common and variable requirements as well as the specification, documentation, and reuse in SPLE could be substantially improved

Development of Unified Framework for Discovery and Negotiation Requirement for new services in Service Oriented Architecture

Service oriented architecture is a style of software design where services are provided to the other component through a communication protocol over a network. It is an emerging approach that addresses the requirement of loosely coupled, standards based and protocol independent distributing computing. To Build an SOA a highly distributable communication and integration backbone is required. In this paper, Authors presents the unified framework for discovery and negotiation requirement for new services in Service Oriented Architecture. Specially, this paper also address the issue to negotiate and search the new services, differentiating between several old services and the new services that are similar but not identical based on specification

Model-Based Systems Engineering in Mobile Applications

An efficient system development needs reuse, traceability and understanding. Today, specifications are usually written in text documents. Reuse means a copy and paste of suitable specifications. Traceability is the textual note that references to affected requirements. Achieving a full context understanding requires reading hundreds of pages in a variety of documents. Changing one textual requirement in complex systems can be very time-consuming. Model-based systems engineering (MBSE) addresses these issues. There, an integrated system model is used for the design, analysis, communication and system specification and shall contribute to handling the system complexity. This paper shows aspects of this approach in the development of a wheel loader\'s attachment system. Customer requirements will be used to derive a specification model. Based on this, the author introduces the system and software architecture. The connection between requirement and architecture leads to a traceable system design and produces the huge advantage of MBSE