Ursula Meseberg Tanja Weiß

Mobile RE

The Mobile Future of Requirements Engineering

This year we’re definitely headed for the future. Do you remember the 1985 movie Back to the Future? Marty McFly lands in Hill Valley, California on October 21st 2015 at 4:29pm. And what would probably be the first thing you did, if today you landed in the future? Perhaps you would take a photo with your smartphone and share it with as many friends as you have. You would immediately capture the moment.

Nobody can imagine private life without smartphones and tablets nowadays. And at work? More and more employees want to take advantage of this mobility at work, too, because mobile devices offer features that can be very handy for business tasks. Will professional requirements engineering be affected by this trend? And if so, how? This article will look into the requirements engineering process and make suggestions where the use of mobile devices can be useful or risky. Surely, we cannot predict how much more mobile requirements engineering will get, but this article offers our vision.

Back to the Roots of RE

Let’s fly back into the past. In 1985 requirements engineering was still pending. Early birds of this discipline were Tom de Marco’s Structured Analysis and Systems Specification, the use of data flow diagrams for functional analysis from 1979 and Peter Chens’s Entity-Relationship Model for conceptual data modeling of 1976. Both concepts dealt with the visualization of requirements in software engineering, other than just listing texts that describe stakeholders’ requirements. In the early 1990s the Unified Modeling Language (UML) was released to visualize the design of a system. And later on, in 2007, version 1.0 of the Systems Modeling Language (SysML) was launched, which is less software-centric and adds a requirements diagram to the UML. But expert knowledge in UML /SysML doesn’t make you a professional requirements engineer.

With projects failing or project outcomes differing totally from what project sponsors expected, the focus was placed on requirements analysis, specification, documentation, and management. A systematic approach to requirements engineering was needed. In 1996 Klaus Pohl wrote: “Requirements Engineering (RE) as a discipline is still immature.” He introduced a “comprehensive framework for RE” ^[1]. He made a point of tracing requirements during the whole lifecycle of systems development rather than only defining requirements waterfall-like upfront in the concept phase of the process. Professional requirements engineering was in demand: standards, methods, techniques, and a common language for everybody dealing with requirements within organizations, especially those with distributed teams.

How to Meet Requirements

Software and systems engineering have become pressed-for-time business and the amount of volatile requirements to handle is ever increasing. Just imagine developers of software apps for mobile devices or miniature embedded systems for mobile wearables. They face an immense amount of requirements, multiple fast-changing operating systems, short release spans, and very short time to market.

Perhaps this explains why many of them join the Agile crowd. Iterative, incremental development lifecycles have not been invented by the Agile movement, but apparently they outdo the sequential lifecycles, when project deliverables have to be reviewed and redefined in short periods of time. Less lead time also triggers off continuous delivery. Agile methods claim to value “working software over comprehensive documentation” ^[2]. Still, the toolbox for professional requirements engineering applies to the Agile modus operandi as well as to serial lifecycles. It is the application of the requirements engineering approach that differs, not the body of knowledge. Every step: elicitation, documentation, validation, negotiation, and management is vital to projects regardless of the lifecycle model chosen. In fact, Agile teams need more professional requirements engineering know-how as there is no specific role of a requirements engineer. Instead, product owner, development team, and stakeholders negotiate and revise user stories continuously. The focus is much more on users’ acceptance. That’s why Agile teams claim to rarely lose track of stakeholders’ goals and needs.

However, conceptual models like huge use case diagrams are utilized more often in projects where regulatory compliance is requested or changes could have a detrimental impact on architecture. Many of these projects follow a waterfall model and call for meticulous documentation. In projects with distributed teams, collaboration is mostly virtual and documentation is necessary to keep everybody in the picture. Processes, artifacts, and roles vary but the methods to tackle requirements are used either way. The amount of documentation and modeling that has to be done is scalable, depending on the specific project. But if you want to meet requirements you need to follow a systematic approach. Your specific requirements engineering activities have to be closely interlinked with your software engineering process. With this framework you are on solid ground, but your technological infrastructure is ever changing.

