Posts

Showing posts from March, 2020

Chapter 3 - Business Requirements Gathering

Chapter 3 - Scoping the Business Problem This chapter focuses on Project Blastoff Deliverables such as Project Purpose, Scope of work, Stakeholders, Constraints, Names, Estimated Cost and Risks. The chapter refers to Scope, Stakeholders and Purpose as the Trinity confirming that these are core elements of any successful project blastoff. ·          For Project Scope, we must understand the extent of the work to be done and how this task (business improvement) will impact the current operational environment and its existing products and services. We must ensure that we accurately document the depth and breadth of the project. ·          For Project Purpose, we must accurately capture the quantifiable/ measurable business benefit to be gained from the completion of the project. ·          For Stakeholders, we must document all possible persons with a vest...

Chapter 2; The Requirements Process

CHAPTER - 2 THE REQUIREMENTS PROCESS This chapter describes the process for finding the requirements and the ways of using these requirements. To built a right product, you have to discover the right requirements for that product. Project Blastoff: Project Blastoff means project initiation and it defines the scope of the business problem as well as the goals of the project. The main purpose of the project blastoff is to build the foundation for the discovered requirements that needs to follow and all the needed resources are available for the success of the project. Trawling for Requirements: Trawling means discovering the requirements.When the project blastoff is finished, then the business analysts start trawling the work to understand the functionality of the work in which they learn in what ways this process is going. Business Analysts use apprenticing, scenarios, case workshops like trawling techniques to understand the nature of the work. Writing the Requirements:...

Chapter 1 - Business Requirements Gathering

There are some fundamental truths: Truth 1 Requirements are not really bout requirements. Requirements of any product, software, or any action which is to be performed. One cannot develop the requirements because they are generated themselves according to the task which is to be performed. For the completion of the activity some actions are to be performed which are known as requirements for that activity. T ruth 2 If we must build software, then it must be optimally valuable for its owner. The product which is developed by someone must be valuable for its developer. The developed product will only benefit the owner when it will provide benefit to the organization in terms of changing the usual or daily activities in the positive way like increasing the pace of the work. Truth 3 If your software does not have to satisfy a need, then you can build anything. However, if it is meant to satisfy a need, then you have to build what that need is to build the right software. W...