Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników

Znaleziono wyników: 8

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
Wyszukiwano:
w słowach kluczowych:  requirements management
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
1
Content available Ewolucja wymagań w projektach technicznych
PL
Złożoność współczesnych projektów powoduje konieczność ewolucji wymagań, realizowanej w systematyczny sposób, rozumianej jako zarządzanie wymaganiami. Jest to szczególnie istotne w projektach technicznych. W tych projektach należy brać pod uwagę nie tylko aspekty techniczne ale także biznesowe. W pracy zostanie przeanalizowane umiejscowienie zarządzania wymaganiami we współczesnym zarządzaniu projektami.
EN
The complexity of contemporary projects necessitates the evolution of requirements, implemented in a systematic manner, understood as requirements management. This is particularly important in technical projects. In these projects, not only technical but also business aspects should be taken into account. The place of requirements management in contemporary project management will be analyzed in the work.
EN
The purpose of this paper is to study how requirements management could be utilized in connection to a service performance measurement system. Public private partnership (PPP) in Finnish Defence Forces’ (FDF) catering operations is studied as a case example. There are two research questions, which are studied: Firstly, do catering operations create KPI’s, which enable inter- functional co-operation and service development? Secondly, do these KPIs support both efficiency and effectiveness of PPP catering operations? Evidence from the previous studies on the subject indicates that there should be a single “power-by-the-hour” metrics unit, which enables a transparent follow-up of the performancebased operations. This research highlights requirements value in creation of economic efficiency and effectiveness from the end-user point-of view and reciprocal value creation between inter-functional service systems. This research’s results show that focus on portion control can produce information, which enhances inter-functional co-operation between PPP stakeholders.
EN
In this article the authors present the methodology adopted and the results obtained in the first stage of the research encompassing focus group interviews (FGI) about the needs of public transport users in a selected city (Poznan). The elicitation and assessment of the requirements were carried out for three groups of people with disabilities using public transport in the city of Poznań: blind and partially sighted people, deaf and hearing-impaired people, as well as people with locomotor dysfunctions. A study carried out on the basis of a scenario especially designed for the FGI purpose has made it possible to identify barriers for people with disabilities and, consequently, to formulate their pre-trip, on-trip and post-trip requirements when it comes to urban public transport services. The results will be used to construct a questionnaire to be used further on in the project.
PL
W artykule scharakteryzowano podstawowe wymagania występujące w typowym procesie projektowym oraz omówiono zagadnienia zarządzania tymi wymaganiami. Zidentyfikowano kluczowe problemy w definiowaniu i przetwarzaniu wymagań w trakcie projektowania produktu. Zaproponowano koncepcję systemu wspomagającego zarządzanie wymaganiami.
EN
The article describes the basic requirements occurring in a typical design process. The issues of requirements management are discussed as well. The key problems in requirement defining and processing during the product design are identified. The conception of requirements management system is also proposed.
EN
Requirements analysis is a highly critical step in software life-cycle. Our solution to the problem of managing requirements is an embedded domainspecific language with Clojure playing the role of the host language. The requirements are placed directly in the source code, but there is an impedance mismatch between the compilation units and electronic documents, that are the major carriers of requirements information. This paper presents a coverage for this problem.
6
Content available Acquisition of requirements for diagnostic systems
EN
Defining the expected functionality of a designed diagnostic system is the most critical stage of the development process. In general, needs that describe such system can be determined by means of a requirement set pursued by the designed system. One important task during the requirement acquisition process is the problem of requirement management. Specific requirements can be defined based on information from multiple sources, and the acquisition process is reduced to that of a negotiation between a customer and a contractor. However, an immediate application of many well-known software engineering methods is impossible in the case of diagnostic systems. Issues arise due to difficulties in defining a customer in the negotiation process. The proposed approach relies on considering a technical object as a virtual customer in the negotiation process. The customer is represented by an expert system with a knowledge base in the form of a multimodal statement network.
PL
Jednym z najtrudniejszych fragmentów procesu projektowania systemu diagnostycznego jest etap definiowania oczekiwanej funkcjonalności takiego systemu. Potrzeby opisujące taki system mogą być określane za pomocą zbioru wymagań stawianych projektowanemu systemowi. Ważnym zadaniem pojawiającym się w procesie gromadzenia wymagań jest odpowiednie zarządzanie tym procesem. Poszczególne wymagania mogą być definiowane na podstawie wielu źródeł a sam proces ich pozyskiwania zazwyczaj sprowadza się do negocjacji pomiędzy klientem a potencjalnym wykonawcą projektu. Bezpośrednie zastosowanie jednej z wielu znanych metod, rozwijanych w ramach inżynierii oprogramowywania, jest jednak w tym przypadku niemożliwe. Spowodowane jest to przede wszystkim trudnościami w zdefiniowaniu klienta dla procesu negocjacji. Zaproponowano sposób postępowania polegający na rozpatrywaniu obiektu technicznego jako wirtualnego klienta w procesie negocjacji. Klient ten reprezentowany jest przez system doradczy z bazą wiedzy w postaci wielomodalnych sieci stwierdzeń.
7
Content available Improving software systems by Flow Control Analysis
EN
Using agile methods during the implementation of the system that meets mission critical requirements can be a real challenge. The change in the system built of dozens or even hundreds of specialized devices with embedded software requires the cooperation of a large group of engineers. This article presents a solution that supports parallel work of groups of system analysts and software developers. Deployment of formal rules to the requirements written in natural language enables using formal analysis of artifacts being a bridge between software and system requirements. Formalism and textual form of requirements allowed the automatic generation of message flow graph for the (sub) system, called the “big-picture-model”. Flow diagram analysis helped to avoid a large number of defects whose repair cost in extreme cases could undermine the legitimacy of agile methods in projects of this scale. Retrospectively, a reduction of technical debt was observed. Continuous analysis of the “big picture model” improves the control of the quality parameters of the software architecture. The article also tries to explain why the commercial platform based on UML modeling language may not be sufficient in projects of this complexity.
PL
W artykule przedstawiono zastosowanie podejścia ukierunkowanego na architekturę systemu informatycznego w procesie projektowania oprogramowania eksperymentalnego do budowy modeli ścieżek klinicznych. Artykuł przedstawia także wyniki analizy zasadności zastosowania standardów BPMN, GELLO, UML, OCL, XML oraz HL7 w kontekście ich przydatności do modelowania architektury systemu informatycznego. Wybrany zestaw standardów oceniany jest pod kątem uzyskania pożądanych efektów budowy architektury systemu informatycznego oraz tworzenia modeli ścieżek klinicznych w oprogramowaniu eksperymentalnym.
EN
The paper describes the use of an information system architecture-driven approach in the process of experimental software design to build models of clinical paths. This article presents the results of the analysis of the applicability of BPMN, GELLO, UML, OCL, XML, HL7 and GLIF standards in the context of their suitability for modelling system architecture. Selected set of standards is evaluated in terms of obtaining the desired effects of construction of information system architecture and creation of clinical paths models in the experimental software.
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.