istar@CAiSE2018 - A Goal Model for Crowdsourced Software Engineering - Fiza Siyal and Xavier Franch

Crowdsourcing Software Engineering (CSE) - emerging paradigm, but a lot of old problems.

He mentioned some problems found in the RISCOSS project, and how risk analysis is very important in Crowdsourcing settings.

He presented a (small) goal-model for CSE

RiSD

This approach includes a decision tree-based set of guidelines for choosing the correct intentional element (e.g. goal, softgoal or task) in an i* model. Such guidelines do not work on 100% of the times, but they provide some assistance.

RiSD comprises three stages:

• Domain analysis, 
• Social system construction
• Socio-technical system construction

In this presentation, Xavi focuses in the second stage, i.e. Social system construction. 

RiSD guides the analyst in:

step 1 - start modeling all dependencies as goal dependencies

setp 2 - reflect if some of the dependums are actually tasks or resources. 

Model 1) He presents a Dependency Diagram, showing the dependencies between the Requester and the CSE Organization and between the Worker and the CSE Organization. 

Model 2) Then, he shows a second model with some of the revised dependums.

Model 3) A third, more refined model also includes some traceability links between elements, as suggested by the results of the RISCOSS project.

Key concerns to be analyzed (according to a different author referenced in his slides):

• task decomposition
• planing and scheduling
• coordinating and ommunication
• intellectual property 
• motivaation and qulity challenges 

istar@CAiSE2018 - Keynote: Oscar Pastor - Making Software Fulfil Users Goals: From Goals to Code

Context and History

If we want to think of Code as a Model, we should also be able to understand Model as Code -- manifesto with Steven Little, Veda Storey at al.

Oscar told us the history of software from object-oriented software modeled with UML, arriving at GORE, going through model-driven architecture, up to the need of ontologies to make the languages' and models' semantics precise.

From Oscar's PhD (1996) - OO-Method Approach (Problem Space level -- Automated Translation -- Solution Space Level (already doing Model-driven development, with automatic code generation).

At this time, he had also a solution to develop web-based systems, and he talked about the business layer (which includes services).

Old Metaphor: software as a table with three legs: structure, behavior and interaction. This view is still useful. Yesterday, he has seen presentations on the structural part (database schemes, information model etc.).

The MDD transformation may be in this direction:
                                      roles, requirements -> conceptual schema -> code

Oscar thinks Information Systems engineering is more important than Software Engineering, because it is important to handle with socio-technical systems. In ISs, we have not only technical people working, but also lawyers, and other people from the social sciences.

There is an emerging need to focus on interactive requirements - the main thing we must target is our perception of the world. There are different means of interaction between the analyst, the stakeholder and the world, so we must put lots of attention to interactive concepts and interactive requirements.

Since the beginning, Oscar's work focused on providing automation for the software development process, focusing on the whole life cycle. With Hugo and Alicia, he worked on what they called "a complete model based software production process."


Model-driven Engineering: a Practical Experience

He presented the usual MDA models and transformations, connecting them with RE (Computation Independent Model), Software Analysis (Platform Independent Model), Software Design (Platform Specific Model) and Implementation (Code).

He thinks that having an OntoUML compiler that generates code directly could be a good idea.

For model transformation, there are several tools, both for the transformation itself and to each of the modeling languages we must apply. He showed a big list of existing tools.


Communication Analysis: a Requirements Engineering Method for Information Systems

Sergio España's PhD work: still ongoing in terms of using, improving and automating the method.

