Chapter 9 - Strategies for Today’s Business Analyst
Balance
A requirements strategy serves as a guide for determining where to start,
whether you have sufficient detail, which iterative cycles you need, which
form to use when recording your knowledge, when to have reviews, when to
involve which stakeholders, when to build prototypes, and when and how to
do any of the myriad things that will bring your efforts closer to producingthe optimal value for the business. The variations in every project necessitate
differences in the order in which you do things, the level of detail to which
you do them, and the forms in which you communicate.
Three variable characteristics that provide useful input for planning your
requirements strategy are Requirements Knowledge, Activities and People.
Requirements Knowledge is your understanding of the work, and the product
needed to be developed to support that work. It includes the information you
obtain from the artifacts you build during the course of your requirements
activity and, of course,the requirements you write. Activities are the tasks
and checkpoints that your project performs to discover and communicate this
knowledge. The last characteristic is People. Who are the stakeholders—the
people whose knowledge you need? What do they know? Where are they?
What is their availability?
(Mastering Requirements Process, pg. 204)
When you are working in a position like business analyst in a big organization making balance between all of the things including knowledge, activities, people etc. becomes an important part of your job. You have to be certain about the project, your organization is working on, people who will be affected by the end of that project and the solution this project provides.
Sequential Strategy
ReplyDeleteIn this strategy team members focus on completion of each phase after proceeding towards next one. Completion of a phase is usually signaled by the production of a document. technique is regularly utilized by both huge scale ventures and projects portrayed by a hierarchical or statutory requirement for this sort of custom and documentation.
We need to identify the area that will be influenced by the delivery of the item. To do as such, you more likely than not decided the vital objective that drives the venture. You likewise have a support who acknowledges duty regarding the venture, and you probably recognized the key partners. At long last, you ought to have some thought of the plan. Also to find out item is proposed to improve some piece of your customer's work, so you have to invest that work to find the necessities and meet the objective of the venture. To accurately scope the work, you determine the interfaces between the work and different pieces of the association, or between the work and applicable outside frameworks or clients.
To develop a better strategy you need to develop these following goals :
- Stakeholders required by having incessant conveyances of ancient rarities, or working software
●Respond to business changes more quickly
●Make it simpler for partners to give feedback
●Avoid creating expectations that copy existing information, or that give practically zero new information
This comment has been removed by the author.
ReplyDeleteCommon Project requirements profile: -
ReplyDeleteThe requirements strategy is a framework for the activities that we need to carry out to discover the appropriate level of Knowledge and communicate it to the right People given the profile of your project. There are three project requirements profiles that we commonly encounter in our work: External, Iterative, and Sequential.
External: -A project with an External profile is one where, having discovered the requirements, you send them to an external solution provider. The external profile applies when you are buying a ready-made solution from an external vendor, or you have outsourced the development of the solution, or you are sending a request for proposal to several suppliers. It might involve more than one supplier when you are buying and integrating a number of components.
Iterative: -With a project with an Iterative profile, you have the opportunity to iteratively discover the requirements and release partial solutions until the product is complete. The motivation for this profile is wanting to deliver some results to the customer as quickly as possible, and to be responsive to business changes. With this profile you are developing your solution using developers with whom you can work closely; normally (but not always), they are located within your own organization.
Sequential: - Projects fitting the third project profile, known as Sequential projects, have more constraints on the specific activities and deliverables; in the most extreme cases, they have rigid phases and documents that must be produced before progressing to the next phase. The requirements must be completely defined before passing them (usually in a prescribed form) to the designers and developers to work on the solution. With this profile, it is difficult to change anything once it has passed through a phase checkpoint.
Looking for Business Rules
ReplyDeleteBusiness rules are directions set down by the organization to direct operations,
people, and systems as to what they are to do. Such rules can apply
to any aspect of the organization, from top management to the lowest-level
process. They can be as all encompassing as “Employees are directed not to
commit any crime” or as detailed as “The help desk employees will report
to their supervisor any cases that are still unresolved 48 hours after the first
contact.” Business rules can be written down, or they can be understood by
employees and verbally transmitted.
No Longer a Stenographer
Traditionally, the business analyst was seen as someone who wrote requirements.
This task was usually described as “Go and interview the users, and
write down whatever they say.” Thus the business analyst filled a passive
role, responding to whatever was asked for.
Today, the business analyst is no longer a stenographer. We can go so far
as to say that the today’s business analyst is no longer just a requirements
writer.
We know from bitter experience that poor requirements contribute to
more than half of all project and system failures. This high failure rate suggests
very strongly that we must change our approach to discovering requirements.
Instead of thinking almost exclusively about a software solution,
today’s business analyst is much more concerned with the business problem
to be solved. As noted earlier (and repeatedly) in this text, it is the failure to
identify the real problem to be solved that causes projects to deliver up poor
results and poor products.
Today, the business analyst must be much more proactive. Doing so means
interacting more closely with the business stakeholders, and using a variety
of models and techniques to ensure that the business stakeholders give an
accurate portrayal of the business they are responsible for.
The emphasis is, or should be, on understanding the problem and letting
the solution follow along. As part of this approach, the business analyst must
prevent his business stakeholders from becoming fixated on a solution. The
question to ask is not “What do you want?” but “What do you do?”
The business analyst must now study not just the stakeholders’ needs, but
also the people who have those needs. The delivered product must match
those people, in terms of both the way they work and the skills they have.
After all, there is little point delivering a dumbed-down product to a group
of scientists, or a standard interface to a group of teenagers who are accustomed
to exciting and interesting software products.