A Requirements Engineering Process for Embedded Systems

1. A Requirements Engineering Process for Embedded Systems Tarcísio Couto Pereira tcp@cin.ufpe.br Advisor: Jaelson Castro Co-advisor: Fernanda Alencar

2. Outline • Context and Motivation; • Research Goals and Questions; • Systematic Literature Review; • Requirements Engineering Standards; • REPES Process; • Assessment and Evolution of the Process; • Conclusions.

3. Context and Motivation

4. Context and Motivation • BROY. (1999) define Embedded System as a system that regulate a physical device by sending control signals to actuators in reaction to input signals provided by its users and by sensors capturing the relevant state parameters of the system. • According to BROY; STAUNER (1999), in the embedded system domain, more than 50% of the problems occur when the system is delivered (misconceptions in capturing requirements). • The use of RE good practices is associated with the success of development or software maintenance, especially if software is critical and complex (ALENCAR, 1999).

5. Context and Motivation • Embedded Systems complexity. • There is a shortage of processes, methods, techniques, and requirements engineering tools specially developed for the ES domain (OSSADA, 2010); • In order to verify if RE is a problem in the ES domain, we performed a SLR (KEELE, 2007) to evaluate and synthesize the evidence available in the literature;

6. Research Objective • This work proposes a particular requirements engineering process by providing roles, inputs, outputs, techniques and work products for correct requirements development and management for the scope of embedded systems.

7. Research Questions • RQ1. What is the state of the art on requirements engineering for embedded systems? • RQ2. What should be taken into account in the development of requirements engineering for embedded systems? • RQ3. How should a systematic requirements engineering process for embedded systems be developed? • RQ4. How should the feasibility of the new requirements engineering process be validated?

8. Research Methodology Adopted Methodological Procedures (Adapted from PRODANOV; FREITAS (2013)).

9. Overview of the Research

10. Out of Scope • How to perform a task; • Requirements models interoperability; • Integration between requirements and architecture;

11. Statement of the Contributions • A Systematic Literature Review; • A Metamodel; • [ONGOING] A Requirements Engineering Process for Embedded Systems (REPES); • [ONGOING] Survey with experts and a feasibility evaluation based on GQM measurement method with companies;

12. Systematic Literature Review

13. Systematic Literature Review Process

14. Systematic Literature Review (SLR) • RQ1. How are requirements engineering approaches contributing to the solution of requirements engineering problems in the embedded systems domain?

15. Systematic Literature Review (SLR) • RQ2. What type of requirements have been supported by the approaches?

16. Systematic Literature Review (SLR) • RQ3. What phases of the requirements engineering process have been supported by the approaches?

17. Systematic Literature Review (SLR) • RQ4. What are the open issues that the approaches have?

18. Systematic Literature Review (SLR) • RQ5. What are the domains that the approaches support? Green – funcional requirements specification Red – non-functional requirements.

19. Systematic Literature Review (SLR) • Findings: • i) an urgent need by the community of ES to know how requirements engineering is being used in the development of embedded systems (RQ1 and R3); • ii) an evaluation of the studies as many of the selected contributions presented interesting proposals, though for some reason did not provide any evaluation (quality assessment); • iii) guidelines for further research since, through identification and classification, it was possible to categorize the open issues that the approaches have (RQ4);

20. Systematic Literature Review (SLR) • Findings: • iv) an alert for the community to include the requirements management phase and the handling of NFRs in the research agenda (RQ2, RQ3, and RQ4); • v) a need for the development of specific RE processes, techniques, and methods to support the development of embedded systems (RQ1); • vi) a warning to the development of a process to cover all RE phases since only one study covers all five phases (RQ3); • vii) a glossary of embedded systems terminology;

21. Requirements Engineering Standards

22. Requirements Engineering Standards • Standards that set out principles and guidelines have been proposed for developing requirements engineering; • The use of RE Standards is motivated by potential benefits;

23. Requirements Engineering Standards • A RE for Embedded Systems is challenging since it has unique properties that make it complex, expensive and error-prone. • (i) Embedded Software Systems (ESS) are usually tightly coupled to their physical environment; • (ii) the context of ESS require a very broad range of stakeholders with different roles; • (iii) the interaction interfaces are mostly hardware components; • (iv) Hardware Requirements Specification (HRS) is as important as SRS; and, • (v) most of the Embedded Software functions are performed regularly and repetitively (MATE; SILVA, 2005);

24. Requirements Engineering Standards • Research on RE standards; Analyze Adapt Add complementary practices

25. Requirements Engineering Standards • Relation among the standards and the key factors; • The key factors were identified in our SLR and MM4ES;

26. REPES Process

27. Metamodel Development Process • According to our SLR, no evidence explicitly depicts how an ES must be elicited and specified; • What should be considered in ES development?

28. Assessment and Evolution of the Metamodel • Goal: Analyze the metamodel for the purpose of checking whether the concepts are correct with respect to the natural language narrative from the point of view of an expert domain in the context of medical device development; • Scenario: Insulin Infusion Pumps;