Oscar highlights that opposite to other kinds of models (such as data models, business process models etc.),  there is no standard language for interaction/presentation model. Giancarlo highlights that there are some standard developed for protocol engineering which may be useful here: e.g. ISDL (see https://link.springer.com/book/10.1007%2F978-3-319-43298-4).

To add to the discussion, in the perspective of HCI, Eric mentions that possibly the work on ISDL cannot capture the complexities of human interaction. In fact, Giancarlo says, interactive and presentation modeling are two different things anyway. Oscar acknowledges that these two perspectives are sometimes inappropriately mixed.

Oscar has a strong opinion that if a software engineer does not have strong skills on abstraction, he/she should not have his/her degree. But in practice, he realizes that most of his students in the master level do not. For example, they mix in one model, things that belong to different abstraction levels. That is a big problem!

Oscar showed an example of a socio-technical system to motivate the use of communication analysis. The main problem in such scenarios is one of communication.


Deriving Conceptual Models from Req Specifications

They propose in OlivaNova (see this article), a Requirements model is compiled into a conceptual model (composed of structural model, communication model and business model).

They apply conceptual schema to generate the class-diagrams they need. This is done interactively.

And in the end, they can also generate code and view the user application.


Linking Goal Models with Communication Analysis Models

Still, there is one missing dimension in this work: the connection to goals, as they understand that the intentional dimension is important to understand why the business processes are executed.

Their work aims at connecting: intention + processes and communication + behavior + interaction

Advantages:

• integrated approach allows understanding the motivation for processes
• goals can be used to guide process design
• traceability is enhanced
• sustainability in organizations may be achieve

In this work, they apply a design science approach.

They use the FRISCO Ontology to connect i* and communication analysis (the integration should be well founded in theory).

They provide some guidelines of how to go from i* to the process and communication models.

Oscar says that there is an important issue to be targeted, which is the point that people prefer to use BPMN and not the business process modeling language that they propose.

Notes on the RE PhD Course - University of Trento - Class: RE Methodologies - Angelo Susi

Notes on the RE Course - Requirements Engineering Methodologies - 

*while Angelo projected the Day4 slides

The Spiral Model (Boehm 86, 88) is a very well-known iterative model. The interesting thing he wants to highlight is Risk Analysis.

We talked about some examples regarding data protection. For instance, many emails are coming now asking us to click a link in the email (a well-known major source of problem!) to confirm the new policies of different sources, complying with the new European Policy for data protection. So in the end, such policy is inducing a strange behavior on companies and end users. It seems that nobody has performed risk analysis.

He also mentioned the fact that such model inaugurated the software evolution concept connected to software maintenance.

Relying on a risk assessment expert for knowing how to proceed is a good practice.

The Rational Unified Process has been proposed by the Rational company in an attempt to start with business analysis (Inception phase).

I reminded the students that this process was actually empowered by this very popular case tool in the 90s, called Rational Rose. This was a UML modeling tool, which also generated Java code. Angelo complemented saying that besides the emphasis on business modeling, for the first time, somebody allowed software production from start to end (including code automatic generation).

"RUP is a process framework, but unlike ISO 12207, it comes not empty, but prepopulated with a wealth of guidance, methods, techniques, templates, and examples, out of which a concrete process can be instantiated. RUP can actually support an organization that is trying to achieve CMM Level-2 and Level-3" (from the slides)

RUP's emphasized the development of a standard development process.

---

There was an interesting discussion regarding Open Source.

Student A said "Open means that you have open access to knowledge, not that you have unrestricted use of the artifact (i.e. code)."

Angelo reminded us that there are different Open Source models. The problem with OS models is attributing responsibility. Who is liable if something goes wrong?

RISK ANALYSIS IS ESSENTIAL HERE!

Student B said Red Hat, the biggest Linux distributor, gives you the license to contribute, and you can even earn money for producing some enhancements. However, regarding the kernel, this license  does not allowed you to publish any enhancements. This company is worth billions in the marked, so you can trust it.

This is what a lot of CEOs of big organizations take into account to hire OS services.

*I do not agree that you can trust it based on the market value! : ) At least for end users, we must be aware that we give lots of access to big companies, but I am willing to give the same access to small companies, provided that they provide me with useful service that eases my life. It is not a solution for the problem, of course. It is just awareness

Student A joked: for a solution, please read the books by Mauro Corona, who lives in the mountains, with no technology whatsoever!

