Use cases have proven helpful for eliciting, communicating and documenting requirements. But whereas functional requirements are well supported, use cases provide less support for working with extra-functional requirements, such as security requirements. With the advent of e-commerce applications, security and other extra-functional requirements are growing in importance. In an earlier paper, the authors have introduced the concept of misuse cases -- inverted use cases to denote functions that should not be possible to perform in a system. In this paper, security related misuse cases are elaborated in further detail through a discussion of templates for their textual description.

A streamlined and simplified variant of the usage-centered process that is readily integrated with lightweight methods is outlined. Extreme programming and other so-called agile or lightweight methods promise to speed and simplify applications development. However, as this paper highlights, they share with the "unified process" and other heavyweight brethren some common shortcomings in the areas of usability and user interface design. Usage-centered design is readily integrated with these lightweight methods. As in extreme programming , ordinary index cards help streamline the process of modeling and prioritizing for design and implementation in successive increments. Links to selected Web resources on extreme programming, agile modeling, and other agile processes are also provided.

Abstract. In this paper, we argue that current user interface modeling tools are developed using a formalism-centric approach that does not support the needs of modern software development. In order to solve this problem we need both usable and expressive notations and tools that enable the creation of userinterface specifications that leverage the design and thought process. In this paper we present the CanonSketch tool. CanonSketch supports a new UI specification language – Canonical Abstract Prototypes (CAP) – that bridges the gap between envisioned user behavior and the concrete user interface. The tool also supports two additional and synchronized views of the UI: the Wisdom UML presentation extension and concrete HTML user interfaces. In this way the tool seamlessly supports designers while switching from high level abstract views of the UI and low-level concrete realizations. 1

Software developers often fail to respect the intentions of designers due to missing or ignored documentation of design intent. SCL (Structural Constraint Language) addresses this problem by enabling designers to formalize and confirm compliance with design intent. The designer expresses his intent as constraints on the program model using the SCL language. The SCL conformance checking tool examines developer code to confirm that the code honors these constraints. This paper presents the design of the SCL language and its checker, a set of practical examples of applying SCL, and our experience with using it both in an industrial setting and on open-source software.

The paper proposes a reuse-based approach to determining security requirements. Development for reuse involves identifying security threats and associated security generic threats --- expressed as misue cases --- and requirements --- expressed as security use cases. Development with reuse involves identifying security assets, setting security goals for requirements, based on reuse of generic threats and requirements from the repository.

The UML is recognized to be the dominant diagrammatic modeling language in the software industry. However, its support for building interactive systems is still acknowledged to be insufficient. There is a common misconception that the same models developed to support the design of the application internals are also adequate to support interaction design, leveraging the usability aspects of the applications. In this paper we identify and discuss the major problems using the UML to document, specify and design interactive systems. Here we propose a UML profile for interactive systems development that leverages on human-computer interaction domain knowledge under the common notation and semantics of the UML. Our proposal integrates with existing object-oriented software engineering best practice, fostering co-evolutionary development of interactive systems and enabling artifact change between software engineering and human-computer interaction. 1

Abstract. Scenarios have gained acceptance in both research and practice as a way of grounding softwareengineering projects in the users ’ work. However, the research on scenario-based design (SBD) includes very few studies of how scenarios are actually used by practising software engineers in real-world projects. Such studies are needed to evaluate current SBD approaches and advance our general understanding of what scenarios contribute to design. This longitudinal field study analyses the use of scenarios during the conceptual design of a large information system. The role of the scenarios is compared and contrasted with that of three other design artefacts: the requirements specification, the business model, and the user interface prototype. The distinguishing features of the scenarios were that they were task-based and descriptive. By being task-based the scenarios strung individual events and activities together in purposeful sequences and, thereby, provided an intermediate level of description that was both an instantiation of overall work objectives and a fairly persistent context for the gradual elaboration of subtasks. By being descriptive the scenarios preserved a real-world feel of the contents, flow, and dynamics of the users ’ work. The scenarios made the users ’ work recognisable to the software engineers as a complex but organised human activity. This way the scenarios attained a unifying role as mediator among both the design artefacts and the software engineers, whilst they were not used for communication with users. The scenarios were, however, discontinued before the completion of the conceptual design because their creation and management was dependent on a few software engineers who were also the driving forces of several other project activities. Finally, the software engineers valued the concreteness and coherence of the scenarios although it entailed a risk of missing some effective re-conceptions of the users’ work.

This paper examines the use of the Unified Modeling Language (UML) as a representation for interaction design. We discuss the trade-offs related to applying UML outside its intended application domain and the suitability of UML components for modeling various aspects of interaction: representing user requirements, early envisionment of interaction, task modeling, navigation and detailed interaction specification. Where appropriate we propose and illustrate the combination of UML with purpose-specific notations.

Use Case Modeling is a technique for handling the functional requirements in a software development project. The Use Case Model can serve as a means of communication between the different stakeholders in a project. It is used in planning the project and is updated and used during the project. In order to reduce the possibilities for misunderstandings and differences in understanding, it would be useful to be able to evaluate to what extent the different stakeholders have understood the model and also to detect differences in interpretation. Low comprehension or differences in interpretation may indicate a need for more effort on specifying the requirements. If this is not feasible, it may be necessary to assume a higher risk when planning and estimating the project. We propose using knowledge on how humans understand text from cognitive psychology in the design of an experiment with a twofold goal: Investigate methods for measuring comprehension of Use Case Models and analyze the differences in understanding. Keywords: Understanding, Requirements engineering, Use Case Models, Schema Theory 1.

specification