Requirements Engineering Process Improvement Approach for Embedded Software Systems in Android-Based Mobile Devices

Transcription

1 Requirements Engineering Process Improvement Approach for Embedded Software Systems in Android-Based Mobile Devices 1 1 Universiti Kuala Lumpur Malaysian Institute of Information Technology, aedah@miit.unikl.edu.my Abstract Requirements engineering (RE) is considered important in producing successful software projects and quality software products. Researches in RE have proven that requirements errors affect the software product quality. The overall aim of this research paper is to design and document a requirements engineering process improvement approach to facilitate the elicitation and management of dynamic, and multi-stakeholder requirements and thus improve the RE process as a whole. The focus is to determine the requirements engineering approach in the embedded software systems domain. This paper provides relationship between process improvement and requirements engineering, process improvement method and RE approach for real-time and embedded systems (REARES). Process improvement methods emphasize on the importance to improve software development processes and it is achievable via effective requirements engineering process. Requirements engineering is defined as the process that develops product specifications which are complete, consistent and unambiguous. This product specification is treated as a common agreement among all stakeholders and it describes on what the product will do. The outcome of this research paper is a consolidated list of processes for requirements engineering in embedded software projects. Keywords: Requirements engineering, Process improvement, Real-time and embedded systems 1. Introduction Requirements engineering (RE) has been recognized as important discipline in order to produce successful software project and products. The importance of RE has become increasingly affecting the software industries to invest effort of their corresponding RE processes. In current situation, software industries also have focused mainly on improving the RE processes. Best practice such as CMMI has been adopted by the industries to improve their software development processes. Various process improvement frameworks have been adopted and invested by the software industries to strengthen the software processes and deliver the best services for their customer [9-11]. RE practices influence private sectors, public sectors and software industries domain. The literature defines RE as the process that develops product specifications which are complete, consistent and unambiguous. The product specification is treated as a common agreement among all stakeholders and it describes on what the product will do. The focus of this research work is the RE process in the real-time and embedded (RTE) system domain. The overall aim is to design and document a RE process improvement approach to facilitate the elicitation and management of dynamic, and multi-stakeholder requirements and thus improve the RE process as a whole. The systematic approach for requirements engineering process improvement that provides the guidelines and steps to improve the RE process in embedded software systems are determined. 2. Process improvement (PI), requirements engineering (RE) and real-time and embedded application (RTE) domain Process Improvement and Requirements Engineering. The relations between process improvement (PI) and RE is visible and important. Software projects whether it is small, medium or large scale need to have proper requirements engineering practices to deliver quality software products. Performing good RE practices prevents project failure. The importance of RE also has been stated by process improvement approach such as Capability Maturity Model International Journal of Engineering and Industries (IJEI) Volume4, Number4, December

2 Integration (CMMI). The main ingredient towards a successful software development is the management of RE process. The key process in ReqMan research project presented works on RE approach and is based on inputs from the academia and industries; and quality frameworks such as CMMI and SPICE [5]. It is based on a set of best practices rather on complex reference processes that needs to be tailored on the specific needs of the companies. Current software process improvement approaches reveals a gap in the area of requirements engineering. Therefore, there is a need to introduce the concept of requirements engineering process improvement (REPI) bridge and fill in the missing portion. This practice-based approach for REPI is customized for the embedded software systems applications in mobile devices. Requirements Engineering. Research on requirements engineering practices in information systems development has been conducted rigorously. Studies have been made in the academic, industry, private and public sectors. RE is known as being the most critical process of software development. Defects or errors injected during this process can have severe effects on the subsequent phases in software development and the software product quality. The defects injected at the early stages may propagate in the subsequent phases and thus produce major defects and problems [3]. There is a difference between what a product should do and how it should be performed. The RE focuses on the what aspect and the logical needs of a product. This defines a clear distinction between the logical and technical specification. The how aspect related to technical specification and architectural design are considered on the next software product design phase. In developing requirements for software projects, it is important to initially classify the projects into three types, namely information system, embedded systems, and finally command and control systems. RE processes involve a range of stakeholders from different backgrounds, individual goals and organizational goals [1]. The multi-stakeholder elements and involvements influence the development of requirements specification and RE processes as a whole. There are perceived benefits and drawbacks of RE process implemented for any types of software projects [2]. It is important to reduce the possibility of communication gap among the stakeholders and requirements practitioners and other possible weakness that may arise by implementing proper RE approach. Real-Time and Embedded Application Domain. Among software applications common examples are such as word processors, and Internet applications. Software also can be embedded into electronic products such as cellular phones, medical equipment, microwave ovens, televisions, and other mechanical and electronic equipment. Embedded software is defined as software that determines the functionality of microprocessors and other programmable devices that are used to control electronic, electrical and electromechanical equipment and sub-systems. This programmable devices are often hidden from the user. Among the characteristics of the embedded products are reliability, device autonomy and the time criticality of the product delivery. Further characteristics that need to be considered when designing the embedded software projects are multi-user, multi-stakeholder, distributed, collaborative, dynamic and complex. The embedded software projects is a complex domain and therefore the proposed RE approach should be capable of monitoring and adapting requirements over lengthy durations and in a timely manner. The development of embedded software products is complex. Therefore, the quality of the software process and product is greatly emphasized. 3. Research method This section discusses on the steps involved in the research method which includes: (1) determination of process improvement (PI) method, (2) selection of product-based software projects, and (3) evaluation of the PI method. PI highlights the importance of product quality. This research project selects the requirements engineering as the method for process improvement [6]. RE is used for the specification of the quality of software product. Three projects have been identified to be included in the RE approach, namely: (1) Android-Based Speech to Text Translator, (2) Bus Information System via QR-Code, and (3) Android-Based Bus Tracking System. The projects are developed based on Rational Unified Process (RUP) software development methodology. The input, process and output for the three projects are monitored and controlled. The evaluation of RE is performed by analyzing the 21

