How to effectively elicit user interface requirements

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Software Requirements Gathering, Analysis, Quality and Testing How to write a Software Requirements Specification (SRS) document Problems caused by skipping analysis stage of SDLC Software development life cycle phases, iterations, explained step by step Waterfall versus iterative development misconceptions Differentiating between Functional and Nonfunctional Requirements Writing a software requirements specification (SRS) for a portal app Should QA check changes from outside the requirements document? Software testing metrics for a medium-sized project Template for requirements use cases What should a business analyst's requirements document include? Software requirements techniques (Prototyping, Storyboards, Modeling, State transitions) Requirements practices evolving, but organizations still struggle Why business analysts are application development key players today Defining report requirements with use cases When it comes to requirements, what is 'just enough'? How requirements use cases facilitate the SDLC GatherSpace beefs up cloud-based requirements management Software development life cycle phases, iterations, explained step by step How to deliver, implement testable software requirements Excelling in the art and science of requirements elicitation Software requirements: Moving beyond use cases Use cases and misuse cases Requirements practices evolving, but organizations still struggle Defining report requirements with use cases How requirements use cases facilitate the SDLC Excelling in the art and science of requirements elicitation Requirements use cases tutorial: Advanced formats, test case comparisons Use cases for software requirements tutorial: Strengths, flaws, formats Writing a software requirements specification (SRS) for a portal app Agile software development tutorial: Agile requirements gathering Pros and cons of requirements-based software testing How to avoid requirements creep

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary requirements analysis  (SearchSoftwareQuality.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

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!