WICSA 2009 WS2 -- Stakeholder Concerns
From WICSA Conference Wiki
Session Chairs: Nick Rozanski and Len Bass
Tuesday, 15th September, 13:30 - 15:30
Contents |
Participants (Tentative)
- Please sign your name here if you are thinking of attending this BoF. (Click the signature button in the editor). Tell us something about your background. Add a few sentences about the working session topic such as your position, questions you would like to see discussed, etc.
- (example) --Bob Schwanke, Siemens Corporate Research. Stakeholder concerns should be testable, early and often.
Papers
- "RQ-Tech Method for User-Involved Software Development", by Christine A. Hoyland, and Kevin MacG. Adams
- One of the most perplexing issues facing the United States Department of Defense (DoD) is defining and documenting business processes as a precursor to system and software development. The Reusable Quality Technical Architectures (RQ-Tech) Methodology creates a virtual business environment that empowers business process owners (users) with tools and techniques for modeling requirements in a user-friendly architectural framework. Once a few simple rules are conveyed, the users' model can grow as rapidly as they can search, name, click, and save. RQ-Tech fills the ever-widening gap between DoD- and Coalition Partner-users (requirements generators) and system and software developers (capability providers) by invoking an XML translator disguised as the user's planning environment. RQ-Tech updates a proven modeling technique for documenting processes, controls and mechanisms; while simplifying the model presentation.
- "Detecting Architecture Instabilities with Concern Traces: An Exploratory Study", by Eduardo Figueiredo, User:Ismênia Galvão, Safoora Shakil Khan, Alessandro Garcia, Claudio Sant'Anna, Afonso Pimentel, Ana Luisa Medeiros, Lyrene Fernandes, Thais Batista, Rita Ribeiro, Pim van den Broek, Mehmet Aksit, Steffen Zschaler and Ana Moreira
- Sustaining architecture stability in incremental software development is an important aim for software engineers. Traceability mechanisms can be used to assess and predict architecture stability based on recorded information of early software artefacts. However, there is little empirical knowledge on whether traceability of stakeholders' concerns can assist the identification of architecture instabilities. This paper reports on a first exploratory study that analyses the effectiveness of concern traces for architecture stability assessment. We investigate to what extent properties of concern traces, such as their shapes, are correlated with architectural instabilities. Our analysis is based on eight releases implementing two versions of a software product line for handling mobile media.
Contributions
If you have relevant materials or references, please add here:
Working Session Details
Welcome to the working session on Stakeholder Concerns.
Goal
The guiding principle for this working session is quite straightforward: User requirements drive architecture decisions. Mistakes due to incorrect or incomplete requirements and user specifications still rank the highest for adding cost to the IT project. Keynote speaker Jaap Schekkerman spoke to us about why business and IT professionals do not understand each other and how Enterprise Architects can bridge that gap! From the point of view of the WS #2 presenter, I could not agree more with Mr. Schekkermann. In fact, some of us who live on the interface between requirements generators (users) and capability providers (IT) must try to bridge the gap constantly.
Strategy
To achieve this goal we should be working together. By "we" I mean the requirements generators and the software architects. The systems engineering approach is to identify as many requirements as possible, and organize them. Requirements must be parsed such that they are single phrases, and then identified in a matrix or database for further analysis. But the work of the systems engineer is not complete as she continues to work to model the user's domain to clearly illustrate what the user does, and correctly identify the capabilities the user needs. As a systems engineer, I believe that USE CASES are a poor way of identifying the user requirements. The practice only identifies a small subset of processes and rarely rolls up to a good, representative model of what the user needs. If software architects believe use cases will tell them what they need to know, then they will not have a good representation of what the user needs.
USE CASES are good for test scenarios, and it is the right thing to do to ask for what is your requirement along with "how would you test to see that the requirement was satisfied?" This is a common techniques that systems engineers use because they are educated in building the entire model in s holistic fashion, vice a sequential process that takes much longer.
Results
From the discussion that followed the User-Defined presentation, I got the impression that the user is held responsible for either their good or the not so good requirements they state. I also get the feeling from other conversations that the software architects may be looking to "requirements engineers" to provide what is necessary for the design. I believe that although it may be easier to blame the user, it might be better to be more open to the difficulties in communicating between the users and the IT providers. If users, or requirements engineers for that matter, are not encouraged to share ideas about how to talk about their ideas, then we won't get far. In this way, no one really benefits!
