Managing Requirements & Traceability in Axure

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    2 Favorites

    Managing Requirements & Traceability in Axure - Presentation 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

    + Fred BeecherFred Beecher, 1 month ago

    custom

    200 views, 2 favs, 0 embeds more stats

    Many large organizations without user experience de more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 200
      • 200 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 2
    • Downloads 10
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories