BOF4WSS : a business-oriented framework for enhancing web services security for e-business

When considering Web services' (WS) use for online business-to-business (B2B) collaboration between companies, security is a complicated and very topical issue. This is especially true with regard to reaching a level of security beyond the technological layer, that is supported and trusted by all businesses involved. With appreciation of this fact, our research draws from established development methodologies to develop a new, business-oriented framework (BOF4WSS) to guide e-businesses in defining, and achieving agreed security levels across these collaborating enterprises. The approach envisioned is such that it can be used by businesses-in a joint manner-to manage the comprehensive concern that security in the WS environment has become

How do software architects consider non-functional requirements: an exploratory study

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft

Requirements elicitation techniques for software development: a systematic review of literature

Introduction: Requirements elicitation (RE) is a difficult task in which there are issues related to information ambiguity, incomplete and inconsistent data. It seeks to discover and understand the users' problems and needs. The success of software development depends on the correct elicitation of requirements, and its quality is influenced by the techniques used.  This research aims to identify the RE techniques most cited in the literature of software development projects within this context. Method: a systematic literature review was carried out, which analyzed 61 articles from the Scopus database. Results: We identified the 10 RE techniques most cited in the literature. The ranking of these techniques showed that those obtained by stakeholders' groups' involvement were the least mentioned. Conclusions: the research identified the opportunity and relevance for developing a descriptive or confirmatory analysis of RE techniques based on the interaction between groups of users and members of the software development team.Introdução: A elicitação de requisitos (ER) é uma tarefa difícil na qual é necessário lidar com ambiguidade de informações, dados incompletos e inconsistentes. Ela busca descobrir e entender o real problema e as necessidades dos usuários. O sucesso do desenvolvimento de software depende da elicitação correta dos requisitos, e a qualidade deles é influenciada pelas técnicas usadas. Dentro deste contexto, o objetivo desta pesquisa é identificar as técnicas de ER mais citadas na literatura em projetos de desenvolvimento de software. Método: Foi realizada uma revisão sistemática da literatura, que analisou 61 artigos da base de dados Scopus. Resultados: Foram identificadas as 10 técnicas de ER mais citadas na literatura. A classificação dessas técnicas mostrou que aquelas obtidas pelo envolvimento de grupos de stakeholders foram as menos citadas. Conclusão: A pesquisa identificou a oportunidade e relevância para o desenvolvimento de pesquisa acadêmica descritiva ou confirmatória sobre técnicas de ER baseadas na interação entre grupos de usuários e membros da equipe de desenvolvimento de software

Topics in Software Engineering

Software engineering is a discipline which specifies, designs, develops, and maintains software applications. It applies practices and technologies from computer science. Software engineering is the backbone of software systems and forms the basis of operational design and development of software systems. Analysts use requirements elicitation techniques to ascertain the needs of customers and users, with the goal being a system that has a high chance of satisfying those needs. Success or failure of system development relies heavily on the quality of requirements gathering. Software modeling is an essential part of the software development process. Models are built and analyzed before the implementation of a system and are used to direct implementation.The Unified Modeling Language (UML) provides a standard way to visualize the design of a system. During the planning and design stages, software engineers must consider the risks involved in developing a system. Software must solve a problem and must respond to both functional and nonfunctional requirements. Software systems generally follow a pattern or an architectural style. We show the initial steps of developing a software system, define its specification and design topics, and demonstrate their creation by presenting a case study

Developing Crisis Training Software for Local Governments – From User Needs to Generic Requirements

In this paper we analyze and present the generic requirements identified for a software aiming at supporting crisis management training in local governments. The generic requirements are divided into overall requirements, requirements connected to the trainer’s role and requirements connected to the trainee’s role. Moreover, the requirements are mapped to problems as well as opportunities. Finally, we present examples of elaborations of the addressed requirements based on software design considerations. In our work we applied a design science approach and the artifact presented in this paper is a list of generic requirement. The presented requirements and the systems development process used, provide guidelines for systems analysts and developers in future systems development projects aiming at constructing new software for crisis management training

Non-Functional Requirements Elicitation Guideline for Agile Methods

One of the essential activities in software development is elicitation of requirement. Majority of the studies has pointed out that less attention is given to the NonFunctional Requirement (NFR). The negligence of NFR elicitation is due to lack of knowledge of the user and developer about NFR. Our study presents elicitation guidelines for NFRs in agile methods. This guideline will helps developers as well as users in agile methods. A case study is conducted on the group of master students for eliciting NFR with the help of elicitation guidelines. In addition, the initial results were obtained by extracting NFRs from eProcurement document that carries requirements of major European Union projects. The result of the case study is positive and encouraging for the new developers and users having less awareness about NFRs. Furthermore, the study describes the role of cloud computing in agile methods, especially in elicitation activity

Proceedings ICPW'07: 2nd International Conference on the Pragmatic Web, 22-23 Oct. 2007, Tilburg: NL

Proceedings ICPW'07: 2nd International Conference on the Pragmatic Web, 22-23 Oct. 2007, Tilburg: N