Requirements Elicitation Practices for Mobile Development

Posted Monday, June 1, 2015 in Software Engineering

Introduction

Requirements elicitation is a critical component to the success of a software development effort. A successful software development effort is one that is completed on time and to the satisfaction of the customer. A significant risk to success is an incomplete requirements specification or one that is subjected to change outside the planned scope of the effort. It is therefore in the best interest of both the development team and appropriate stakeholders to develop a well-defined requirements specification. To do so, a requirements elicitation should identify what defines the functionality of the system, what constraints are present, and what constitutes success. The following focuses on the requirements elicitation process in the area of mobile application development.

Problem Space and Solution Space

A misconception is to initially define what the solution should be rather than defining what the problem is. Imagine a mobile software development project to create a voice over IP (VOIP) application. In a good faith effort to narrowly define the requirements to include the requirement to use a specific codec and noise reduction algorithm from the customer's experience in desktop application development. After development, the customer finds that the VOIP app performs poorly due to a loss of efficiency in mobile environments for the chosen codec and noise reduction algorithm. The issue here is that the customer did not necessarily want the codec and noise reduction algorithm they chose but wanted a VOIP application that provided the best audio quality in the constraints of known mobile environments. The customer defined the solution instead of the problem during the requirements elicitation phase.

It is important to separate the problem space and solution space to prevent issues of mismatched problems and solutions (Fægri & Moe, 2015). Defining the problem space first also allows an opportunity to explore several possible solutions. In the VOIP example, this may mean choosing the most appropriate codec and noise reduction algorithm which may have several trade-offs such as licensing costs or development effort. The goal of requirements elicitation should be to clearly define the problem space, including functionality, constraints, and goals.

Requirements Modeling Patterns

The requirements elicitation process is fundamentally a knowledge transfer activity. Pressman (2010) wrote that requirements elicitation can often be performed multiple times for closely matched problems. When a generalized method of requirements modeling is determined it can be classified as a requirements modeling pattern and reused for similar problems. Table 1 outlines the requirements modeling patterns described in this section.

The first of the requirements modeling patterns, as described by Pressman (2010), is the actuator-sensor pattern. In several cases, mobile phones can have very low level operating systems matching that of an embedded system. For example, WhatsApp, a popular mobile messaging app, built a significant user base by spending development effort on developing a J2ME version which is an operating system for low-end smartphones (Pottier, 2014). The actuator-sensor pattern defines a device as a series of sensors, actuators, and the logic that defines how sensor input and mechanical functions are handled. The actuator-sensor pattern could help a mobile developer define the requirements for a very low-level mobile application.

The next several patterns are defined by Vdovenko, Marchenkov, and Korzun (2013) as architectural patterns for mobile application development. Each may be used as a starting point for needs elicitation since each act as general reference patterns for a wide variety of mobile, desktop, and server applications.

The first, model-view-viewmodel (MVVM), separates the application by data, user interface, and an intermediary module for handling UI events and data binding. Separation of modules using the MVVM architecture separates requirements into business logic (model), look of the app (view), and behavior of controls (viewmodel).

Next, the model-view-controller (MVC) operates similarly to the MVVM architecture but allows the view to directly access the model and uses a controller module to handle changes to the UI. The MVC architecture is ideal for server-client interactions and may be suitable for a web-based mobile app. In the MVC architecture, the controller replaces the viewmodel for handling UI events but does not directly bind data between the model and views.

Lastly, the model-view-presenter (MVP) architecture strictly separates the view and model by defining interfaces at the presenter module. The MVP architecture may be ideal for development efforts that separate work between the UI and business logic. Requirements for the MVP architecture may be defined for each module in a mostly separated manner which is important with volatile requirements or efforts requiring large teams.

As Pressman described (2010), requirements modeling patterns are discovered through in-depth requirements elicitation. The general modeling patterns described so far constitutes common architectures for general purpose applications. However, a development team may wish to define a requirements modeling pattern more inline with the customer's needs and the problem that is being addressed. For example, game development can require a more complex set of requirements that need to take into account the management of game assets, sprite tracking, and game states. Once a general pattern is defined, more in-depth requirements can be examined and given sub-patterns if needed. With the MVC pattern, a sub-pattern just for the view component may be defined to comprise requirements regarding the user interface. At certain points, these sub-patterns may be migrated to design models in which behavior, processes, and components are designed based on the inputs from the requirements elicitation phase.

Practical Application of Requirements Elicitation

As a knowledge transfer activity, one of the challenges of requirements elicitation arises from working in large teams of one or more development companies. Communication can be difficult in these scenarios and requirements from the customer or principal can become misinterpreted between developers or agents. Subasingha, Sedera, and Murphy (2012) described the use of agency theory to determine how requirements elicitation should occur in a multi-level organization to find goal conflict, and retain knowledge. By understanding that each agent can have different and sometimes conflicting goals helps define requirements so that conflicts do not threaten the success of the development effort. For example, an outsourced development team on a fee-based contract may desire an on-time completion of the development effort which may conflict with the principal or another agent's desire to produce the highest quality product. Adjusting the requirements to balance the goals of each agent can help ensure the success of the development effort. A mobile development team can become an agent in a larger effort to develop a suite of software applications. For example, a primarily desktop-oriented software product such as tax preparation software might desire an additional mobile app to access a reduced set of functionality that the desktop version provides. In this scenario, the agency theory helps balances the conflicting goals that development for a mobile environment would have compared to a desktop environment.

Activities may also be developed to improve the requirements elicitation process such as with improvements to process diagrams and automation of requirements tracking. For process diagrams, the unified modeling language (UML) may assist developers to understand complex interactions between modules, business logic, and UI interactions. Although somewhat complex at first, UML offers a wide range of visual queues to explain relationships and entities in a concise manner. Secondly, automation of requirement discovery and classification can assist in knowledge transfer between disjoint development teams. Vlas and Robinson (2012) proposed a method of discovery and classification of natural language requirements into a formal language for the purposes of open source development efforts.

Problem Solving

It should be noted that requirements elicitation is not primarily a problem-solving activity. As stated, the problem space should be defined before a solution is proposed. However, during the elicitation process requirements may define an isolated problem space such that a solution space may be defined and requirements narrowed. Once the customer selects and approves the proposed solution, such as through an engineering implementation plan, execution of the development effort may begin. The goal of the elicitation process is to initiate a development effort that ends on time and with the stakeholder's approval of the final product. The method of eliciting requirements that best meets this goal is then the ideal method of solving the initial problem.

Conclusion

For software development efforts, the requirements elicitation phase is key to the overall success. A solution that best meets the customer's needs begins at the requirements elicitation phase with a clearly defined problem space, listed constraints, and success criteria. Requirements modeling patterns help streamline this effort for future efforts that share architecture and design elements. Requirements elicitation is further improved in practice through careful consideration of goals between development teams, diagram development, and automation. Once prepared, requirements elicitation is a strong foundation to start a successful development effort.