Requirements engineering is an important stage in any software development. It is more so in the case of software development for social development projects in rural areas of the developing countries. ICT4D which stands for “Information and Communication Technologies for Development” is gaining more and more attention as computing is more widely affordable. This article is concerned with requirements engineering in the ICT4D domain. In many developing counties, a significant effort is being put into providing people in rural areas with access to digital content and services by using Information and Communication Technologies. Unfortunately most ICT4D projects pursue a top-down development model which is driven by the technology available and not by the very needs and social problems of the people living in rural communities (Frohlich et al., 2009). Existing technologies are often applied in a non-inclusive manner with respect to the local population, without sufficient adaptation or re-invention, and often without regard for user’s needs and their social contexts.
TopRequirements Engineering
Among the various software engineering disciplines, understanding the requirements of a project is one of the most difficult tasks faced by a software engineer (Pressman, 2005). In fact, a recent survey shows that 71% of software projects are late, go over budget or even fail completely (Standish-Group 2004). The most significant factors causing projects to be challenged or fail is related to the mismanagement of requirements (Taylor, 2000). Incomplete or incorrect requirements inevitably propagate into the later stages of software development and hence lead to the implementation of a product that does not meet user expectations. Such failures can be avoided, if end users and stakeholders are involved earlier in the software development process and if appropriate elicitation techniques are employed.
In order to facilitate end-user involvement, the requirements engineering community has proposed different methods (e.g., contextual inquiry, interviewing, requirements workshops, focus groups) to elicit software requirements and to facilitate the communication between users and analysts. In this paper we propose a novel elicitation technique, called structured digital storytelling (SDS), which can be used in a complementary fashion and, as we will demonstrate in this paper, is particular suited for eliciting requirements within an ICT4D context.
During requirements production, the elicited information is systematically transformed into a set of software requirements. Throughout this process it is important to establish traceability links that clearly relate requirements to their sources; the originally elicited information. In general terms, requirements traceability is defined as the ability to describe and follow the life of a requirement in both forward (post-requirements traceability) and backward direction (pre-requirements traceability) (Orlena & Finkelstein, 1994). Within an ICT4D context, requirements traceability is particularity important, if we take into account the fact that requirements come from different sources, such as regulatory and governmental bodies, international and national development agencies, product managers, and of course, the actual end users (Leite, 2003). These stakeholders all have different requirements on the product. Using requirements traceability an implemented feature can be traced back to the person, or organization, that requested it during requirements elicitation. Well established traceability links allow showing that every requirement is related to one or more stakeholder’s needs and that all needs have been addressed by the specified requirements.