Angelo: sometimes governments go into OS community to influence them to add new requirements to the software so that it accounts for some ethical issues that allow such government to use the developed software in hospitals or other sensitive environments.

Interesting reference on OS licenses: Roberto di Cosmo.

---

*back to the slides - still on Open Source:
Walter Scacchi (U California, 2003) is one of the most important researchers in OS Communities.

There are several communication tools that support OS communities (threaded discussions, newsgroups, email etc.) and .

There is a high degree of informality: to-do-lists, FAQs, communities' website, bug reports, bug database tracking (E.g. Bugzilla) etc.

Agile Methodologies

*interesting slide comparing agile vs. standard approaches.

Scrum
Requirements are expressed like user stories, following simple templates such as:
As a <role>, I can <activity> so that <business value>

Dynamic System Development Method is an agile method, a bit heavier than Scrum, but that tries to improve Scrum in some points. It may work for some domains.

Such methodologies may completely change the company's power structure. The new roles agile methods propose prevents some people to be recognized as, for instance, analyst (or another kind of) expert in the common sense. This may lead to some resistance from the personnel.

*interesting slide on a REFSQ paper that presents examples of how companies use agile methodologies.

Microservices inaugurate a different perspective on software development. For one micro service, there are different experts involved AT THE SAME TIME, thus there is no division of roles by development phase or activity, as before. See the work of Luciano Baresi, already referenced in the previous post.

Notes on the RE PhD Course - University of Trento - Class: Requirements Prioritization - Angelo Susi

Notes on the RE Course - Requirements Prioritization  

*while Angelo projected the Day3 slides for recap

Luciano Baresi – micro-services (pieces of code that are very good for Agile Team Development – they have a precise goal – not the same of micro-goal, simply precise)
Here is one of his interesting papers

For that to work, you need:

-      Reliable information/documentation about the micro-service

-      Well-developed interface to enable interconnection.

Release Plan– 

*The PhD work by Azevedo, C. seems to be of particular interest.

We must apply algorithms that are agnosticto the problems. The same algorithms that exist for so many years (e.g. genetic algorithms, markov chain based algorithms etc.) may be used to solve new problems. 

These algorithms are sensible to small changes, so you must FIRST understand the problem. 

In terms of agnostic algorithms, the human intuition works like this: the algorithms give you the RIGHT QUESTIONS to ask the stakeholders to find out the information you need.

What to do about the consistency of human information? People may lie, ignore or be bound by ethics not to disclose some information. Angelo says that there are existing decision-making algorithms that enable consistency check using mathematics.

Pareto Optimality in multi criteria

*send to Angelo the reference by … at CIbSE 2018

Interesting discussion on the kinds of approaches to solve the problem: kinds of algorithms and the tradeoff human automated vs. human assisted.

Very interesting slide on RE Prioritization Works in Literature 

Setting requirements with actual measures 

Characteristics of requirement B (on slide): 

-      Title

-      Description

-      Cost of implementation

-      Risk

-      Value for stakeholder

In practice, there is only partial knowledge about each requirement. In company A, for e.g. there are written requirements (text-based) in a worksheet and for 1 requirement in 20, there is an information given by the manager, e.g. “high risk”.

Analytic Hierarchy Process 

Very interesting decision-making algorithm;

Angelo explained it really well!

*Rank Boost (Freund, Iyer, Shapire and Singer 1998) – according to Angelo, a very well-written paper. I found a 2003 paper of this group.

Very interesting Machine learning algorithm  (named CBRank) by Angelo, Anna and Paolo Avesani. Paper on Transaction of Software Engineering 2013. A previous version was published in the RE Conference. 

To learn, the ML algorithm (named CBRank) compares its own results to rankings done by users (called domain knowledge in the algorithm). The principle was combining machine and human-based knowledge.

Disadvantage(according to a Mirheidari): linear learning. With a new/updated domain knowledge, you must of course update the pair sampling. However, you must wait for the system to learn, because it only works well after lots (let’s say 100) iterations.

*Angelo replies: ok, but we can also change the algorithm, which is an old one. However, if you read the 1998 paper, you will see that they talked about user feedback already at that moment.

*Mirheidari presentation in the class:

Paper about detecting problems in decision-making regarding security.

Categorization of over 100 works

Ref: Seyed Ali Mirheidari, Sajjad Arshad, Rasool Jalili. Alert Correlation Algorithms: A Survey and Taxonomy In: CSS. 

Similarity algorithms

Knowledge-based algorithms

1)   Pre-requisite and consequence

2)   Scenario

Statistical-based algorithms

They discussed advantages and disadvantages of these works based on 5 metrics that are related to their work:

-      Algorithm capability

-      Algorithm accuracy

-      Algorithm computation power

-      Required KB

-      Algorithm extendibility and flexibility.

*After the survey, he designed a hybrid approach to maximize the probability of finding the attack.

Another good survey (Seyed says even better than his): Alert correlation survey: framework and techniques. Sadoddin and Ghorbani (2006) Alert correlation survey: framework and techniques at PTS'06

Empirical Study

Angelo made a very good description of their empirical study to validate CBRank. 

Search-based approach - Angelo explained an approach based on Interactive Genetic Algorithm (IGA).

In this algorithm, an individual is a complete rank of requirements.

Getting information from the user works by restricting the population (in other words, increasing the number of constraints). An important point here is to minimize bothering the user, while also taking from her the right kind of information that will make the algorithm better (better means faster, more accurate and having less conflict).

The Production of individuals phase may also work well to generate test cases for the algorithm.

After the production of individuals, you may have conflicted individuals and this is made explicit, so that we may ask the users preferences regarding such conflict.

CibSE 2018 - Requirements Engineering Track (WER) - Session 2 - RE@Industry and Emerging Trends

La Elicitación de Requisitos No Funcionales en el Contexto de la Industria del Software: Un Reporte de Experiencias
Sandra Lorena Buitron Ruiz and Francisco J. Pino

Goal: Find out how the medium and small organizations are conducting the NFR elicitation activities using the MREliNN framework.

They start by understanding the Business Processes. They use a method called ERNF, which is part of the applied framework.

This method has three dimensions: Knowledge, Technical and Organizational dimensions.

They applied the study in 9 projects of 4 existing companies, in the areas of Health, Services and Education.

She presented a list of observations that were gathered in the application of the project.

Then she presented a list of lessons learned in the application of the project.

Among the limitations, she mentioned the lack of a process for the elicitation of NFRs by the company limited the efficiency of the application of the method and limited availability of the project leaders.

She concluded by saying that there is an intention by several companies to adopt RE activities to elicit and analyze NFRs, but now the practice is very ad-hoc. They need tools to help automate the process of application of the method they applied.

As future work, she mentioned a few goals to improve MERliNN.


Ontología para la Especificación de Casos de Uso, Casos de Prueba y su Trazabilidad
Marcela Vegetti, María Luciana Roldán, Marcelo Marciszack, Silvio Gonnet and Horacio Leone

Tools supporting Use Case specification and Test Case Management are not integrated. They propose the use of an ontology of requirements and test cases to support that, improving the traceability between the produced artifacts.

Methodology:
- requirements specification:
- semi-formal conceptualization using UML class diagrams.
- implementation and formalization
- evaluation in terms of the specified requirements

For the requirements specification, they defined the ontology scope, elicited competency questions and then identified some concepts related to each competency questions.

She showed two UML class diagrams, one for Use Cases and another one for Test Case Management.

Part of the work reuses previous work of the group on use cases consistent analysis. They propose the application of an analogous technique to define the test cases. Thus, the concepts regarding such work have been included in the ontology, serving as a way to integrate Use Cases and Test Cases.

She showed a UML class diagram focusing on the artifacts for which traceability is required. This model is composed of concepts modeling the artifacts and the type of traceability that may be provided between them.

The ontology was implemented using Protege.

