Chapter 2 – The Requirements Process - Posted by Liliane Castano Marino
According to chapter 2 of the Mastering the requirements process book, the first step of the Volere requirements process is the Project Blastoff. It might last a
few hours or several days it all depends on the size of the project and the
amount of uncertainty.
Key Purpose – The key purpose of the project blastoff
is to build the foundation for the requirements discovery and ensure that all
the needed components for a successful project are in place. It identifies the purpose of the result the
project is trying to achieve and the stakeholders.
Main deliverables:
1)
Purpose of the project
The blastoff group confirms the goals of the project. In order to determine
where to start the requirements gathering, the BA must understand what the
project is trying to achieve.
2)
Project Scope
The scope must be set and understood by the project team. Identifies
boundaries on what part of the business to study and who to interview for the
requirements. The meeting participants
draw a context diagram on a whiteboard to show which functionality is included
in the work, and by extension, which elements they consider to be outside the
scope.
3)
Stakeholders
The stakeholders are those people who have an interest in the product or
has requirements for it. In order to develop requirements, the BA must
understand who the stakeholders are.
4)
Constraints
Includes items such as schedule, budget variance, and priorities. Small
budgets and impossible deadlines can cripple projects.
5)
Names Conventions
Each project uses different product and naming. All stakeholders and clients must understand
and agree on the terminology to be used in each project.
6)
Facts and assumptions
All the BAs need to know the facts and assumptions to ensure an
appropriate outcome.
7)
Estimated costs
Project work may be expensive, and teams need to know if this is
acceptable to the business. So, it is a good practice at this stage to produce
a preliminary estimate of the costs involved for the requirements part of the
project.
8)
Risks
High level risks must be identified up front, so they are visible to stakeholders.
9)
Go/no go
This is the decision whether to proceed with the next phase of the
project or not. The blastoff group
members arrive at a consensus on whether the project is worthwhile and viable –
that is, they make the “go /no go” decision.
The group considers whether the product is viable, and whether its
benefits outweigh its costs and risks.
Thanks to provide useful information about project Blastoff. In addition, we can say that Blastoff defines the scope of problem and helps to discuss about functionality that will include in requirements discovery by setting a Blastoff meeting with stakeholder, analyst to reach at aggrement on business area that can be improved. After agreement, they will be able to define scope more clearly with stakeholder and initialise the project. It means Blastoff set a clear and confirm goal for project.
ReplyDeleteThe 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.
ReplyDeleteWhether you are building complex custom systems, using commercial software developed by third parties, or making simple changes to an existing system, you will still need to work with project stakeholders to understand, often discover, and communicate requirements. As small as they are, they will always be there and are the first challenge that can make your project a success or a complete failure.
ReplyDeleteRequirements discovery should be seen as a necessary precursor to any activity. Still, it should also be viewed as something that can be conducted quickly, sometimes informally, sometimes overlapping with subsequent design and construction activities, but never ignored.
Upon completion of the blastoff, business analysts begin to scour work to learn and understand its functionality and partition the work context diagram into business use cases. Each business use case is the amount of functionality required by the job to give the correct response to a business event.
Before reading i had assumed that a project blastoff was like a before project party involving the project manager and any participants of the project but i see i was wrong. After i reading i can now see that the project blastoff is more of a project overview planning than a party. The project blastoff meetings can seem to last anywhere from a few hours to even days depending on how big the project size is and how long the group can focus and stay on task. the final step of the blastoff is interesting to me because i would assume the project manager just decides to move forward with the project but instead the team must come to a census on a go or no go vote to carry on or not.
ReplyDelete