powerpoint slides
TRANSCRIPT
1
Requirements Management with Tools –
A panel presentation
March 30th, 2006
Hosted by:Consulting Matters and Solutia Consulting Inc.
Please do not distribute this information.
Twin Cities Business Analyst Community
2
Agenda• Panel Participants
– Cathy Herfindahl– Leroy Miller– Nandan Dasgupta – Jon Iversen
• Panel Participant Experiences– Tool experience– Success story on the usage of the tool– Pro/Con’s of the tool features– Tips or lessons learned with the tool
• Questions and Discussion
Twin Cities Business Analyst Community
3
Panel Participants• Cathy Herfindahl
Cathy works in the Delivery Assurance Group of GMAC-RFC specializing in requirements management. She has consulted on IT requirements and project management across a variety of industries for over 12 years. She will share her experiences with Borland’s Caliber-RM tool.
• Leroy Miller Leroy works in the IT Custom Applications Group for Boston Scientific. He has worked in the IT industry for 5 years as a business analyst. He has been using the Telelogic DOORS RM tool for the past 2 years.
• Nandan DasguptaNandan works for Wells Fargo as an E-Business Systems Consultant. He has been using Rational Requisite Pro for over 6 years.
• Jon IversenJon works for WynEdge consulting. He is currently at the National Marrow Donor Program working on a project to create a robust, comprehensive, and definitive data model and protocol for exchanging marrow transplantation data between systems . He has 10 years of analyst experience. His RM tool experience is with Rational Requisite Pro.
Twin Cities Business Analyst Community
4
Cathy -CaliberRM Experiences• Tool experience -
1. We have been leveraging CaliberRM for 2 years
• Requirements tool assessment
– Cost
– Functionality
– Ease of Use
• Prototype of tool was successful
– Reduction on testing defects by 30 – 50%
– Standardization of deliverables (business & system requirements)
2. 70+ projects utilizing CaliberRM
3. Largest project has over 2700 requirements
Twin Cities Business Analyst Community
5
Cathy -CaliberRM Experiences• Success story on the usage of the tool -
1. Standardization of basic requirements definition attributes –
– Unique numbering, priority, status, source, etc.
2. Requirements Traceability throughout the development lifecycle
– Business Requirements to System Requirements
– System Requirements to System Test Cases
– Business Requirements to User Acceptance Tests
3. Re-use of Requirements
4. Project team collaboration – online discussions
5. Standardization of requirement deliverables
6. Single source of truth for all project requirements
7. Alignment with the testing team
– Leveraging integration with Test Director
– Utilizing “validation” field
8. Requirements change management – Impact analysis
Twin Cities Business Analyst Community
6
Cathy -CaliberRM Experiences• Pros and Cons of tool –
Pro’s of Tool Features
+ Integration with testing tools
+ One central repository
+ Ease of customization – alignment of company process & policies
+ Standardized terminology & online glossary
+ Audit trail & change history
+ Requirements versioning & baselining
+ Ease of use
+ Ability to move requirements in & out of scope
Con’s of Tool Features
– Requirements traceability reporting
– No basic requirements metrics reporting
– Initial requirements template set-up was cumbersome & difficult
– Out of box templates were not very good
Twin Cities Business Analyst Community
7
Cathy -CaliberRM Experiences• Tips or lessons learned with tool –
• Adoption – moving from a paper based solution to an online tool
– Take time to help everyone understand the benefits
– Create a buddy system
• Document your organization’s requirements process and align the tool to match the process
• Create a central support site for all users’ needs
• Integration of requirements change management processes
• Communication & training
Bottom-line – We are no longer focusing on the mechanics of
requirements definition and management.
We now can spend more time on the scope & functionality and fine
tuning our elaboration skills.
Twin Cities Business Analyst Community
8
Leroy - DOORS Experiences• Our Search for a RM Tool• After the Honeymoon• Ongoing Investigation• Epilog
Twin Cities Business Analyst Community
9
Our Search for a RM ToolTwin Cities Business Analyst Community
• Background– In previous projects we experienced great pain while trying to keep all documents in sync – Each of our requirement documents contained the business rules necessary to support that
section of system functionality– We decided that the best solution would be to have a system (tool) where we could
document business rules in one location– We could then reference that instance from multiple documents– We started with the idea that we would purchase a tool and use a ‘pilot’ project to evaluate its
use
• Initial Results– We started our search for a RM tool and discovered the Rational Rose and Telelogic DOORS
suites– Our objectives were to find a tool that could – accomplish the single-source and reference idea– ensure full coverage between business rules and requirements– ensure full coverage between requirements and testing– We invited both companies to present their product
Leroy - DOORS Experiences
10
Our Search for a RM ToolTwin Cities Business Analyst Community
• Rational Rose– Rational Rose set up a webinar to show their product– We were interested in their WORD solution, since the editing methods would already be
familiar to us– However, we thought that the method used to maintain the links (field codes?) seemed
unstable or problematic– We asked several questions concerning this method, but the answers were not convincing– The questions weren’t too probing, since we could not dig into the details during the webinar
• Telelogic– Telelogic set up a webinar to show their product– Telelogic sent some representatives to present the DOORS suite– We had a chance to grill them on their product and methods for maintaining the links– Our comfort level was much higher with the ‘database’ approach of objects for the links, but
were skeptical on the editing methods (not WORD-like)
Leroy - DOORS Experiences
11
Our Search for a RM ToolTwin Cities Business Analyst Community
• Our Decision– In the end, our group voted on the DOORS product, since we had already agreed that we
had to have something NOW– We thought that the linking method would be less problematic– A SMALL group in another division was the only other example of a RM tool, and they had
chosen DOORS– Cost was about the same– Product philosophy was about the same– Different products in a suite to cover all the needs from dev to test– The companies willingness to come and present meant we had dedicated access to ask
many questions and dig into the details at our leisure– With a product like this, there is so much you don’t know at the start that you don’t even know
where to start asking questions
Leroy - DOORS Experiences
12
After the HoneymoonTwin Cities Business Analyst Community
• Installing the software– We decided to install the network version of the software which allowed several users to share
licenses (Flex Licenses)– The instructions for installation required a network manager to get involved– The licensing structure requires a specific machine to be cited in the license– You can request a new license key’ if you need to move to another server, but that took some time
to obtain (an afternoon)– We had to request that the license key be based on the IP address, not the machine name since
there was some virtual things going on in our network– After some difficulty, we were able to obtain the licensing key file we needed– We were up and running
• Support– During the initial installation process, the Telelogic sales guys were available to support our
questions– We asked them and they provided a ‘guru’ to get us up and running– They offered to spend some (free) time with us to kick start the use of DOORS (the entire suite, if
possible)– They were legitimately interested in getting this thing rolling, but we were not ready to ramp up to
using the entire suite until we gained experience with the initial product (RM Tool: DOORS ERS)– Once the initial phase was completed, support was relegated to calling and requesting a return call– Most support calls were returned later that day or the following day– The support people were knowledgeable and friendly and knew when to ask for more help– Answers were accurate and helpful
Leroy - DOORS Experiences
13
After the HoneymoonTwin Cities Business Analyst Community
• Training– DOORS comes with a self tutorial database, which I thought was excellent
– It required time to plow through the details
– We learned that opening the tutorial REQUIRED eating a license
– We argued this point (why should training take a license away?)
– They provided node locked licenses for free (with some coercion)
– It required some gymnastics with the license setup, but was a workable solution while someone got up and running on the basics
– Telelogic also offered on-site training, but the cost were prohibitive for us
– We opted for offsite, but only 1 of 3 people were allowed to attend (me)
– Afterwards, I conducted our own onsite training which was mildly successful since no-one had the time to commit to using the product after the training
– It would have been more successful if we made the commitment to start using the product (allotted the time in the project schedule) and then sent the entire team to the training
Leroy - DOORS Experiences
14
After the HoneymoonTwin Cities Business Analyst Community
• Get Ready, Set, Go?– The biggest obstacle to using DOORS, however, was our own process – HOW were we
going to use this new tool– The tool was designed to be consistent, according to rules that we would put in place for its
use, but what documents would we create for each project and how would we connect them– We had to decide what types of templates were wanted to use or create– We were not constrained to any industry standards (military or IEEE)– We diagramed our development process and decided which documents belonged inside of
DOORS and which needed to be outside DOORS• Business Rules• Functional requirements• Use cases• Test specification
– We polled previous projects to determine what attributes we wanted in our ‘standard’ requirements document
– We created documents for each of these and used them in a copy/paste method to propagate to various projects
– However, we had only one project that was ‘ready’ to transition to DOORS– Others were either too far along the process or not willing to make the plunge all together
(someone had to test the waters)– We decided to transition one project to see how things would go
Leroy - DOORS Experiences
15
After the HoneymoonTwin Cities Business Analyst Community
• Breaking the dependence on WORD– Now that we had the software installed, we needed to transition our existing WORD
documents into DOORS– The import process was problematic for any tables were we using, so we decided to break
them up and use attributes– Once in DOORS, each paragraph became an ‘object’ that had ‘attributes’– The whole application is based on creating and managing attributes and views– Adding new objects was not as simple has hitting a return key, you had to know what you
were asking for– In the end we decided that once a user was acclimated to the editing idiosyncrasies, that
they would become second nature– This is true, but we underestimated our ability to become acclimated (if you don’t use it, you
loose it)
Leroy - DOORS Experiences
16
After the HoneymoonTwin Cities Business Analyst Community
• Linking– We focused on getting the text of each existing document into DOORS and organized
appropriately (business rules, functional requirements, use cases)– When we were ready to ‘link’ we learned that DOORS had a standard, no frills, no setup for
managing the links, but that it would provide no reporting as well– We needed to design a linking philosophy so that we could guarantee the ‘full coverage’
objective easily and efficiently– It took some time to set up the ‘link modules’ and ‘link rules’ for each document– Once they were set up, the use was quite simple– Creating a traceability view was easy and insightful (easy to navigate and understand)– Creating and editing links was best done on a large monitor, with both documents open
• Other Issues– We learned that there was a lot to the baselining capabilities, but that their intended use
would best be learned by calling on a guru– Everything in DOORS is based on objects, attributes and views– DXF is their ‘programming’ language – To create your own auto-templates, you need to know and understand DXF– Giving ‘reviewers’ access meant chewing up a license, hence DOORSNet
Leroy - DOORS Experiences
17
Ongoing InvestigationTwin Cities Business Analyst Community
• We decided that we needed to bring in a consultant to answer several key questions that we have with how to use DOORS more efficiently
• Our key questions revolve around (in priority order)– Printing/Formatting/Readability
– Referencing external data
– Versioning
– Security settings – Projects, Modules, Views, Objects
– Mockups
– Templates
– Import Hierarchy
– Tables
– DOORSNet
– Test Director Link
Leroy - DOORS Experiences
18
EpilogTwin Cities Business Analyst Community
• With any piece of software, the only way to use it efficiently is to dive in and get wetdive in and get wet
• The only way to continue being efficient is to keep using it on a consistent basis
• We did neither effectively• We did not commit ourselves to use the entire functionality, instead,
we committed to use it one step at a time until we had the time to fully implement
• We have suffered frustration as a result• This would be true for any tool that we purchased!• I believe the key is to commit to diving in and staying in, not
necessarily the tool you choose• I also believe that it is imperative that a process be in place for
structuring requirements prior to choosing a tool to manage those requirements
Leroy - DOORS Experiences
19
Twin Cities Business Analyst Community
• Tool experience -– Has utilized and served as the tool administrator for Req. Pro, and Pro-Use case for projects
covering the past 6 years.
• Success story on the usage of the tool -– Adapted the tool for a project – centralized its Requirements
Nandan – RequisitePro Experiences
20
Twin Cities Business Analyst Community
• Pro and Con’s of the tool features -Cons
• Support of a RUP-Mentor for a (the) project• Support of a DBA for the tool
Pros• Requirements provide the bedrock of a project. Capturing the requirements through
Use Cases puts them in a medium that everyone can understand and keeps the requirements in context.
• Provides a repository for requirements, these could be from other sources.• It allows a project team to centralize their requirements process and track requirements
throughout the software development lifecycle by ‘tracing’ them from their originating document all the way to their validation in a test case and deployment
• Also other types of tracing can be setup with RequisitePro, like for business rules, decisions, issues,...
• Overall Repository for Requirements• RequisitePro designed for use with Use Cases and other document based requirement
documents – one of its main focuses is linking relationships between different parts of different documents
• Provides a double click access to see more detail or context for a requirement based upon the it’s relationship
Nandan – RequisitePro Experiences
21
Twin Cities Business Analyst Community
• Types of requirements– Requirement types
• Stakeholder Requests - STRQ
• Feature Requirement Type - Feat
• Test Case Specification Requirement Type - TC
• Glossary Requirement Type - TERM
• Test Plan Requirement Type - TR
• Use Case Requirement Type - UC
• Tips or Lessons Learned with the tool– Easy to Learn
– Move its focus to Business Side (team)
Nandan – RequisitePro Experiences
22
Twin Cities Business Analyst Community
• Tool experience -– Has utilized and served as the tool administrator for Req. Pro for projects covering the past 5
years.
• Success story on the usage of the tool -– Good results but no spectacular successes achieved (it’s not a cure for cancer).
Jon – RequisitePro Experiences
23
Twin Cities Business Analyst Community
• Pro and Con’s of the tool features -Cons
– Requires a competent tool support staff. – Older versions are buggy.
Pros– It is simple to use– Keeps you on track for deliverables and traceability– Keeps you organized
• no lost files• no version control issues
– You only need to use the parts you want to use– It doesn’t take much more work to use Requisite Pro than to it does to not use an RM tool at
all – Eliminates most Requirements configuration management and control issues – Can be used as a knowledge repository – easy categorization and search capability are built
in– Knowledge assets of multiple projects can be linked – Easy to reconfigure for individual project needs– Can be easily integrated with other Rational tools or used as part of an overall Configuration
Management Plan (requirements are an important configuration item).
• Tips or Lessons Learned with the tool -– Start simple; Build slowly, but build; Don’t over-promise
Jon – RequisitePro Experiences
24
Additional Resources• INCOSE - Requirements Management Tools Survey
http://www.paper-review.com/tools/rms/read.php http://www.incose.org/productspubs/products/setools/tooltax/reqtrace_tools.html
• Automating Requirements Management (By Karl E. Wiegers)http://www.processimpact.com/articles/rm_tools.html
• Calculating ROI On Your Investment In Requirements Management Tools (By Richard Denney)http://www.itmanagementnews.com/itmanagementnews-54-20030822CalculatingROIonyourInvestmentinRequirementsManagementTools.html
• 14th IEEE International Requirements Engineering Conference(RE’06 will be held September 11-15, 2006 in Minneapolis/St. Paul)http://www.re06.org/
Twin Cities Business Analyst Community
25
QUESTIONS?
For TCBAC information or feedback please contact [email protected]
Future TCBAC Meetings:(same time and location, look for an evite)
Thursday June 22nd
Thursday October 5th
Twin Cities Business Analyst Community