As validation, she gave some reasoning examples allowed with the ontology that match the elicited competency questions

Other ontologies in other software engineering sub-areas may be integrated with the developed ontology to provide traceability between other software engineering artifacts.

Q&A:

Regarding the competency questions, she said that they were elicited by the authors of the work, based on their previous knowledge about the domains being modeled. They used the general question grouping, refining and abstracting to get to the final set of questions. Beatriz mentioned that this process can leave out some important questions.

* Competency questions remains as the main used techniques for requirements elicitation. However, this is not very efficient. Indeed, the ontology engineering community usually ignores the RE findings which can be useful to help elicit, analyze and document requirements. We should fix that!

*There have been works from NEMO using:

1) goal-modeling to come up with the competency questions for ontology development.

2) using the results of a systematic literature mapping to support the definition of competency questions.


Do users talk about the software in my product? Analyzing user reviews on IoT products
Kamonphop Srisopha, Pooyan Behnamghader and Barry Boehm

Two challenges in investigating products reviews

- huge volume of data (velocity might not be as high)
- cannot assume that sentence are related to only software (also hardware, service etc.)

What kind of information we can get out of a user review: user background, hardware complaint, product general evaluation, general evaluation, general evaluation comparing with competitive product, software feature request, software praise, software praise comparing with competitive product.

Goal of this study: study if and how much users talks about the software in an IoT product and how it can be beneficial for software engineering:

RQ1: how can IoT product review be categorized?
RQ2: How much information in the studied product reviews is relevant for software engineers
RQ3: how effectively can machine learning techniques classify such reviews?

1) For  responding RQ1:

Their study looked as data having a sentence-level granularity.

Top level categorization (based on the domain) - To come up with the categories for his dataset, he made a study based on his own categorization and the categorization of 52 master students.

Second level categorization (based on what kind of informations messages provide): For the message types, he applied an existing user feedback taxonomy classifying the types of  messages there are in product review.

Four types considered: Information Giving, Inquiry, Feature Request and Problem Discovery

2) For responding RQ2:

They made a manual classification of the dataset according to the categories defined in 1).

He showed some results of his findings, also discussing some related works.

3) For responding RQ3:

They used a text processing technique based on the vector model (using TF-IDF metrics). They used Word2Vec (distributional hypothesis approach), which states if two words appear in the same context, they have similar semantics. The approach plots words in a matriz, showing graphical proximity of semantic related words.

He presented his findings on the use of such method.

Q&A:

* I believe there is room for the use of semantic-based approaches (ontology-based reasoning) in connection with the machine learning techniques. He said he did not think about it but he thinks it can be useful.

He wants to look for Sentiment Analysis and to an Ontology on software quality to help improve their categorization. 

CIbSE 2018 - Keynote Speech - In Quest of Requirements Engineering Research that Industry needs - Daniel Méndez, Technical University of Munich, Germany.

In Quest of Requirements Engineering Research that Industry needs
Daniel Méndez, Technical University of Munich, Germany
Daniel very kindly made his slides available at https://www.slideshare.net/mendezfe/in-quest-of-requirements-engineering-research-that-industry-needs

Guest Editorial Reflections on Requirements
Since the first paper published in RE in 1977, the social challenges we still face today. He talks about a Human Social Environment in which lie human needs and an intangible dimension.

Today, it is easy to find examples of industrial projects that fail due to a poor understanding of the system requirements.

As an example, he talked about this case:
http://www.dw.com/en/germany-seeks-toll-collect-compensation/a-1324248

33% of problems in software are related to requirements.
36% of the RE problems lead to software project  problems.

Now, our challenges are bigger because we have distributed systems (as discussed yesterday in Sharan's keynote)

Some of the research targets problems that are ill-understood and they "pretend" to work universally, when they in fact do not.

No matter how you look at it, there is a gap between RE research and practice

So how can we develop research that is in fact needed by industry?

1) Turn RE research into a theory-centric discipline

