Posts

Showing posts from October, 2019

Chapter 01 - Some Fundamental Truths

This post will summarize the 11 fundamental truths described in the book "Mastering the Requirements Process - Getting Requirements Right" , which are considered the essential contribution of requirements. Truth 1: Requirements are not about requirements The requirements activity is not mainly about writing a requirements document. It’s about focusing on understanding a business problem and providing a solution for it. Truth 2: If we must build software, then it must be optimally valuable for its owner. The owner is the person or organization that pays for the software or hardware. He/she will not pay unless the product provides a benefit. The software/hardware must be optimally valuable, that being that it provides a benefit that is in proportion to the cost of the product. It’s part of the business analyst’s, or other “requirements discoverer” job to understand what that value is. Truth 3: If your software does not have to satisfy a need, then you ca...

Chapter 2 - The Requirement Process (Business Requirements Gathering)

Image
          Chapter 2 tells us about the The Requirement Process in which how we present this processes for the discovering requirements and how you might use it in a process. The book Business Requirement Gathering also describes this as, "we describe a requirements process that we have derived from our years of working in the requirements arena, working with clever people who do clever things, and working on projects in wonderfully diverse domains."           The Volere Requirement Process was also developed from the different activities and deliverables that had been proven to be the most effective in project and consulting  assignment with clients. The results of this can be the discovering of requirements and processes which are specific principles can be applied. This is an example diagram of the Volere Requirements Process which details the different activities and deliverables. It also used a stylized data flow n...

Chapter-6 Strategy Analysis

Where do the strategy analysis focus? Strategy analysis focuses on defining the future and transition states needed to address the business need, and the work required is defined both by that need and the scope of the solution space. Area of Knowledge: The Strategy Analysis knowledge area includes the following tasks: Analyze Current State:    It understands the business need and  the way it function today. It also sets a baseline and context for change. Define Future State:    To define goals and objectives that will tell the business needs which has been satisfied and defined that what parts  need to change in order to meet the goals and objectives.   Assess Risks:     Focuses on  uncertainties around the change, considers the effect those uncertainties may have on the ability to deliver value through a change, and recommends actions to address risks where needed.   Define Change Strategy:    It is make a ...

Chapter 5 - Requirement Life Cycle Management

Image
The Requirements Life Cycle Management Area is defined as the tasks that a business analysts do to maintain order to manage requirements and design information from the start up to its conclusion. And its purpose according to BABOK is, to ensure that business, stakeholder, and solution requirements and designs are aligned to one another and that solution implements them. It will involve control over the desired requirements and how this requirement will be implemented to the solution on how it would be constructed and delivered. Here are some steps of the requirements life cycle: begins with the representation of a business to determine its needs as a requirement; continues through the development of a solution, and ends when a solution and the requirements that represent it are retired. The Requirement Life Cycle Management knowledge area as defined by the table above includes this tasks according to BABOK Guide: Trace Requirements: analyzes and maintains the re...