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:
Sometimes, requirements create misunderstanding, To avoid this, Business Analysts must write requirements so that the stakeholder understands and agrees with these requirements. The written requirements helps the team members to ensure that the right product is built.

Reusing Requirements:
Before implementing the new requirements on a project, you should check reusable material or specification requirements of the previous project. Non-Functional requirements are fairly standard, So, use can reuse the requirements within your organization for different projects. Once your project is successful, you don't need to rediscovered the requirement, you can reuse it.

Reviewing the Requirements:
You should review the requirements once your specified requirements for a project is completed. In this method, you should check all requirements are completed and consistent with each other. This process confirms that the needed or specified requirements for a project is confirmed and now you can move on to the next step.


Comments

  1. Kerone Barnett26 March 2020 at 18:20

    “At times, project managers seem to forget that many of the conventional forms, charts, and tables that they must fill out are intended to serve as aids, not punishments.”
    Taken from Mantel, Meredith, Shafer, and Sutton, Project Management in Practice, 2005

    Chapter 2 makes reference to Appendix A – Volere Requirements Specification Template, which provides a comprehensive outline for documenting the requirements process. This template was prepared to support the process of documenting business requirements and is, with reference to the above-mentioned quote, an aid in the process. This template is a step by step and detailed description of the requirements process, giving summaries and examples that serve to guide both inexperienced and seasoned project management professionals. The template outlines the project drivers, constraints, functional and non-functional requirements, project issues, the scope of work, facts and assumptions, risks, costs, user documentation and training and concludes with possible project ideas/ solutions that will become the business benefit/ improvement. Use of this template will appropriately guide the Business Analyst or Project Manager towards capturing and documenting as much information as required to execute and complete the Business Requirements Process.

    Source:
    https://blog.learningtree.com/ca/susans-favorite-project-and-requirements-quotes/

    ReplyDelete
  2. Karandeep singh2 April 2020 at 12:27

    Project Blastoff - The key purpose of the project blastoff is to build the foundation for the
    requirements discovery that is to follow, and to ensure that all the needed
    components for a successful project are in place. The principal stakeholders—
    the sponsor, the key users, the lead requirements analyst, technical and
    business experts, and other people who are crucial to the success of the project—
    gather together to arrive at a consensus on the crucial project issues.

    ReplyDelete
  3. Sukhpreet Singh2 April 2020 at 20:14

    Scenarios: - Scenarios are the important part of the project which make the project run smoother. To make all the business processes accessible to all stakeholders, the processes are broken into small organized steps. These all small steps of the scenario are taken by stakeholders as their part of the project. After the scenarios is prepared and all the stakeholders agree upon it then it becomes the foundation of the project.

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 7 – Business Requirements Gathering

Chapter 7 –  Understanding the Real Problem This chapter focuses on the Business Analyst “thinking above the line” and focusing on the true essence of the business. This requires reviewing the Brown Cow Model – that is looking at the area above the line – the “ What Now ”. This section examines the undiluted and core reason for the business’ existence. The next step would be to look at the future of the business, called the “Future What”. Examining these two areas helps the Business Analyst get to the heart of the business problem, rather than focus on possible solutions. With the right focus the Business Analyst is not distracted by what others may think the solution could be, but the BA delves and trawls through as much information as possible to accurately understand the business and how it functions, minus technology or automation. This determination to channel all efforts towards the core purpose of the business allows the BA to be more open to all possible solutions...
Read more

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...
Read more

Chapter 4 - BUSINESS USE CASES

Business use cases  -Business events are useful to partition the work, but it is the work’s response to the  event that now captures the interest of the requirements analyst. For every business event, there is a preplanned response to it, known as a business use case (BUC). Rabbit Projects - it is important to have a rock-solid grasp of the business problem to be solved. Rabbits make use of business use cases to explore their problem domain before starting to formulate a solution. This approach does not add to the documentation load, and it lessens the time spent delivering inappropriate solutions. Horse Projects - Horse projects are more strategic than rabbits. they need more time to complete. There is also the possibility of using Business use case scenarios as the documentation to pass along to the developers. Elephant Projects - elephant projects have a large number of stakeholders, clear communication is both important and difficult. Business ...
Read more