Overall I have not been impressed with automated Requirements tools from vendors like Rational or MKS; they just seem to be just list managers with change control... but I would like to hear from anyone using one of these products who finds them useful.
The main reason for today's post is a white paper I read today, from SOFEA Inc about their 'Customer Oriented Software Development' Methodology, which is supported by their Profesy tool (which is a pretty aggresive, self-confident name, even if it is spelled with an 'f' insteaf of 'ph').
The white paper is a pretty good, almost entertaining read for 15 pages, laying out how getting the right Requirements is the most important part of software development ( a little ego-stroking for us Business Analysts) but the methods used in the past (waterfall) could not ensure getting it right, and newer methods (CMMI or Agile) that were supposed to improve this have not made any impact.
So, what is SOFEA suggesting? ...that Requirements can't really capture the 'Customer Idea' that initiates software projects, you need to transform the 'Customer Idea' into 'Customer Needs' first, and from those you can generate all the rest of the usual development artifacts, starting with the Requirements... and then the White paper ends! No example of a Customer Need! or how it is different than what a Requirement would be!
I have been cruising their website (www.sofeainc.com) and have not seen any more detail; there are a few more documents available to download, but they make you identify yourself and your company before you can get the document ( I hate websites that do that!) , and I am not yet ready to contribute my identity to their marketing database. Perhaps they consider the definition and content of a 'Customer Need' to be a company secret, but they have to give it up at some point.
So, is anyone out there using Profesy? or has at least seen some more details that they could share? If so, post a comment to let me know. I am pretty much prepared to be underwhelmed if or when I get more details, but the white paper was just so good as far as it went, I can only hope they really have something good here.
Wednesday, April 26, 2006
Wednesday, April 12, 2006
Requirements are a means to an end.
A scan through my previous entries will confirm that I view documented Requirements as an essential artifact for systems development.
Given that, I don't want to imply that Requirements are 'sacred' in some way or worse yet, an end in themselves. They are a vital but intermediate deliverable along the way to delivering the solution that your business needs to succeed.
This brings me to the often-cited problem in Requirements work most commonly known as 'analysis paralysis'. Requirements gathering, analysis, and documentation cannot be some endless task that defers delivering the Requirements because of uncertainties or changes in the details of the Requirements. It does require sufficient time, but historically I have seen the effort spent on Requirements average around 25% of a total systems project. If you are spending more than 25% on a regular basis, you might have some paralysis going on.
(Sidebar: the other 75%? Typically I see 50% on design, build, and unit testing, and 25% on the rest of Testing: System, User, Acceptance, Volume, Regression, and probably more I am forgetting.)
How can you avoid paralysis?
- Define a clear scope of the Business process or function that is to be supported by the solution. If you have or can quickly put together a process map (start by defining all the external events the business must respond to), then it can be shown what you are are gathering Requirements for, and what you are not. Having that Process Map also helps identify units of work in process steps that can be documented as Use Cases.
- If nailing scope down is difficult, then time-box the work; take what you do have defined as likely in scope, and spend 2 to 3 weeks of focussed work with business involvement, and you will be surprised the volume of Requirements you will produce. Stop at the end of the time-box, and re-group/review with your Sponsor. You may have enough to start a round of development/delivery, or a better view of how much time you need to finish a complete set of Requirements.
It is also important to recognize the Requirements will change, but not necessarily for the reasons you might think. For example, you may document a portion of the requirements and review it with the business staff involved in the gathering, and you just may have written it down wrong or misunderstood what they told you; reviews/walkthroughs are essential for any quality product. If you can succeed in getting agreement that the documented Requirements are correct from the business, the amount of change after that point will be minimal.
(Agile methods proponents will tell you the business changes too much and too often for documented requirements to remain valid; don't believe it. Core information systems requirements about collecting, storing and using data do not change much over time; what does change the most is process/procedural activities, the main reason why an Information System should not automate business process, especially now that BPM tools are available that are designed to accommodate procedure changes. As author Steve McConnell recently said, the main reasons requirements change during agile development is that the requirements were not fully investigated before development started.)
The last advice I would offer to fellow BA's is that you document the Requirements, but you do not own them; they belong to the business. So, don't agonize over what may happen to Requirements after you have delivered them. There is a quote about working whose source I must track down, as it guides me every day; it is:…
"Show up on time, do your best, don't get attached to the results".
Wise words. Besides, there is always another project up next that needs its Requirements documented, so get to it!…
Wednesday, April 05, 2006
Discussion of Agile and Business Analysis/Analysts, continues
Here's an email message set from the Agile Analysis Yahoo Group...
From : Chris Matts
Reply-To :
Sent : Wednesday, March 29, 2006 2:17 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Hi Jeff, Kent. Long time no speak. Hello David
Lets get something straight. There is a place for business analysts within Agile. Business Analysis is not about writing documents though.Lets get something else straight. The reason Agile says they do not need them is because approximately 98% of BAs are crap. I should know I have interviewed close to 100 in the last year or so. One of the problems is that no one knows what a BA is. I do (from my perspective) and as a result I have tried to train the 20 people in my department to do the role. Guess what..... they are lazy/scared and do not want to change.........
Does this sound like Agile?Drop me a line and we can chat when I'm sober.
Chris
From : David Wright
Reply-To : agileanalysis@yahoogroups.com
Sent : Thursday, March 30, 2006 6:03 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Chris, what are you drinkin'? I think I could use some too...
"Business Analysis is not about writing documents though."
Right, it is about documenting Requirements, which is different.
I have written about this a fair bit at
http://www.businessanalysis56.blogspot.com/
From : Kevin Brennan
Reply-To :
Sent : Thursday, March 30, 2006 7:41 PM
To : agileanalysis@yahoogroups.com
Subject : Re: [agileanalysis] Any activity in this Group?
Chris Matts wrote:> Lets get something else straight. The reason Agile says they do not need> them is because approximately 98% of BAs are crap....
That's one of the big reasons the IIBA got started. The goal behind developing the Body of Knowledge and associated certification activities is to try and get people to understand what a BA does and does not do. I agree, it's hard to find someone with the right general skills.A big part of the problem is that a lot of BAs are "accidental"; they get seconded to the job as part of an IT project and then become a"Business Analyst" because their old job got filled while the poject was going. The result is that many BAs are little more than above-average end users with no special training or aptitude for the role.-------------------------------------
Kevin Brennan, PMPCo-Chair, IIBA Body of Knowledge Committeekevin.brennan@theiiba.org
From : Jeff Patton
Reply-To : agileanalysis@yahoogroups.com
Sent : Friday, March 31, 2006 8:24 AM
To :
Subject : RE: [agileanalysis] Any activity in this Group?
:-) Good to hear from you Chris! Although Chris might be drunk, his point isn't completely off. I'll be honest. I work alongside business analysts in agile contexts, and struggle with their thought processes at times. I consider myself an interaction designer. I work with end users and business stakeholders, talk with them about their goals, build models, think hard, and work to arrive at solutions that optimize business's return on investment while meeting user goals. I call that work design. The BAs I work with do very much the same work, only they refer to it as requirements capturing. I struggle with the term requirements capture vs. design. For me design implies some creativity and invention - and most importantly some responsibility. Requirements capture doesn't imply any of those things to me - sounds sort of like a passive thing that requires good listening and recording skills. Although I know that if I pick up any decent book on requirements work, I'll find the words creativity and invention in it - I just won't find the words design in it -at least not in reference to what the BA does. I sometimes wonder if that posture of elicitation and capture vs. a posture of responsible design isn't part of the key to their effectiveness - or lack thereof.
Although I'm not drunk, my plane is over 3 hours late and I'm ticked off and stuck at the airport. So if this sounds inflammatory to BAs - I'll blameUnited Airlines.
Cheers,-Jeff
From : David Wright
Reply-To :
Sent : Friday, March 31, 2006 9:58 AM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
In short, having Requirements first supports the choice of solution, which may not always be to design and develop something new.I can't recall where I first heard this mantra-like statement, but it has stayed with me:
"Re-Use before Buy, Buy before Build, Build for Re-Use".
Requirements are like blue-prints, especially those using models. If system delivery and software development (which are not always the same thing) are to move beyond being a craft to a real discipline, we have to stop starting with Design and know What to build before we decide How.
Dave Wright
>From: "Kent J. McDonald" mailto:kent@kentmcdonald.com
Reply-To: agileanalysis@yahoogroups.com>
To: agileanalysis@yahoogroups.com>
Subject: RE: [agileanalysis] Any activity in this Group?>
Date: Fri, 31 Mar 2006 21:13:11 -0600>>
Is it necessarily a bad thing that Software Development is a craft?
>-->Kent J. McDonald>kent@kentmcdonald.com>http://www.kentmcdonald.com>Words to lead by: Collaborate; Iterate; Serve the Team; Consider Context;>Practice Excellence; Reflect and Adapt; Deliver Value
From :
David Wright
Reply-To :
Sent :
Saturday, April 1, 2006 9:22 PM
To : agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
"Is it necessarily a bad thing that Software Development is a craft?"
A craft-work approach to delivery implies custom-made, low-volume and high-cost results. Shoes haven't made by cobblers for a century or two, and just because software is a relatively new and uniquely malleable product, this does not mean it won't and shouldn't be produced using engineering-based production methods. This will be the way software will become a product where quality is assumed, not just hoped for.
What implications does this have for programming as we know it? It will become less and less of a technical creation skill amd more of an assembly role, putting together software components to create systems.
(If that upsets any programmers reading this, well, I have been out drinking some single-malt tonight, so my opinions may be a little direct by this time of night.... :-) )Dave W
From : Chris Matts
Reply-To :
Sent : Wednesday, March 29, 2006 2:17 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Hi Jeff, Kent. Long time no speak. Hello David
Lets get something straight. There is a place for business analysts within Agile. Business Analysis is not about writing documents though.Lets get something else straight. The reason Agile says they do not need them is because approximately 98% of BAs are crap. I should know I have interviewed close to 100 in the last year or so. One of the problems is that no one knows what a BA is. I do (from my perspective) and as a result I have tried to train the 20 people in my department to do the role. Guess what..... they are lazy/scared and do not want to change.........
Does this sound like Agile?Drop me a line and we can chat when I'm sober.
Chris
From : David Wright
Reply-To : agileanalysis@yahoogroups.com
Sent : Thursday, March 30, 2006 6:03 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Chris, what are you drinkin'? I think I could use some too...
"Business Analysis is not about writing documents though."
Right, it is about documenting Requirements, which is different.
I have written about this a fair bit at
http://www.businessanalysis56.blogspot.com/
From : Kevin Brennan
Reply-To :
Sent : Thursday, March 30, 2006 7:41 PM
To : agileanalysis@yahoogroups.com
Subject : Re: [agileanalysis] Any activity in this Group?
Chris Matts wrote:> Lets get something else straight. The reason Agile says they do not need> them is because approximately 98% of BAs are crap....
That's one of the big reasons the IIBA got started. The goal behind developing the Body of Knowledge and associated certification activities is to try and get people to understand what a BA does and does not do. I agree, it's hard to find someone with the right general skills.A big part of the problem is that a lot of BAs are "accidental"; they get seconded to the job as part of an IT project and then become a"Business Analyst" because their old job got filled while the poject was going. The result is that many BAs are little more than above-average end users with no special training or aptitude for the role.-------------------------------------
Kevin Brennan, PMPCo-Chair, IIBA Body of Knowledge Committeekevin.brennan@theiiba.org
From : Jeff Patton
Reply-To : agileanalysis@yahoogroups.com
Sent : Friday, March 31, 2006 8:24 AM
To :
Subject : RE: [agileanalysis] Any activity in this Group?
:-) Good to hear from you Chris! Although Chris might be drunk, his point isn't completely off. I'll be honest. I work alongside business analysts in agile contexts, and struggle with their thought processes at times. I consider myself an interaction designer. I work with end users and business stakeholders, talk with them about their goals, build models, think hard, and work to arrive at solutions that optimize business's return on investment while meeting user goals. I call that work design. The BAs I work with do very much the same work, only they refer to it as requirements capturing. I struggle with the term requirements capture vs. design. For me design implies some creativity and invention - and most importantly some responsibility. Requirements capture doesn't imply any of those things to me - sounds sort of like a passive thing that requires good listening and recording skills. Although I know that if I pick up any decent book on requirements work, I'll find the words creativity and invention in it - I just won't find the words design in it -at least not in reference to what the BA does. I sometimes wonder if that posture of elicitation and capture vs. a posture of responsible design isn't part of the key to their effectiveness - or lack thereof.
Although I'm not drunk, my plane is over 3 hours late and I'm ticked off and stuck at the airport. So if this sounds inflammatory to BAs - I'll blameUnited Airlines.
Cheers,-Jeff
From : David Wright
Reply-To :
Sent : Friday, March 31, 2006 9:58 AM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
In short, having Requirements first supports the choice of solution, which may not always be to design and develop something new.I can't recall where I first heard this mantra-like statement, but it has stayed with me:
"Re-Use before Buy, Buy before Build, Build for Re-Use".
Requirements are like blue-prints, especially those using models. If system delivery and software development (which are not always the same thing) are to move beyond being a craft to a real discipline, we have to stop starting with Design and know What to build before we decide How.
Dave Wright
>From: "Kent J. McDonald" mailto:kent@kentmcdonald.com
Reply-To: agileanalysis@yahoogroups.com>
To: agileanalysis@yahoogroups.com>
Subject: RE: [agileanalysis] Any activity in this Group?>
Date: Fri, 31 Mar 2006 21:13:11 -0600>>
Is it necessarily a bad thing that Software Development is a craft?
>-->Kent J. McDonald>kent@kentmcdonald.com>http://www.kentmcdonald.com>Words to lead by: Collaborate; Iterate; Serve the Team; Consider Context;>Practice Excellence; Reflect and Adapt; Deliver Value
From :
David Wright
Reply-To :
Sent :
Saturday, April 1, 2006 9:22 PM
To : agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
"Is it necessarily a bad thing that Software Development is a craft?"
A craft-work approach to delivery implies custom-made, low-volume and high-cost results. Shoes haven't made by cobblers for a century or two, and just because software is a relatively new and uniquely malleable product, this does not mean it won't and shouldn't be produced using engineering-based production methods. This will be the way software will become a product where quality is assumed, not just hoped for.
What implications does this have for programming as we know it? It will become less and less of a technical creation skill amd more of an assembly role, putting together software components to create systems.
(If that upsets any programmers reading this, well, I have been out drinking some single-malt tonight, so my opinions may be a little direct by this time of night.... :-) )Dave W
Tuesday, April 04, 2006
Agile falls short, says author
Software development concept hasn’t blossomed: McConnell
By: Paul Krill(31 Mar 2006)
From Computerworld Canada: www.itworldcanada.com
The article is at http://www.itworldcanada.com//Pages/Docbase/ViewArticle.aspx?ID=idgml-8e5499c3-e4fe-49ac-8230-9fa5a564512e
but you might have to register to read it.
Steve McConnell lists his worst ideas of Agile, my favourites being:
•Requirements are always changing.”[The] single most common source of changing requirements [is] requirements that were not significantly investigated in the first place,” said McConnell.
• Requirements can be gathered or they just drop out of the sky like manna from Heaven.
• Entrepreneurial companies cannot be afraid of risk.
• One single development approach will work best for all projects.
Mr. McConnell is a published author on software topics; while I don't know what his original views of Agile might have been, he has certainly laid a shot over the bow of agile proponents.
Comments, anyone?
By: Paul Krill(31 Mar 2006)
From Computerworld Canada: www.itworldcanada.com
The article is at http://www.itworldcanada.com//Pages/Docbase/ViewArticle.aspx?ID=idgml-8e5499c3-e4fe-49ac-8230-9fa5a564512e
but you might have to register to read it.
Steve McConnell lists his worst ideas of Agile, my favourites being:
•Requirements are always changing.”[The] single most common source of changing requirements [is] requirements that were not significantly investigated in the first place,” said McConnell.
• Requirements can be gathered or they just drop out of the sky like manna from Heaven.
• Entrepreneurial companies cannot be afraid of risk.
• One single development approach will work best for all projects.
Mr. McConnell is a published author on software topics; while I don't know what his original views of Agile might have been, he has certainly laid a shot over the bow of agile proponents.
Comments, anyone?
Subscribe to:
Posts (Atom)