Wyniki wyszukiwania - BazTech

1

Formal verification of extension of istar to support big data projects

Djeddi Chabane, Zarour Nacer Eddine, Charrel Pierre-Jean

Computer Science

|

2021

|

T. 22 (3)

321–344

EN

Identifying all of the correct requirements of any system is fundamental for its success. These requirements need to be engineered with precision in the early phases. Principally, late correction costs are estimated to be more than 200 times greater than the cost of corrections during requirements engineering (RE), especially in the big data area due to its importance and characteristics. A deep analysis of the big data literature suggests that current RE methods do not support the elicitation of big data project requirements. In this research, we present BiStar (an extension of iStar) to undertake big data characteris tics such as volume, variety, etc. As a first step, some missing concepts are identified that are not supported by the current methods of RE. Next, BiStar is presented to take big data-specific characteristics into account while dealing with the requirements. To ensure the integrity property of BiStar, formal proofs are made by performing a Bigraph-based description on iStar and BiStar. Fi nally, iStar and BiStar are applied on the same exemplary scenario. BiStar shows promising results, so it is more efficient for eliciting big data project requirements.

2

Extending UML Use Case Diagrams to Represent Non-Interactive Functional Requirements

Iqbal Saqib, Al-Azzoni Issam, Allen Gary, Khan Hikmat Ullah

e-Informatica Software Engineering Journal

|

2020

|

Vol. 14, nr 1

97--115

EN

Background: The comprehensive representation of functional requirements is a crucial activity in the analysis phase of the software development life cycle. Representation of a complete set of functional requirements helps in tracing business goals effectively throughout the development life cycle. Use case modelling is one of the most widely-used methods to represent and document functional requirements of the system. Practitioners exploit use case modelling to represent interactive functional requirements of the system while overlooking some of the non-interactive functional requirements. The non-interactive functional requirements are the ones which are performed by the system without an initiation by the user, for instance, notifying something to the user or creating an internal backup. Aim: This paper addresses the representation of non-interactive requirements along with interactive ones (use cases) in one model. This paper calls such requirements 'operation cases' and proposes a new set of graphical and textual notations to represent them. Method: The proposed notations have been applied on a case study and have also been empirically evaluated to demonstrate the effectiveness of the new notations in capturing non-interactive functional requirements. Results and Conclusion: The results of the evaluation indicate that the representation of operation cases helps in documenting a complete set of functional requirements, which ultimately results in a comprehensive translation of requirements into design.

3

Exploring impact of Requirements Engineering on other it project areas - case study

Jarzębowicz Aleksander, Poniatowska Katarzyna

Computer Science

|

2020

|

T. 21 (3)

273–298

EN

Requirements Engineering (RE) is recognized as one of the most important (yet difficult) areas of software engineering that has a significant impact on other areas of IT projects and their final outcomes. Empirical studies investigating this impact are hard to conduct, mainly due to the great effort required. It is thus difficult for both researchers and industry practitioners to make evidence-based evaluations about how decisions about RE practices translate into requirement quality and influence other project areas. We propose an idea of a lightweight approach utilizing widely-used tools to enable such an evaluation without extensive effort. This is illustrated with a pilot study where the data from six industrial projects from a single organization were analyzed and three metrics regarding the requirement quality, rework effort, and testing were used to demonstrate the impact of different RE techniques. We also discuss the factors that are important for enabling the broader adoption of the proposed approach.

4

Delta analyzer: tool-based evaluation of modified requirements for an efficient development effort estimation in the RFQ process

Zichler Konstantin, Ritter Felix, Schul Aaron, Helke Steffen

Annals of Computer Science and Information Systems

|

2019

|

Vol. 19

59--66

EN