The Mobile Mind Shift

The world has become more agile and more mobile. With the invention of smartphones and tablet PCs we are now used to getting everything done at the very moment with an app on a mobile device. We can order books, check in for a flight, browse restaurants, or check available cars to rent nearby in an instant. Already more than one billion smartphones and more than 150 million tablets are being used worldwide. Forrester Research call the expectation to get what you want in the immediate context and moment of need the Mobile Mind Shift.

Not only the minds of digital natives have shifted. Anybody who uses mobile devices expects service in so called Mobile Moments. A “mobile moment” is a point in time and space when someone pulls out a mobile device to get what he or she wants immediately, in context ^[3]. This affects work as well as private life. How useful could mobile moments be for requirements engineers?

The following chart shows where the use of mobile devices could be helpful. The size of the arrows indicates which tasks might profit more or less:

The biggest arrow obviously points to requirements elicitation. That’s when requirements engineers get mobile. They leave their workplace and talk to stakeholders and sponsors. They elicit requirements by interviewing, brainstorming, and observing stakeholders or focus groups in their surroundings. If given permission, they can easily tape interviews, take photos or videos, and scan documents – with mobile devices. The collected data is transferred up into the cloud and will be retrieved from there later on for documentation. Requirements engineers might also access and edit documents or models on tablets or laptops when they validate and negotiate requirements or when they determine and cross-check the system scope and boundaries with their stakeholders. Our evaluation is that requirements documentation and management will be less affected. Minor changes might be added at once but major changes will probably not be done in passing. The usefulness of mobile devices will of course depend on the amount of data to handle. Prototyping, emulation, and simulation tools, unless they are in the cloud, need more processing capability than mobile devices can offer today. But bearing technological advance in mind, it is foreseeable that requirements engineers – and not only millennials – will increasingly use mobile devices when they go out to collaborate with their stakeholders. They will seize mobile moments regardless of the methodology they follow. For Agilists, the use of mobiles might be especially helpful to immediately capture the essence of conversation. The Agile movement claims the primacy of conversation over documentation but still has to document the outcomes of the conversations.

The “Media Richness Theory” gives evidence to this assumption. It states that “the more ambiguous a message is to the receiver, the more rich a medium needed to communicate it” ^[4]. The richest medium is face-to-face communication, followed by video conferencing, telephone, letters, and emails. Less rich, so-called “leaner”, mediums include written and numeric documents. Although this theory dates back to 1984 it still seems valid today. We can connect virtually with anybody in real time, but there is still a need to interact personally.

Documentation of such personal meetings will increasingly involve mobile devices. Mobile moments in interviews and workshops are captured by one click out of the pocket. Snapshots of user story cards on pinboards, simple use case drafts, and prototypes are taken right on the spot. High-quality video recording is possible with any smartphone or tablet today. Notepad features are used to add sketches, notes, and figures. These “captures” are the source of requirements and should be kept in a safe place from where they can be shared easily.

The impact of instant messaging, live chatting, and online social networking services is growing. This will surely affect communication with stakeholders. Once you get connected on Twitter, Facebook, and LinkedIn (for example), information flows along these paths. Since employers have realized that employees with followers and friends can be quite profitable, they object less to accessing social networks for business purposes. Web-based social networking provides countless opportunities for mobile moments. Requirements engineers could for example design and conduct surveys, share videos and files, and receive instant feedback. Market researchers use these networks to find people for focus groups or to analyze potential users. Requirements gathering techniques are quite often derived from market research techniques. Social media will have an impact on requirements elicitation and probably on validation as well.

We agree with Christian Wünch’s blog ^[5], that mobile requirements engineering will be more authentic, more spontaneous, and more personal. He points out, that requirements engineering deals with human beings and their interests. Consequently, you can get a lot closer to your stakeholders through social sharing.

