Group 2 Q&A Elvira Jonas Matthias Reetta Rehan
Summary of User-Centered Requirements engineering chapter 1 to 4 Chapter 1: A introduction to what Requirement Engineering is (RE). It also discuss the importance and the problems with RE. People Communication (Non-)Functional Requirements Documentation
Summary of User-Centered Requirements engineering chapter 1 to 4 Chapter 2: This chapter deals with different aspect of understanding people, it handles different kinds of memory and social structures which must be considered when designing. Memory Limits Models Human errors
Summary of User-Centered Requirements engineering chapter 1 to 4 Chapter 3: Here we handle how to Elicit Requirements and how to build suitable models of the design. There are a lot of analysis involve in this chapter describing how to get the right Requirements. Requirements Modeling Validation
Summary of User-Centered Requirements engineering chapter 1 to 4 Chapter 4: Understanding Requirements Conversations, What good is requirements if we can't talk about them? We need a common way of communicate. This chapter gives a greater understanding of the importance of a good communication during the design. Communication Connections Dependencies
Question 6.1 “Are there ways to safeguard against the limitations of the human memory when eliciting requirements?” For stakeholders it is important that we have a clear way to communicate and to validate that they actual are talking about the same things as the designers. Sometimes it can even be necessary to educate the stakeholders so they really know what they want. And it is important not to put to much pressure at the stakeholders. It is important to give the stakeholders time to formulate their visions for the design and not to force them into deciding upon anything. But if we looking at the limitations of the designers it can be hard to safeguard against it. Then we need to have a better recruiting if their memory fails them when eliciting requirements. So the best safeguard is to be prepared for anything and even have backup plans for the rest. Another thing that is important is to have a lot of resources and time. There where very little information about this subject around, most papers are about how to eliciting requirements, and all of the papers points at the benefits you get by doing a good and proper eliciting.
Question 6.2 “How should we deal with contradicting requirements in the best way?” I don't know exactly what the best way should be, are there any best way? I think there might be several best ways depending on what kind of requirements we have. But here a re some way to handle it. Desirability Functions, By using a risk factor R(A) that is defined as R(A) = P(A)L(A) where P(A) is the probability that the activity A will happened and L(A) is the calculated Loss if A occurs. Then by using some functions you can plot the R(A) and then see what the worse case outcome might be and also where we have critical aspects. The benefit with this kind of functions is that we can see what parts of the design we need to prioritize, and also the total minimal loss for different solutions. //Zsolt Réthy & Zoltán Koczor & József Erdélyi, University of West Hungary, 2004 When dealing with new technology it is often hard to get a correct set of requirements from the users in the beginning, One approach to solve this is to make very early prototypes that lets the users to get a feeling of what the system will do. And it is then easy to make early changes in the requirements to avoid the contradiction. //Alon Ravid & Daniel M Berry, Israel Institute of Technology Haifa
Question 6.3 “Are there smart ways to deal with NFR that can't be broken down to FR? (except for goal-question-metric strategy)” The Holistic way, some times the NFS can be so complicated that breaking them down will change the original idea and the it can be better to keep the NFS so the stake holders know what we want to achieve. To make this to fit into the design cycle we need to have a open discussion with the stakeholders to increase the understanding of the subject. This can be achieved by having workshops with the stakeholders. // Albin Zuccato, University of Karlstad, October 31 2003 NFR-assistance, This is a framework that will help the developers to transform the NRF into softgoals the will be tied together with interdependency links which represent the relationships between the different softgoals, the framework also provide a language to categorize the softgoals in different categories depending on the impact of the design. The soft goals can now be describe together with common boolean algebra and you will be able to get a more scientific overview of the different softgoals. //Quan T. Tran & Lawrence Chung, University of Texas at Dallas, October 15 1998
Question 5.1 There can be a mistake while understanding a person when doing a requirement analysis. How do you think we can address mistakes due to lacking knowledge in a particular domain? - Eliciting requirements only first step - Requirements have to be modelled (e.g. Data Modelling, Behavioural Modelling and Domain Modelling) - Domain Modelling maybe the most important part, because it tries to summarize the problem domain in an abstract way * Misunderstandings can directly be identified by stakeholders * Gives a base for underderstanding for every party involved - Validation of the requirements is always an important part of the process * Models are always incomplete * Models sometimes results of compromises between several stakeholders (Requirements Engineering: A Roadmap - Bashar Nuseibeh and Steve Easterbrook - http://mcs.open.ac.uk/ban25/papers/sotar.re.pdf)
Question 5.3 Should we regard a product as a success even if the designers didn't fulfill the requirement but the product sells? - Only partly a problem of requirement engineering - Requirements define goals which have to be met - When a design is used, without meeting the predefined requirements, the design process itself is violated - Exit conditions (for cancelling the design iterations) are most probably also defined in the requirements
Question 7.3 In todays requirement engineering processes, "automated support" is almost an unskippable phase of the functional allocation. How could we best use "automated support" in order to help user achieve their goals? - Funtional allocation deals with the deligation of tasks to several entities (users, computer algorithms etc.) - When task consists out of several dependent steps, which can be expressed by an algorithm, it is a candidate to be automatized - Interaction between users and automated systems has to be kept in mind since both parts co-evolve, so that their type of interaction changes over the time -
Question 7.3 cont. For a RE it is important to look at every detail of a usage scenario to keep track of all kind of interactions of the participants - automated support is very usefull for monitoring tasks and repeated actions which can be scripted and/or described in an algorithm - normally decision tasks are never delegated to automated systems - only suggestions are generated by an automated system (Function allocation: A perspective from studies of work practice - Peter Wright, Andy Dearden, Bob Fields - http://www.cs.mdx.ac.uk/staffpages/bobf/papers/func-all.pdf) (Function Allocation: Optimising the Automation Boundary - Catherine Cook and Colin Corbridge - http://ieeexplore.ieee.org/iel5/6803/18256/00842704.pdf? arnumber=842704)
Question
Recommend
More recommend
