Managing Requirements As An Asset


Published on

Investing in the future means defining a requirements management process and having a tool framework that will allow the investment in requirements definition to be managed as an asset.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Managing Requirements As An Asset

  1. 1. Managing Requirements as an Asset Jolene Eichorn & Joe Patock Presented to the Twin Cities Rational Users Group
  2. 2. Typical Situation  Rational tool set, including RequisitePro, acquired  Little training provided  No standard usage model  Anyone asking has administrator privileges  New repositories created for each funded project  Project teams decide if/when they will use automation tools
  3. 3. The Problem  Potential for large number of repositories  Inconsistent usage creates ramp-up for Business Analysts on each new funded project  Different requirement types and attributes  Different tracing strategy, if any  Different requirements management processes  Requirements for a system became stale and/ or lost  Funded projects have a beginning and end, but applications live beyond the project
  4. 4. Solution Options 1. Single Project in single Repository 2. Multiple projects in a single repository or multiple repositories
  5. 5. Single Project/Repository Advantages  Easier to access requirements and archive/baseline project  Database maintenance is easier with all projects in one schema/database  Use one project per schema  Avoid cross project traceability  Security access is simplified
  6. 6. Single Project/Repository Disadvantages  Everyone has access to everything – Security issue  Scalability - performance can be an issue once the project reaches 40,000 requirements  Backup/Restore cannot be performed at single funded project level  Traceability from external tools could be a problem – E.g: traceability from the Test tool is at the requirement type level and cannot be filtered by attribute  Requires all users to follow a disciplined, standard approach
  7. 7. Solution Goals  The goal of the Tools Repository Strategy is to  Leverage existing investments to provide a collaborative software delivery environment that will empower the project teams to simplify, automate, and govern software delivery  Improve reporting that will reduce administrative overhead and provide more accurate information required to effectively govern software projects.  Reduce rework, improve communication, and facilitate global development  Benefits include:  Consolidation of repositories at the highest level possible (Promote reuse and integration)  Standardized queries and reports (Better information)  More complete status reporting (Facilitate communication)
  8. 8. RequisitePro Repository Architecture Goals  Support Requirements pattern reuse  Provide standards that support consistency and flexibility to accommodate project specific needs  Simplify cross-project traceability for those requirements that cross business areas  Simplify security access requests and accessibility  Support CMMi best practices  Support business rule reuse, consistency and elimination of conflicting rules  Support gathering of business requirements during the early phases of a project before specific applications are identified
  9. 9. Repository Architecture Strategy  Move from project based repository structure to a business area based structure  Consolidate repositories by business area  Centralized repository for application visions  Centralized repository for business rules  Centralized repository for terms (Glossary)  Organize package structure by application  Provide security access per business area  Standardize package naming approach
  10. 10. Package Structure  Repositories hold reusable assets  Artifacts are organized by application and specifically designed for reuse  Specification status and other attributes settings are available and reported using BIRT
  11. 11. Report Generation By standardizing on requirement types, attributes and traceability, reports can be generated across both funded projects and applications.
  12. 12. Considerations Enterprise Requirements Librarian Role Management Plan  Allows standardized approach to  Responsible for contents, requirements management monitoring and consistency of  Defines base set of document repositories types, requirement types and  Works with requirements team to: attributes  Properly identify requirements  Explains traceability patterns crossing two or more projects  Provides direction for managing  Update requirements at changing requirements implementation to reflect the throughout the lifecycle current production state  Manage changing requirements throughout the application lifecycle
  13. 13. Additional Notes  Skilled resources need to be available to train and mentor, not just the Analysts, but also the Enterprise Architects, Testers, Developers.  Have executive buy-in to the plan  Be prepared for expectations to go from “zero to 60” very quickly  Managing ‘Requirements as an Asset’ requires a long-term way of thinking  Customizing attributes is limited since they are applied across the enterprise
  14. 14. Additional Notes  Successful strategic companies invest in the future and that means a process and a tool framework that will grow with the organization as it matures over time