3,437 research outputs found

    Requirements engineering for business workflow systems: a scenario-based approach

    Get PDF
    Workflow implementations require a deep understanding of business and human cooperation. Several approaches have been proposed to address this need for understanding, but largely in a descriptive way. Attempts to use them in software development have had mixed results. The work reported here proposes that these approaches can be used in a generative way, as part of the requirement engineering process, by (a) extending requirements engineering modelling techniques with underlying cooperation properties, (b) integrating these techniques through the use of a derivation modelling approach, and (c) providing pragmatic heuristics and guidelines that support the real-world requirements engineering practitioner to ensure a high probability of success for the business workflow system to be developed. This thesis develops and evaluates a derivation modelling approach that is based on scenario modelling. It supports clear and structured views of cooperation properties, and allows the derivation of articulation protocols from business workflow models in a scenario-driven manner. This enables requirements engineering to define how the expectations of the cooperative situation are to be fulfilled by the system to be built - a statement of requirements for business workflow systems that reflects the richness of these systems, but also acts as a feasible starting point for development. The work is evaluated through a real-world case study of business workflow management. The main contribution of this work is a demonstration that the above problems in modelling requirements for business workflow systems can be addressed by scenario-based derivation modelling approach. The method transforms models through a series of properties involving cooperation, which can be addressed by using what are effectively extensions of current requirements engineering methods

    Semantics of trace relations in requirements models for consistency checking and inferencing

    Get PDF
    Requirements traceability is the ability to relate requirements back to stakeholders and forward to corresponding design artifacts, code, and test cases. Although considerable research has been devoted to relating requirements in both forward and backward directions, less attention has been paid to relating requirements with other requirements. Relations between requirements influence a number of activities during software development such as consistency checking and change management. In most approaches and tools, there is a lack of precise definition of requirements relations. In this respect, deficient results may be produced. In this paper, we aim at formal definitions of the relation types in order to enable reasoning about requirements relations. We give a requirements metamodel with commonly used relation types. The semantics of the relations is provided with a formalization in first-order logic. We use the formalization for consistency checking of relations and for inferring new relations. A tool has been built to support both reasoning activities. We illustrate our approach in an example which shows that the formal semantics of relation types enables new relations to be inferred and contradicting relations in requirements documents to be determined. The application of requirements reasoning based on formal semantics resolves many of the deficiencies observed in other approaches. Our tool supports better understanding of dependencies between requirements

    Aplicando una estrategia de mejora que incluye conceptos de requisitos funcionales y no funcionales

    Get PDF
    Organizations should set and reach business goals for varied purposes using the suitable strategies. Basically, a strategy specifies the activities, methods and another related resources that should be considered in order to achieve a given goal purpose. Goal purposes and their associated strategies can aim at evaluating, testing, developing, or maintaining some entity. Some concrete evaluation purposes such as to understand or monitor can be achieved by strategies embracing non-functional requirements definition, measurement, evaluation and analysis activities. Other specific evaluation purposes such as to improve or control also imply changing the target entity; therefore, strategies should embrace functional requirements definition activities as well. Moreover, specific development and maintenance purposes always involve functional requirements. In this work, we relate business and information need goals with functional and nonfunctional requirements concepts, which are paramount for well-defined strategies. Therefore, we specify vocabularies for them, and illustrate the applicability of an improving strategy –which embeds these concepts- in the context of a running example. Having well-structured vocabularies serving as common ground for diverse strategies may promote a more effective operationalization of projects dealing with evaluation, testing, development and maintenance goal purposes.Las organizaciones deben establecer y alcanzar metas de negocio para diferentes propósitos utilizando las estrategias adecuadas. Básicamente, una estrategia especifica las actividades, los métodos y los recursos relacionados que deben considerarse para lograr un determinado propósito. Los propósitos de las metas y sus estrategias asociadas pueden apuntar a la evaluación, prueba, desarrollo o mantenimiento de alguna entidad. Algunos propósitos específicos de evaluación, como comprender o monitorear, pueden lograrse mediante estrategias que abarcan actividades de definición de requisitos no funcionales, medición, evaluación y análisis. Otros propósitos de evaluación, como mejorar o controlar, implican además cambiar la entidad o su contexto; por lo tanto, las estrategias también deben incluir actividades de definición de requisitos funcionales. En cuanto a los propósitos específicos de desarrollo y mantenimiento, estos siempre implican requisitos funcionales. Este trabajo relaciona las metas de negocio y de necesidad de información con conceptos de requisitos funcionales y no funcionales, que son fundamentales para estrategias bien definidas. Por lo tanto, especificamos sus vocabularios e ilustramos la aplicabilidad de una estrategia de mejora –la cual embebe estos conceptos- mediante un ejemplo que desarrollamos a lo largo de las secciones. Tener vocabularios bien estructurados que sirvan de base común para diversas estrategias puede promover una operacionalización más efectiva de los proyectos que tienen que ver con propósitos de metas de evaluación, prueba, desarrollo y mantenimiento.Facultad de Informátic

    Requirements Elicitation from BPMN Models

    Get PDF
    Tarkvarasüsteemi loomiseks on väga oluline mõista, millised on tegelikud vajadused ja nende rahuldamist takistavad piirangud. Nõuete tuvastamise käigus õpitakse tundma ümbritsevat keskkonda ja tehakse kindlaks kasutajate ning teiste osapoolte vajadused. Üheks peamiseks kohaks, kust nõudeid leida, on hetkel kasutatavad süsteemid (protsessid, organisatsioon, keskkond ja kasutatavad infosüsteemid). Kasutusel olevaid protsesse kujutatakse tihti graafiliselt mudelitena ja need mudelid kujutavad endast väga olulist informatsiooniallikat nõuete tuvastamisel. BPMN mudelid on saanud väga populaarseks ja neid kasutatakse tihti süsteemide kirjeldamiseks, kuid vaatamata sellele, et nad on väärtuslikud teadmiste allikad, kasutatakse neid nõuete tuvastamisel siiski harva. Üheks selliseks põhjuseks on asjaolu, et puuduvad konkreetsed ja põhjalikud juhised, mis aitavad süstemaatiliselt mudelist nõudeid tuvastada. Selles töös esitletakse meetodit funktsionaalsete nõuete tuvastamiseks BPMN mudelitest. Meetod läbib süsteemselt kõiki nõude komponente ja annab juhised, kuidas BPMN mudelist komponendi kohta informatsiooni leida ning annab lisaks kogumi küsimusi, mida valdkonna spetsialistidele esitada, et nõue oleks põhjalik, järjepidev, piiritletud ja nõutava detailsusega. Loodud meetodit rakendati ka juhtumiuuringu käigus ja tõestati, et uus meetod on rakendatav ning on struktureeritud lähenemine nõuete tuvastamiseks. Meetod tuvastas rohkem nõudeid kui meetod, mis oli algselt kasutusel juhtumi organisatsiooni poolt ja tuvastatud nõuded olid ka parema kvaliteediga. Meetodi rakendamine võttis märkimisväärselt vähem aega, tuvastamise protsess oli hästi kontrollitav, see võimaldas täpsemalt hinnata tuvastamisele kuluvat aega ja seeläbi on meetodit kasutades lihtsam protsessi planeerida ja ülesandeid delegeerida.When building a software system, it is crucial to understand the actual needs and the interfering constraints that apply in the surrounding environment. Elicitation of requirements is all about learning the environment and discovering the needs of users and other stakeholders. One of the primary sources for requirement elicitation is the system (processes, organization, environment and legacy systems) currently being used. The system is often captured in the form of graphical models, which are an important source of information for requirements elicitation. BPMN models are gaining popularity and are frequently used to model systems. Despite the fact that they are a valuable source of knowledge, they are rarely used as a source for eliciting requirements. One reason for this is the lack of concrete and comprehensive guidelines that would assist a systematic requirements elicitation from such models. This thesis presents a method for eliciting functional requirements from BPMN models. The method covers all components of a requirement and gives guidelines where in the BPMN model the information about the components can be found. It also provides a set of questions to be asked from domain experts to make sure that the requirement specification is complete, consistent, bounded and on the required level of granularity. The method was applied on a case study and it was proved that the method is applicable and provides a structured approach to eliciting requirements. The method elicited more requirements than the method previously used by the case organization, and the elicited requirements were also of better quality. The method took considerably less time to apply, it gave better control over the elicitation process, it was easier to evaluate the needed effort, and it enabled to better plan the process. The structured approach makes it easier to delegate work, and there are less situations where something might be overlooked

    Towards a Systematic Propagation of Evolution Requirements in IS Adaptation Projects

    Get PDF
    Information system adaptation is a type of system evolution that can be managed defining evolution requirements as a set of gaps with the current system. Today, most Requirements Engineering approaches for system evolution guide the modification of requirements, but very few tell how the required modifications can be elicited or even specified as such in a requirements document. This paper proposes an approach that facilitates the search and expression of evolution requirements. It advocates a business driven approach to align system adaptations to the objectives of the changing organisation. The approach is presented, then and illustrated it with an example

    Evaluation of the Goal-Oriented Requirements Engineering Method KAOS

    Get PDF
    Software engineering is a complex task. But although there is no silver bullet that guarantees accomplishing this task, appropriate methods can support the engineer by addressing the characteristics that make it complex. The objective of this paper is to evaluate whether and how the goal-oriented requirements engineering method KAOS addresses these characteristics of complex tasks and thereby, whether it effectively supports software engineering. For serving this purpose, we conduct a literature analysis, which discloses core concepts underlying to the KAOS method, and we apply KAOS in two software development projects, which provide insights into KAOS in use. Our results show that KAOS, despite of some shortcomings, addresses all characteristics, but that applying it can be work intensive. Consequently, while KAOS supports software engineering, provided support must be weigh up against invested work
    corecore