Once an automotive OEM decided to source a new component, a Request for Quotation (RFQ) is send to potential suppliers. Among other documents the RFQ contains a Component Requirements Specification (CRS), which describes the properties of the desired component. As a next step, the supplier has to evaluate the requirements and other boundary conditions of the RFQ and to provide an offer to the OEM. In case the supplier already developed a similar component in the past, it is possible to compare the CRS of the predecessor product with the actual CRS, to estimate the additional development effort. This activity is known as the delta analysis. Since no sufficient tool support is offered, this activity is still a predominantly manual task. The main challenge arises from the fact, that specification documents within the RFQ are provided in different office formats, written by different authors and therefore cannot be compared automatically with the CRS from the predecessor product. In our previous work, we presented the Requirements to Boilerplates Converter (R2BC), which automatically converts random natural language requirements into a predefined syntax. The aim of the approach is to facilitate a subsequent toolbased delta analysis. Consequently, we hereby introduce our proprietary developed Delta Analyzer (DA). This tool is based on Natural Language Processing (NLP) and allows to compare automatically two random specification documents. Moreover, the DA prioritizes requirements deltas according to their impact on development effort. As an output of the DA requirements engineers receive a delta report, which outlines the major differences between the requirements of the two CRS.We validate our approach by experiments on real-life specification documents.

5

A survey on identifying and addressing business analysis problems

Jarzębowicz A., Marciniak P.

Foundations of Computing and Decision Sciences

|

2017

|

Vol. 42, No. 4

315--337

EN

Despite the growing body of knowledge on requirements engineering and business analysis, these areas of software project are still considered problematic. The paper focuses on problems reported by business analysts and on applicability of available business analysis techniques as solutions to such problems. A unified set of techniques was developed on the basis of 3 industrial standards associated with IIBA, REQB and IREB certification schemes. A group of 8 business analysts was surveyed to list problems they encounter in their work and to assess their frequency. Selected problems were further analyzed and most suitable techniques were proposed to address them. These proposals were validated through follow-up discussions with business analysts. The main results of research reported in this paper are: the comparative analysis of techniques included in IIBA, REQB and IREB standards and the list of problems reported by practitioners associated with techniques suggested as effective solutions.

6

Evaluation of product design analyses for the identification of perception-defining characteristics

Steinberg F., Woll R.

Management and Production Engineering Review

|

2015

|

Vol. 6, No. 2

45--55

EN

In most cases, customers evaluate a product based on the first impression, which is propagated by the product itself. These impressions are often subjectively engraved in the products, difficult to describe thus making them difficult to handle. Technical specifications on the other hand are less considered at first sight. In the case of leisure products such as Motorbikes (motorcycles), subjective factors are considerably intensified. Thus, such products are suitable to describe as “difficult-to-quantify” characteristics. Subjective and difficult to quantify features for products such as motorcycles could be; the design, the dynamics (vitality) as well as the price (value) impression. Thus, amid a DFG research project, a method will have to be developed that allows the scaling of difficult to quantify characteristics in other to support a requirement-orientated product development. For this purpose, four different levels were developed to contain scaling based on usage. To support the scaling development, methods such as the AHP or the Multivariate Analysis Method can be used. In the following analysis it will be shown how perception-defining characteristics for motorcycles can be derived from design analyses. The first step is the design analyses conducted with the help of the analytic hierarchy process (AHP) scale based on Thomas L. Saaty. The advantage of this approach is a direct comparison of all alternatives to themselves. If, for example, five motorcycles are compared with regards to design, then a benchmark for good design implicitly arises. These scales build up dynamically depending on the analyzed alternatives. Based on the previous example, the more alternatives are used the more valid the scale. The systematic arrangement of the perception-defining characteristics in product development can be a deciding factor for a better product design and its related product perception. Special gender specific perception differences for motorcycles will be evaluated in this paper. Thus, it is shown that there are specific motorcycle models that appeal to women while other specific models are preferred by men. In this case, perception-defining characteristics can be derived from a detail analysis of a preliminary assessment which can aid the description of female and male preferences for motorcycles. In this paper a method to concatenate the perception-defining characteristics and products will be presented. Above all, these characteristics should be considered in the product planning phase. This approach offers producers the possibility, through identification of important perception-defining characteristics, to differentiate themselves from competitors because important product characteristics are deigned to relate to the various target groups.

7

Designing of the Diagnostic Systems Based on the Sets of Requirements

Amarowicz M.

Machine Dynamics Research

|

2015

|

Vol. 39, No. 1

125-134

EN

