Luisa Mich: John, can you please briefly describe your RE background?
John Mylopoulos: I am professor of Computer Science at the University of Toronto since 1970, now retired. For the past 49 years, I have conducted research in Artificial Intelligence (AI), Databases and Software Engineering (SE), specifically Requirements Engineering (RE). My involvement in RE research started in 1978 when I was asked by a prospective PhD student, Sol Greenspan, whether I’d be willing to work on a formal specification language for requirements. I agreed, and the result of our efforts was one of the first formal requirements modelling languages (RML), presented at ICSE 1982. This was followed by a new proposal for an extensible requirements modelling language (Telos) that could be extended to support requirements and domain modelling and analysis for different domains (e.g., cyber-physical systems, socio-technical systems). Our research on RE continued with a proposal for modelling and analyzing non-functional requirements as “softgoals”: goals that have no clear-cut criterion for their satisfaction. In the same period (early 90s), we proposed a requirements modelling language (i*) that viewed requirements in a social setting consisting of actors with associated goals who depend on each other for the fulfilment of their goals.
Objectives and scope of the discipline: have they changed?
I think not. The main objective of RE was, and remains, to develop concepts, tools and techniques for eliciting, modelling, and analyzing stakeholder requirements to produce a requirements specification that is complete, unambiguous, valid and consistent. What has changed is that today we distinguish between stakeholder requirements that describe stakeholder needs or goals, and functional and quality requirements, which make up a requirements specification for the system-to-be. The scope of RE has also broadened to include new classes of requirements, such as legal requirements derived from laws and regulations, security and privacy, adaptation requirements for adaptive systems, and more.
Open problems: which are the most critical issues?
I will mention two. Firstly, we do not have yet a comprehensive framework for tackling the requirements problem, i.e., a set of concepts, tools and techniques that support the elicititation, modelling and analysis of stakeholder requirements to produce a requirements specification that is complete, unambiguous, valid and consistent. Although there has been progress on specific aspects of such a framework, we are not there yet, by a long shot. Secondly, even though there is ample evidence that RE constitutes the riskiest phase of software development and the cause of most failed projects, there is still resistance to paying proper attention to this phase in Software Engineering practice. This has resulted in failed projects that constitute an embarrassment to our profession. For the latest such fiasco in Canada, check the Phoenix Payroll Project: This is a system whose original development project was costed at less than CAN$5M, has cost the Government of Canada almost CAN$1B so far, and will be scrapped altogether once a replacement is available. And remember, the most popular software development technique, agile, only pays lip service to RE and doesn’t work at all for non-functional requirements.
Certifications: is RE certification relevant?
Given the problems noted above with respect to RE practice, I think that certification needs to be made mandatory for practicing requirements engineers. If we are to take seriously the ‘Engineering’ part of RE, we should insist that we do what all other engineering disciplines do: make certification a requirement for RE practitioners.
AI challenges: are they changing the role of RE?
AI systems, such as autonomous vehicles, autonomous weapons and robot-doctors do not change the role of RE, only its scope. Such systems call for new classes of requirements that need to be studied and analyzed by RE researchers so that we develop techniques for operationalizing them. Among the new classes, I note ethical requirements which are derived from ethical principles. For an autonomous vehicle, these might include being considerate to nearby vehicles and pedestrians. For an autonomous weapon, on the other hand, these would include not firing at non-combatants. Such requirements would be operationalized in terms of new functions, such as being able to recognize a nearby vehicle, pedestrian or a non-combatant, along with dos and don’ts on what can be done with instances of each class. Fairness requirements constitutes another class of requirements for machine learning (ML) systems that make sure that no class of users in discriminated against on the basis of race, religion etc. This is a critical issue for ML systems because what they learn is based on the training data the system was trained with. Explainability requirements for ML systems are a special class of transparency requirements that is also critical and hinges on the fact that such systems learn in terms of probabilities on patterns of raw data, rather than higher-level concepts. This means that a face recognition ML system has a model of the face(s) it recognizes as probability distributions on arrays of pixels, rather than in terms of shapes of constituents of a face, e.g., eyes, mouth, nose, etc. This means that the ML system cannot give a conceptual description of a face, and therefore cannot explain why a particular pixel pattern is/isn’t that face. In conclusion, I think that RE has a huge role to play in the design of AI systems. After all, such systems are still software (more precisely, cyber-physical) systems.
Thank you for having shared your thoughts with us.
- [1] Source of the photo: webmagazine.unitn.it
Comments (4)
Nice article. About AI reqs, the presentation and maybe research by Prof Vogelsang is of interest. His presentation from 2009 gives an idea how to specify and work with "artificial intelligence"
Nice interview, thanks for the insights.
I wonder what recent empirical research underpins this statement: "there is ample evidence that RE constitutes the riskiest phase of software development and the cause of most failed projects, there is still resistance to paying proper attention to this phase in Software Engineering practice"
The evidence that RE is the riskiest phase of software development comes from industrial studies performed by the Standish Group in the 90s and others more recently.
The three most important success factors and failure ones all have to do with stakeholders and requirements - extract from a slide presented 5 years ago on occasion of an RE talk:
Causes of project failure: Survey of US software projects by the Standish group
Successful
Challenged
Cancelled
Top 3 success factors:
1) User involvement
2) Executive management support
3) Clear statement of requirements
Top 3 factors leading to failure:
1) Lack of user input
2) Incomplete requirements & specs
3) Changing requirements & specs
(also see: http://calleam.com/WTPF/?page_id=1445)
The details on the Standish Group studies come from Al Davis’ textbook on Requirements Engineering.
Interesting article!
Especially the part of AI systems and the new scope of requirements that lay ahead.