141 research outputs found

    Understanding requirements engineering process: a challenge for practice and education

    Get PDF
    Reviews of the state of the professional practice in Requirements Engineering (RE) stress that the RE process is both complex and hard to describe, and suggest there is a significant difference between competent and "approved" practice. "Approved" practice is reflected by (in all likelihood, in fact, has its genesis in) RE education, so that the knowledge and skills taught to students do not match the knowledge and skills required and applied by competent practitioners. A new understanding of the RE process has emerged from our recent study. RE is revealed as inherently creative, involving cycles of building and major reconstruction of the models developed, significantly different from the systematic and smoothly incremental process generally described in the literature. The process is better characterised as highly creative, opportunistic and insight driven. This mismatch between approved and actual practice provides a challenge to RE education - RE requires insight and creativity as well as technical knowledge. Traditional learning models applied to RE focus, however, on notation and prescribed processes acquired through repetition. We argue that traditional learning models fail to support the learning required for RE and propose both a new model based on cognitive flexibility and a framework for RE education to support this model

    Using protocol analysis to explore the creative requirements engineering process

    Full text link
    Protocol analysis is an empirical method applied by researchers in cognitive psychology and behavioural analysis. Protocol analysis can be used to collect, document and analyse thought processes by an individual problem solver. In general, research subjects are asked to think aloud when performing a given task. Their verbal reports are transcribed and represent a sequence of their thoughts and cognitive activities. These verbal reports are analysed to identify relevant segments of cognitive behaviours by the research subjects. The analysis results may be cross-examined (or validated through retrospective interviews with the research subjects). This paper offers a critical analysis of this research method, its approaches to data collection and analysis, strengths and limitations, and discusses its use in information systems research. The aim is to explore the use of protocol analysis in studying the creative requirements engineering process.<br /

    Perception and enterprise communication networks to improve the requirements elicitation process

    Get PDF
    The requirements elicitation phase of software development projects is characterised by the intensity and importance of communication activities. Requirements elicitation is a traditional exploratory phase in which context is analysed and an abstraction is performed as a consequence. However, exploratory processes are characterised by a deep interaction with environmental factors. In this paper, we present a process for managing communication during the requirements elicitation phase. Our process would help get well-defined requirements by using knowledge inside organisations and a classification of requirements perception based on how environment is controlled by stakeholders. Our approach can be used to guide the elicitation process as well as to validate the requirements.Eje: Procesamiento Concurrente, Paralelo y DistribuidoRed de Universidades con Carreras en Informática (RedUNCI

    Software Project Management: Scenarios of Failure and Potential Solutions

    Get PDF
    This paper provides the project manager (PM) with three (3) scenarios for examining project failure. For each scenario a decision tree is provided. By asking questions about the task, the PM can determine points of failure, and potential remedies. This is intended to be a learning tool and should affect how a PM prepares for his/her next project

    Survey on Software Task Extraction and Navigation

    Get PDF
    In gathering requirement phase of developing software model, knowledge needed by software developer’s is captured in many forms of documentation, basically it is written by different individuals. Whenever developer build a software, he struggles to find the right information in the right form at the right time so to help developers navigate documentation, In this paper we survey various techniques for extracting structured and unstructured data and automatically extracting tasks from software documentation by conceptualizing tasks as specific programming actions that have been described in the documentation. This essential information need to be extracted & annotated automatically which is challenge in software engineering

    Estudio de la Percepción sobre Técnicas de Educción de Requisitos

    Get PDF
    La Ingeniería de Requisitos (IR) es una actividad crucial en el desarrollo de software. La calidad del producto final queda supeditada a la captura de requisitos cuyo éxito depende, en buena parte, de las técnicas de educción utilizadas. Sin embargo, los ingenieros siguen teniendo dificultades para distinguir ventajas y limitaciones entre la gran cantidad de técnicas existentes. En este estudio se utiliza el emparrillado para conocer la percepción de los ingenieros noveles acerca de las técnicas de educción y su comparación con la visión experta. Los resultados, que muestran una sustancial diferencia entre ambas visiones, son la base para la modificación de estrategias formativas. Además, el análisis detallado de las características contextuales de la educción en IR facilitará la selección de la técnica más apropiada para un contexto dado

    Modeling functional requirements using tacit knowledge: a design science research methodology informed approach

    Get PDF
    The research in this paper adds to the discussion linked to the challenge of capturing and modeling tacit knowledge throughout software development projects. The issue emerged when modeling functional requirements during a project for a client. However, using the design science research methodology at a particular point in the project helped to create an artifact, a functional requirements modeling technique, that resolved the issue with tacit knowledge. Accordingly, this paper includes research based upon the stages of the design science research methodology to design and test the artifact in an observable situation, empirically grounding the research undertaken. An integral component of the design science research methodology, the knowledge base, assimilated structuration and semiotic theories so that other researchers can test the validity of the artifact created. First, structuration theory helped to identify how tacit knowledge is communicated and can be understood when modeling functional requirements for new software. Second, structuration theory prescribed the application of semiotics which facilitated the development of the artifact. Additionally, following the stages of the design science research methodology and associated tasks allows the research to be reproduced in other software development contexts. As a positive outcome, using the functional requirements modeling technique created, specifically for obtaining tacit knowledge on the software development project, indicates that using such knowledge increases the likelihood of deploying software successfully

    Requirements and Risk: Singing From the Same Hymn-Sheet

    Get PDF
    Failing to elicit requirements is as much of a risk in the traditional, negative sense as successfully defining requirements is a positive step towards successful systems development. The discipline of risk management has long since had to deal with the spectre of emergent risk and its inherent lack of predictability. Just as risk management considers how any number of vulnerabilities in a system may be exploited by accident or by malicious intent that preys upon exposure to otherwise independent factors, so successful requirements elicitation is beholden to the ability to recognise the need for, and define, derived requirements. In this paper we suggest that risk assessment and requirements elicitation are two manifestations of the same activity: creating trustworthy software. We propose the research and development of a methodology where the two disciplines converge
    corecore