3 progress and processes applied on the three real-time and embedded software projects, A, B and C. In order to assess the state of the process improvement progress, the maturity matrix is developed. 4. Result and analysis This research identifies several components for the RE process flow for real-time and embedded applications that includes input, process and output for RE process. Output from the RE process produces the specification document, acceptance test plan and possible initial version of the system manual. The input to the RE processes for RTE system is categorized into the following elements: current information about the system, stakeholder needs and demands, domain area and information, organizational standards and regulations [4] [7-8]. In relation to the input for RE processes, the domain information for each of the software projects is presented in Table 1. Table 1. Input to RE process The domain information Project ID Domain information Smartphone (Android) and mobile phone, Optical character recognition (OCR), A Algorithm for recognition, Speech recognition Smartphone (Android) and mobile phone, Global positioning system (GPS), Detection B method and tracking system (DMTS) for vehicle (bus) Fleet tracking & Geo-location, QR code, Mobile passenger information system C Smartphone (Android) and mobile phone, GPS, DMTS for vehicle (bus) The outcome of RE process is a product requirements specification document. This is indicated in Figure 3 as specification document. Other outputs expected from the RE processes are acceptance test plan and system manual (where possible). The specification document should include agreed set of requirements and system models of the software project. The definition on RE processes includes [13]: (1) Elicitation: The process involves the customers and developers to elicit, review, communicate and understand user s needs; (2) Analysis: The process of analyzing user s needs to establish a set of agreed requirements which are complete and consistent; (3) Specification: The development of a document that clearly define each of the requirements of a product; and (4) Verification: The process of ensuring that the requirements specification complies with the product s needs, which certifies that the requirements document is an acceptable description of the system to be developed. Apart from the above definition on requirements elicitation, the use of viewpoints for eliciting requirements [12] is also important. The comparison of research works among authors is presented in Table 2. This research (REARES) applies RE approach with four identified processes, namely elicitation (P1), analysis (P2), specification (P3), and verification and validation (P4). The final process used in REARES project is different with the one used by other authors in Table 2. Table 2. Comparison of RE processes among researches Research/Author Requirements Engineering Processes Management P1 P2 P3 P4 REARES X X X X X [5] X X X X X [10] X X X X (Verification) X [4] X X (Analysis and Negotiation)X (Documentation) X (Validation) X The initial processes use the similar names however different for the final process. Instead of using verification and validation (V & V) as separate process, REARES combines both V & V. This promotes further completeness of the requirements testing phase as this is aligned to process improvement objective. These processes are based on the CMMI process areas which contain V & V process areas in the Engineering Process [9-11]. The RE processes for the RTE systems defined in this research which are applied on the three projects are depicted in Figure 1 below. 22

