Showing papers on "User story published in 1999"

Extreme Programming Explained: Embrace Change

Abstract: Software development projects can be fun, productive, and even daring. Yet they can consistently deliver value to a business and remain under control.Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned.Fundamentals of XP include: Distinguishing between the decisions to be made by business interests and those to be made by project stakeholders. Writing unit tests before programming and keeping all of the tests running at all times. Integrating and testing the whole system--several times a day. Producing all software in pairs, two programmers at one screen. Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity. Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.Why is XP so controversial? Some sacred cows don't make the cut in XP: Don't force team members to specialize and become analysts, architects, programmers, testers, and integrators--every XP programmer participates in all of these critical activities every day. Don't conduct complete up-front analysis and design--an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development. Develop infrastructure and frameworks as you develop your application, not up-front--delivering business value is the heartbeat that drives XP projects. Don't write and maintain implementation documentation--communication in XP projects occurs face-to-face, or through efficient tests and carefully written code.You may love XP, or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software. 0201616416B04062001

Analyzing user requirements by use cases: a goal-driven approach

Abstract: The purpose of requirements engineering is to elicit and evaluate necessary and valuable user needs. Current use-case approaches to requirements acquisition inadequately support use-case formalization and nonfunctional requirements. Based on industry trends and research, the authors have developed a method to structure use-case models with goals. They use a simple meeting planner system to illustrate the benefits of this new approach.

How stories capture interactions.

Abstract: Stories have an important role in designing HCI systems because they contribute to the representation of contextual information. User Stories are the first artefacts we use in order to describe interactions, but for implementation purposes we need something more formal such as Use Cases. In this sense, Use Cases are similar to user stories but different in that they lose most of the context that user stories maintain. User stories are the bones with which to complete a skeletal script of interactions. At the same time, stories capture much of the intentions of the users, allowing to trace intentions (derived from the context of the activity or workplace) to a set of interactions between actors and system that constitute a set of use cases. The paper proposes an approach to analysing user stories through experientialist concepts of stories, mental spaces, projection and blends in order to be able to establish a more rigorous traceability between user stories (which could be considered as pre-requirements) and semi-formal requirements such as use cases.

Separating the wheat from the chaff in Internet-mediated user feedback expectation-driven event monitoring

Abstract: The Internet enables cheap, rapid, and large-scale distribution of software for evaluation purposes. It also presents hitherto unprecedented, and currently underutilized, opportunities for increasing user-developer communication in software development. For instance, the Internet can be used as a medium for collecting "direct" user feedback in the form of subjective user reports, as well as "indirect" feedback in the form of automatically-captured data about application and user behavior. Both of these practices, however, face a number of challenges that can be summarized in the following statement: there is more feedback to be collected -- ranging in quality from useful to useless -- than there is time and resources to sift through and act upon the meaningful parts. This paper describes an Internet-based approach for capturing user feedback -- both "direct" and "indirect" -- that attempts to address this problem by focusing feedback collection based on the notion of "usage expectations" in the development process.

User participation in requirements negotiation

Abstract: This paper discusses the user involvement in the early phases of the software development life-cycle, specifically in the requirements definition. It argues that designing for product quality means enabling an effective communication and involvement of the user factor in the process of defining the requirements for the system to be developed. It addresses the human dimension and the social interaction of the requirements negotiation, and discusses issues involved in designing groupware for user participation in a remote setting. We believe that groupware should not only give technical support to the modeling of requirements, but also to the group social interaction through which the requirements are captured and negotiated.

Is There Such a Thing as a User Requirement

Abstract: We requirements engineers seem to be having quite a hard time tracking down the real, primal, User Requirement. In fact, it is as elusive as the Wild Man of the Appalachian forests. When I actually meet ‘users’ – whatever they are, and that is an equally hard question, to which I will return – I find that they certainly have needs, but that these do not appear in canonical form at all. The needs come out in a rush, a mixture of complaints, design decisions, interface descriptions, current situations, and from time to time specific human–machine interface requirements (though not often). It is sometimes possible to isolate chunks of this as definite functions; it is rather easier to come up with required scenarios, which can be analysed as hierarchies of use cases. Proper constraints are even harder to come by, even in safety-conscious industries such as rail and aerospace. Instead, safety and reliability and so on appear as oblique references to a mass of standards, precedents, policies, reviews and assessments, which never seem to add up to a neat and tidy safety case as understood by the academics. In short, there seems to be a gap between theory and practice. Theory says that on the one hand we’ll find people who state what they want, and on the other, people who make things to please the first bunch of people. Instead, all the people and tasks and documents seem to be muddled up together. This should be alarming news to those whose philosophy of system development requires a neat sequence from user requirement to system specification to design to test. Now, I do not believe that I have been especially unlucky in my meetings with clients. I think they are, if not a random selection, at least reasonably representative of the industrial world at large. The people who I work with and for seem to have a good idea of their jobs, are generally hard-working, and are keen to provide a service. But they do not think of themselves as users or requirement providers. This brings me to the term ‘users’. It is an odd word for the start of a process, as it clearly implies that something, some system, is being used. That system must already exist if the use is actual rather than potential, in which case we cannot expect to get pure, green-field requirements: we will get comments which refer, no doubt often obliquely, to the current system. That system is undoubtedly old, constricting and awkward, so the expression of wishes and needs for a new, custom system may well be distorted by the cramped present (or past) reality. Generals, for example, are classically accused of always preparing to fight the last war (or the last war but one) again, rather than the unpredictable next one. Another possibility is that the ‘users’ do not yet have a system, so they are purely potential or planned users of a future system. In this case, they are being asked to describe how they would like something to be, when Requirements Eng (1999) 4:221±223 ß 1999 Springer-Verlag London Limited Requirements Engineering

