Requirements management in the world of mobile devices and cloud computing

Requirements management in the world of mobile devices and cloud computing

Recently we’ve found ourselves eliciting requirements for mobile devices, the cloud and social media—and who knows what will be invented next? What do we need to know about developing requirements in this new world of digital interaction?

    Requires Free Membership to View

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

The key thing to remember is that functional (and most nonfunctional) requirements are implementation independent. For example, suppose you’re defining requirements to implement guaranteed‑for-late-arrival hotel reservations. From the perspective of functional requirements, making a reservation includes the ability to verify availability of the requested room type and to validate the guest’s credit card. The hotel needs to make a reservation however it is implemented—via phone call, in person at the hotel, Web page, kiosk or voice response system. Nonfunctional requirements include three things: design and implementation constraints, interfaces and quality attributes. Of these, a performance quality attributes—such as “the application must handle 5,000 concurrent users” or “the application must provide 10-second response time for queries”—must be met regardless of implementation technology.

The advent of new interfaces (such as mobile devices and social media sites) or new ways to provide and connect services (such as the cloud or through social media) does not change your need to focus on implementation independence. Yet, these kinds of new technologies, along with the devices and infrastructure on which they reside, can introduce constraints on your design and implementation. For example, the limited real estate on a mobile phone may dictate a simpler user interface compared with the one offered over the Web. If that simpler design limits functionality or usability, or if there is a significant monetary cost to implement all the desired functionality and usability at once, the organization may need to prioritize which functions to initially offer over the mobile phone. What’s more, you may need to select which device to support first. Does the hotel have enough time and resources to develop and test a reservation app and release it simultaneously on all smart phones, or will it have to choose to offer it first on the iPhone or BlackBerry or Android? These are business considerations, and they need business input and prioritization.

Thus, as technology becomes more pervasive, and enabling it challenges us to reconsider current business practices and gives us opportunities to innovate, the boundary between technology and business becomes increasingly blurred. Here are some examples:  

  • Rather than print and carry your airplane boarding pass, you can scan your pass using your mobile device. 
  • A new blood glucose product monitors diabetics’ blood pressure as well as blood glucose. It transmits the results to a secure server for review by physicians, helping them coordinate patient care.    
  • Computers can examine and compare large volumes of information to prescreen medical records and suggest patterns for physicians to explore in more detail. Then physicians can apply their unique insights, experience, and knowledge of their patients to zero in on a diagnosis quickly and effectively.   

If you develop—that is, elicit, analyze, specify and validate—requirements, you need to be mindful of the role of new technologies. Be sure to consider these factors.

  • New user types: If you’re moving tasks from internal staff to the end user, you may need to change the user interface design to make it friendlier. Beyond design considerations, the actual usage may be different, too.  
  • New and changing user interfaces: Smart phones and tablet devices are only the tip of the iceberg. Who knows what the future may bring? Again, beyond design considerations, the actual usage may be different because new interfaces present opportunities for innovation.
  • New interfaces to services:  If you can subscribe to services on the cloud or within a social media setting, you can gain competitive advantage by invoking newly available functionality or by combining functionality in new ways.

The takeaway: don’t abandon your good requirements practices. Elicit and analyze user requirements by using multiple techniques, such as user stories or use cases in conjunction with prototypes, a data model and acceptance tests. Keep using best practices for eliciting and analyzing nonfunctional requirements, such as Planguage (Tom Gilb, Competitive Engineering: A Handbook for Systems and Software Engineering Management Using Planguage, Addison-Wesley, 2005). And always be sure that your requirements are testable. At the same time, as technology barriers—and the boundaries between the real and virtual worlds—disappear, be sure to collaborate with your business partners to envision new ways to conduct business.

This was first published in November 2011