Problem on Software Engineering Learning: Domain Engineering

During the system information undergraduate course, besides the knowledge on how to build a software system, the students should also know how to analyses business processes. Integrated projects would be a good opportunity to practice this concept if it had been better direction to this objective since it is a longer project that is supported by many chairs. Those projects use to presents the business rules and requirements to the students withdrawing from them the chance to exercises the domain and requirement engineering. It was made an experience to close that gap, so, 20 students were asked to get the requirements to a project. It was expected that the students should got requirements using the use case approach, also, they should realizes the need of domain engineering to empower the requirement\´s elicitation process. The need of this realization is based on the learning strategy used on the experience called problem-based learning (PBL) where the students should find solutions to a stated problem even before the presentation of the proper concepts that best solves the problem, so, in this study the need of domain engineering was not formally defined. To perform the strategy, the problem should had defined in a way which avoids the student\´s business rules intuitive inferences, so, it was defined a problem in an unknown domain. Another property of the problem is that should be a unique distributed system sharing the same business rules even the groups had different requirements. It was expected that the students got the requirements and realizes the need of domain engineering from a high level stakeholders\´ need in a 18 weeks time frame. Despite this, the students neither got requirements neither realizes the domain engineering needs during the first 5 weeks (27% of the time frame) they just had asking to the professor "which are the requirements?" and did not performed any requirements procedures. Supposing a conceptual problem, the use case approach concep- ts were retrieved, but it were realized that there were not a conceptual problem, so, the next logical step is consider concept\´s transfer problems. It was performed a transfer procedure where starting from a high level need, going through the approach till got the first classes of a rental software system (a well know domain to focuses the approach) the domain engineering aspects are commented as demanded by the students. During the transfer, the students tried to just create the requirements on a intuitively way on this time, they had been pushed back to follow the approach and get the requirements using it. During this activity, they once again, tried to escape from the procedure outweigh the lack of business rules just intuitively creating them, once again, they were induced to obtain and elicit the business rules and not just create them. The second part of the induction was very important since it was used to instigate on the students the curiosity about the domain engineering becoming a start point to the solution\´s search as defined by PBL. Once the transfer procedure was accomplished, the students started to ask the "correct questions" and the project could be started. After this point, the students should realizes the need of a unified domain engineering to the whole project positioning themselves as parts of the system, once again it did not happened and a new transfer procedure was made. In this transfer procedure was enough just help the students retrieve the distributed system\´s concepts and help them to identify each module and their position on them. During the transfer procedure the professor realizes that the students did not considered the modules communications and they had started to create incompatible modules leading the professor to start a new induction to solve this problem. From this point to the end, the project had a normal development. As a remark some students had declared they have difficulties to uses the theoretical knowledge o