@Ibtisam:

I’m glad to hear that we’re helping ;-)

2.5.4.3: Yes, this section is not entirely consistent. In this case, it is saying why you would record 'Author', rather than defining it. Are we using the same definition? You seem to be storing 'Business Analyst' in the Author field, where I would store the person's name, eg 'Kimbo'. That way, I could contact the person directly... as in, "Hey Kimbo, mate, what did you mean by that?" It would be more likely that the author is also a BA, so I could interrupt them more easily and effectively than the Source, who is busy doing their job and perhaps can't remember or explain it well.

I did not mean the "role". It should be the name of the Business Analyst that's stored there or whoever else actually documented the requirement, as you said e.g. Kimbo. Originator should go in source e.g. Jane smith. That's the person who "created" the requirement.

2.5.4.2 Traceability. Yes, I agree, the wording would have been better with your text. Not only is 'type of views of requirements' more accurate, it prevents the confusion from readers who parse the text as 'number of views' (a web term) instead of 'number of views of requirements'.

Number means just that, something that identifies a count. It can never be construed to mean "type" even from the context of that paragraph. I agree that BABOK should be better written than it is. Perhaps the authors of it are watching this thread.

2.2.5.1: No, they included the word "Definition" because the Techniques sections list the names of the Techniques listed in Chapter 9. They needed to use the full name.

Understood. Readers, especially nitpicking ones like me, would've fared better if the technique was labeled differently.

2.2.5, 9.27: an example of a stakeholder who interacts with a solution, but is not in scope: We recently had a project involving the flow of information from system A to system C. The information flowed via system B, which was a system used by technicians visiting customers' houses. System B was in a lockdown phase, so we were not allowed to make changes to it, but we needed their cooperation for testing.

Interestingly, the eventual solution chosen involved a change to system B, so they came into solution scope.

I still think that anything that's affected directly or indirectly by requirements is within scope for that project/iteration/sprint. From your example, despite system B being in a locked down state, you [probably] had to ensure that System A provided sufficient information in a certain way to System B, so that System B could relay it forward to System C, enabling some job function to be completed. Clearly then the requirements for your project for System A were shaped by expectations/limitations of System B. You had to consider these in scope, and involve some kind of integration testing with System B at the end, to call the new System A a success/failure. All those invesigations/tests into the limitations of System B took someone's time. You had to have considered these activities in scope to budget time and resources to them. Otherwise you were probably faced with scope creep at some point in the project. I'm just speculating based on my understanding of things, and things may actually have been different for you.

As for the statement written in front of 9.27 (under 2.2.5), I would rephrase it to: "Scope models should identify stakeholders that fall inside the scope of the solution, as well as those that fall outside of the scope of the solution." Clearly Stakeholders that are inside the scope are just as important, if not more so, than the ones that are outside.

2.2.4.3: You make a good point: it is the Project Manager's job, or the Change Analyst's job, to deal with the risks relating to low levels of influence.

I looked at the definition of the Task Output: Stakeholder List, Roles and Responsibilities (section 2.2.7). This includes "Description of stakeholder influence and interest". The output is used for Task 2.3 - Plan BA Activities, for which the output is the BA Plan.

Perhaps the BABOK authors decided that the BA will be the one who discovers this risk, rather than the Project Manager. In any case, as a BA, it is valuable information to know, even if it's not formally documented in the BA Plan or the risk register.

I agree that knowing "who calls the shots" can be useful for a business analyst when identifying requirements and working with the team to assign priorities in the real world. It does not however have any direct forbearance on Business Analysis Activities or Business Analysis Plan. How would I use my knowledge of stakeholder influece in my plan? Should I say for example, "John Smith has a lot of influence on the project team. Jane Smith, despite being an important stakeholder to the project, does not command much influence within her team. Now say that Jane created a requirement that clearly would be needed to accomplish a business goal, but John disagrees with it and wants to exclude it from the scope not knowing the impact it may have; since I know who has more influence should I not really bother much because I know that John is actually calling the shots. Neither should anyone else bother on the project team, because John might influence his team to cut the budget." What good does that do?

In summary, your main point is right - the BABOK should be unambiguous and logically correct. It's not 100% at this stage, but it does reward patience and further reading.

Work on BABOK Version 3 has started... I have volunteered to be a reviewer... so we'll see what that brings.

Cheers

Chris