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?
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.
Dig Deeper on Gathering Software Requirements Use Cases
Related Q&A from Sue Burk
Does sequence matter when you are not using use cases or process modeling techniques? Expert Sue Burk explains the importance of sequence by using a ... Continue Reading
Expert Sue Burk explains the importance of gaining proper approval for requirements changes and offers suggestions for the most efficient ways to ... Continue Reading
In this response, expert Sue Burk describes the importance of the relationship between hardware and software in embedded systems, and how they must ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.