4 Requirements Engineering Approach for Real-Time and Embedded Systems RE Processes Elicitation Analysis Specification Verification & Validation Management Figure 1. RE processes in real-time and embedded systems The first phase, requirements elicitation for REARES involves discovering the system requirements through consultation with multi-stakeholders, from system documents, domain knowledge and market studies. The stakeholders may comprise of persons of organizations such as legal entities e.g. companies and standard bodies. They are the one who have interest in the system and may be involved and affected directly or indirectly. Stakeholders may also include organization that employ the business analyst or requirements engineer, the persons who operate the system, persons who gained benefit from the system, involved in the purchase or procurement of the system, organizations who are involved in systems regulations whether it is safety, financial or other type of regulations, persons or organizations who are divergent from the system or also know n as negative stakeholders, and other systems which have interface with the current system under development. The second phase, requirements analysis includes analyzing the requirements and negotiating with multi-stakeholders to decide on the requirements to be agreed upon and accepted. Figure 2 illustrates some of the activities that occur in the requirements analysis phase. Stakeholder Identification Use Cases Stakeholder Interviews Requirements Analysis Phase Prototyping Requirements Checklist Figure 2. Activities in the requirements analysis phase Use case is one of the activities in the requirements analysis phase. A use case is a technique that documents the requirements of a new system to be developed. There are two types of use cases, the use case diagram and use case scenario (in textual form). It may also document a software change. Every use case contains one or more scenarios that describes on how the system should interact with the user or other system to achieve business goal. The use case is developed using language that is 23

5 understandable by the user and domain expert. The requirements engineers, business analyst and stakeholders jointly review the use case to ensure that it meet overall stakeholders requirements. Use cases describe the software or systems behavior. It explains the ways the intended users should work with the embedded systems software. Use cases do not describe the internal systems process and do not describe on how the system should be implemented. In use cases, the steps of accomplishing a certain tasks are provided. Figure 3 illustrates the excerpt of use case scenario for Project B. Use Case Diagram for User to Scan QR Code Use Case Scenario for User to Scan QR Code Use Case ID: UC001 Description: Preconditions: Post conditions: Initiated By: Use Case Name: Scan QR Code When user scan the QR code, the scanner then generates and converts the code to a URL, directing to the bus information Mobile Website. User must installed a QR Code scanner application in their Smartphone and On the built-in camera and the internet User can access the application User Normal Course of Events: 1. User launch the QR code scanner application 2. User positioning the camera so that the QR code is within the square margins of the scanning application screen 3. User chooses from the available actions presented by the scanner application 4. User will be directing to the Main Menu of the application Alternative Courses: Exceptions: Extends: Includes: None User not installed the QR Code scanner User without Smartphone None None Figure 3. Excerpt of use case diagram and use case scenario for Project B The third phase is the requirements specification which makes sure the requirements to be documented and ensure that the written requirements are understandable by all system stakeholders. The software requirements specification (SRS) contains complete description of the system behavior which is intended to be developed. In this phase, the natural language and diagrams are applied. There are several types of requirements, the functional requirements (FRs) and non-functional requirements (NFRs). This documentation phase includes set of use cases (or also known as functional requirements) and supplementary requirements (or also known as non-functional requirements). The examples of the NFRs are quality standards, performance requirements or design constraints. Table 3 indicates some of the NFRs applied on the three projects. 24

6 Type Usability Data Transfer Performance Security Safety Portability Reliability Table 3. Non-functional requirements of the software projects Description The application shall present simple and easy-to-understand interfaces to its users. The amount of data returned from the server shall be kept as small as possible so that web page can avoid slow loading. The application should be able to process and perform all user enquiries between 5 to 30 seconds. Only system s developer that authorized by the system s owner shall makes changes to all system s data. The system should no longer operate in the event of cyber attack. The system s interface shall be supported and available on mobile devices and desktop. The system should behave perfectly normal after user reloaded the system again if the system crash. This phase uses the standard template, IEEE The fourth phase, V & V ensures that the requirements are checked for consistency, completeness and unambiguity. This phase detects problem in requirements document before it used further in the system development. Requirements management manages changes to systems requirements. The three software projects A, B and C have kicked-off and the progress of processes involved is monitored. The completeness and coverage of the RE processes conducted on each software project is discussed further. Project A and B completed three RE processes P1 to P3. However the P4 is partially completed. Project C completely conducted the four RE processes, namely P1 to P4. Software Product and Process Improvement Management (SPPIM) is used as an indicator for the progress status of the current process improvement state for a particular process. In this case, the research examined the process improvement in requirements engineering phase of a software development life cycle in embedded software systems. A maturity matrix is developed to show the levels of each step in requirements engineering. The ranges are Level 1 (Initial), Level 2 (Repeatable) and Level 3 (Defined). Level 1 Initial, represents the limited use of best practices and success depends on the individuals. Level 2 Repeatable, represents extensive use of best practices and adopts good practices, policies and procedures. Level 3 Defined, represents some use of advanced process improvement best practices and application in critical system. The following Table 4 shows the summary of maturity matrix which is used to assist the SPPIM in order to determine the current state of requirements engineering process improvement of three mobile applications. The REPI approach in the projects A, B and C is based on the CMMI-DEV process improvement framework which is focused on Requirements Development (RD) and Requirements Management (REQM) process areas. The Requirements Specification process of the three projects uses IEEE 830: 1998 standard, which describes the contents, structures and qualities of a software requirements specification (SRS). Table 4. Maturity matrix of SPPIM RE Processes Project A Project B Project C Relevant with Industry Best Practices Requirements Elicitation Level 3 Level 3 Level 3 Requirements Analysis Level 3 Level 3 Level 3 Requirements Specification Level 3 Level 3 Level 3 CMMI DEV: SRS Template is Requirements based on IEEE 830: Development 1998 Requirements Verification and Validation Level 3 Level 3 Level 3 Level 3 Level 3 Level 3 CMMI DEV: Requirements Management Requirements Management 5. Conclusion This research paper determines the requirements engineering approach for product-based embedded software projects. Three case software projects are Android-Based Speech to Text Translator, Bus Information System via QR-Code and Android-Based Bus Tracking System. The process flow for each RE phases: input, process and outputs have been outlined and 25

