No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
The Harmony in Rechoirments
Abstract
The true essence of requirements, is trying to understand a customer's needs. This is true when building custom or mass-marketed software (or systems). Requirements involves more than knowing how to analyze using the latest method such as structured whatever or object-oriented whatever, or knowing how to specify systems using finite-state machines or Petri nets, or knowing how to program in a specification language such as Z. A person involved in requirements needs human skills, communication skills, understanding skills, feeling skills, listening skills-so that he/she can function in the setting as harmoniously as a seasoned choir member. Tactical skills such as interviewing, brainstorm facilitation, information organization, and formal specification can improve one's effectiveness. But these are relatively useless if a person does not have the most basic skills: listening, open-mindedness, feeling, compassion, and caring.
... The proposed model was not applied and tested due to the fact that not all process activities of the EasyWinWin process have been modeled in details. Requirements, in essence, can be said to be the embodiment of everything a user values A.M. Davis 1998 [17]. The successful elicitation of these values, however, demands an understanding of the specific problem and its context, in which the requirements are embedded-both locally and in the wider organisation. ...
Requirements elicitation (RE) phase is very critical and crucial to the success of IS projects in
telecommunication sector. RE elicits and transforms the stakeholders’ desired system into
reality, through direct and indirect interaction with the system analyst. Unfortunately, this phase
of IS projects development is subject to a large degree of errors, influenced by key factors rooted
in the applied communication techniques, which results in a requirement conflicts that widen the
gap of what is being build and what is being desired by the stakeholders. The issues manifest in
the form of communication barriers between the system analyst and stakeholders has a major
impact on preventing the achievements of the shared understanding state, which results in a
failure of many IS project [1]. The aim of this paper is to present a Requirements conflict
resolution and communication model to address the lack of a systematic mechanism to quantify
the communication obstacles and to classify the requirements conflicts in the RE phase. The
proposed model will pre scan the stakeholder’s technical background and articulation level for
the preference of better communication mode selection by the system analyst. Moreover, the
selected elicitation technique will embed the proper knowledge transfer preference to facilitate
the transitions of knowledge between the system analyst and the stakeholder in a structured way
which grantees the level of authenticity to overcome the issues of inappropriate requirements.
Furthermore, the model will introduce the Resistance Resolution Protocol to insure the
stakeholder’s involvement in the RE phase. Lastly, the model will introduce the conflict
detection and resolution mechanism based on the normalized cross correlations function
(NCCF), standard deviation (SD) and the standard error (SE) functions to detect and quantify the
conflicted requirements based on the calculation of the requirements correlations and accuracy.
The proposed model will overcome the reoccurring issues of the requirement elicitation phase.
... − La fase di analisi dei requisiti, benché sia riconosciuta come critica per il successo dei progetti, è scarsamente supportata dai CASE tool o dagli ambienti di sviluppo. − L'uso del linguaggio naturale aiuta la raccolta dei requisiti e la comprensione del problema, indicata come essenziale per la successiva modellazione dei requisiti [9]. − L'analisi automatica dei documenti dei requisiti consente di mettere in luce ambiguità e contraddizioni prima ancora di iniziare a modellare i requisiti. ...
Negli ultimi anni si è registrato un interesse crescente all’uso e alla realizzazione di applicazioni per il linguaggio naturale. Si pensi ad esempio ai sistemi di riconoscimento del parlato o ai programmi di traduzione proposti dai motori di ricerca sul Web. La gamma di applicazioni possibili è decisamente vasta, essendo legata alla pervasività del linguaggio. Un filone di ricerca più recente, riguarda l’uso di sistemi per il trattamento del linguaggio naturale a supporto dell’analisi di domini aziendali complessi, in particolare per l’analisi e modellazione dei requisiti. Nella loro progettazione giocano un ruolo essenziale aspetti organizzativi, oltre che comunicativi e relazionali, che rendono indispensabile il ricorso a tecniche e strumenti di supporto alla modellazione e validazione dei requisiti flessibili e intelligenti. Tuttavia, al crescere della complessità del compito da affrontare, si richiedono approcci che siano in grado di affrontare i problemi del linguaggio corrente e di rappresentare adeguatamente la conoscenza contenuta nei documenti. In questo lavoro faremo riferimento a un progetto per un tool di supporto all’analisi dei requisiti basato su LOLITA, un sistema sviluppato secondo l’approccio dell’ingegneria del linguaggio naturale.
... We may emphasize the Fidelity Register is essentially a heuristic; it is a placeholder for the discernments System Analysts continually absorb while interacting with users and understanding their perception of the system's usefulness to them [Davis, 1998]. Leveraging such intuition is essential in building a system that, in summary, meets the users' needs. ...
The objective of my doctoral dissertation research is to formulate, implement, and validate metrics and techniques towards perceiving some of the influences on software development, predicting the impact of user initiated changes on a software system, and prescribing guidelines to aid decisions affecting software development. Some of the topics addressed in my dissertation are: Analyzing the extent to which changing requirements affect a system’s design, how the delegation of responsibilities to software components can be guided, how Aspect Oriented Programming (AOP) may be combined with Object Oriented Programming (OOP) to best deliver a system’s functionality, whether and how characteristics of a system’s design are influenced by a outsourced and offshore development. The metrics and techniques developed in my dissertation serve as heuristics across the software development life cycle, helping practitioners evaluate options and take decisions. By way of validation, the metrics and techniques have been applied to more than 10 real life software systems. To facilitate the application of the metrics and techniques, I have led the development of automated tools which can process software development artifacts such as code and Unified Modeling Language (UML) diagrams. The design and implementation of such tools are also discussed in the dissertation.
... The guest editors offered an introduction illustrating the conduit metaphor. [2] The general editor, on the other hand, offered a contrasting view that stressed that 'the field of requirements (and it no longer matters to me what word you like to append to requirements to make it sound more esoteric) has to do with understanding, not documentation' [8]. This realization had only come to him over the 20 years since had been confronted with a document entitled 'Software Requirements Specification'. ...
This paper considers the impact and role of the 'engineering' metaphor, and argues that it is time to reconsider its impact on software development practice.
Capture client requirements is considered one of the most important steps in the field of information technology projects. In University courses related to Computer Sciences, this subject is sometimes trained through interviews with real companies. However, voluntaries of companies participating in the interviews do not act like real interlocutors, as their interest is not the project itself, but just the interview. In this regard, we miss custom dynamics such as conflicts or demanding requests, which are inherent parts of interviews. To include these conditions for a more realistic experience, we propose the students themselves to also take the role of clients, randomly playing different characters that are based on a set of features that define their personalities and technical skills. In this way, teams of analysts interview teams of customers, generating scenarios not only derived from the project requirements, but also the personal and strategic interests of each part. Results show that the main problems of analysts to handle meetings are precisely related to the emotional behaviors, which influenced quality, fluency, empathy and appropriateness in the analyst's conduct. Moreover, results show that after this experience the students achieved a strong improvement of abilities to dynamically manage an interview process, self-control skills, adequately express their ideas and anticipate client needs, compared to those who performed classical pre-designed interviews with real costumers. Students reported a gain of auto-assessment and a better empathy with clients, which increased the chances to successfully capture and prioritize requirements.
This chapter argues that many requirements engineering researchers fail to understand current practices. In most fields, the purpose of performing research is to synthesize new knowledge that can be either put into practice, or used by other researchers to help them perform research. Every responsible requirements engineering researcher must at least identify how their research compares and contrasts with existing research, and how it can be used practically in the real world. The challenge to researchers in requirements engineering is to either acknowledge that their research is purely theoretical (and stop lamenting its lack of use), or to study current practice carefully. This discussion would not be complete without acknowledging the presence of systemic issues that interfere with authors' ability to produce research results ready for common practice.
Numerous studies in recent months have proposed the use of linguistic instruments to support
requirements analysis. There are two main reasons for this: (i) the progress made in natural language processing and (ii) the need to provide the developers of software systems with support in the early phases of requirements definition and conceptual modelling. This paper presents the results of an online market research intended (a) to assess the economic advantages of developing a CASE (computer-aided software engineering) tool that integrates linguistic analysis techniques for documents written in natural language, and (b) to verify the existence of the potential demand for such a tool. The research included a study of the language – ranging from completely natural to highly restricted – used in documents available for requirements analysis, an important factor given that on a technological level there is a trade-off between the language used and the performance of the linguistic instruments. To determine the potential demand for such tool, some of the survey questions dealt with the adoption of development methodologies and consequently with models and support tools; other questions referred to activities deemed critical by the companies involved. Through statistical correspondence analysis of the responses, we were able to outline two ‘‘profiles’’ of companies that correspond to two potential market niches, which are characterised by their very different approach to software development.
Erratum in Volume 9, Number 2 / May, 2004; 10.1007/s00766-004-0195-3; http://www.springerlink.com/content
/etkrf85ev9831ueu/?p=1f3f1cb51aa74cafb104f78dc60a8705&pi=1
The term software engineering has had a problematic history since its appearance in the 1960s. At first seen as a euphemism for programming, it has now come to encompass a wide range of activities. At its core lies the desire of software developers to mimic ‘real’ engineers, and claim the status of an engineering discipline. Attempts to establish such a discipline, however, confront pressing commercial demands for cheap and timely software products. This paper briefly examines some of the claims for the engineering nature of software development, before moving to argue that the term ‘engineering’ itself carries with it some unwanted baggage. This contributes to the intellectual quandary in which software development finds itself, and this is exacerbated by many writers who rely upon and propagate a mythical view of ‘engineering.’ To complicate matters further, our understanding of software development is grounded in a series of metaphors that highlight some key aspects of the field, but push other important issues into the shadows. A re‐reading of Brooks' “No Silver Bullet” paper indicates that the metaphorical bases of software development have been recognized for some time. They cannot simply be jettisoned, but perhaps they need widening to incorporate others such as Brooks' concepts of growth and nurture of software. Two examples illustrate the role played by metaphor in software development, and the paper concludes with the idea that perhaps we need to adopt a more critical stance to the ‘engineering’ roots of our endeavours*.
*I should like to express my thanks to the anonymous reviewers of the first draft of this paper. Two of them offered useful advice to enhance the finished version; the third gave vent to a perfectly valid concern, that the argument as stated could have grave side effects if it was used as a point of leverage in arguments over ownership of the term ‘engineering.’ I understand this concern and the potential financial implications that prompt its expression; but in the longer term I see this exercise in clarification as a contribution to such discussions, inasmuch as it helps defuse the potency of terms such as ‘engineering.’
ResearchGate has not been able to resolve any references for this publication.