A good overview article about why gathering, documenting, and interpreting software requirements can be a difficult task.
Interpreting Requirements in a He Said/She Said World
by Deb Jacobs , Software Engineering Services.
Jason Barrett
Senior Business Analyst
www.collective-genius.com
Wednesday, November 22, 2006
Recommended BA Books
Real life experience is always best but what books have helped you learn the trade of being a business analyst?
Here are some of mine...
1. Mastering the Requirements Process (2nd Ed) - by Robertson and Robertson
2. Software Project Survival Guide - by Steve C McConnell
3. Use Case Modeling - by Kurt Bittner and Ian Spence
Jason Barrett
Senior Business Analyst
www.collective-genius.com
Here are some of mine...
1. Mastering the Requirements Process (2nd Ed) - by Robertson and Robertson
2. Software Project Survival Guide - by Steve C McConnell
3. Use Case Modeling - by Kurt Bittner and Ian Spence
Jason Barrett
Senior Business Analyst
www.collective-genius.com
Thursday, November 9, 2006
To RUP or not to RUP
Former Post on RUP
Jim said... Jeff Martin of Collective Genius asked this question, and it's a good one. When do you use RUP, and when don't you use RUP?
Jim Furey
Senior Business Analyst
11/09/2006 7:28 AM
Jeff Martin (http://www.collective-genius.com) said... When speaking with business analysts every day I find many of them if not nearly all of the people do not feel comfortable with having RUP on their resume. However when these same people further review RUP they find they have been performing multiple elements of RUP for a very long time.I also find it interesting that almost every BA role is asking for BAs with RUP experience. These are also the same opportunities where the RUP methodology will not be applied to the extent implied.
What the RUP?
Jeff Martin
Founder
www.collective-genius.com
11/10/2006 1:10 PM
Jim said... I know I do this because I'm probably a perfectionist with a methodology. I think a good comparison would be if I've done all of the parts of a programming language. For instance...I may have experience with VB, but I've never coded VB.net. Many clients want VB.net experience. I have all of the coding, logic, and problem solving tools that I've used for years, but I don't have the one key element.I guess if I were having heart surgery, and my doctor said he or she had experience with surgery and could do all of the aspects of your basic surgery. I'd decline to have that doctor work on me, if they hadn't done heart surgery before. In fact, I'd want to know I wasn't one of the first patients as well.I don't think RUP is heart surgery, but I think BA's want to KNOW the methodology and experience it before being a point person for a business.
Jim Furey
Senior Business Analyst
11/11/2006 9:39 AM
Jason Barrett said... I think a lot of business analysts see RUP as something as difficult as heart surgery, but I don't think it has to be. RUP is based on the following software principals:1. Develop software iteratively.2. Manage requirements.3. Use component-based architectures.4. Visually model software.5. Continuously verify software quality.6. Control changes to software.Not one of these principals is groundbreaking or new. I would propose that most BAs feel comfortable with these ideas and have even used a majority of them in their past work. Lastly, like coffee there are many flavors of RUP. RUP is designed to be an adaptable framework and most companies have changed it to best meet their company specific needs. Instead of using the full-blown, highly caffeinated RUP, most companies have de-caffeinated it and added lots of cream and sugar.So when most companies post BA positions for RUP heart surgeons most of the time a general BA practitioner will do just fine.
Jason Barrett
Business Analyst
www.collective-genius.com
11/22/2006 11:51 AM
Jim said... Well said Jason. Isn't there a point where you're not really using the methodology, but you're just putting a name to the way you'd like to display your analysis. I can't tell you how many times I see the business tell me they want a diagram to do everything but make coffee for the office, when there really is no readable diagram that will accomplish that. Customization is great, but many times I find that the business wants to adjust the methodology before they understand the artifacts.
Jim Furey
Senior Business Analyst
Jim said... Jeff Martin of Collective Genius asked this question, and it's a good one. When do you use RUP, and when don't you use RUP?
Jim Furey
Senior Business Analyst
11/09/2006 7:28 AM
Jeff Martin (http://www.collective-genius.com) said... When speaking with business analysts every day I find many of them if not nearly all of the people do not feel comfortable with having RUP on their resume. However when these same people further review RUP they find they have been performing multiple elements of RUP for a very long time.I also find it interesting that almost every BA role is asking for BAs with RUP experience. These are also the same opportunities where the RUP methodology will not be applied to the extent implied.
What the RUP?
Jeff Martin
Founder
www.collective-genius.com
11/10/2006 1:10 PM
Jim said... I know I do this because I'm probably a perfectionist with a methodology. I think a good comparison would be if I've done all of the parts of a programming language. For instance...I may have experience with VB, but I've never coded VB.net. Many clients want VB.net experience. I have all of the coding, logic, and problem solving tools that I've used for years, but I don't have the one key element.I guess if I were having heart surgery, and my doctor said he or she had experience with surgery and could do all of the aspects of your basic surgery. I'd decline to have that doctor work on me, if they hadn't done heart surgery before. In fact, I'd want to know I wasn't one of the first patients as well.I don't think RUP is heart surgery, but I think BA's want to KNOW the methodology and experience it before being a point person for a business.
Jim Furey
Senior Business Analyst
11/11/2006 9:39 AM
Jason Barrett said... I think a lot of business analysts see RUP as something as difficult as heart surgery, but I don't think it has to be. RUP is based on the following software principals:1. Develop software iteratively.2. Manage requirements.3. Use component-based architectures.4. Visually model software.5. Continuously verify software quality.6. Control changes to software.Not one of these principals is groundbreaking or new. I would propose that most BAs feel comfortable with these ideas and have even used a majority of them in their past work. Lastly, like coffee there are many flavors of RUP. RUP is designed to be an adaptable framework and most companies have changed it to best meet their company specific needs. Instead of using the full-blown, highly caffeinated RUP, most companies have de-caffeinated it and added lots of cream and sugar.So when most companies post BA positions for RUP heart surgeons most of the time a general BA practitioner will do just fine.
Jason Barrett
Business Analyst
www.collective-genius.com
11/22/2006 11:51 AM
Jim said... Well said Jason. Isn't there a point where you're not really using the methodology, but you're just putting a name to the way you'd like to display your analysis. I can't tell you how many times I see the business tell me they want a diagram to do everything but make coffee for the office, when there really is no readable diagram that will accomplish that. Customization is great, but many times I find that the business wants to adjust the methodology before they understand the artifacts.
Jim Furey
Senior Business Analyst
Thursday, November 2, 2006
Iterative Process
While doing some research into Rational tools, it occurred to me that nearly every deliverable should be iterative. If I'm working on a requirements document, the document itself is the deliverable. The process of delivering that document should have the Inception, Elaboration, Construction and Transition phases within it. That means you would have some requirements for the document itself, some analysis and design of the document, testing and deployment. There is also Configuration and Change Management.
Jim Furey
Senior Business Analyst
Jim Furey
Senior Business Analyst
Subscribe to:
Posts (Atom)