The article deals with the problem of designing the project of the diagnostic systems. The main attention was paid to the fact, that the overall design process can be improved by using the set of requirements, that are commonly used during the implementation of the software projects. The two main stages of proposed approach i.e. gathering and evaluation of set of requirements are described in this article. These stages can be realized by using the specialized expert system. The elaborated expert system and the example of using the proposed design approach are also presented in this article.

8

Diagnostic systems design process with using the sets of requirements

Amarowicz M.

Diagnostyka

|

2014

|

Vol. 15, No. 2

19--26

EN

The article deals with the problem of designing diagnostic systems. During this process it is possible to use sets of requirements which are very commonly used in the software area. The requirements may influence both on the set of possible solutions of diagnostic system as also on the set of criteria which will be used for evaluation of these solutions. Selecting an optimal solution is not an easy task, especially for given the nature of the diagnostic field. But this process can be improved by using expert system. Knowledge base of this system, which contains possible solutions of designed system can be recorded in the form of multimodal statement networks. During the inference process, it is possible to isolate some subset of preferred solutions. This process should be carry out based on available information about technical object, operational conditions and imposed project limitations. The received subset of solutions should be the basis for further analysis, which leads to get the final solution of a diagnostic system.

PL

Artykuł opisuje problematykę projektowania systemów diagnostycznych. Zwrócono uwagę, że podczas przeprowadzania takiego procesu możliwe jest wykorzystanie zbiorów wymagań powszechnie stosowanych w obszarze inżynierii oprogramowania. Wymagania mogą mieć wpływ zarówno na postać definiowanego zbioru możliwych rozwiązań projektowanego systemu, jak również na zbiór kryteriów, względem których rozwiązania te będą oceniane. Proces wyboru rozwiązania optymalnego z powodu specyfiki dziedziny jaką jest diagnostyka techniczna nie jest zadaniem łatwym. Może być on usprawniony poprzez wykorzystanie systemu doradczego. Baza wiedzy tego systemu zawierająca możliwe rozwiązania projektowanego systemu diagnostycznego może być zapisana pod postacią wielomodalnych sieci stwierdzeń. W wynik procesu wnioskowania na podstawie dostępnych informacji o obiekcie technicznym, warunkach jego pracy oraz narzuconych ograniczeniach projektowych wyodrębniany jest pewien podzbiór rozwiązań preferowanych. Są one podstawą dalszej analizy, w wyniku której opracowywany jest ostateczny projekt systemu diagnostycznego.

9

Managing DO-178 compliance with IBM Rational platform. Leverage state-of-the-art best practices to develop avionics software

Çakmak M. K.

Journal of KONBiN

|

2013

|

No. 1 (25)

59--74

EN

DO178 is a standard for avionic software for the aerospace industry which can be used as a guidance to determine if the software product will perform reliability in airborne environment. The standard has 5 different certification levels each of which has a certain set of objectives. The certification levels are determined depending on how critical the system or subsystem is. To address DO-178 objectives, companies need a defined systems and software engineering process that can delineate workflows, inputs, outputs, roles and responsibilities. The major objectives outlined in the DO-178 standard include; Requirements engineering Design and development. Validation and verification Engineering tasks, such as configuration and change management In this presentation, we will try to explain the main principles of the DO178 standard very briefly and try to give an insight about how the objectives of this standard can be satisfied.

PL

DO-178 jest normą dla oprogramowania awionicznego dla przemysłu lotniczego, która może być stosowana w charakterze wytycznych w celu ustalenia, czy oprogramowanie będzie wykazywać niezawodność w środowisku lotniczym. Norma ma pięć różnych poziomów certyfikacji, z których każdy ma określony zestaw celów. Poziomy certyfikacji są ustalone w zależności od tego, na ile krytyczny jest system lub podsystem. W celu spełnienia celów DO-178 przedsiębiorstwa potrzebują zdefiniowanych systemów i procesu tworzenia oprogramowania, które mogą prezentować przebiegi procesów, wartości wejściowe, wyjściowe, role i zakresy odpowiedzialności. Główne cele nakreślone w normie DO-178 obejmują: ustalenie wymagań, projektowanie i rozwój, walidację i weryfikację, zadania inżynierskie, takie jak konfiguracja i zarządzanie zmianami. W niniejszej prezentacji spróbujemy wyjaśnić w skrócie główne zasady normy DO-178 oraz sposób, w jaki cele tej normy mogą zostać spełnione, a odpowiednie poziomy certyfikacji osiągnięte dla tworzonego systemu lub podsystemu. and the relevant certification level can be achieved for a system or subsystem under development.

