We have had to cancel some of the tutorials because they have not attracted enough paid registrants to cover even the cost of the rooms in which they will be given. Please do not register for any marked as ``Cancelled'' below. If you have already registered for one or more cancelled tutorial, please contact Daniel Berry (dberry AT uwaterloo DOT ca) about making other arrangements. In any case, he will contact you about moving to another tutorial, participating in a workshop, or getting a refund.
Monday, August 31st, 2009
M1. Design science research methodology: Principles and practice, Roel Wieringa, U Twente, full day
Computing sciences such as software engineering, information systems and requirements engineering are design sciences because they solve classes of practical problems and validate technical solutions in practice. Pure, curiosity-driven, empirical research may deliver knowledge that is not usable in practice; pure, curiosity-driven technical research may deliver solutions to problems no one has. Only the combination of design science research with an orientation to practice will lead to solutions with generalizable scientific interest as well as with potential relevance for practice.
This tutorial treats design science as rational problem solving. It discusses the engineering cycle, positions the role of requirements engineering, elaborates the structure of problem investigation and of solution validation, and explains the structure of internal and external validity of design solutions. The tutorial also shows how to integrate research into these tasks, classifies different kinds of research questions and gives a checklist for designing and validating empirical research. We look at the difference between lab experiments, field experiments, field trials, case studies and technical action research. To illustrate these methods, many examples are given, and the participants are given the opportunity to apply the concepts to their own practice.
Practicing researchers will learn how to set up the methodology of a design science project and how to choose empirical research in their project. Practitioners will learn how to assess research results and how to set up requirements engineering following the rational engineering cycle.
M2. Cancelled Due to Insufficient Registrations Reducing omission errors using cross product models, Shmuel Ur, IBM Haifa, full day
Omission is one of the most important errors in requirement, design and testing. The tutorial teaches how to reduce omission errors in design testing and requirements. We present the material with two real use cases and hands on usage of FoCus (http://www.alphaworks.ibm.com/tech/focus). The tutorial is based on practices used in IBM some of which have been taught outside in conferences and some shown for the first time.
First use case - Designing for many configuration
We present the requirements as written.
We build a model defining all the possible configurations that are possible.
We show how to review the model and why reviewing a model is preferable to reviewing the requirement document.
We show how to create a small test plan with combinatorial test design (CTD) such that:
- the size of the test plan meets the resource allocated, and
- the quality, given the resources, is very high.
We cover additional practical issues such as how to run tests in an optimal order, what to do if some tests can not be executed.
We show how to reduce the test list even further taking into account tests executed for other line items.
We show how to find out important configuration that were not tested by automatically evaluating the coverage of executed tests.
Second use case - Recovery of a RAS applications
We describe the requirement - the application should continue to execute correctly after components fail and recover.
We review the design and test plan for this requirement.
We create a model containing all the relevant scenario and review it.
We evaluate alternatives for small test plan with CTD.
We show how to measure coverage on real applications and use the scenarios that occur in practice to reduce the tests.
We show how to find relevant missing scenarios using coverage.
M3. Cancelled Due to Insufficient RegistrationsProduct Management for Software and Systems, Christof Ebert, Vector, full day
This one-day tutorial provides practical training on product management based on “best practices” in companies. Covering the entire product life-cycle it offers a reference framework split into the five phases of inception, development, market launch, deployment and service. For each of these phases the tutorial offers a well-balanced program of overview, short case studies and mutual learning in interactive sessions and discussions. It provides insight into best practices around strategy building, translating strategy into a project vision, portfolio management, requirements elicitation, creating and managing the project business case, prioritizing requirements, customer and market interaction, uncertainty management, project execution, quality assurance, release management, service delivery and support.
The tutorial will take the software or IT product manager’s perspective to provide a comprehensive view on what matters to be successful on the market and as a business. The subject will be introduced by way of an interactive guided tour through the entire product life-cycle, looking at relationships with other functions (e.g., project manager, marketing and quality), mapping the processes, and dealing with vertical and horizontal/cross-functional communication.
Asking the questions “what is the specific value of product management at this point” or “what would happen if at this particular stage our product management process was flawed” will provide an understanding of the value and potential of software or systems product management. Short examples will offer opportunities to underpin the learning with practical examples and “by doing”. The tutorial complements the participants’ knowledge and problem solving competences in the subject area and enables them to implement effective upstream processes in their companies.
This tutorial fits particularly well to RE09 because of its holistic view on products, value, sustainability and requirements. It emphasizes a perspective across the product’s life-cycle. And it directly links to the core of currently ongoing evolution and definition of the product management body of knowledge, thus allowing the audience to not only learn but also influence this crucial discipline – which is essential for the success of each single enterprise and person attending RE'09.
M4. The User Requirements Notation (URN) and Aspects, Gunter Mussbacher and Daniel Amyot, SITE, U Ottawa, full day
In November 2008, ITU-T (the standardization sector of the International Telecommunication Union) approved the User Requirements Notation (URN) standard. URN is the first standard that combines modelling concepts and notations for goals and intentions (mainly for non-functional requirements, quality attributes, and reasoning about alternatives) and scenarios (mainly for operational requirements, functional requirements, and performance and architectural reasoning). The two complementary notations of URN are GRL (the Goal-oriented Requirement Language) for goals and UCM (Use Case Maps) for scenarios
The first part of the tutorial gives an introduction to the basic concepts and notations of URN, together with the main requirements analysis, transformation, and management techniques relevant to URN and supported by the jUCMNav Eclipse plug-in, the most comprehensive URN tool available to date. The URN standard incorporates changes to GRL and UCM that address long-standing issues with the notations. These are highlighted and discussed in more detail during the tutorial and include various types of GRL evaluation approaches, new notational concepts for UCM, and an improved UCM traversal mechanism that clarifies the semantics of the UCM notation.
The second part of the tutorial focuses on Aspect-oriented URN (AoURN), an extension to the URN standard and a strong candidate for inclusion in future versions of the standard. AoURN combines goal-oriented, scenario-based, and aspect-oriented modeling in one unified framework. Typical concerns in URN are non-functional requirements, use cases, and stakeholder goals. As AoURN expresses concerns and concern composition rules with URN itself, it is possible to describe rules in an exhaustive and highly flexible way that is not restricted by any specific composition language. In addition, AoURN employs a composition technique that is not based solely on language syntax but takes semantics into account, and therefore is more robust to refactoring of the aspect-oriented model. AoURN introduces new modeling constructs based on aspects that encapsulate goals and scenarios throughout the development process and thus improve the modularity, reusability, scalability, and maintainability of goal and scenario models. Aspects, on the other hand, are provided by AoURN with a standardized modeling environment for functional and non-functional requirements.
M5. Cancelled Due to Insufficient RegistrationsChange Agency for Requirements Engineers, Erik Simmons, Intel, full day
If requirements engineering is such a good thing to do, why aren’t more companies and teams embracing it?
While the answer to this question is complex, one major reason more companies don’t embrace requirements engineering is that they appar to be unable to change their culture and behaviors even though they know it would be beneficial. However, there is a set of skills that can be learned and applied within this setting to greatly increase the odds of successful requirements engineering adoption or improvement: change agency skills.
A requirements engineer who is also a skilled change agent can be very successful in applying requirements engineering within a variety of cultural settings. A change agent understands:
- The structure and makeup of a culture and how to assess existing cultures
- The nature of cultural change and the role of a change agent
- How to effectively plan and carry out projects designed to improve practices in areas like requirements engineering
- The types of resistance to change, the reasons behind them, and how they can be overcome
- How to scale change agency to large populations
- A business model for change agency within a corporation
Certain foundation practices of change agency are the keys to success, including:
- Managing change agency projects using Evolutionary Delivery
- Use of Diffusion of Innovations as a framework and vocabulary for change
- Practical, powerful influencing skills
In this tutorial, we will examine chance agency from a requirements engineering viewpoint. The material will serve as both a practical introduction and a guide to the rather extensive literature availble on related topics. Several exercises throughout the day serve to apply the concepts and skills learned to requirements engineering and change the way that students approach the problem of improving requirements engineering practices. Numerous examples are provided based on the successful application of these techniques in a global corporate setting over the last six years.
Tuesday, September 1st, 2009
T1.Cancelled Due to Insufficient Registrations Selective Homeworkless Reviews, Shmuel Ur, IBM Haifa, full day
The selective homeworkless reviews methodology taught in this tutorial was originally conceived for reviewing design and code. The introduction of iterative development and the shrinking of project life cycles, means that traditional review techniques, for example Fagan inspection, had to be adapted to modern development methods and to the new short time-to-market duration. After successfully using selective homeworkless reviews in IBM, offering tutorials at many sites, and certifying instructors, we extended it to additional domains. It is now being used for reviewing test plans and many other documents such as requirements specifications and high-level design.
T2.Cancelled Due to Insufficient Registrations Roadmap to Success: Scope Modeling, Mary Gorman, EBG Consulting, Inc., full day
This interactive tutorial builds skills in scope modeling, a crucial first step in defining and developing project requirements. You will learn to elicit, analyze, and specify eight requirements models that help you clearly define the boundaries of your project. These scope models are your framework for project planning and the basis for subsequent detailed requirements modeling. You can use your scope models for a variety of project situations: new (custom) development, selecting and implementing Commercial Off-the-Shelf (COTS) software packages, and enhancements. You will also learn how these techniques associate with applicable IIBA 2.0 BABOK® and PMI Fourth Edition PMBOK® materials.
T3. Risk Focused Requirements Management, Discovering the opportunities, exposing the hazards, Donald C. Gause, Consultant, full day
The very process of design involves risk. At the highest level of generality, we run the risk of expediency – rushing ourselves and our product to market too quickly in order to gain the competitive advantage of being first with a new concept. By the same token, when we become overly careful in seeking perfection, we run the risk of coming to the market place too late with the “perfect” product. Either extreme leads to the same consequence – a failed product. Our premise for this tutorial is that there is nothing wrong with taking design risks so long as we are aware of the risks, the rationale for assuming these risks, their potential consequences, and the means for mitigating the risks. We can develop these levels of understanding as a natural by-product of our requirements management approaches. We will present and apply, in a highly interactive manner, a series of requirements elicitation heuristics that we have found to be very helpful in uncovering and managing many sources of design risk including risks associated with designer and client bias, lost opportunity, surprise, nature’s last laugh, unintended consequences, scope paralysis and creep. These heuristics have been very helpful in managing client and end user expectations as well as uncovering many hidden critical design issues in non-functional and functional product requirements. Design visibility and traceability are substantially enhanced during the requirements elicitation, analysis and full design process in such a manner that all design stakeholders – product managers and directors, systems analysts, designers, software developers, clients and end-users – can effectively participate in critical design decision making. We will illustrate the surfacing and resolution of those costly invisible design issues and assumptions that contribute to product inconsistency and failure to meet customer expectations.
T4. The ``Physics'' of Notations: A Scientific Approach to Designing Visual Notations in Requirements Engineering, Daniel L. Moody, full day
Visual representations form an integral part of the "language" of requirements engineering. Most RE techniques rely heavily on diagrams to document and communicate user requirements: an RE notation without a visual notation is almost unheard of. Visual representation aspects critically determine the effectiveness of RE notations both for user communication and in supporting problem solving by requirements engineers.
Currently, RE visual notations are designed in an ad hoc and unscientific manner. Decisions about graphic representation are typically made in a subjective way, without reference to theory or empirical evidence, or justifications of any kind (design rationale). The majority of effort is spent designing the semantics of notations
(what constructs to include and what they mean), with design of visual syntax (how to visually represent these constructs) taking place largely as an afterthought.
While RE now has mature methods for designing semantics of notations (e.g. ontological analysis, formal semantics), equivalent methods for designing visual syntax are notably absent. Currently, in evaluating, comparing and constructing visual notations, we have little to go on but intuition and rule of thumb - we have neither theory nor a systematic body of empirical evidence to guide us.
The aim of this tutorial is to establish the foundation for a science of visual notation design, to help it progress from a craft to a design discipline. It defines a set of principles for designing cognitively effective visual notations: ones that are optimised for human communication and problem solving. The principles form a theory of visual notation design: this is called the Physics of Notations because it focuses on the physical (perceptual) properties of notations rather than their logical (semantic) properties.
The principles have been successfully used to evaluate and improve several modelling notations as well as to design visual notations from first principles. Importantly, the principles are evidence-based: they are based on theory and empirical evidence from a wide range of fields. They also rest on an explicit theory of how visual notations communicate. The principles provide a scientific basis for evaluating, comparing and constructing visual notations, which has previously been lacking in the RE field.
The tutorial is designed to be highly interactive, with practical exercises on designing and improving visual notations as well as group discussions and brainstorming sessions on the finer points of visual notation design. A range of examples (both exemplars and counter-exemplars) and exercises are used to illustrate the principles,
featuring some of the leading RE notations (e.g. i*, UML, ER, EPCs).
NOTE: The content of this tutorial is based on a paper to appear in the October issue of IEEE Transactions on Software Engineering - this will be available for distribution to participants at the time of the conference. This tutorial will be the first time this work has been presented at a public forum and includes much material excluded from the
journal paper for reasons of space.
T5m.Cancelled Due to Insufficient Registrations Morning: Use of Quality Models in Requirements Engineering and their Application on OTS Components Selection, Juan Pablo Carvallo, Etapatelecom, Ecuador, Xavier Franch, UPC, Spain, 1/2 day
The specification of quality requirements is crucial in order to deploy socio-technical systems. It is necessary to have available models and methods for the elicitation, validation, documentation and management of quality requirements.
Among the existing types of models used by the community, quality models play a prominent role. A quality model defines a hierarchical set of quality factors and their relationships. Quality models have been largely used in several activities and in particular their applicability in requirements engineering has been studied by several authors.
In this tutorial we present our methodological findings and lessons learned on the use of quality models in requirements engineering. The tutorial is divided into two parts.
Part I: General Concepts. In the first part, the basic concepts are explained and a particular proposal is chosen, the quality model proposed by the standard body ISO under id. ISO/IEC 9126-1. Then, we introduce the IQMC (Incremental Quality Model Construction) method for building quality models for software domains, and we present the extensions over the ISO/IEC 9126-1 that we have issued in our industrial experiences, with special attention to the treatment of non-technical quality factors. Finally, the use of quality models in the different requirement engineering activities is illustrated.
Part II: Application to OTS selection. In the second part, we focus on the use of quality models for driving Off-The-Shelf (OTS) component selection. In this context, we highlight the role of quality models as the shared ontology between stakeholders’ needs and OTS components’ features. Then, we pay attention to a particular type of OTS selection processes, namely call-for-tenders, in which different suppliers bid for a public offer. Last, we summarize the main lessons learned in the industrial cases we have carried out in the last years.
T5a. Afternoon: Modeling the Flow of Requirements: Improved Communication and Documentation in Software Projects, Kurt Schneider and Kai Stapel, U Hannover, 1/2 day
Communication and documentation are means to take requirements where they are needed in a project. Tuning communication and the use of documents is a key contribution to improving requirements engineering in practice. The individual needs of a project or an organisation need to be taken into account when the flow of requirements is evaluated.
This tutorial presents a new approach of modelling the flow of requirements in software projects. Participants learn about the fundamental concepts based on practical experiences from industry and research. They see a technique for analysing a project situation, and they learn about using the approach for conceiving a novel requirements engineering intervention by designing the flow of requirements and design. Basic information flow analysis is easy to learn. There are a graphical notation and a few support tools, including templates and checklists for good questions during analysis.
Documents are essential to capture and save requirements, design decisions, and so on. In industry, the effort required for documentation is often considered too high. Surprisingly, many projects suffer from missing documentation at the same time. At this point, information flow modelling enters the stage. It considers flow of requirements through both documentation and oral communication. Documents and oral information flows are modelled and optimized together. The approach combines elements of disciplined and agile development without dogmatic barriers. It does not assume an ideal reference model. Instead, it supports modeling and understanding a software project or situation. Recurring patterns and other findings are identified and can lead to improvements
After a presentation of examples, participants have a chance to model a typical situation of requirements engineering in practice.
T6m. Morning: Good RE for Interface Requirements and Allocation and Traceability, Ivy Hooks, CEO Compliance Automation Inc. (CAI), 1/2 day
There is nothing easy about interfaces and even allocation and traceability can take a lot of work to do correctly. Many of our customers have been making all of this harder than it has to be. This tutorial will give you some do’s and don’ts regarding these topics and walk you through the basic process for each. We will show you why this process will work for you. These are proven practices on many different projects. The intended audience is RE practitioners with experience who want to make writing and managing interface requirements and doing allocation and traceability a little easier.
T6a. Afternoon: Requirements Engineering for Large and Very Large Scale Systems, Brian Berenbach, Siemens Corporate Research, 1/2 day
Requirements engineering processes for very large systems are very different from those for small to medium sized systems. Most texts on requirements engineering, for example, tend to describe small or medium scale systems (up to about 5K requirements), or if the systems are large, describe the processes associated with product development and product lines. Industrial projects, however, start at 20K requirements and up. Furthermore, they are often contracting based, sometimes dealing with large numbers of subcontractors (who often don’t know and don’t care about requirements). The creation of scalable processes that will support a large infrastructure project of the kind we are reading about in the headlines today (e.g. “shovel ready”) can be a daunting prospect. Topics that will be touched on in the tutorial include:
- RE Organization and Processes
- Roles and Responsibilities
- Contract Management
- Management of Regulatory Codes
- Tooling and Tool Chains
- RE Support for Hazard Analysis
- Leading (warning) Indicators and Metrics
- RE Relationship to V&V and QA Processes
- Best Practices for Success
This tutorial will describe some of the challenges associated with the requirements engineering of such large and very large projects, and suggest guidelines for processes and tooling to support them.