4. Requirements Elicitation
4.2 Project Requirements
The project requirements were formulated after investigating the codebase, reading existing documen-tation, and discussing with experts. Table 3 shows the list of the requirement derived from stakeholders’
interests and their priorities. These requirements also include the system’s quality (non-functional) as-pects and other requirements related to constraints. Furthermore, the requirements are described in de-tail, i.e., the rationale behind each of these requirements is given and the test strategies that were used for verifying each of these requirements are also explained.
Table 3: Project requirement
Req_Id Description, Rationale, and verification Priority
Description: The image sensor’s camera driver shall be redesigned using class and object modeling (object-oriented modeling). The redesign must be implementation technology independent.
Must
14
Req_Id Description, Rationale, and verification Priority
Req-1 Rationale: If the redesign is implementation specific, it would be highly coupled to the implementation technology. This would make changing implementation technology cumbersome without redesigning the driver.
Verification: This will be tested through reviews by supervisors and stakeholders. The test passes if no implementation-specific concepts are included in the design; it fails otherwise.
Req-2
Description: The design shall be implemented in the C++ (C++11 (with limited features) + boost) programming language.
Rationale: The design is targeted to be implemented using OOP lan-guages such as C++, Java, and Python. C++ is the target for this project and is a standard at ASML.
Verification: This will be tested by code reviews and compiling the im-plemented code using C++ compilers.
Must
Req-3
Description: The C++ implementation of the design shall follow the C++
coding standard of ASML.
Rationale: The implementation should be in compliance with the ASML coding standard for consistency purposes.
Verification: This will be tested by running an ASML tool called TICS that checks the compliance of the code with the coding standard.
Must
Req-4
Description: The implementation of the redesign shall use ASML’s C++
exception handling macros that propagate and log the exception (error) to the calling function or client.
Rationale: If an exception (error) occurs during an operation, the calling client should be notified about the error. Additionally, the source of the error should be known for debugging (diagnostics) purposes.
Verification: This will be tested by using a test-to-fail scenario. The test passes if the exception is correctly logged in the TwinScan machine’s error log file, and the record shows the source of the error as it propagates through different software classes; otherwise, it fails.
Must
Req-5 Description: The implementation of the redesign shall use the TwinScan diagnostic tracing facilities to log function tracing.
Rationale: It helps to identify failures caused by functional errors.
must
15
Req_Id Description, Rationale, and verification Priority
Verification: This will be tested by running the camera driver on Devbench and activating the trace mode. The test passes if the trace is correctly logged in the trace file of the ASML tracing facility.
Req-6
Description: A brief guideline reference on migrating a C component to C++ shall be formally reported in a document for future reference in ad-dition to this final report. The guideline report is added as an appendix to the confidential version of this final report.
Rationale: The findings, challenges, guidelines, and best practices can be used as a reference for future use or decision making in the image sensing domain and possibly other ASML domains.
Verification: The guideline reference will be reviewed by an expert. In addition, periodic progress updates through presentations, demos, and reports will be done with all stakeholders to ensure that all project find-ings and progress are discussed clearly.
Must
Req-7
Description: The complete solution (design and implementation) shall be integrated with the existing image sensor subsystem driver and other TwinScan generic facilities.
Rationale: The implementation of the redesign should be integrable with its client and other software components.
Verification: This will be tested by executing integration tests; after the implementation of the main use cases are fully developed.
Must
Req-8
Description: The redesign shall be extendable for new image sensors or relay devices.
Rationale: New image sensors or relay devices can be introduced in the near future.
Verification: This will be tested through reviews by supervisors and stakeholders.
Must
Req-9 Description: The redesign shall avoid cyclic dependency between the different layers of the driver component.
Rationale: Cyclic dependency between the layers increases complexity.
Hence, the cyclic dependency between layers of a component should be avoided.
Verification: This will be tested through reviews by supervisors and stakeholders.
Must
16
Req_Id Description, Rationale, and verification Priority
Req-10
Description: The implementation of the redesign shall be testable.
Rationale: The developed driver should be tested to verify that it is free of bugs and meets the functionality of the driver.
Verification: Unit tests will be applied for key public functions of each class of the driver. Besides, an integration test will be applied to test the camera driver with its client.
Must
Req-11
Description: The external interfaces of the driver shall not be redesigned or modified.
Rationale: These interfaces are a contract among the different image sen-sor subsystem components and should not be changed.
Verification: This will be tested through reviews by supervisors and stakeholders.
Must
Req-12
Description: The complete solution shall not hurt the performance (exe-cution time) of the existing system. The exe(exe-cution time should be more or less the same compared to the existing implementation.
Rationale: The implementation of the redesign should not introduce ex-ecution time bottlenecks.
Verification: This can be tested by running critical module use cases of the driver under the same environment setting and measuring the time it takes for both the new and existing systems.
Should
Req13
Description: The total memory size consumption of the implementation of the redesign shall be the same or less compared to the existing imple-mentation.
Rationale: The implementation of the redesign should use efficient memory management utilities (libraries).
Verification: This will be tested through a memory consumption ana-lyzer tool if it exists.
Could