@Tony,

Me too... I tried to convert the BABOK Input/Output diagrams into Data Flow Diagrams, and it was impossible.

I soon realised my mistake: the Tasks are not processes... you can do the Tasks in any order, for any amount of time, to any depth... you don't have to complete a Task before moving on to something else.

An Input/Output diagram is subtly different to an Input/Process/Output diagram (aka a Data Flow Diagram). (Funnily enough, the BABOK doesn't list Input/Output diagrams as a Technique in Section 9, even though they are used throughout the BABOK! ;-)

What I did instead was to I convert the task-level Input/Output diagrams to Knowledge-Area-level Input/Output diagrams, and showed the Task number that produced each Input, and showed the Task numbers that used each Output, where off-page links were needed.

That helped me a lot.

There is no "flow of behaviour" in the BABOK... it is not a methodology. It is merely a standard, a definition. Choose your methodology (or methodologies) based on the standard.

That's my understanding...

I hope this helps.

Cheers

Chris

Hi Chris,

Thank you for clarifying this for me. I appreciate your and everyone else's feedback.

My point is that if the BABOK 2.0 is to be used as the text for an examination, it should be unambiguous and logically correct. It should also be edited to prune irrelevant and extraneous material.

From the examples above:

2.5.4.3 - I understand that a definition is not listed for "author of the requirement". However the section provides definitions for all requirements attributes except for "Author ..." It seems that whoever wrote this section could not come up with "who" or "what" the author is - as s/he did for every other attribute that is listed - and instead explained one function that may be performed by an author. Perhaps the explanation provided for all attributes should've been more consistent. All I'm saying is that we should help to edit this information and define/state it better. If Author means "writer/documenter" then requirements clarification is not the most important function of that role. Requirement should always ultimately be clarified with the source. In most cases, business anlayst will be the one documenting the requirement or in some cases the source may do that as well.

2.5.4.2 is labeled Traceability.Thank you for clarifying what was meant by views here. However, the number of views of requirements has very little to do with traceability or even requirements. The number itself is meaningless. There may be 10, 20, 37, or 499 views that may be produced. It is more important to identify the types of views that may need to be produced, as you stated natural language, sequence diagrams, state diagrams etc. Me stating that "5 views of each requirement will be produced" in the business analysis plan will have very little meaning for anyone. This number will be even less useful for traceabiliy. Some requirements may be explained with a diagram, some with natural language only, some may require state machine diagrams, sequence diagrams or elaborte use cases to really capture what's required. Not all views that I identify will apply to all requirements. Therefore, the number of views of requirements holds no value to me or anyone else on the project team. It is probably more useful to state the types of views that may be produced for requirements and traced back to the original requirement statement. Perpahs the text intended to state "the views of requirements that will be produced" as opposed to "the number of views ..." I know I am being pedantic here but I am taking BABOK 2.0 for what it states it is: sum of knowledge for our profession, and judging it to that high of a standard.

2.2.5.1 "Acceptance and Evaluation Criteria Definition (9.1)" Please tell me that the word "Definition" was just left here due to poor editing.

Under 2.2.5 (page 28), 9.27 states "Scope models should show stakeholders that fall outside the scope of the solution but still interact with it in some way". Scope modeling is defined on page 93. I see several problems with the statement on page 28. I would personally consider everyone who interacts with a proposed solution to be within the scope. If something is outside the scope, it does not matter at least for that particular iteration. Perhaps the statement from page 28 should have told me to determine what stakeholders are within the scope so that I can expend my effort in the right place i.e. talk to in-scope stakeholders for requirements elaboration. Can you please provide me with an example of a stakeholder that is outside the scope of a solution but still interacts with it in some way? What should I do with this knowledge and how would it help me with requirements analysis? If Mr. Smith is outside the scope but still interacts with it, should I revel in the knowledge that although this guy is affected by the solution I am not going to listen to his needs?

2.2.4.3 That function falls more within the role of a Project Manager. As a business analyst it is my job to determine what is required to fulfill  a particular need/want. It is not my job to be a project lead or project champion or to determine how much political influence should be exercised within the organization for the project to be successful. What's needed for the success of a project should be identifed in the Project Plan not in the business analysis plan or stakeholder analysis. If lack of influence is indeed a project risk, it should go in the risk register or similar.