Integrating Lightweight Systems Analysis into the United Process by Using Service Responsibility Tables

This paper is a step toward establishing direct, but non-automatic links between lightweight (semi-formal) analysis methods for business professionals and heavyweight analysis methods for IT professionals. After noting the importance of user involvement in obtaining accurate and meaningful user requirements, the paper summarizes the Unified Process, a software development methodology that employs Unified Modeling Language (UML). Another section in the paper summarizes previous extensions of the work system method that produced a lightweight analysis tool called Service Responsibility Tables (SRTs). This paper uses a straightforward example to demonstrate a set of heuristics for translating between service responsibility tables produced by business professionals and UML diagrams that IT professionals can use as a partial basis for programming. This type of guideline-based link between lightweight and heavyweight methods could lead to more effective user involvement in requirements determination and reduce failure rate in IT projects

The Influence of Analyst Communication in IS Projects

Information system (IS) researchers have long noted that IS analysts need to understand users’ needs if they are to design better systems and improve project outcomes. While researchers agree that analyst communication activities are an important prerequisite for such an understanding, little is known about the nature of different communication behaviors IS analysts can undertake to learn about users’ system needs and the impact of such behaviors on IS projects. To address this gap, this paper draws from the learning literature to articulate the information transmission activities IS analysts can undertake and the content of the information they can transmit when learning about users’ organizational tasks and information needs. The influence of analyst communication activities on the generation of valid information regarding user needs, analyst learning, and IS project outcomes are then investigated via a case study of two IS projects. The analysis of the two cases suggests that analysts who encourage the use of concrete examples, testing, and validation, and who solicit feedback about users’ business processes are likely to better understand users’ tasks, and in turn design systems that better meet users’ task needs than analysts who do not

Eliciting User Requirements Using Appreciative Inquiry

Many software development projects fail because they do not meet the needs of users, are over-budget, and abandoned. To address this problem, the user requirements elicitation process was modified based on principles of Appreciative Inquiry. Appreciative Inquiry, commonly used in organizational development, aims to build organizations, processes, or systems based on success stories using a hopeful vision for an ideal future. Spanning five studies, Appreciative Inquiry was evaluated for its effectiveness with eliciting user requirements. In the first two cases, it was compared with traditional approaches with end-users and proxy-users. The third study was a quasi-experiment comparing the use of Appreciative Inquiry in different phases of in the software development cycle. The final two case studies combined all lessons learned using Appreciative Inquiry, with multiple case studies to gain additional understanding for the requirements gathered during various project phases. Each study evaluated the requirements gathered, developer and user attitudes, and the Appreciative Inquiry process itself. Requirements were evaluated for the quantity and their type regardless of whether they were implemented or not. Attitudes were evaluated for process feedback, as well as requirements and project commitment. The Appreciative Inquiry process was evaluated with differing groups, projects, and project phases to determine how and when it is best applied. Potentially interceding factors were also evaluated including: team effectiveness, emotional intelligence, perceived stress, the experience of the facilitator, and the development project type itself. Appreciative Inquiry produced positive results for the participants, the requirements obtained, and the general requirements eliciting-process. Appreciative Inquiry demonstrated benefits to the requirements gathered by increasing the number of unique requirements as well as identifying more quality-based (non-functional) and forward-looking requirements. It worked well with defined projects, when there was time for participants to reflect on the thought-provoking questions, structured questions and extra time to facilitate the extraction and translation of requirements, and a knowledgeable interviewer. The participants (end-users and developers) expressed improved vision and confidence. End-users participated consistently with immediate buy-in and enthusiasm, especially those users who were technically-inhibited. Development teams expressed improved confidence, and improved user communication and understanding

Respondent Perceived Threat During the Information Systems Requirements Determination Process: Understanding and Mitigation

Requirements determination is a critical driver in a successful software development process. Despite decades of research prescribing various software development methodologies, intended to aid in achieving an eventual convergence between the user’s mental models and an informationally equivalent representation that is codified within an information system, we can still attribute many of the deficiencies in software development projects to the improper or ineffective execution of the requirements determination process. This study draws on the user resistance, software development, and psychology literature to discuss how perceived threats by potential users and key respondents can result in sub-optimization of a proposed information system via reduction in the quality of their responses during the requirements gathering phase. A laboratory experiment was carried out to explore the sources and effects of various threat perceptions and the effectiveness of techniques intended to detect and mitigate such perceptions of threat. The results confirm that perception of threat does lead to a degradation in response quality, with perceived adaptability fully mediating the relationship. The findings on whether interviewer reassurance has a moderating effect on the relationship between threat and perceived adaptability had interesting results, which are discussed