Delay is less tolerated. Once you leave your workplace you use your smartphone to check emails. Mobile devices are increasingly used for business collaboration. They make it easy to take work along. “Short time to the market” suggests that no time should be wasted. As a result, an increasing number of corporate solutions will be accessible from mobile browsers to satisfy the ever growing demand for getting things done immediately. Rob Tiffany, the Global Technology Lead of Microsoft, predicted in a Guardian article last December: “Moving into 2015, the enterprise mobility megatrend will drive some of the largest corporate expenditures seen in years as organizations bring these vertical, line-of-business solutions to mobile platforms”^[6].

Join Max – Our Requirements Engineer Persona

Max is 37, father of 2 children, married to Anne and likes Sushi, basketball, and gadgets with a bitten fruit logo on top. What does it matter? Well, Max is our fictitious requirements engineer, our persona. His technique is used in interaction design to imagine real user experience ^[7]. Let’s use it now to zoom in on his job. We made him up and filled him with life to find out what a day in his life could be like. Modeling so-called “A Day in the Life" scenarios is a technique originally used in UX (User Experience) design, but it can also be of great use for requirements engineers trying to gain a deeper understanding of stakeholders and to sequentially string together use cases of a whole day. Max is on his way to meet a stakeholder and wants to elicit requirements of an embedded automotive system. Figure 2 illustrates “A-Day-in-the-Life” scenarios that facilitate utilizing mobile moments.

His day is filled with mobile moments. He wants to take as many impressions to his workplace as possible. He is also a busy Dad at home. That’s why he wants to make sure, that important information in the interviews does not slip his mind over night. He uses his mobile devices several times that day, especially when he receives face-to-face information. He records the entire interview with a potential user, he takes photos of the production hall, he adds digital notes and accesses data via web browser. At the end of his work day he remotely edits his timesheet. He uses three different devices to work on one project – each of the three suits particular tasks best. For filming, audio recording and photos he pulls out his smartphone; for drawing simple use case sketches and flicking through specifications he uses his tablet; and for accessing project artifacts like pre-modeled activity diagrams he uses his laptop. Data is scattered in disparate systems. He will synchronize it the next day. He also uses his mobile devices for communicating with his family. He sends them photos from his business trip and chats with them on Skype. His mobile devices are his private property.

Bring Your Own Device

Bring Your Own Device (BYOD) is common practice in many organizations nowadays. The practice promises benefits like better work-life balance and higher productivity due to round-the-clock availability. According to the German BITKOM report of 2013, 43% of all German ICT organizations gave permission to use private devices for business purposes ^[8]. But if private gadgets are used there is no clear-cut separation of private and corporate data any more. Organizations can no longer guarantee confidentiality and security standards for handling customer information if they assume the risks and the impact on activities and deliverables. Enterprise data security is jeopardized. However, this is a project and configuration management problem, not a requirements engineering problem.

What effect does BYOD have on mobile requirements engineering? Countless apps are available to record all your gained insights as images, memos, pictures, videos, or audio files „live“. But the use of these data sources is particularly problematic for organizations. Individually chosen apps generate data that are nonhomogeneous, often stored in various clouds, and cannot be monitored by the organizations. Also, the rest of the team cannot access the data. The step from gathering information to derived requirements is only traceable for the author himself.

Organizations need special BYOD policies and terms-of-use agreements to tackle these problems. Legal and network security advice is in demand. Organizations have to introduce new safeguard applications, quite often Security-as-a-service defenses. The shift in workforce connectivity also requires also data governance between private clouds and corporate platforms. Consequently, BYOD programs are quite a challenge.

App-solutely secure?

What could a solution for mobile requirements engineering look like? How could we create mobile moments and share them in real time with the rest of the team? One suggestion is a tool application that shares data rather than importing it from different clouds. The infrastructure for such a tool app could look like this:

In this case, the mobile app sends videos, images, and audio files from the mobile device directly to the server. The collected sources for requirements are stored in the same database as the project data. The database can be a cloud or on-premises solution. This improves traceability and creates a secure environment for sharing data, while admittedly at the same time increasing the threat of data leakage. IT admins have to raise security levels because each mobile device that gets lost or accessed by the wrong person is a corporate security risk. Still, requirements engineering will become part of mobile enterprise with complete ubiquitous access to all corporate resources and services. "Bring your own device (BYOD) is no longer just a trend—it's how business gets done,"^[9] wrote Clayton Jones, Google Enterprise product manager, in a May 21st 2014 post on the Google Enterprise Blog.

