Status of Nonfunctional Requirement in Mobile Application Development in Academic Projects

Academic Projects Survey/Case Study

The software projects implemented by the students are claimed to be industrial oriented. Hands-on experience on these projects helps the buddy engineers to learn new techniques, technologies and processes for undertaking quality software engineering. Hie ups and downs learned during academic projects help them to update their project database that could provide learning experience with industrial projects. The academic projects could find their applicability in industries and hence the quality of such software is important. Quality depends on the quality of software engineering practices. It is thus important to analyze that state of software development from nonfunctional requirements’ (NFRs) point of view. The study is based on the objectives as established for industrial and literature studies performed in

Chapters 2 and 3 of this book. This work is an extension of the work given in previous chapters but in academic environment settings.

To answer the seven research questions as framed in Chapters 2 and 3 of this book, the 30 final year and pass out students belonging to both B. Tech and M. Tech academic programs were interviewed to get answers to the research questions. Tire responses obtained for each research question are given in the following.

RQ 1. What is the extent to which nonfunctional requirements get the software developers’ attraction?

NFRs are the most ignored parts of academic projects. Tire reason is unrealistic deadline for submission (typically one semester), small team size (group) and less experience with similar projects. Tire effort is to complete the project in terms of its functional requirements (FRs) that will make enough justification that the project is working. Only very basic NFRs get the attraction of the developer and that is limited to security (username and password) and GUI. Again the students were of the opinion that it is not the nonfunctional ones that pay, but functional ones that get them good awards. Student projects are normally developed using one-go technique expect when they are to be extended as majors. In the latter case, extension is in the form of implementation of functional codes only.

RQ2. What is the cost and time percentage of NFR in overall project cost and duration?

Cost of academic projects is hard to compute; however, the actual hours devoted by students in the development were collected from them. In the case of computer software projects, it is not possible to confirm the actual hours devoted since students can also work after official hours in their hostels or home. Student projects are medium complexity and low complexity with a total time percentage share of NFRs estimated to be 2% of the total project development time.

RQ 3. What is the implementation status of NFR to FR for different complexity projects?

Tire number of NFRs in academic projects is negligible as compared to functional projects. But, if still compared, the ratio comes out to be 0.12

Table 5.1 NFR to FR Ratios for Different Categories and Complexity Academic Projects

SI. No.

Product Complexity

NFR to FR Ratio







for medium-complexity projects and higher 0.14 for low-complexity projects. Typical ratios are given in Table 5-1.

Table 5-1 shows that there is no addition of NFRs with the increase in complexity of the academic projects. Complexity increase is attributable to increase in FRs.

RQ 4. What are the typical categories of NFRs implemented by mobile software developers?

Student academic projects are restricted to very basic NFRs, including security requirements like user name and password, database encryption and GUI requirements. Very few students had incorporated NFRs like multilanguage support, notifications and storage requirements. The reason reported by these students was that the application they developed would have made the app of no use if these three NFRs are not implemented. It means that NFRs for student projects depend on the nature of the functionality expected from the app.

RQ 5- How are nonfunctional requirements prioritized?

Students never prioritize the NFRs. The guidance from the project mentor about the NFRs is the only identification or selection criteria for NFRs.

RQ 6. What is the extent to which the answers to the above questions depend on the maturity and size of software organization?

The reputed universities or engineering colleges enable the students to implement projects on live research problems. Some innovative NFRs are considered, but the emphasis is to get automatization of the research problem solution. It means FRs are considered. Cost and time does not vary since the students are less experienced in implementing innovative NFRs and such requirements are less attractive to them. Good organization will consider innovative NFRs apart from basic ones, but prioritization never happens. Such projects are normally one-go projects.

RQ 7. How the present practices of the mobile development firms impact project success and failure rates?

The student projects are one-go-type projects or medium complexity. The feedback of the project mentor and evaluation committee is used as a means by the student to implement remaining requirements. Students were asked if they have to implement NFRs as a result of feedback. Student reported that for medium- or low-complexity projects, the mentors focus mostly on functionality. If functionality is satisfactory, students are asked to implement NFRs. However, the information was difficult to recall for the students. The outcome is that if functionality is completely implemented, then software is verified for NFRs. This means NFRs determine the success of student projects.

The findings of the academic projects survey are presented in Table 5-2.

< Prev   CONTENTS   Source   Next >