Thoughts on Software Engineering Ph.D. Research

I would say that there are 3 main characteristics for a successful Ph.D. in Software Engineering:

• It should be guided by Ethics
• It should be anchored on shoulders of giants, but digging deeper
• Be visionary, be bold

A must:

A software researcher must understand that software evolves, as it is been built, by a social process for a social purpose

Some other observations:

• Industry is a lighthouse, but auxiliary
• The researcher should be ethical in bringing new knowledge to society
• Keep in mind Aristotle’s beginning, middle, end
• Satisfice Transparency (aim to make your work transparent)
• Data is dear, ideas are good, code is king
• Useful OR Insightful?  The difficult challenge of producing valid work that is novel or/and of interest.  This is particular important when dealing with industry related projects.

From the point of view of the advisor:

• Tell the researcher that to succeed there must be a passion for the topic
• Tell the researcher that it is hers/his work
• Guide towards ethics, shoulders and vision

Requirements Elicitation

In the requirements literature there is a lot of confusion about termininology, which is perfectly fine, since this is a young discipline.  In addition, requirements engineering has been approached from different perspectives and viewpoints.

One point that brings different terminology and discussion is about Requirements Elicitation.

I believe that Requirements Elicitaton may be performed by three main strategies: 

1.  model-driven elicitation (where the elicitors gather what the syntax of the modeling language demands), 
2. uncompromised elicitation (where the elicitors gather information from the Universe of Discourse, without any predefined standard/language), and 
3. a mix of the two.

Another aspect that it is also confusing is: what is to be elicited.  Some authors make a distinction among requirements and domain. However, some  mix the idea of domain (a general knowledge that applies to several instances) to context information (knowledge specific to a given environment of a domain).

Although the term requirements have been a placeholder for different semantics, I opt for understanding that a  requirement is a sentence with a unique identifier. 

I gave a keynote talk at Istar'15 that tackles part of the issue: Elicitation Awareness in Conceptual Modeling: The Role of Transparency.

Below I list a series of papers that tackles the issue of Elicitation:

1. Proceedings of the Seventh International Workshop on Computer-Aided Software Engeneering, IEEE Computer Society Press, pp. 260-269, (1995), FAES: A CASE Tool for Information Acquisition. Gilvaz, A.P., Leite, J.C.S.P.
2. WER 2007 p. 25-34 (2007) A Strategy for Information Source Identification. Leite, J.C.S.P., Moraes, E.A., Castro, E.P.S. 
3. Proceedings of the 29th Annual ACM Symposium on Applied Computing (SAC '14) p. 1001-1006 (2014) Eliciting concepts from the Brazilian access law using a combined approach. Engiel, P, Cappelli, C., Leite, J.C.S.P. 
4. Requirements Engineering, 2015, V. 20, I. 2 p. 139-161 (2015), Early identification of crosscutting concerns with the Language Extended Lexicon.  Antonelli, L., Rossi, G., Leite, J.C.S.P., Araújo, J.