Your SlideShare is downloading. ×
Managing Requirements & Traceability in Axure
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Managing Requirements & Traceability in Axure

6,414
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 …

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
6,414
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
267
Comments
3
Likes
17
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Managing Requirements & Traceability Presented by Fred Beecher
  • 2. AXURE IS NOT A REQUIREMENTS MANAGEMENT TOOL!!!!!!!!!!!!!!!!!!!!
  • 3. But that doesn’t mean you can’t do it
  • 4. AXURE IS NOT A REPLACEMENT FOR USER EXPERIENCE DESIGN!
  • 5. No getting around that one. Sorry.
  • 6. My Approach Structure Manage Collaborate Documents References
  • 7. Collaboration
  • 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. Documentation Structure
  • 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. 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. Structure Documentation
  • 13. Reference Management
  • 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. 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. 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. 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. Other Approaches
  • 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. 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. Discussion
  • 22. Fred Beecher fbeecher@gmail.com @fred_beecher

×