Managing Requirements & Traceability in Axure

8,276 views

Published on

Many large organizations without user experience designers like to try to use Axure to fix their communication problems. Partially this is because it can generate documentation. This presentation teaches you how best to attempt to manage requirements & traceability in Axure.

3 Comments
17 Likes
Statistics
Notes
No Downloads
Views
Total views
8,276
On SlideShare
0
From Embeds
0
Number of Embeds
167
Actions
Shares
0
Downloads
356
Comments
3
Likes
17
Embeds 0
No embeds

No notes for slide

Managing Requirements & Traceability in Axure

  1. 1. Managing Requirements & Traceability Presented by Fred Beecher
  2. 2. AXURE IS NOT A REQUIREMENTS MANAGEMENT TOOL!!!!!!!!!!!!!!!!!!!!
  3. 3. But that doesn’t mean you can’t do it
  4. 4. AXURE IS NOT A REPLACEMENT FOR USER EXPERIENCE DESIGN!
  5. 5. No getting around that one. Sorry.
  6. 6. My Approach Structure Manage Collaborate Documents References
  7. 7. Collaboration
  8. 8. 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
  9. 9. Documentation Structure
  10. 10. 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
  11. 11. 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 flows associated with use cases. • The pages associated with each flow 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
  12. 12. Structure Documentation
  13. 13. Reference Management
  14. 14. Manage References UX documentation can be very fluid up until delivery, so only reference it at the use case level in the business requirements
  15. 15. 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.
  16. 16. 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
  17. 17. 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 infinite 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 find where they’re referenced and make updates to the design as necessary 6. This works well in reverse too.
  18. 18. Other Approaches
  19. 19. 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 file you generate the functional spec to • Business requirements before the spec • Technical requirements after the spec
  20. 20. 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!
  21. 21. Discussion
  22. 22. Fred Beecher fbeecher@gmail.com @fred_beecher

×