10

User requirements for mission-critical application - the SECRICOM case

O'Neill S., Strother J., Zych J., Wojciechowicz W.

Technical Sciences / University of Warmia and Mazury in Olsztyn

|

2012

|

nr 15(1)

81-99

EN

The SECRICOM Project as a communication system for operational crisis management, requires paying significant attention to the requirements engineering phase. Any mistakes made during the requirements gathering phase may affect the subsequent software development phases, which creates excessive operational risks for the users of the system. These types of risks - as in any other critical systems - could have serious consequences, such as inefficiency of rescue actions and loss of lives. This article presents the requirements engineering process, which was defined and carried out for the needs of the SECRICOM project. It describes the system's environment (the crisis management reference structure and the main organizational rules) and its impact on the developed. As a result, a requirements engineering process for SECRICOM is proposed. Finally, main points of gathered requirements are presented.

PL

W systemie SECRICOM, ze względu na tworzenie systemu komunikacji do operacyjnego zarządzania kryzysowego, szczególnie ważne było położenie szczególnego nacisku na etap gromadzenia wymagań. Błędy popełnione na etapie specyfikacji wymagań mogą rzutować na kolejne etapy wytwarzania systemu, co w rezultacie generuje nadmiarowe ryzyka dla użytkowników systemu. Ryzyka te - jak w przypadku innych systemów krytycznych - mogą spowodować poważne konsekwencje, w tym obniżenie skuteczności akcji ratunkowych, a nawet straty po stronie ludności. W artykule przedstawiono proces inżynierii wymagań, który zdefiniowano oraz przeprowadzono na potrzeby projektu SECRICOM. Przedstawiono środowisko systemu (zarówno referencyjną strukturę zarządzania kryzysowego, jak i główne zasady organizacji) oraz określono wpływ na budowany system. Na zakończenie przedstawiono główne wnioski z zebranych wymagań.

11

Analiza porównawcza witryn internetowych w skali pomiarowej HHS

Pieczyński S., Susłow W.

Pomiary Automatyka Kontrola

|

2012

|

R. 58, nr 5

475-479

PL

Artykuł przedstawia technikę analizy porównawczej jako narzędzie inżynierii wymagań. Wytyczne HHS tworzą obiektywną porządkową skalę pomiarową, przydatną do porównywania jakości użytkowej witryn internetowych o zbliżonej tematyce. Kompletowanie zestawu wytycznych zgodnie z celem analizy zwiększa praktyczne znaczenie uzyskiwanego rankingu witryn internetowych. Technika analizy porównawczej opartej o skalę pomiarową HHS okazała się skuteczna w ramach projektów dydaktycznych i kwalifikacyjnych.

EN

This paper presents a comparative analysis technique as a tool for requirements engineering. HHS guidelines form an objective ordinal measuring scale which is useful for comparing the usability of web-sites with similar themes. Each guideline is described in a study using the relative weights (called Relative Importance) and probative force (called Strength of Evidence). Completing a set of guidelines in accordance with the objective of the project increases practical significance of the obtained ranking of IT products. The comparative analysis technique based on the measuring scale HHS proved to be effective for qualification projects. Section 2 of the paper describes a set of guidelines and a grading scale of HHS. Section 3 presents the authors' proposal concerning the order of selection guidelines for a particular study (see Fig. 1). Section 4 describes a case study on the comparative analysis of selected music vortals in the master's diploma project (it was the pioneering work for the Department of Electronics and Computer Science of the Koszalin University of Technology).

12

Prerequisites for Effective Requirements Management

Grzanek K.

Journal of Applied Computer Science Methods

|

2012

|

Vol. 4 No. 1

21--28

EN

