Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  CBAP - Certifie...  Have you wondered (about the BABOK 2.0) ...
Previous Previous
 
Next Next
New Post 8/16/2012 11:44 PM
User is offline Chris Lewis
5 posts
10th Level Poster


Re: Have you wondered (about the BABOK 2.0) ...  

Hi ibtisam,

Don't Panic.

There are reasonable answers to these (understandable) misunderstandings.

 ibtisam.jawad wrote
 

Section 2.5.4.3

1.  Definitions of "Author of requirement" and "Source of the requirement" have overlapping and ambiguous definitions. Text of BABOK 2.0 does not suggest a clear difference between source and author. No proper definition of author is provided. Instead, the BABOK states a function of the author. Perhaps the writers of BABOK  meant "Writer/Documenter" instead of "Author". Now imagine a question that asks "Who should be consulted if a requirement needs clarification? A) Author, B) Source, C) Business Analyst, D) Project Sponsor, E) Project Manager". What would you pick as the answer based on your knowledge of the BABOK 2.0?

Those sentences are not definitions. Yes, they could have been clearer. Yes, they did mean "Writer/Documenter". Yes, someone could ask a silly question like that, but then it would show they are silly. Don't waste your time with practice questions written like that.

Section 2.5.4.2

What is meant by "... the number of views of requirements that will be produced..."? What is the importance of "number of views" of requirements anyways? How would you arrive at that number when Plan[ning] Requirements Management Process? "Number of views" just seems extraneous as it serves no real function in determining what is required and how it will be documented. I would argue that a requirement should have only one view that evolves over time, if "view" means "snapshot" in the text. That single view would continue to show different informtion about the requirement as the requirement evolves over time.

"Views" of requirements are ways of representing them, for example, natural language, or diagrams. That is: (Section 6.2) "The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives." It might be sufficient to write paragraphs, or use E-R diagrams, data flow diagrams, use cases, etc.

Karl Wiegers is doing a series of articles on Requirements Views right now on Modern Analyst.

Section 2.2.5.1

(9.1) The stated definition does not make sense. Acceptance and evaluation criteria for a requirement should not be limited to identifying who can accept of reject a solution. It should instead identify attributes that the solution to a particular problem or requirement must have in order for it to be considered completed e.g. software must add ten 5-digit numbers in 5 seconds or less. It may additionally identify that John Smith must sign off on this but that cannot be the only evaluation and acceptance criteria.

The words in the Techniques sections (like 2.2.5) are not definitions; they are explanations of how the technique is applicable to this Task.

9.19 and 9.21 - I understand that 9.19 is relevant to Conduct[ing] Stakeholder Analysis but I do not see why 9.21 is listed as an acceptable technique. Yes, additional stakeholders can be identified based on process models but if you are conducting stakeholder analysis before understanding the actual processes in place (since it is mentioned under Business Analysis Planning and Monitoring), process modeling has no relevance. If you do not clearly understand the process, you may come up with an incorrect model and therefore, may identify wrong stakeholders or fail to identify any altogether.

Following on from the last point: to Conduct Stakeholder Analysis, consult any existing Process Models (9.21).

Why are 9.26 and 9.33 listed as techniques for 2.2? These do not help to identify the stakeholders but actually use the stakeholders as source of information.

Same again.

Section 2.2.4.3

Please explain what you mean by "Influence needed for the good of the project"? When you state "how much influence", are you asking the business analyst to quantify influence? 

In a word, yes. If you are working on a large, complex project, you will have more chance of success if you have an influential project sponsor, project manager, CIO, etc. If they have the influence level of (say) the work experience kid, you are doomed ;-)

Section 2.2.5

9.27 cannot really take place unless you've identified some requirements. Even if I were to use 9.27 for its stated purpose, what do you propose should be done with the knolwedge that some stakeholders indeed fall outside the scope of the solution but still interact with it in some way? 

Please take this the right way... take a deep breath... calm down... slow down ;-)

The BABOK has flaws, but it's pretty good, considering the profession has been condensed to 264 pages.

In fact, the misunderstandings you have highlighted here (eg what is a requirements view) are a good explanation of why the BABOK is needed.

I hope this helps.

Cheers

Chris

 
New Post 8/17/2012 12:46 AM
User is offline Chris Lewis
5 posts
10th Level Poster


Re: Have you wondered (about the BABOK 2.0) ...  

@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

 
New Post 8/17/2012 1:01 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Have you wondered (about the BABOK 2.0) ...  

Chris:

Glad to here you had better luck at integrating the BABOK than me.  I think you should approach the authors and tell them of the need to integrate and about your success.   The BABOK really needs to flow better.

You say an Input/Process Diagram is different than a Input/Process/Output Diagram.    Question:  Inputs have to input to somewhere and outputs output from somewhere.  What is the case with Input/Output Diagram?

Tony Markatos

 
New Post 8/17/2012 4:44 PM
User is offline ibtisam.jawad
15 posts
9th Level Poster


Re: Have you wondered (about the BABOK 2.0) ...  
Modified By ibtisam.jawad  on 8/17/2012 5:47:45 PM)

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.

 

 
New Post 8/20/2012 12:36 AM
User is offline Chris Lewis
5 posts
10th Level Poster


Re: Have you wondered (about the BABOK 2.0) ...  

@Tony,

Perhaps I should pass this on to the authors... good suggestion.

Your statement: "the BABOK really needs to flow better"... well, yes and no. A novel that flows well is easy to read, but to understand the relationship between the characters, you need to read the whole novel (more than once, usually). The BABOK is more like a map (as mentioned earlier)... you don't need to study the whole map to navigate somewhere, just understand the legend, and the area in question, and you can start using it. Perhaps the BABOK needs a companion guide: How to Read the BABOK. No doubt, companies will offer a training couse for this ;-)

Regarding your question:

The Input/Output diagrams in the BABOK show inputs and outputs from Tasks. 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".

For example, as a BA on a new initiative: you might spend some time defining the business case. You might then elicit some information from your manager, who knows more about the problem. You might document what he tells you. You might then plan how you are going to do more BA work. You might then identify stakeholders, prepare to elicit some information from them. This preparation might help you understand the problem, so you go back to defining the business case. Then your manager tells you something else that he forgot, so you document that too. This affects what you just wrote on the business case, so you update it again.

So, what you've done:

  • Define Business Need (Task 5.1)
  • Conduct Elicitation Activity (3.2)
  • Document Elicitation Results (3.3)
  • Plan BA Activities (2.3)
  • Conduct Stakeholder Analysis (2.2)
  • Define Business Need (5.1)
  • Conduct Elicitation Activity (3.2)
  • Document Elicitation Results (3.3)
  • Define Business Need (5.1)

This jumping from Task to Task is not possible with processes. In general, a process needs to be completed before you move onto the next process.

Does this help?

Cheers

Chris

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  CBAP - Certifie...  Have you wondered (about the BABOK 2.0) ...

Community Blog - Latest Posts

Context:  Intro Change Request Definition Reasons for CRs Adaptive, predictive and mixed projects Flow of processing change requests Change Management Workflow Tools and Techniques 1. Intro  The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An or...
For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pur...
There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.  T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace.  I’ve recently...

 






 

Copyright 2006-2023 by Modern Analyst Media LLC