1 |
Practical Insights into Recurring Issues of Requirements Elicitation : The potential of systems analysis in addressing these issuesJanits, Michael January 2013 (has links)
Requirements elicitation has been identified by researchers as a highly critical and error-prone phase of IT development projects. Many challenges are rooted in the human and social dimension of this phase, which requires intensive communication activities between stakeholders with different backgrounds and perspectives. The conduct of a systems analysis supports stakeholders in reaching a shared understanding about crucial elements. The aim of this paper is to identify and describe recurring issues in requirements elicitation, and to better understand the potential of systems analysis efforts for addressing these issues. While literature provides plenty of high-level categorizations of requirements elicitation issues most often the argumentation is not complemented with concrete, real-world examples. Therefore five interviews with IT practitioners have been conducted in order to back-up a theoretical framework of problem areas elaborated by Saiedian and Dale (2000) with practical insights. This approach enabled a thorough analysis of four major issues in requirements elicitation covered by this research: Problem Perspective Differences, Resistance, Poor Communication and Articulation/Expertise Problems. Finally, a first linkage between a specific systems analysis method, the Work System Method, and its potential for addressing these problem areas has been established.
|
2 |
Program Comprehension Support for Assembly Language: Assessing the Needs of Specialized GroupsBaldwin, Jennifer Ellen 29 April 2014 (has links)
Advances in software engineering and programming languages have had an impact on productivity, time to market, comprehension, maintenance, and evolution of software. Low-level systems have been largely overlooked in this arena, not only because of their complexities, but also the "bare bones'" culture of this domain. This dissertation investigates the program comprehension needs of two stakeholder groups using different assembly languages: a mainframe development group and a malware analysis group. Exploratory interviews and surveys suggest that the groups' needs may be similar at a high-level. However, a detailed study involving requirements elicitation and case studies, reveals that the truth is much more complicated. As a proof of concept, we have created the AVA (Assembly Visualization and Analysis) framework, which is independent of the underlying assembly language. Despite this independence, tools within AVA could not be applied with equal efficacy, even just within these two groups. This dissertation shows that there exist fundamental differences not only in the highly-specialized nature of each group's work, but also in the assembly languages themselves. This reality necessitates a disjoint set of tools that cannot be consolidated into a universally applicable framework. / Graduate / 0984 / jebaldwin@gmail.com
|
3 |
Program Comprehension Support for Assembly Language: Assessing the Needs of Specialized GroupsBaldwin, Jennifer Ellen 29 April 2014 (has links)
Advances in software engineering and programming languages have had an impact on productivity, time to market, comprehension, maintenance, and evolution of software. Low-level systems have been largely overlooked in this arena, not only because of their complexities, but also the "bare bones'" culture of this domain. This dissertation investigates the program comprehension needs of two stakeholder groups using different assembly languages: a mainframe development group and a malware analysis group. Exploratory interviews and surveys suggest that the groups' needs may be similar at a high-level. However, a detailed study involving requirements elicitation and case studies, reveals that the truth is much more complicated. As a proof of concept, we have created the AVA (Assembly Visualization and Analysis) framework, which is independent of the underlying assembly language. Despite this independence, tools within AVA could not be applied with equal efficacy, even just within these two groups. This dissertation shows that there exist fundamental differences not only in the highly-specialized nature of each group's work, but also in the assembly languages themselves. This reality necessitates a disjoint set of tools that cannot be consolidated into a universally applicable framework. / Graduate / 0984 / jebaldwin@gmail.com
|
4 |
Investigation of Storytelling as a Requirements Elicitation Method for Medical DevicesGausepohl, Kimberly Ann 16 January 2009 (has links)
Medical device usability directly impacts the practitioner's ability to perform their diagnostic task in an effective, efficient, and safe manner. A device with poor usability may frustrate the practitioner, increasing the worker's stress level in a high-stress work environment. In addition, a device with poor usability may facilitate operator error, increasing the patient's risk of injury.
Designers of healthcare systems and devices face a unique conundrum that has been documented in the literature (Martin, Murphy, Crowe, & Norris, 2006; Martin, Norris, Murphy, & Crowe, 2007; Ward & Clarkson, 2007). Standards require the use of user research techniques, yet patient privacy standards prevent designers from observing users in context. The inability to observe users in their work environment impedes understanding the context-of-use. Since understanding context-of-use is required to ensure usability, further exploration into alternative methods for requirements gathering is needed.
This study explored the storytelling as an elicitation method for medical device requirements by comparing the information elicited from nurses during requirements gathering for an infusion pump by two methods: focus groups followed by interviews (Group #1) and focus groups followed by storytelling sessions (Group #2). Results suggest further exploration of storytelling is warranted as Group #2 contributed similar quantity and breadth of information in significantly less time. Results also indicate potential support for the efficacy of storytelling within the healthcare domain as Group #2 participants contributed more distinct context-of-use information with an emphasis on the social context. Contributions of this study include a plan for mixed-method data analysis, a protocol for conducting a storytelling session, and a framework for defining requirements within the healthcare domain. / Master of Science
|
5 |
Development of a user-centred design methodology to accommodate changing hardware and software user requirements in the sports domainMullane, Sarah January 2012 (has links)
The research presented in this thesis focuses on the development of wireless, real time performance monitoring technology within the resistance training domain using a user-centred design methodology. The functionality of current performance monitoring technology and differences in monitoring ability is investigated through comparative force platform, video and accelerometer testing and analysis. Determining the complexity of resistance training exercises and whether performance variable profiles such as acceleration, velocity and power can be used to characterise lifts is also investigated. A structured user-centred design process suitable for the sporting domain is proposed and followed throughout the research to consider the collection, analysis and communication of performance data. Identifying the user requirements and developing both hardware and software to meet the requirements also forms a major part of the research. The results indicate that as the exercise complexity increases, the requirement for sophisticated technology increases. A simple tri-axial accelerometer can be used to monitor simple linear exercises at the recreational level. Gyroscope technology is required to monitor complex exercises in which rotation of the bar occurs. Force platform technology is required at the elite level to monitor the distribution of force and resultant balance throughout a lift (bilateral difference). An integrated system consisting of an Inertial Measurement Unit (both accelerometer and gyroscope technology) and a double plate force platform is required to accurately monitor performance in the resistance training domain at the elite level.
|
6 |
Towards using BPM Patterns in Requirements ElicitationAbdElKader, Mohamed AbdElRazik Mansour 06 November 2014 (has links)
In an increasingly changing environment, different organizations are trying to improve their agility and efficiency by improving their business processes; thus, business process management has been gaining momentum for the last decade. The first step in business process management is the modeling of business processes. Business Process Modeling (BPM), in itself, is very important because it captures business requirements, allows for better understanding of a business and its processes, facilitates communication between business analysts and IT people, and pinpoints deficiencies in processes. It also serves as a basis for automation of these processes. But business process modeling comes with its own challenges since it is a time-consuming, complicated, and error-prone task. As a result, producing a high quality, precise business process model is not easy. BPM patterns, which are general reusable solutions to commonly occurring problems in business process modeling, have been proposed to address these challenges. In this research, we conducted an exploratory study about requirements engineering practices in a large organization. This study identified key challenges in requirements engineering and showed how business process modeling is currently being conducted. Then, we created a survey of the different BPM pattern catalogs existing in the literature. Finally, we presented one of the BPM pattern catalogs in a clear format along with examples of each pattern. The ultimate objective is to allow business analysts to effectively use BPM patterns while creating precise BP models.
|
7 |
An Approach For Eliciting Functional Requirements Of The Software Intensive Systems Based On Business Process ModelingYildiz, Okan 01 January 2003 (has links) (PDF)
In this thesis, eliciting system functional requirements based on business
requirements during software intensive systems acquisition or development process
is investigated and an approach is proposed for this purpose. Concepts and current
problems within the framework of business requirements are investigated with a
general literature review of requirements engineering and technology acquisition.
Determination of requirements of IT system to be acquired according to the business
objectives and base lining business processes is dealt with business process
modeling. ARIS providing integrated and complete information system architecture
along with modeling techniques and modeling tool is also investigated. Proposed
approach recommends EEPC as process modeling technique and ARIS software as
supporting toolset, and explains how to conduct application of automatic
requirements eliciting from business process models, by extending a reporting script
provided by ARIS software. Proposed approach was partially applied to the real
project and the obtained results were presented in this thesis.
|
8 |
Value based requirements engineeringThew, Sarah Louise January 2014 (has links)
Whilst numerous studies have retrospectively reported the impact of negative user emotions, motivational problems or value clashes during software developments, few Requirements Engineering (RE) studies have considered the elicitation of users’ values, motivations or emotions (VM&Es) and there is little advice for practising analysts as to how to deal with these factors. This thesis explores the impact of users’ VM&Es within RE work. The starting point was a review of the current state of analyst practice. A literature survey considered the RE guidance available to analysts on the elicitation and understanding of ‘soft issues’ such as VM&Es. In parallel, a series of interviews with 12 industry analysts sought their views on the relevance of users’ VM&Es, the impact on requirements work, and approaches to identifying such information. This study identified behaviours adopted by experienced analysts that would be useful to promote to novice analysts, and documented the analysts’ own requirements for a method to support them in eliciting VM&Es. These findings informed the design of the Value Based Requirements Engineering (VBRE) method and website (www.vbre.org.uk), intended to support requirements analysts in identifying and considering the impact of such ‘soft factors’. Research into RE method adoption highlights the importance of industry input, so a Participatory Design (PD) approach was taken in developing VBRE, iteratively evaluating and refining the method with input from practising analysts. A series of complementary evaluations of the method are presented. An experimental study investigated the method’s utility and usability with computer science undergraduate students, whilst a set of four case studies explored adoption of the VBRE method with industry analysts. The analysts used the method during their RE work, adapting the approach according to their circumstances and levels of experience. The participants credited the method with a positive impact on their RE work and the novice analysts reported feeling more confident of their abilities to handle ‘soft issues’. The key contributions of this work are:1. An exploration of the views of practising analysts as to the relevance and impact of VM&Es within their RE work.2. Development of an analysis method and support materials to aid analysts in identifying users’ VM&Es.3. A demonstration of the utility of adopting a PD approach to the development of RE methods.4. An evaluation of the use of the method in industry, exploring the use of case studies to understand how novice and expert analysts adopt and adapt the VBRE approach. This thesis is unusual in taking a PD approach to developing a solution for a RE problem: that analysts need to understand users’ VM&Es and their impact on software projects. The VBRE method attempts to address this gap, and the positive reception given by the analysts involved in evaluation of the method indicates they see utility in the approach. Future work will focus on continuing to collaborate with industry analysts to understand their use of the VBRE method, identifying improvements to the method and website, and gathering examples of the method’s impact.
|
9 |
Developing Software Requirements for a Knowledge Management System that Coordinates Training Programs with Business Processes and Policies in Large OrganizationsKiper, James Richard 01 January 2013 (has links)
For large organizations, updating instructional programs presents a challenge to keep abreast of constantly changing business processes and policies. Each time a process or policy changes, significant resources are required to locate and modify the training materials that convey the new content. Moreover, without the ability to track learning objects to processes and policies, training managers cannot conduct an effective training gap analysis in these areas. As a result, the corporate training picture is unclear and instructional needs cannot be accurately determined.
The research addressed these problems by recognizing the need for linkages between an organization's business processes, its policies, and the learning objects that package the corresponding training content and deliver it to the workforce. The overall investigation was completed in three parts. In the first study, a thorough examination of the literature was conducted to determine the extent of the research problem and to provide a theoretical foundation for a solution. In the second study an expert panel was used to elicit user needs for a knowledge management system that addresses training management shortcomings in a large law enforcement agency. Another expert panel from that agency validated and prioritized the user needs during the third study. Through a combination of research-based elicitation and validation techniques, an accurate list of natural language software requirements emerged to represent the collective needs of the law enforcement training experts. The software requirements may now serve to analyze the capabilities of existing information technology systems or to form the basis for a request for proposal (RFP) to build the envisioned knowledge management system.
|
10 |
Requirements specification using concrete scenariosAu, Oliver T. S. January 2009 (has links)
The precision of formal specifications allows us to prove program correctness. Even if formal methods are not used throughout the software project, formalisation improves our understanding of the problem. Formal specifications are amenable to automated analysis and consistency checking. However using them is challenging. Customers do not understand formal notations. Specifiers have difficulty tackling large problems. Once systems are built, formal specifications quickly become outdated during software maintenance. A method of developing formal specifications using concrete scenarios is proposed to tackle the disadvantages just mentioned. A concrete scenario describes system behaviour with successive steps. The pre- and post-states of scenario steps are expressed with actual data rather than variables. Concrete scenarios are expressed in a natural language or formal notation. They increase customer involvement in the creation of formal specifications. Scenarios may be ranked by priorities allowing specifiers to focus on a small part of the system. Formal specifications are constructed incrementally. New requirements are also captured in concrete scenarios which guide the modification of formal specifications. On one hand, concrete scenarios assist the creation and maintenance of formal specifications. On the other hand, they facilitate program correctness proofs without using conventional formal specifications. This is achieved by adding implementation details to customer scenarios. The resulting developer scenarios, encapsulating decisions of data structures and algorithms, are generalised to operation schemas. With the implementation details, the schemas written in formal notations are programs rather than specifications.
|
Page generated in 0.1578 seconds