Managing Requirements & Traceability in Axure

Managing Requirements & Traceability Presented by Fred Beecher

AXURE IS NOT A REQUIREMENTS MANAGEMENT TOOL!!!!!!!!!!!!!!!!!!!!

But that doesn’t mean you can’t do it

AXURE IS NOT A REPLACEMENT FOR USER EXPERIENCE DESIGN!

No getting around that one. Sorry.

My Approach Structure Manage Collaborate Documents References

Collaboration

Collaborate User Experience Design is a collaborative discipline. Early and frequent collaboration will minimize drastic changes down the line. 1. Developers & Visual Designers • What info do they need to build the site? • What format do they need it to be in? 2. Business Analysts • Are business requirements or site design driving the project? • Understand features up front & circle back to check on use cases & then detailed requirements

Documentation Structure

Structure Documentation The architecture of your prototype & business requirements document affects how you keep them in sync. Business Requirements Feature • I work with BAs to structure the Use Case Use Case BRD hierarchically RQ RQ RQ RQ BR BR • Features are the primary component and they are RQ RQ RQ RQ composed of use cases. BR BR • Use cases are themselves composed of detailed requirements & business rules • Some requirements & rules might be tied to features instead or to the system as a whole

Structure Documentation The architecture of your prototype & business requirements document affects how you keep them in sync. Prototype/Functional Spec • I split my prototypes into 3 sections: Pages, Page Types, & Functionality. Only relevant sections get generated in the spec. • Functionality contains ﬂows associated with use cases. • The pages associated with each ﬂow display beneath it • Page Types contains wireframes of page templates • Pages contains instances of the page types with content required for prototype testing. This section is NOT generated in the spec

Structure Documentation

Reference Management

Manage References UX documentation can be very ﬂuid up until delivery, so only reference it at the use case level in the business requirements

Manage References The key to keeping UX documentation & the BRD in sync is to reference detailed requirements & rules in page notes & annotations Page Notes • I create three page notes sections: Description, Business Rules, Error Messages • Description should be obvious :) • Business Rules displays those rules that apply to the page as a whole • Error Messages displays any error messages that can occur on the page. • Numbering rules & errors is helpful.

Manage References The key to keeping UX documentation & the BRD in sync is to reference detailed requirements & rules in page notes & annotations Annotations • I create two annotation fields from which to refer to the BRD, Business Rules, Requirements • The Business Rules field summarizes the applicable business rules & references them by number • I also indicate here which error messages are displayed & under what conditions • The Requirements field lists applicable requirements by number

Manage References Numbering. It can be a pain or a help. Here’s how I make it work 1. I do not allow requirements to be deleted or renumbered EVER!!!! 2. Strike requirements out and add numbers instead (after all, there are an inﬁnite number of them) 3. Append some letters to make it easy to search the document for them, e.g., BR19.2, RQ37, etc. 4. In the annotations, refer to rules by summary & number and refer to requirements just by number 5. If the business rules or requirements change, just use Axure’s Find feature to ﬁnd where they’re referenced and make updates to the design as necessary 6. This works well in reverse too.

Other Approaches

My way is not the only way I’ve been exposed to methods that many different organizations use to keep their requirements & UX documentation in sync... • Using a shared project without sharing to keep track of different versions • Integrating other requirements into the .DOCX ﬁle you generate the functional spec to • Business requirements before the spec • Technical requirements after the spec

An interesting possibility... Did you know you can export .CSV files of your widget and page annotations from Axure? This gives you access to the unique IDs Axure uses to keep track of widgets. 1. Click on Generate > More Generators and Configurations 2. Choose Add New > CSV Reports, & name the report 3. Select the report and hit Generate 4. Choose what you want to generate, and open the .CSV files in Excel If you manage your business requirements in Excel, you can use its VLOOKUP function search for widget IDs and pull in the contents of specific annotation fields dynamically!

Discussion

Fred Beecher fbeecher@gmail.com @fred_beecher

http://bbkiaob.posterous.com	74
http://www.slideshare.net	22
http://posterous.com	22
http://localhost	19
http://pixelblume.posterous.com	8
http://www.linkedin.com	4
http://webcache.googleusercontent.com	1
http://jbaeck.posterous.com	1
http://malinovskaya	1

Managing Requirements & Traceability in Axure

by Fred Beecher on Nov 15, 2009

Accessibility

Categories

Upload Details

Usage Rights

9 Embeds 152

Statistics

Managing Requirements & Traceability in Axure Presentation Transcript