29. Assessment and Evolution of the Model • Natural Language Narrative; • John, Mary, Fred, and Thomas are stakeholders on the development of an embedded system. They are working on the elaboration of a low-cost insulin infusion pump. The system they are producing belongs to an environment to its operation. The stakeholders must know the domain knowledge and the business (and its business rules) in which the embedded system operates to get sufficient knowledge to follow its development.

30. Metamodel Development Process - MM4ES Metamodel – Second Turn Legend: Blue – Enterprise Level; Green – System Level; Yellow – Requirements Level; Orange – Context Level;

31. REPES • 4 Levels based on ZHA; SRIRAM (2006); • ZHA; SRIRAM (2006) - design; • Enterprise Level; • System Level; • Component Level; • Feature Level;

32. REPES

33. REPES • Relation among the systematic literature review open problems and the REPES tasks.

34. REPES • Relation among the embedded systems key factors and the REPES tasks.

35. REPES – Enterprise Level (EL) • Purpose: To describe business rules, business process, and environmental information in which the system will operate. • Description: This level is responsible for the elicitation, modeling, description and validation of business rules, business process, and environmental information. This information is useful to identify and understand the application domain, facilitating the execution of the tasks of the following levels.

36. Enterprise Level – Business Modeling (ELBM) • Purpose: The goal of this task is to describe the business and business rules of the system. • Roles: Business analyst, requirements analyst. • Inputs: Raw Domain Knowledge. • Outputs: Raw Document Updated. • ELBM1: The business processes identified in ELE1 must be modeled and documented. • ELBM2: The business rules identified in ELE2 must belong to the business processes and should be described textually.

37. Enterprise Level – Business Modeling (ELBM) • Techniques: Business process modeling notation (BPMN), activity diagrams, stock and flow diagrams of system dynamics, tropos, role activity diagram, flowchart, and natural language (PEREIRA et al., 2013). • Work Products: • ELBM-WP1 - Modeled Business Processes: A document that summarizes the modeled business processes. • ELBM-WP2 - Business Rules Description: A document describing the set of business rules involved in the domain.

38. [ONGOING] REPES • System Level (Embedded System / Environment); • Requirements Level (Hardware / Software); • Context Level (Context Information);

39. Assessment - Survey

40. Survey Based on Expert Opinion • Expert Opinion is about “the speculations, guesses, and estimates of people who are considered experts in so far as these serve as “cognitive input” in some decision process” • The expert opinion method has been used to: evaluate the success of a project using subjective factors.

41. Survey Based on Expert Opinion • The number of experts: We are planning to select 5 potential candidates to compose the group of experts in the survey; • According to McGraw (MCGRAW; SEALE, 1988), groups of about five people seem optimal for tasks that depend on the exchange and discussion of information. • Expert selection process: • Systematic literature review; • Guidelines - the guidelines is based on the merit of expertise and of a diversity of opinions;

42. Survey Based on Expert Opinion • Expert aggregation: • We will adopt the arithmetic aggregation method since it will be justified by our analysis of experts ratings and responses; • WU et al. (2008) stated that arithmetic is an appropriate procedure for ratio scales; • Expert bias and calibration: • During the expert opinion process, the experts should provide detailed explanations for their ratings;

43. Survey Based on Expert Opinion • The survey will be composed of a questionnaire adapted from GARCIA (2010). • We must repeat pilot testing of the instrument; • The new instrument must be assessed for validity and reliability. • Research question: “Is the REPES process viable, complete and adequate?”

44. Survey Based on Expert Opinion • The questionnaire is related to issues such as: • the way the levels are distributed in the process; • the specification, description and main goal of the levels; • goals related to the tasks of the levels; • roles, inputs, outputs, techniques and work products related to the goals/tasks; • possible gaps in the evolution prescribed by each level of the process; and, • the difficulty in evolving through the levels of the process; • The experts should justify their answers for objective questions, making clear what level or task should be included, removed, merged or updated.

45. Assessment - GQM

46. GQM Paradigm • The GQM approach is a measurement system that target a particular set of issues and a set of rules for the interpretation of the measurement data; • The GQM is composed of three levels: • Conceptual level (GOAL); • Operational level (QUESTION); • Quantitative level (METRIC);

47. GQM Paradigm • Measurement Instrument [Motorola] • Commitment to perform; Approach • Ability to perform; • Activities performed; 3 Dimensions Deployment • Monitoring implementation; • Verifying implementation; Results

48. GQM Paradigm GQM model instance.

49. GQM Paradigm • METRIC: The metrics were defined following the steps used in the RE Maturity Measurement Framework (REMMF) to measure the maturity of RE processes. The structure of the REPES evaluation. Adapted from NIAZI; COX; VERNER (2008)

50. GQM Paradigm • Results – Example poor (0), weak (2), fair (4), marginally qualified (6), qualified (8), and outstanding (10)