He gives an example in GORE (citing a literature review paper by Jennifer Horkoff), which shows that from more than a hundred reported case studies in the literature, only 20 were "real" case studies, like the ones discussed by Fabio, on the first day.

He makes a joke: there are more people believing in elves (54%) than there is using GORE in industry (5%).

RE is largely dominated by conventional wisdom

• Lack of empirical awareness
• Neglecting particularities of practical contexts
• neglecting relation to existing evidence 

First take of this talk is:
We should change from conventional wisdom to evidence based, theory-centric, context sensitive RE research.

One of the biggest problems at this moment is the lack of data, especially because this is the kind of sensitive data that industrial partners are reluctant towards giving access.

2) Understanding the practitioner's problems

NaPIRE - http://www.re-survey.org
They are performing a bi-yearly replicated, globally distributed family of surveys, based on collaborative design, analysis and synthesis.

The goal of this survey is to understand the status quo in practice w.r.t: Req. Elicitation, Req. Documentation, Req. Change and Alignment, RE Standards and RE Improvement.

He shows a chart created as a result of this survey, analyzing many problems such as: insufficient support from project leader, inconsistent requirements, unmeasurable NFRs.

He also shows a model in which he analyses the problems happening as result of customer communication flaws.

One thing he started to investigate is if the agile methodologies, which supposedly take into account communication with the customer are actually doing it.

Empirical studies should try to understand the following dimensions.
context - causes - problems - effects
This is the approach they take in NaPIRE.

How can we profit form NaPIRE:
- The results of the survey are available for public use.
- He also invites us to join the initiative.

There are other initiatives worth joining, e.g. RE Pract, Elena

3) Academia and Industrial Collaboration

He gives some personal examples of participation in industrial projects, some of which were successful also for research purposes, and others weren't (mainly for social reasons, such as data access).

Success factors for collaboration with industry (according to practitioners):

• Shared-long term vision and project goals
• Common problem- and domain-understanding
• Proper project organization: manageable-sized sub-problems, minimal-invasive solutions, regular on-site work and meetings, fast feedback loops
• Proper mindset and principles: pragmatism and lack of idealism when solving industry problems.

Challenge: engaging in academia-industry collaboration while preserving our integrity.

---

Q&A:

One thing we should understand is that RE is very, very young, when compared with existing sciences, such as physics, for example. 

Instead of saying we need agile RE, we should be investigating in which conditions is agile RE appropriate for a particular industrial sector. 

For a long time, in model-based system development community, we've been talking about meta models and we should have into account that the meta model's developer and reader have their own mental models when writing and interpreting such models. And in RE, we are just in the beginning of understanding how to target this problem. To enable shared semantics is very important.

Roel says that the difference between research and consultancy is that for the latter, we are aiming at solving a problem that has been solved many and many times before, while this is not the case for the former.

Replicating case studies should be done so that we can compare results. However, they are rarely accepted as publications because people claim that case study has been done. 