End-user programming and blended-user programming

Abstract: End-User Programming has not lived up to expectations: today's computer world is dominated by "fatware" programs with hundreds of features, not simple applications built by the users themselves. Yet a strange convergence is taking place between the roles of programmers and end-users. Professional programmers are now end users of complex IDEs (Integrated Development Environments) similar to tools for non-programmers. On the other end of the scale, end users of major applications are gradually eased into real programming by extensive customization, macro recorders, "wizards", and GUI builders. In between are the informally-trained software professionals we call "blended-user programmers" who configure computers and networks, control industrial machines, and build active Web pages and business applications. Like conventional programmers, they are paid to program full-time, and develop skills in a variety of tools. Like end-users, their knowledge is applied and experimental rather than theoretical. Many started as end users, but moved into these software careers instead of becoming "gurus" or "gardeners" [1] who help other users.

Lessons learned applying software engineering principles to visual programming language application development

Abstract: Visual programming languages make software design accessible even to untrained programmers, but basic software engineering practices must still be followed to create a usable product. This paper describes the process by which software was developed to control sophisticated laboratory equipment for a radio frequency interference monitoring system (RFIMS). Development of requirements and specifications is discussed. It is shown that the product was improved by the use of extensive planning and user testing. In addition, the steps required for designing a clear and intuitive graphical user interface (GUI) are discussed. The GUI interface specifications, user panel templates, menu system hierarchy, and programmatically guiding the user are some of the tools that were successfully employed in the project development.

An Analysis of the Performance and Usability of a Software User Coach for Navy Manpower Planning

Abstract: Advances in user interface design have made it possible to improve the effectiveness of complex software tools. This study explores the feasibility of improving user performance on a manpower-planning task by employing a user coach. A user coach is a software aid, often built directly into software applications, that assists the user at critical stages. The user coach developed for this project closely resembles the "wizards" that are commonly used in commercial software today. The user coach was applied to a software application known as SKIPPER, a manpower modeling tool employed by the Department of the Navy to plan and manage the enlisted personnel. In addition to procedural assistance, the coach also provides a visual picture of the planning process based on a hydraulic metaphor (e.g., manpower planning as a series of holding tanks, faucets, pipes, valves, etc.). This article describes the user coach, and documents a formal evaluation of its effectiveness. The evaluation compared the use and understan...

Pragmatic user modelling for complex commercial systems

Abstract: While user modelling has become a mature field, with demonstrable research systems of great power, comparatively little progress has been made in the development of user modelling components for commercial software systems. The development of minimalist user modelling components, which are simplified to provide “just enough” assistance to a user through a pragmatic adaptive user interface, is seen by many as an important step toward this goal. This thesis describes the development, implementation, and empirical evaluation of a minimalist user modelling component for the Tax and Investment Management Strategizer (TIMS), a complex commercial software system for financial management. The experimental results demonstrate that a minimalist user modelling component improves the subjective measure of user satisfaction. Important issues and considerations for the development of user modelling components for commercial software systems are also discussed.

Expert I/F with planning recovery for erroneous interactions

Abstract: Proposes an effective interaction management method named "mutual interaction control". We implemented the proposed method on a user interface development tool. The method builds a front-end interface that works between the user and back-end systems. This interface has interaction plans called "interaction flows" (I/F), which are like a flow chart. The user indicates his/her purpose to the interface, and the interface uses the plans and drives the back-end systems instead of the user to achieve the user's purpose. A user can freely change topics and more than one topic can proceed in parallel. The interface can automatically change plans according to the user's answer even if the user does not consciously change topics.