Requirements Management the Key to
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Requirements Management the Key to

on

  • 1,125 views

 

Statistics

Views

Total Views
1,125
Views on SlideShare
1,124
Embed Views
1

Actions

Likes
0
Downloads
56
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • The Business Analyst is a key facilitator within an organization, acting as a bridge between the client, stakeholders, and the solution team. [IIBA BOK, R1.4, p. 15] We base much of our content in this course and the balance of the curriculum on the International Institute of Business Analysis (IIBA) Body of Knowledge (BOK). The IIBA BOK was current with Release 1.6 (R1.6) as of August, 2006. Per the IIBA BOK, “ A Business Analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies, and information systems. The Business Analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.” [IIBA BOK, R1.6, p. 9]
  • Go to: http://www.jiludwig.com/Requirements_Management_Tools.html

Requirements Management the Key to Presentation Transcript

  • 1. Requirements Management the Key to Keeping Scope In Check
  • 2. Tonight’s Presentation
    • Business Analysis - The Process
    • The Business Analyst - The Role
    • Traceability - a Necessity
    • Controlling Scope through Requirements Management – Change Requests
    • Tools
  • 3. The Business Analyst Process
  • 4. Definition of a Requirement
      • “A condition or capability needed by a stakeholder to solve a problem or achieve an objective.”
      • “A condition or capability that must be met or possessed by a system or system component (a product) to satisfy a contract, standard, specification, or other formally imposed document.
      • A documented representation of a condition or capability as in 1 or 2 above”
    Source: The IIBA BOK v1.6
  • 5. The Life of a Requirement Concept Phase Business Requirements Need, Problem or Opportunity Justification Project Charter Funding: Business Requirements Solution Requirements Describes the characteristics that meet the business and stakeholder requirements: - Functional - Non-Functional - Implementation Stakeholder Requirements: Needs of a stakeholder and their interaction with the system How WHAT WHY Requirements Phase
  • 6. Business Analysts Act to Bridge “States” IIBA BOK, R1.6, p. 9 Problem Solution
    • Business Analysts:
      • Elicit
      • Analyze
      • Communicate
      • Validate
    “ current state” “ desired state” IIBA BOK provides the materials needed to build and maintain the bridge.
  • 7. The BA Manages Client Expectations
    • Through traceability and requirements change management the BA manages the client expectation of the resulting solution
    Backward Forward Requirements Business Idea Need Design/Code Test Cases
  • 8. Is Traceability Necessary?
    • Question: Would you feel more confident about the quality of your food if it could traced from retail to the source?
    US food producers have traceability systems to trace food from retail to key points in production process, and some are robust enough to trace food to the exact field where the food was grown. In Canada there was a listeriosis outbreak that eventually killed over 20 people. The source of the contamination was traced to two slicing machines. Source: http://www.ers.usda.gov/Publications/AER830 /
  • 9. Traceability Matrix Example
    • A traceability matrix is a two-way mapping of requirements numbers against design, code (configuration items), release, and test reference
    • Helps to ensure requirements aren’t missed, removed or added without approval
    • Helps to trace issues to source
  • 10. Traceability and SDLC Documents
    • The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another (draft update to IEEE-STD-729, November 30, 1989)
  • 11. Who Should Manage Traceability?
    • According to the business analysis professional association, in version 2 of the BABOK®, the business analyst should trace requirements and work with the project team to trace them to other project work products.
    Business Process Business Rule Test Case
  • 12. The Benefits of Traceability
    • Links downstream work products to the purpose for which they were created
    • Provides a process to confirm that the requirements gathering process is complete
    • Ensures that project work is not authorized for items that are outside of project scope
    • Increases quality on all projects sizes and types
    • Provide valuable metrics for the project
    • Enables stakeholder notification during the change management process
    Source: IIBA, The Business Analyst Body of Knowledge, Rel 1.4, 2005, p163
  • 13. Requirements Change Management
    • “ To improve is to change, to be perfect is to change often.” Winston Churchill (1874-1965) British politician
    RQM Business Understanding of need and solution Change requests as Business Knowledge increases Project Timeline
  • 14. The Business Analyst’s Role in Change Management
    • Impact analysis to the requirements and the solution
    • Identify and communicate the change impacts to all stakeholders, business, organizational, solution transition impacts
    • Use traceability matrix to assist in analysis
    • Modify requirements document to reflect solution and new version
    • Assess solution scope against the request
  • 15. The Manage Part of Change Management
    • “ I get up every morning determined to both change the world and have one hell of a good time. Sometimes this makes planning my day difficult? ” E. B. White (1895 – 1985)
    • Business Analysts use some techniques to manage changes:
    • Requirements Prioritization
    • Benefit, Risk, Cost
    • Impact Analysis
  • 16. Requirements Prioritization
    • Ensures the functionality with the most value is implemented when timelines become short
    • Helps to manage competing demands
    • Helps PM to manage time, cost and resources and move lower-priority requirements to later phases, releases
    TIP: “Avoid ‘decibel prioritization’, in which the loudest voice heard get top priority, and ‘threat prioritization’, in which stakeholders holding the most political power always get what they demand.” Karl Wiegers, Software Requirements 2 nd . Edition Microsoft Press
  • 17. Approaches to Prioritization
    • Ask questions:
      • Is there some other way to satisfy the need that this requirement addresses?
      • What would happen if this requirement isn’t implemented right away?
      • How would the deferral of the requirement affect the user community?
    • Use Priority Scales
      • High – Must be in the first release
      • Medium – The business needs the functionality however can wait if necessary – can be implemented in the next release
      • Low – The user can live without the functionality and it can be implemented in later releases
  • 18. Prioritization – Value, Cost, Risk
    • You can use a prioritization matrix.
    Source: http://www.processimpact.com/goodies.shtml 2.104 100.0 7 100.0 135 100.0 19 5 14 Totals 0.661 14.3 1 41.5 56 36.8 7 1 6   0.780 28.6 2 5.2 7 26.3 5 1 4 rows as needed; the formulas will adjust automatically.> 0.356 42.9 3 16.3 22 21.1 4 1 3 in these cells, one item per cell. Copy and insert additional 0.308 14.3 1 37.0 50 15.8 3 2 1 <List each feature, requirement, or use case to be prioritized Priority Risk % Relative Risk Cost % Relative Cost Value % Total Value Relative Penalty Relative Benefit Feature or Function (don't mix them use either feature or function or use case)                         1   1     1 1 Relative Weights:
  • 19. Prioritization on Basis of Value
    • Have the business estimate the benefits that each requirement provides them (e.g. rate 1-9)
    • Working with the business and I.T. estimate the penalty if the requirement isn’t included. Assess based on quality issues, legal, compliance, function loss that would affect productivity, harder to add capability later, other issues such as marketing, corporate communications
    • Ask the business/I.T. to weight the requirements
    • Ask, is the cost a factor?
    • Calculate using spreadsheet
    Priority = Value% (cost% * cost weight) + (risk % * risk weight)
  • 20. Or You Could Use …
  • 21. Managing Requirements Scope Creep
    • Once the requirements are baselined then a change request process should be activated
    • Change process manages scope creep
    • According to Capers Jones (1996) requirements for information management can grow at an average rate of 1% per month – after requirements baseline
    • Say NO
    • Freezing requirements doesn’t work (K. Wiegers)
  • 22. Change Control Process Business Analyst PM & Project Team Approver (Change Control)
  • 23. Change Control Process
    • Determine a Change Control policy
    • List the roles and responsibilities – it is suggested that the BA be the first line in the request process
    • Change statuses
    • Entry / Exit Criteria
    • Determine change request items
    • Reporting and metrics regarding changes
  • 24. Change Request
    • What needs to change: Interface Data Documentation Other CHANGE TYPE: New Requirement Requirement Change Design Change Other: REASON:
    • Legal: Market: Performance: Customer Request: Defect: Other:
    • Details: (include as much information as possible
    • include examples)
  • 25. Impact Analysis by the Business Analyst
    • Review for the following:
    • Implications of the Proposed Change
    • System Elements Affected by the Proposed Change
    • Requirement conflicts
    • Impacts to organization, users, processes, business rules, data
    • Then estimate effort
    • Estimate affects regarding benefits, penalty, and solution risk
  • 26. Assessment by Project Team
    • PM should assess for impact to project
    • Resources needed, cost, and time
    • Complete assessment and make a recommendation to approver
    • BA should be a liaison with requestor
    • Approver evaluates determines Y or N or later
    • If yes all documents are updated and affected parties advised.
    • No matter what the disposition the requestor is advised
  • 27. After Disposition of Request
    • Manage the change activities
    • Gather metrics about:
      • Number of change requests received
      • Number of requests from sources
      • Type of requests
      • Reason for requests
      • Disposition of requests
      • When requests received
  • 28. Tools to Manage Requirements
    • Checklists
    • Spreadsheets (excel)
    • Automated Tools
      • Compuware Optimal Trace
      • Borland – Caliber
      • IBM/Telelogics – Doors
      • Other Free tools
        • Lighthouse
        • Top Team Analyst
        • Tracer
  • 29. Thank You
  • 30. Contact Information
    • Web: www.iil.com
    • E-mail: [email_address]
    • Phone: 1-416-889-0496
    Version 1.0 IIL
  • 31. Resources
    • Tools:
    • http://www.softreq.com/tracer
    • http://www.jiludwig.com/Requirements_Management_bTools.html
    • Prioritization Matrix: http:// www.processimpact.com/goodies.shtml
    • Checklists and documents
    • www.iil.com (available with this presentation as a download)