Recommended
More Related Content
What's hot
What's hot (16)
Similar to Requirements Management
Similar to Requirements Management (20)
More from Shwetha-BA
More from Shwetha-BA (10)
Recently uploaded
Recently uploaded (20)
Requirements Management
- 1. Page 0Classification: Restricted Business Analysis Training Requirement Management
- 2. Page 1Classification: Restricted Agenda •Requirements Management • Requirement Prioritization • MoSCoW Analysis • Time Boxing • Voting Technique • Verifying and Validating Requirements • Verifying Requirements • Validate Requirements • Key Requirements Management Practices • The Requirements Baseline • Requirements Version Management • Requirements Change Control • Impact Analysis of Requirements • Requirements Attributes • Requirements status tracking • Requirements Traceability • Requirements Traceability Matrix
- 3. Page 2Classification: Restricted Components of Requirements Engineering
- 4. Page 3Classification: Restricted Requirement Prioritization • Prioritization plays a key role in our daily lives since we have a number of tasks to be performed in the various roles we play. Likewise as a business analyst we should be able to prioritize the requirements we gather from the client. There are various techniques to do so such as MoSCoW Analysis, Timeboxing or Budgeting, Voting, Decision Analysis and Risk Analysis.
- 5. Page 4Classification: Restricted MoSCoW Analysis The requirements can be categorized into the following: • Must: These are the most crucial requirements Without these the final solution will be incomplete. • Should: These are also crucial requirements but there could be workarounds to satisfy these. • Could: These are desirable or "nice to have" requirements. If time permits these will be included in the final solution. • Would/Won't: These will be included in the next release or will be omitted completely.
- 6. Page 5Classification: Restricted Time Boxing Time boxing which is also known as budgeting. There are three approaches in this. All in: The group assigns a duration of time or cost to implement each requirement. We start with all requirements in the box and remove one-by- one based on the deadlines and budget.
- 7. Page 6Classification: Restricted • All out: The group assigns the duration of time or cost to implement each requirement. All requirements are out of the box and we add these one-by-one until the cost/time limit is reached. • Selective: This is a balanced approach. Here we identify the high priority requirements and then add/remove those one-by-one to meet the scheduled time/budget limits.
- 8. Page 7Classification: Restricted Voting Technique • A set requirements are distributed to a group of stakeholders and each of them gives a vote to prioritize the distributed requirements. • We can conclude by stating that one of the key skills a good business analyst should have is prioritization of tasks as it would help in minimizing overheads and maximizing the resource utilization.
- 9. Page 8Classification: Restricted Verifying and Validating Requirements
- 10. Page 9Classification: Restricted Verifying Requirements The purpose of Verifying Requirements is to ensure that requirements and designs specifications and models meet quality standards and are usable for the purpose they serve.
- 15. Page 14Classification: Restricted The purpose of Validate Requirements is to ensure that all requirements and designs align to the business requirements and support the delivery of needed value.
- 21. Page 20Classification: Restricted Key Requirements Management Practices • Create a requirements baseline. • Manage version of requirements documents. • Adopt and enforce a change control process. • Perform requirements change impact analysis. • Store requirement attributes. • Track the status of each requirement. • Trace requirements into designs, code, and tests. • Store requirements in a requirements management tool.
- 22. Page 21Classification: Restricted The Requirements Baseline
- 23. Page 22Classification: Restricted Requirements Version Management
- 24. Page 23Classification: Restricted Requirements Change Control
- 25. Page 24Classification: Restricted Possible Change Request Statuses
- 26. Page 25Classification: Restricted A Change Control System
- 27. Page 26Classification: Restricted Change Control Board
- 28. Page 27Classification: Restricted Impact Analysis for Requirements Changes-1
- 29. Page 28Classification: Restricted Impact Analysis for Requirements Changes-2
- 30. Page 29Classification: Restricted Impact Analysis for Requirements Changes-3
- 31. Page 30Classification: Restricted Requirements Attributes
- 32. Page 31Classification: Restricted Requirements Status Tracking-1
- 33. Page 32Classification: Restricted Requirements Status Tracking-2
- 34. Page 33Classification: Restricted Requirements Traceability
- 35. Page 34Classification: Restricted • The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested. • The requirements traceability matrix is usually developed in concurrence with the initial list of requirements (functional requirements documents) Requirement Traceability matrix
- 36. Page 35Classification: Restricted RTM Example
- 37. Page 36Classification: Restricted Where Traceability Links Might Come From?
- 38. Page 37Classification: Restricted Requirements Management Best Practices
- 39. Page 38Classification: Restricted Topics to be covered in next session •Quality Assurance/ Software Testing and a Business Analyst’s Role •Software quality testing •Purpose of Quality Testing •Project Life Cycle and Software •Quality testing in different phases of Project Life Cycle Testing •Role of a Software Tester •Types of Software Testing •Various Software Testing Tools •Verification and Validation •Role of a Business Analyst •Purpose of Business Analysis and a Business Analyst Role •Business Analyst effects the change •Business Analyst’s role in different phases of Project life cycle – PLC •Business Analyst’s Role During Build/Test phase In a Project Life Cycle(PLC)