EXPERT RESPONSE
As much as the user experience is essential to successful software products there are many other requirements that must be elicited, analyzed and validated. You are wise to look below and beyond the presentation layer to elicit additional details and gain a comprehensive, balanced representation of the product requirements.
I use a number of techniques to dig down under the user interface's surface. Multiple models can give you and your customers rich information, quickly. Here are some suggestions:
Ask your customers to describe "cases of use" (a.k.a. scenarios or stories) for the interface. Identify data values for each scenario. Then, with the customers, test each scenario. Run the scenario through the appropriate navigation path using the test data. Lots of questions will pop up. As you analyze the interface you are likely to uncover data requirements such as whether a field is optional or mandatory, what fields are editable, and default values. Ask questions to uncover rules such as selection criteria to populate fields or list boxes, how to calculate totals, and error conditions.
You can also drive your requirements exploration by taking a user role- (or actor or persona) based approach. With your customers, identify all different types of user roles that the interface must support. Question how usage across roles varies, and what is common. Find out if there are restrictions for each role and document these requirements with data and rules, e.g., security permissions, what is actionable on a menu, or role-specific default values. Write scenarios for each role, define data values and test drive them through the navigation and screens.
Go beyond UI requirements to discover any temporal events. Temporal events are triggered by the passage of time, for example, "time to generate invoice," or "time to produce financial summary report." Unlike business events that are triggered by users, temporal events can be overlooked when user interface prototyping is center stage. Work with the customers to identify temporal events that are in scope for your product. Be prepared to uncover many detailed requirements: process steps, data, business rules, and even quality attributes such as throughput, security, reliability, interoperability, and more. Write scenarios to test these events.
Get to deeper requirements such as the "invisible" system-to-system interfaces. I refer to them as "invisible" because they may not be readily thought of by your users. While your business experts may not be directly involved with defining these detailed requirements, they can identify which business or temporal events require data from another system, or provide data to another system. Revisit the scenarios you wrote for the UI and temporally initiated events. Look closely to determine if they require system-to-system interfaces. If so, extend your scenarios to incorporate these details.
Yes, modeling UI requirements is essential. AND it can serve as a jumping off place to delve below and beyond for requirements to support the entire product. Look to broaden your customers' perspective of the application by engaging them in writing and testing a variety of scenarios. Leverage a variety of requirements representations to model events, data and business rules. Bottom line -- you and your customers will produce deeper, detailed requirements -- and they will undoubtedly be more complete, clear and correct!
|