I raised a question regarding what kind of evidence is expected from a research papers so that the work is considered as consistently evaluated. This is a problem for us (outside the empirical studies' community) because it is impossible to have the kind of rigor that is sometimes expected from us. Daniel said that he thinks that publications having only claims have a place, so as to raise discussion. The biggest problem he sees is the strong claims that people do without having evidence to support them. If a researcher claims something works in a particular condition, some evidence should be provided to support it.

CibSE 2018 - Requirements Engineering Track (WER) - Session 1 - RE@Agile and Big Data

As técnicas de elicitação e de documentação de requisitos nos métodos ágeis
Angélica T. S. Calazans, Roberto Avila Paldes, Eloisa T. S. Masson and Fernando De A. Guimarães

The principles of Agile Methods should be taken into account to create new RE approaches that are also more agile.

The present literature on Agile RE takes focuses on the academic view on the subject. They would like to complement this view with new studies that take into account the industrial view.

They developed a case study on the development unit of a Higher Education organization.

This study started by listing from the literature, the applied elicitation and documentation techniques; and by developing the software developers' profile.

Then, they applied questionnaires in three rounds to understand the most used techniques. The study at first generated results that were not statistically significant, but new rounds have been performed to reach consensus on the results. In these other rounds, the list of techniques have been reordered, based on the results of previous rounds. With this method they managed to reached consensus.

Most important techniques according to their practice:
- elicitation: Interviews, brainstorm and user stories
- documentation: Tasks, user stories and prototypes.

They also discuss the changes in the results, i.e. techniques that started with less consensus and ended up with more; techniques that showed more stable consensus since the beginning.

Q&A:
Observation by Marcos and Marcela that a case study should focus on what is being currently used int he organization, and not what the software engineers think they should use.
The authors argument that they aimed at understanding what the effective techniques are. But Marcela thinks that another kinds of more exploratory study should be used to understand that.

*The question is what leads to the consensus reaching from one round to the other? Doesn't the reordering induces the responses? Is this good or bad?
The authors responded that in the first round, the participants responded alone; in the next ones, possibly, they talked to each other.

There was a comment about the appropriateness of the techniques according to the characteristics of the project. Perhaps new studies could try to understand if these characteristics (size, time, cost etc.) would change the response.


Mapeamento dos processos e artefatos da Engenharia de Requisitos para o eXtreme Programming
Ricardo Duarte Cardoso, Renata Brasil-Silva and Fábio Levy Siqueira

Objective: analyze how an agile method (namely, eXtreme Programming - XP)  complies with the best practices of the traditional RE approaches.

They mapped the processes and artefacts of the ISO 29148 to XP's practices and artifacts. They applied another ISO standard to support the evaluation of how to compare two distinct processes.

For which item, they gave a grade: not comply, partially comply, highly comply and fully comply.

Threat: this mapping was made according to the understanding of the authors, which is highly subjective.

The author presented some examples to illustrate how this mapping was made.

Two charts were presented, showing their results: one for processes and another one for artifacts.

They concluded that the XP covers well the processes and the artifacts of the norm

The author thanked the company where he works (ProSimulador), which financed his attendance to CIbSE.

For the future, they want to investigate how the XP methodology can be improved to cover better the practices and artefacts that are not well covered today.

Q&A:
*I made an observation regarding the big threat of this kind of work, which is the subjectivity. Probably, if three other authors had made the same study, the result could be different. I suggested other kinds of empirical studies could be sought to make an analysis with a similar objective.

*Giovanni also made a comment on which XP documentation was used for the mapping, because it is difficult to find a standard XP (he used a book on XP 2.0); and about the profile of the participants. This has to be made explicit, because people from industry and academia may have different ideas on the mapping. He said that two of the authors are from the academia and he is from industry, all three of them are Requirements Engineering people.


Modelado de Requisitos de Seguridad para Big Data
Julio Moreno, Manuel Serrano and Eduardo Fernandez-Medina

Big data is not only about data volume.

Properties to consider when connecting two nodes of data: volume, velocity, variety, veracity and value

So how to connect a new data node to the existing big data cloud?

Their objective is to propose a Requirements Elicitation Framework - they propose that abstraction is necessary to solve this complex problem. So there should be an architectural model which considers the common elements of the data nodes being connected.

He presented a meta-model for Big Data Security Requirements.

Then, he presented an agile approach to make requirements analysis in this context. It starts with identifying the Big Data goals and scenarios. Then, the requirements are defined guided by: Big data goals, organizational context, regulations, scenarios and requirements artifacts.

He gives an example in which the security requirements are focused, having different types: analytical requirements, privacy and security, functionality, hardware etc. For analyzing these requirements, they create a table: for each of these requirements types, the five dimensions discussed before (volume, velocity, variety, veracity and value) are analyzed.

Q&A:
The model generated (i.e. the table) is a very abstract high-level view on requirements to guide the users on choosing and connecting data nodes.

In his literature review, he said that he noticed that many companies want to do Big Data, but they do not know exactly why. They just want to use what others are doing.