Despite an undeniable progress in the whole software creation process, software development is still more art than science. The requirements analysis is a highly critical step in the software life-cycle. Requirement managements errors are the most common errors in the software projects. The proper and effective requirements management saves the overall project costs. The key motivation behind this work was opening a way of finding approaches to managing the requirements appearing in such large software projects as compilers for various programming languages. This paper is an introduction to a full presentation of requirements management solution in which the requirements and implementation information is placed directly in the source code. We concentrate on describing a context in which the requirements management process takes place, trying to present the most interesting existing solutions, indicating the problems and opening a discussion on what ways to follow in the future scientific research.

13

Inżynieria wymagań w metodach Agile

Lipski A.

Biuletyn Instytutu Systemów Informatycznych

|

2010

|

nr 5

47-53

PL

"Zwinne" wytwarzanie oprogramowania (Agile Software Development) stało się bardzo popularne na przestrzeni kilku ostatnich lat. Metody Agile zostały wymyślone w celu szybszego dostarczenia działającego oprogramowania do klienta oraz dostosowania się oprogramowania do zmiennych potrzeb klienta. Można zauważyć, że istnieje wiele technik i praktyk wymyślonych oraz opracowanych w kontekście tradycyjnej inżynierii wymagań, które obecnie wykorzystywane są z dobrym rezultatem przez metody Agile. Celem tego artykułu jest pokazanie, w jaki sposób techniki inżynierii wymagań są wykorzystywane przez metody Agile oraz w jaki sposób metody te mogą być udoskonalone za pomocą tych technik.

EN

Agile Software Development approaches have become increasingly popular during the last few years. Agile practises have been developed with the aim to deliyer software faster and to ensure that the software meets changing needs of customers. We can find out that there are a lot of practices and approaches which are created and developed in context of traditional Requirements Engineering and which are used by Agile methods with a good result. The goal of this article is to show how the Requirements Engineering technics are used by Agile methods and how this methods can be improved by them.

14

Handling Inconsistency In Distributed Software Requirements Specifications Based On Prioritized Merging

Mu K., Jin Z., Yue A., Liu W., Lu R., Bell D.

Fundamenta Informaticae

|

2009

|

Vol. 91, nr 3-4

631-670

EN

Developing a desirable framework for handling inconsistencies in software requirements specifications is a challenging problem. It has been widely recognized that the relative priority of requirements can help developers to make some necessary trade-off decisions for resolving conflicts. However, for most distributed development such as viewpoints-based approaches, different stakeholders may assign different levels of priority to the same shared requirements statement from their own perspectives. The disagreement in the local levels of priority assigned to the same shared requirements statement often puts developers into a dilemma during the inconsistency handling process. The main contribution of this paper is to present a prioritized merging-based framework for handling inconsistency in distributed software requirements specifications. Given a set of distributed inconsistent requirements collections with the local prioritization, we first construct a requirements specification with a prioritization from an overall perspective. We provide two approaches to constructing a requirements specification with the global prioritization, including a merging-based construction and a priority vector-based construction. Following this, we derive proposals for handling inconsistencies from the globally prioritized requirements specification in terms of prioritized merging. Moreover, from the overall perspective, these proposals may be viewed as the most appropriate to modifying the given inconsistent requirements specification in the sense of the ordering relation over all the consistent subsets of the requirements specification. Finally, we consider applying negotiation-based techniques to viewpoints so as to identify an acceptable common proposal from these proposals.

15

Aspects of the management of software-product line development processes

Philippow I.

Management

|

2003

|

Vol. 7, no 1

171-181

EN

Similar to common technical productlines (e.g. for cars, electronical devives a.s.o.) software product lines are supposed to enable the effective automated production of similar software products. Software productlines consist of a core and varible fetures that have to be integrated into a new product based on the order of a particular customer. Different to common software production for the maintanance and adaptation of a software product line to new occuring customer requirements the development process has to be considerd as an evolutionary process that is very strong depending from the requirements engineering phase and a datamodel for the management of activities. In particular the data model has to allow tracability of requirements, former design and implementation decisions and the dependencies of new and old requirements. In the paper a proposed datamodel is introduced in connection to the necessary product line dvelopment process that supports the evolotionary product line development process. Furthermore, the different views and roles of the people involved in the development project are discussed and have to be taken into consideration by the datamodel. Using this datamodel it should be possible to avoid a loss of quality of the fundamental product line architecture and the destroying of the prouctline during the adaptation to new requirements.