Collaborate and challenge to get the right software requirements

Here we will introduce an approach to customer collaboration and requirement definition. This approach is based on some key concepts:

1. Requirements are created by directly building on what we know about how the system (or feature of the system) affects and is affected by other components or parts of the system itself;
2. Discovering and documenting these relationships involves many people — customers, business analysts, project managers, quality assurance engineers, designers, developers, customers of customers — all need to be involved;
3. The effectiveness (and success) of such an effort depends on the degree of collaboration as well as on the degree to which everyone involved takes responsibility for making it work; and
4. The more we can do this, the more we reduce conflicts and misunderstandings.

This approach has been used in a number of projects with very positive results: better systems (features), higher customer satisfaction (because they get what they need and want), lower development costs (because product definitions are created that meet customers’ needs but which require less rework to complete), and lower maintenance costs (because customers report that they use their systems more effectively).

Let’s start by looking at an example of how you might define a new feature for an existing system. Then I’ll talk about how to apply this same process to system definition.

A new feature in an existing system
Suppose you work for a company that has developed a package tracking system, but your marketing department decides they need a new feature that will provide customers with “advance warnings.” They have determined that the advance warnings should inform them of when shipments are due to arrive. For example, if their customer typically receives several shipments per week from your organization, they want to receive notification when the second shipment is about to arrive at their facility – this will give them time to schedule receiving the shipment and preparing it for final assembly or customer shipment.

You might begin by talking with various people in marketing who know more about the business context in which this feature needs to be used: what is the typical shipment arrival cycle? How often do new shipments arrive? Is it possible to group arriving shipments into groups of “like items” so that you can send warning messages for each group rather than one message per shipment.

You might also want to talk with other people who may be involved in defining requirements: customer service representatives, accounts receivable/payable, accounting and finance managers. You probably want to check with your legal department about any notification or data privacy rules that may apply. All these discussions will give you a much better idea of what is needed. They will help you understand how this product fits into the overall business context to which it needs to contribute as a solution.

As a result of all these discussions, you might develop a “product vision” that captures the key ideas:

“Advance warnings” will let customers know when to expect future shipments and provide them with advance notification of these arrivals. Advance warnings will be grouped by shipment type so that multiple messages can be sent for each group of like items. Customers will receive no more than one message per group. If several shipments arrive on the same day, only one message will be sent for those shipments (rather than one message per shipment). Warnings can include information about shipments scheduled during the next 7 days and must be received 5 days prior to scheduled arrival date. At least 3 business days’ notice is required before delivery of certain types of high value deliveries (UPS requires this notification time frame). Customers will be able to update their contact information (for example, phone numbers and addresses) directly by using the application.

The product vision captures key ideas about what needs to be done — it summarizes the overall solution that is required. It doesn’t say anything about how this should be done or who might do it. The vision only describes the problem that needs to be solved now and for future releases of the software system. To capture these requirements, you now need to work with other people in marketing to develop a “requirements document.” This document may contain information similar to what follows:

1. Introduction
An advance warning system is needed so customers can schedule receiving products during regular business hours rather than at night or on weekends when product shipments may arrive.

2. Functionality and User Interface Requirements
Advance warnings should be grouped by shipment type so that users receive only one message per group even when multiple shipments in a group may arrive on the same day.

3. Notification Format and Delivery Schedule: Any advance warning messages should include:
a) A notification date when the customer can expect to receive their product delivery;
b) A list of products scheduled for arrival during this time period; and,
c) The name of each product scheduled for arrival (description will be included if available).
Warnings should contain no more than 7 items per message, with at least 3 business days’ notice before delivery of high value items.

4. Customer Contact Information Updates: Customers should be able to update their contact information directly using the application.

5. Additional Requirements: The solution needs to work with existing databases that store customer data, shipping schedules and product descriptions/images.

6. Glossary of Terms Defined in the Requirements Document: Product types are used throughout this document to refer to products whose delivery might be affected by advance warning messages sent to customers. Product Types include but are not limited to medical equipment and pharmaceuticals (high value), TVs and electronics (medium value) and groceries (low value). Advance warning messages must provide customers with 3 business days’ notice before delivery of high value deliveries, 5 days’ notice before medium value deliveries and 7 days’ notice before low value deliveries.

Some Rohterham organizations also include a “vision document” that describes the product’s future capabilities. For example, this document might detail how the product will be used in 2 years among customers who purchase high value products (e.g., medical equipment), medium value products (e.g., bulk groceries) or low value products (e.g., small household items).

Vision documents are generally less well developed than requirement documents because they describe future capabilities, not present solutions. As with other types of information included in the requirements document, vision statements aim to capture ideas about what is to be done without talking about how it’s to be done or by whom it’s to be done. Vision documents help people understand what’s needed and then build a better solution.

Vision documents may be written at the end of the product release life cycle when it is time to consider what you would like to see in future releases of your software system. As such, they should describe:

• What the next target application will look like (outcomes).
• How users will interact with the next generation application (interfaces).
• What technical challenges need to be solved before reaching this vision for future releases (challenges).

Users could be given an opportunity to provide feedback about their preferences for how they want future versions of the product to behave/look after its initial release. Comments may be posted on internal or open forums about a product’s future requirements or desirable features. Contact Rotherham Apps and we can help you get the right software requirements.