Colin Potts

Inquiry-based requirements analysis

This approach emphasizes pinpointing where and when information needs occur; at its core is the inquiry cycle model, a structure for describing and supporting discussions about system requirements. The authors use a case study to describe the models conversation metaphor, which follows analysis activities from requirements elicitation and documentation through refinement.<<ETX>>

Recording the reasons for design decisions

The authors outline a generic model for representing design deliberation and the relation between deliberation and the generation of method-specific artifacts. A design history is regarded as a network consisting of artifacts and deliberation nodes. Artifacts represent specifications or design documents. Deliberation nodes represent issues, alternatives or justifications. Existing artifacts give rise to issue about the evolving design, an alternative is one of several positions that respond to the issue (perhaps calling for the creation or modification of an artifact), and a justification is a statement giving the reasons for and against the related alternative. The model is applied to the development of a text formatter. The example development is represented in hypertext and as a Prolog database, the two representations being shown to complement each other. The authors conclude with a discussion of the relation between this model and other work and of the implications for tool support and methods.<<ETX>>

Software-engineering research revisited

The author discusses three major changes that he suggests are occurring as a result of the software engineering industry adopting the industry-as-laboratory approach, in which researchers identify problems through close involvement with industrial projects and create and evaluate solutions in an almost indivisible research activity. This approach emphasizes what people actually do or can do in practice, rather than what is possible in principle. The three changes are a greater reliance on empirical definition of problems, an emphasis on real case studies, and a greater emphasis on contextual issues.<<ETX>>

A review of the state of the practice in requirements modeling

A field study of ten organizations was conducted to determine their current practices on definition, interpretation, analysis, and use of the requirements for their software systems and products. The field study consisted of a series of in-depth, structured interviews with practitioners of various kinds. The findings of this study are summarized, and the implications for improving practice either by organizational and methodological interventions or by introducing new technology are explained.<<ETX>>

Goal decomposition and scenario analysis in business process reengineering

This paper presents experiences in applying the goal decomposition and scenario analysis model in the context of Business Process Reengineering (BPR). The relationships of goals, scenarios, as well as the understanding and description of business processes are discussed. Different methods of goal refinement, and the application of scenarios to support this process of refining goals and roles are reviewed. A case study is presented which serves to exemplify and validate the process of using scenarios in refining business process descriptions. We tried deriving full scenarios for business processes, but obtaining them from the organizations prescriptive goals was difficult. Explanatory scenarios that justify descriptive goals are easier to obtain but are fragmentary. We conclude that both types of scenario and goal analysis are necessary for effective BPR. The need for technology support for this process is discussed and attention is given to future anticipated research in this area.

Using schematic scenarios to understand user needs

Scenan’os are narrative descriptions of interactions between users and proposed Tstems. The concreteness qf scenan’os helps users and designers develop a shared understanding of the proposed .ystem ‘s jiinctionali~; but concreteness leads to a potentially unbounded number of scenan’os for a system. To help designers develop a limited set of salient scenarios, we propose a schema similar to story schemata. Like ston’es. scenarios have protagonists with goals. they start with background information already in place, and thqv have a point that makes them interesting or tests the rerrder’s understanding. The scenario schema provides a structuml fmmework for den’ving scenan’os with slots for such teleological information. Scenarios are derived from a description of the vstem’s and the user’s goals, and the potential obstacles that block those goals. In this paper, we describe the scenario schema and a method for deriving a set of’ salient scenarios. We illustrate how these scenarios can be used in the analysis of user needs for a multi-user oflee application.

A Generic Model For Representing Design Methods

A paradigm for representing process information is described. It consists of a simple generic model and a specialization mechanism for customizing the model for any design method. The generic model supports the representation of design arti- facts, steps and heuristics. A specialization of the generic model for JSD is illustrated in detail. The JSD model is then applied to model episodes from a pedagogical design process: the design of a lift system controller.

ScenIC: a strategy for inquiry-driven requirements determination

ScenIC is a requirements engineering method for evolving systems. Derived from the Inquiry Cycle model of requirements refinement, it uses goal refinement and scenario analysis as its primary methodological strategies. ScenIC rests on an analogy with human memory: semantic memory consists of generalizations about system properties; episodic memory consists of specific episodes and scenarios; and working memory consists of reminders about incomplete refinements. Method-specific reminders and resolution guidelines are activated by the state of episodic or semantic memory. The paper presents a summary of the ScenIC strategy and guidelines.

Collaborative conceptual design: a large software project case study

During software development, the activities of requirements analysis, functional specification, and architectural design all require a team of developers to converge on a common vision of what they are developing. There have been remarkably few studies of conceptual design during real projects. In this paper, we describe a detailed field study of a large industrial software project. We observed the development teams conceptual design activities for three months with follow-up observations and discussions over the following eight months. In this paper, we emphasize the organization of the project and how patterns of collaboration affected the teams convergence on a common vision. Three observations stand out: First, convergence on a common vision was not only painfully slow but was punctuated by several reorientations of direction; second, the design process seemed to be inherently forgetful, involving repeated resurfacing of previously discussed issues; finally, a conflict of values persisted between team members responsible for system development and those responsible for overseeing the development process. These findings have clear implications for collaborative support tools and process interventions.

Learning by Doing: Goals & Experience of Two Software Engineering Project Courses

In this paper, we describe two laboratory software engineering class series that are intended to teach the students ‘reflection-in-action.’ We offer the labs at undergraduate and graduate levels, and we present our experience and results from eight project quarters.