Any IDEAs?

Finally, let’s try to think ahead. What other mobile moments in requirements engineering can you think of? It’s hard to predict, isn’t it? If you want to develop apps supporting mobile moments you need to anticipate user behavior and needs.

Successful mobile apps like Evernote, Instagram, or WhatsApp identified real mobile moments and offered simple services for everybody. The Forrester Research group suggests applying a so-called IDEA-framework ^[3] to support the development of mobile apps. It consists of four steps which form an iterative cycle:

• Identify the mobile moments and context.
• Design the mobile engagement.
• Engineer your platforms, processes, and people for mobile.
• Analyze results to monitor performance and optimize outcomes.

Start off with observing the whole requirements engineering process. Where can you find mobile moments? Most likely, when stakeholders and requirements engineers get together. Use “A Day in the Life Scenarios” and Personas to put yourself into their shoes. Then, design the mobile engagement based on the benefit to requirements engineers. Bear UX (User Experience) in mind. It must be intuitive and operable on small and touchscreens. Use Cases, scenarios and UML class diagrams also produce good results here. The next step is engineering: build platforms, transform processes, and organize people. An agile process is recommended. Gartner says: “Agile development is essential for mobile application development”^[10]. It is the best way to cope with fast changing conditions. Scrum might be a good choice.

Once you’re done with engineering a potentially deliverable product increment, you need to analyze the outcome and use your findings to kick off a new IDEA-cycle. Does that remind you of anything? Yes, mobile and agile development have something in common: They are iterative and incremental. Both trends react to swiftly changing markets with cyclic, revolving processes. Proper requirements engineering will play a major role in any of these cycles. To satisfy customer needs now and in the future requirements engineers will have to be mobile and agile. That’s probably not a fortune teller’s assumption. What do you think? We’d be happy to hear what your vision of mobile requirements engineering is.

Conclusion

The future is unstoppable. Remember the movie Back to the Future? How quickly the future arrives! Organizations that are not embracing the mobile future risk the ability to recruit the next generation of requirements engineers. The more requirements elicitation, validation, negotiation, and specification will be done together with the stakeholders in face-to-face communication, the more mobile moments will come up and be captured with mobile devices. Know-how is needed, but also IDEAs to design innovative mobile solutions. Better get ready for the mobile future now.

References and Literature

• [1] K. Pohl: Process-Centered Requirements Engineering. Research Study Press, Advanced Software Development, Taunton, Somerset, 1996.
• [2] Manifesto for Agile Software Development, agilemanifesto.org, 2001.
• [3] T. Shadler, J. Bernoff Josh, J. Ask – Forrester Research: The Mobile Mind Shift: Engineer Your Business To Win in the Mobile Moment, Groundswell Press, 2014
• [4] R.L. Daft, R.H. Lengel: Information richness: a new approach to managerial behavior and organizational design. In: Cummings, L.L. & Staw, B.M. (Eds.), 1984
• [5] C. Wünch: Requirements Engineering, Mobile Computing & die Cloud, Hood Blog, 21 January 2014 blog.hood-group.com/blog/2014/01/21/requirements-engineering-mobile-computing-die-cloud-teil-1
• [6] R. Tiffany, Global Technology Lead: IoT & Enterprise Mobility, Microsoft, in: Mobile trends for 2015, 22 December 2014 theguardian.com/media-network/2014/dec/22/mobile-trends-for-2015
• [7] A. Cooper: About Face: The Essentials of Interaction Design, John Wiley & Sons; 4th edition, September 2014.
• [8] BITCOM: Leitfaden Bring Your Own Device, bitkom.org/files/documents/20130404_LF_BYOD_2013_v2.pdf, 2013.
• [9] googleforwork.blogspot.de/2014/05/new-google-apps-mobile-management.html
• [10] Gartner Inc., Press Release of 14 August 2014, gartner.com/newsroom/id/2823619