7 discussed. Four main processes have been identified to be included in the RE approach, namely elicitation, analysis, specification, and verification and validation. The RE approach for embedded software projects must be capable of evolving with the dynamic changing user needs and many influencing factors in the real-time and embedded applications domain. It is expected that this approach shall fill in the gap in the development of embedded software projects by providing a systematic approach to deal with requirements. This research has been expanded to identify and explore practices in the requirement engineering for embedded software projects. Requirements engineering process improvement approach which is supported by Software Product and Process Improvement Management (SPPIM) and maturity matrix, have been discussed in this paper. As part of the current research work, this RE approach is applied on development of three embedded software projects with the intention to study the effectiveness of the approach and current RE practices in small scale software projects with focus on embedded software systems. 6. References [1] Glinz, M. and Wieringa, R. J. Guest Editor s Introduction: Stakeholders in Requirements Engineering, IEEE Software, IEEE Computer Society, pp , [2] Haron, A. and Sahibuddin, S. The strength and weakness of requirement engineering (RE) process, In Proceedings of the 2nd International Conference on Computer Technology and Development (ICCTD 2010), [3] Hasim, N. and Rahman, A. A. Defect density: A review on the calculation of size program, In Proceedings of the 4 th International Conference on Machine Vision: Computer Vision and Image Analysis; Pattern Recognition and Basic Technologies (ICMV 2011), (December, 09-10, 2011). Proc. SPIE 8350, [4] Kotonya, G. and Sommerville, I. Requirements Engineering: Processes and Techniques, John Wiley & Sons, Inc., New York, [5] Olsson, T., Doerr, J. Koenig, T. Ehresmann, M. A flexible and pragmatic requirements engineering framework for SME, In Proceedings of the 1 st International Workshop on Situational Requirements Engineering Processes, pp. 1-12, [6] Rahman, A. A., "Requirements Engineering Approach for Real-Time and Embedded Systems", In Proceedings of the 8th International Conference on Computing and Convergence Technology 2013 (ICCCT 2013), Gyeongju, Korea, October [7] Rahman,A. A., Haron,A., Sahibuddin, S. and Harun, M., "Requirements Engineering Practice in Malaysia Public Sector A Perspective from the Stakeholders Challenges", th International Conference on Software and Computing Technology (ICSCT 2013). Turkey, October [8] Rahman,A. A., Haron,A., Sahibuddin, S. and Harun, M., "Requirements Engineering Practice in Malaysia Public Sector A Perspective from the Stakeholders Challenges", International Journal of Computer Theory and Engineering 2013 (IJCTE 2013), vol. 6, no. 1 (Feb. 2014), pp , Turkey, [9] Rahman, A. A, Sahibuddin, S. and Ibrahim, S., A Taxonomy Analysis for Multi-Model Process Improvement from the Context of Software Engineering Processes and Services, International Journal of Digital Contents and Its Applications, AICIT, vol. 6, no. 22 (Dec. 2012), pp , [10] Rahman, A. A, Sahibuddin, S. and Ibrahim, S., Using Taxonomy Comparative Analysis for the Unification of Process Improvement Frameworks, International Journal of Digital Contents and its Applications, AICIT, vol. 6, no. 21 (Nov. 2012), pp , [11] Rahman, A. A, Sahibuddin, S. and Ibrahim, S., A Multi-Process Quality Model: Identification of Key Processes in the Integration Approach, International Journal of Computing, GSTF, vol. 2, no. 1 (Apr. 2012), pp , [12] Sommerville, I., Sawyer, P., and Viller, S., Viewpoints for requirements elicitation: A practical approach, In Proceedings of the Third International Conference on Requirements Engineering, pp , [13] Thayer, R.H. and Dorfman, M., Software Requirements Engineering, IEEE Computer Society,