Anyone familiar with 'Profesy' from SOFEA Inc.?

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.

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!…

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 : agileanalysis@yahoogroups.com
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 : agileanalysis@yahoogroups.com
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 : agileanalysis@yahoogroups.com
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 : agileanalysis@yahoogroups.com
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

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?

Discussion on Agile, and Methodologies in General, Part 3

From :
Kent J. McDonald
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 7:33 PM
To :

Subject :
RE: [agileanalysis] Any activity in this Group?

Sorry to hear you were under the weather. That seems to be going aroundhere as well. I've moved up the sections I am replying to and cutting therest out. Hope that's ok (want to keep the message from getting too long).

DAVEW....1) How much time (hours per day) do Agile developers need to be withcustomers/users? Finding available time on key people's schedules is aconstant challenge for me; I basically have to prepare ahead for a veryfocused 60 to 90 minutes that I might get a day (or every 2 days) to gatherrequirements. I often end up addressing multiple projects with differentbusiness people in parallel in order to keep productive. In fact, mycompany expects partcipation in multiple projects at the same time.

Kent... It depends on the environment. Reality dictates that you figure outwhat works within the constraints you are working in. Working on multipleprojects at the same time is not ideal, but I know it happens quite often.
-----------------------------------------------------------

DAVEW...Sorry, i don't follow you here. A good methodology with defined artifactsshould ensure that what is delivered is of value, and no more; I don't havetime to produce content that is not used. ...and any good methodology andartifact set will evolve over time to capture what is required, and dropwhat is no longer required.

Kent...A good methodology is only part of the story. The real key is how do peopleimplement that methodology. Take the RUP for example. Rational decidedthat they were going to make the UP into a product, and wanted to make surethat they provided artifacts to cover as many different types of projects aspossible. The trouble is, more than a few people ignore the advice to craftthe methodology to fit the needs of that particular project and end up doingmore than they need because the methodology "requires" it. More often thennot, the "and drop what is no longer required" does not occur in practice.The ability to do that, to me, is a sign of a mature developmentorganization.

----------------------------------------------------------->

Kent... I actually think analyzing the business is doing more than creating the >requirements, it should also be about collaborating with the customers >to help them arrive at the best solution to their business problem.>

DAVEWRequirements definition is crucial to selecting the best solution for thebusiness; if you have already started developing software, you have probablyselected the technical architecture and operating environment. How do youknow if you shouldn't have gone in a very different direction? Where do youmake the choice to re-use an existing system, or buy instead of build?

Kent...I'm not sure that I was implying that you started developing software. WhenI said "help them arrive at the best solution to their business problem." Iwas thinking things such as understanding what the problem really is andlooking at all possible approaches, which may not include a technologysolution. I should have also made a comment about helping the customerdetermine if they really have a problem, or if they are focusing on thewrong problem.
------------------------------------------------------------

DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of aproject between delivering the best solution and delivering it on time isbest resolved as an external discussion between 2 people, rather than aninternal dilemna for one person... at least that's what works for me.

Kent... 2 Heads is always better than one. I just happen to be a believer that ifthose 2 heads are experienced in a variety of skill sets (with obviousspecialties in one or two fields) the result will be better becausecollaboration is more likely to happen vs when people only specialize andfeel the need to do extensive "Hand offs" between functions. Of course youcannot always get people that are able to and enjoy doing a variety ofdifferent tasks, but it is always something for which to strive.
--------------------------------------------------------------

DAVEWYes, methodologies and documented processes for any activity that producesdifferent deliverables each time (like Information Systems) should not betreated as written in stone. Certification is a long-standing approach tocreating and perpetuating a profession; in fact, there is an ISO standardfor doing it. Managers and HR directors for years have been telling me howimportant it is to 'act professional' and all, I think I would like toactually be recognized as one.

Kent... I don't think you have to be certified to "act professionally", and Isuspect that there are some people with certifications that do not always"act professionally." Certifications have their place, but they have theirflaws as well. My advice to Managers and HR would be to "use with caution."

Kent J. McDonaldkent@kentmcdonald.com
http://www.kentmcdonald.com
Words to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value

Discussion on Agile, and Methodologies in General, Part 2

From :
David Wright
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 6:52 PM
To :
agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?




Sorry, been under the weather for a few days... so let me review and return the favour! DaveW>>

>The key to your statement above is *formal*. Agile methods recognize the>importance of requirements just as much as other methodologies, they just>have the philosphy that given a choice between recording the key points and>then having the ability to collaborate directly with the customer/user when>software development is underway vs documenting everything and throwing the>document over the wall to the developers, they would choose the former. We>all know that real life fits somewhere in the middle. A common agile>requirement mechanism is the user story, which typically consists of a>statement in the form AS A I Want so that>. Where the details are expressed as acceptance tests>so that the requirement artifact can provide multiple uses. Agile>approaches also discourage requirements inventory where all of the>requirements for a project are fully elaborated at the beginning of the>project. Rather they suggest that the requirements are listed at a very>high level at the beginning of the project for scoping purposes, then they>are elaborated upon during the iteration in which that particular chunk of>functionality is built.>
DAVEW....1) How much time (hours per day) do Agile developers need to be with customers/users? Finding available time on key people's schedules is a constant challenge for me; I basically have to prepare ahead for a very focused 60 to 90 minutes that I might get a day (or every 2 days) to gather requirements. I often end up addressing multiple projects with different business people in parallel in order to keep productive. In fact, my company expects partcipation in multiple projects at the same time.2) High-level Requirements are common when scoping a project, either as "I need..." or "The solution must..." statements. I am currently working on a project where high-level requirements were used to define 4 separate phases. Benefits and costs estimated for each phase were used to prioritize the work, and I am now working with the business on detailed requirements for the first phase. I will be feeding those requirements to the assigned designer as they stabilize, who will start development of the first phase while I proceed to detailing the requirements for the second phase, and so on.WIll the results be 'formal'? I suppose, since they will be documented, communicated and approved, and form a baseline for development that virtually eliminates mis-understandings..

>>>>>>>I think if you look at software development overall (including the >Analysis,>development, testing, etc.) from a value perspective, you may find yourself>asking how rigorous should your requirements activities be in order to>provide the information that developers need without performing non value>added work. Where that line falls varies between teams and projects.>
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifacts should ensure that what is delivered is of value, and no more; I don't have time to produce content that is not used. ...and any good methodology and artifact set will evolve over time to capture what is required, and drop what is no longer required.......

"Business Analyst". It is not bad title, and it is one I>have had off and on since 1984, and it does describe what we do --- analyze>the business --- but not what we create: the Requirements.>>>I actually think analyzing the business is doing more than creating the>requirements, it should also be about collaborating with the customers to>help them arrive at the best solution to their business problem.>
DAVEWRequirements definition is crucial to selecting the best solution for the business; if you have already started developing software, you have probably selected the technical architecture and operating environment. How do you know if you shouldn't have gone in a very different direction? Where do you make the choice to re-use an existing system, or buy instead of build?

>>.....I think this is part of the reason that, when some companies hire a Business>Analyst, they believe they are also getting a Project Manager and Software>Tester (the latter better known as Quality Assurance Analysts). I have also>met Business Analysts who would agree with this. I would certainly agree>that having multiple skills will make you more marketable, but it should be>clear that these are three separate skill-sets that are not always>compatible.>
>I would be one of those BA's that agree with that statement.>
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of a project between delivering the best solution and delivering it on time is best resolved as an external discussion between 2 people, rather than an internal dilemna for one person... at least that's what works for me.>>

<snip>>>....................................................If you consider yourself a Business>Analyst, it is imperative you seek out the IIBA, and highly recommended >that>you join.>>
>The good thing about the IIBA is that it is provide a source for BA's to go>for information about Business Analysis and providing a network for people>to expand their knowledge about the subject.>>I would caution about putting too much stock in certifications and BOK's.>Certifications indicate someone's ability to learn one set of knowledge>about a given area and take a test on it, they do not provide a reliable>measure of that person's ability in the subject area that they are being>certified on. BOK's are great because they provide a compiled set of some>knowledge about an area. They become dangerous when people start to>interpret that set of knowledge as *the only correct* thinking for a given>field, and people forget that items in the BOK do not work equally well in>all situations.>>I would agree that you should join the IIBA if you consider yourself a BA >(I>myself am a member). Just remember what a certification is really telling>you, and remember that just because some practices do not find their way>into the BOK does not mean that they are not correct or useful in certain>situations.>>
DAVEWYes, methodologies and documented processes for any activity that produces different deliverables each time (like Information Systems) should not be treated as written in stone. Certification is a long-standing approach to creating and perpetuating a profession; in fact, there is an ISO standard for doing it. Managers and HR directors for years have been telling me how important it is to 'act professional' and all, I think I would like to actually be recognized as one.>

Dave Wright

Discussion on Agile, and Methodologies in General

I recently sent the following email to a Yahoo group I belong to on Agile Analysis...

It has been quiet at this group for some months now... anyone out there doing what they consider to be agile analysis on current/recent projects?I'll be honest, I am still skeptical on this topic... see http://businessanalysis56.blogspot.com/2006/01/information-system-requirements-still.html ...but I am still open to being persuaded.Dave W

..and ended up starting a conversation on the topic that started with the following reply from Kent Mcdonald:

David,I would say yes there are people doing what they consider to be agileanalysis on current/recent projects, they just don't happen to be posting tothis list. The most active discussion surrounding agile analysis typeactivities appear on the Agile Modeling list.(http://groups.yahoo.com/group/agilemodeling/) This list is moderated byScott Ambler who has done a lot of writing on Analysis related activities. Isuggest you read his writtings and join the mailing list. Based on readingyour blog post, I think you may find some of it interesting.
As a matter of fact, when I first started this list, I got a bit of pushbackasking if a list focusing on Agile Analysis was really necessary and whether it continued the fractionalization of the software development community.You can look back in the archives and follow the discussion. My thought basically was that we would "let the market decide" and based on your observation about traffic, they may have been right. None the less, I believe there still is value in talking about doing analysis in an agile manner. This has different meanings for different projects in different environments. In those environments that support full blown agile, that means developers working with customers directly. In environments thataren't quite ready for agile, that means that analysts collaborating with both developers and customers to make sure they are working with the customers to understand their needs and with the developers to understand what information they need to properly develop what the customer needs.

David, I read the blog entry that you referenced and had some thoughts. Ihope you don't mind that I replied to parts of it in this message.-----------------------------------------------------------------------------------------------------------------------If you are familiar with newer Agile or Extreme methods for developingsoftware, you will know that they disdain formal requirements, preferring towork directly with end-users to deliver software in small increments. Ibelieve that these methods are a natural reaction to software developers'long-standing frustrations with receiving poor, incorrect or no Requirementsto work with. Developers should be focused on creating software, and timethey spend trying to find out what they should develop, or developing thewrong software, is a waste of their valuable time.
The key to your statement above is *formal*. Agile methods recognize theimportance of requirements just as much as other methodologies, they justhave the philosphy that given a choice between recording the key points andthen having the ability to collaborate directly with the customer/user whensoftware development is underway vs documenting everything and throwing thedocument over the wall to the developers, they would choose the former. Weall know that real life fits somewhere in the middle. A common agilerequirement mechanism is the user story, which typically consists of astatement in the form AS A I Want so that. Where the details are expressed as acceptance testsso that the requirement artifact can provide multiple uses. Agileapproaches also discourage requirements inventory where all of therequirements for a project are fully elaborated at the beginning of theproject. Rather they suggest that the requirements are listed at a veryhigh level at the beginning of the project for scoping purposes, then theyare elaborated upon during the iteration in which that particular chunk offunctionality is built.
Why do Developers get poor Requirements? There is often no common disciplineor accepted practices being used when creating Requirements in a softwaredevelopment project; but, if Developers do get good Requirements, theresulting software is better is almost every way, primarily that it willmeet the needs of the business that requested and paid for it.
Agree here.
As a discipline, Project Management faced similar problems in the past, buttoday its practitioners all recognize common approaches and techniques: WorkBreakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, andmore. They also have seen their work coalescing as a profession through thePMI and its PMP certification. Project Managers also started with theadvantage that their job title actually describes what they do - ProjectManagers manage projects. Software Developers have the same advantages,although the wide variety of languages and environments mean no singlecertification can be had.
There are positives and negatives to being considered a "profession" and tocertification. More comments on that later.
So, I think Model Driven Architecture will play an increasing role overtime; in the mean-time, if it shows that methods for producing requirementscan be rigorous enough (good enough) to generate code, then why not use suchmethods to document Requirements for developers to use for the rest ofsoftware development

I think if you look at software development overall (including the Analysis,development, testing, etc.) from a value perspective, you may find yourselfasking how rigorous should your requirements activities be in order toprovide the information that developers need without performing non valueadded work. Where that line falls varies between teams and projects.
An ancient Chinese saying tells us that 'All wisdom begins with callingthings by their right names.' So, the job of gathering and documentingRequirements needs a Name. I am being somewhat disingenuous here, as thereis well-known job name already, but it is not always used the same way; I amtalking about the "Business Analyst". It is not bad title, and it is one Ihave had off and on since 1984, and it does describe what we do --- analyzethe business --- but not what we create: the Requirements.
I actually think analyzing the business is doing more than creating therequirements, it should also be about collaborating with the customers tohelp them arrive at the best solution to their business problem.
I think this is part of the reason that, when some companies hire a BusinessAnalyst, they believe they are also getting a Project Manager and SoftwareTester (the latter better known as Quality Assurance Analysts). I have alsomet Business Analysts who would agree with this. I would certainly agreethat having multiple skills will make you more marketable, but it should beclear that these are three separate skill-sets that are not alwayscompatible.
I would be one of those BA's that agree with that statement.
The last question about the Business Analyst job is the importance ofspecific business knowledge and experience, aside from analytical andrequirements-related skills. Again, companies will ask for Business Analysiswith experience in Supply Chain Logistics or Life Insurance or ExpressDelivery or Human Resources or Commercial Credit or Finance/Accounting.Well, I have worked in all of these business 'domains' and more withoutneeding to change how I do my job. In the end, the business people beingserved by Information Systems - executives/sponsors, managers, end-users ---are the ones who need to know their business; what I need to do is be ableto quickly understand their business in order to gather and document theirInformation Systems Requirements.
Agree completely. It has also been my experience that someone who does notnecessarily have a long history in a particular industry, but is able toquickly pick it up, is often not influenced by filters, and would be morelikely to ask those probing questions that could lead to groundbreakingchanges in how the business works based on borrowing ideas from otherindustries.
Finally, you may ask how technical a Business Analyst needs to be. My basicrecommendation is you need to understand what technology can do in order todeliver the solutions that meet the Requirements, but you don't need to knowhow the technology will do it. I started as a PL1 and IMS programmer beforemoving to Business Analysis; since then, I have done Requirements forsystems implemented on mainframes, minis and PCs, using environments fromTSO to OS2 to Windows to Browsers; again, the technology to be used to didnot really change how I did my job; in fact, the best Requirements are thosethat can be implemented in multiple technical environments.
Knowing the technology certainly does not hurt. And sometimes it's nice toknow when a technologist is giving you bad information, especially whenworking with the developers to realize the requirements.
And about certification for Business Analysts, we can now look to theInternational Institute of Business Analysis, at www.iiba.com . It is beingcreated and developed following the appropriate ISO standard forprofessional certification organizations and, much like the PMI, isdeveloping a Body of Knowledge for Business Analysis andcertification/testing based on that BOK. If you consider yourself a BusinessAnalyst, it is imperative you seek out the IIBA, and highly recommended thatyou join.
The good thing about the IIBA is that it is provide a source for BA's to gofor information about Business Analysis and providing a network for peopleto expand their knowledge about the subject.I would caution about putting too much stock in certifications and BOK's.Certifications indicate someone's ability to learn one set of knowledgeabout a given area and take a test on it, they do not provide a reliablemeasure of that person's ability in the subject area that they are beingcertified on. BOK's are great because they provide a compiled set of someknowledge about an area. They become dangerous when people start tointerpret that set of knowledge as *the only correct* thinking for a givenfield, and people forget that items in the BOK do not work equally well inall situations.I would agree that you should join the IIBA if you consider yourself a BA (Imyself am a member). Just remember what a certification is really tellingyou, and remember that just because some practices do not find their wayinto the BOK does not mean that they are not correct or useful in certainsituations.

Looking forward to anyone's thoughts.Kent J. McDonaldkent@kentmcdonald.comhttp://www.kentmcdonald.comWords to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value-----Original Message-----

Come and see my presentation at Business Analyst World, Toronto, May 2006

I am happy to announce that I am scheduled to make a presentation at this year's Business Analyst World in Toronto, on May 11. My subject is Integrating Business Analysis Artifacts (including Business Rules).

The details are available at:

http://www.projectworldcanada.com/toronto/conf_detail.asp?ConferenceID=2646

I highly recommend this conference to all Business Analysts. It is an annual event in Toronto and other locations around North America, paired with ProjectWorld.
See http://www.projectworldcanada.com/ for details.

So come on down, I look forward to meeting any and all who have visited this blog since its inception last year.

A little off topic: linkedin.com

If you are in IT/IS or are a general web enthusiast, you are probably familiar with the Networking sites out there that seem to be a business version of "Six Degrees of Separation". I personally belong to linkedin.com after being invited to join by a valued former co-worker. I now have 10 direct connections, and it can be interesting to follow through and see who is in your network when you go two or more connections into it. I haven't found the site terribly useful in any practical way yet, but the potential is there, I think.

In any case, linkedin now offers to put your 'profile' on the web with your own URL, so I have done so at https://www.linkedin.com/in/dwwright99 . You can choose how much information you want to publish and how much you want to keep private.

Anyway, now I want to see how long before I turn up on a search at zoominfo.com .

Information System Requirements still matter...

If you are familiar with newer Agile or Extreme methods for developing software, you will know that they disdain formal requirements, preferring to work directly with end-users to deliver software in small increments. I believe that these methods are a natural reaction to software developers’ long-standing frustrations with receiving poor, incorrect or no Requirements to work with. Developers should be focused on creating software, and time they spend trying to find out what they should develop, or developing the wrong software, is a waste of their valuable time.

Why do Developers get poor Requirements? There is often no common discipline or accepted practices being used when creating Requirements in a software development project; but, if Developers do get good Requirements, the resulting software is better is almost every way, primarily that it will meet the needs of the business that requested and paid for it.

As a discipline, Project Management faced similar problems in the past, but today its practitioners all recognize common approaches and techniques: Work Breakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, and more. They also have seen their work coalescing as a profession through the PMI and its PMP certification. Project Managers also started with the advantage that their job title actually describes what they do – Project Managers manage projects. Software Developers have the same advantages, although the wide variety of languages and environments mean no single certification can be had.

There is no similar structured discipline or professional recognition around Requirements today; but I submit that it will exist in the future, for two main reasons:
…1) the need has been recognized by a growing number of Requirements ‘practitioners’, who have founded an association similar in mandate and purpose to that of the PMI for PM… more on that later.
… 2) It has been demonstrated in the past the Requirements can be documented using modeling methods with enough rigor that software can be automatically generated from the Requirements. Yes, the main CASE tools of 10 to 15 years ago failed to catch on, but not because they did not work. I see this level of rigor and code generation surfacing again with Model-Driven Architecture.

Granted, I am in no position to say that model-based Requirements and code generation are going to reduce or eliminate creation of software by programmers. I could however draw on the common justification for any automation that is used so often; that it won’t eliminate people’s work or jobs, but free them up to work on more challenging tasks .

So, I think Model Driven Architecture will play an increasing role over time; in the mean-time, if it shows that methods for producing requirements can be rigorous enough (good enough) to generate code, then why not use such methods to document Requirements for developers to use for the rest of software development?

But where to begin?

An ancient Chinese saying tells us that ‘All wisdom begins with calling things by their right names.’ So, the job of gathering and documenting Requirements needs a Name… I am being somewhat disingenuous here, as there is well-known job name already, but it is not always used the same way; I am talking about the “Business Analyst”. It is not bad title, and it is one I have had off and on since 1984, and it does describe what we do --- analyze the business --- but not what we create: the Requirements.

I think this is part of the reason that, when some companies hire a Business Analyst, they believe they are also getting a Project Manager and Software Tester (the latter better known as Quality Assurance Analysts). I have also met Business Analysts who would agree with this. I would certainly agree that having multiple skills will make you more marketable, but it should be clear that these are three separate skill-sets that are not always compatible.

I myself have and will manage small to middle-sized projects, but primarily when I have first completed the Requirements myself; if you need more than one Business Analyst to get the Requirements delivered, you need a separate Project Manager. I do recognize that many Business Analysts have worked hard to acquire Project Management skills and experience to then become a certified PMP, but it is often because there has been no equivalent certification for Business Analysts; again, more on that later.

I have also had a successful career as Business Analyst without testing software; I see that as a very specific discipline for which I have great respect, but no inclination to perform. It’s possible or probable that I have no talent for it either.

Another issue I have with the misuse of the Business Analyst title are those companies who advertise for a ‘Business Analyst’ with specific software product experience, such as Oracle Financials or SAP (even a specific SAP module). I think what these companies are looking for are ‘Application Analysts’. This again is a separate skill-set, and a popular one, but these analysts still need to have the Requirements of the business provided to them, and I believe ‘real’ Business Analysts are probably doing that first.

The last question about the Business Analyst job is the importance of specific business knowledge and experience, aside from analytical and requirements-related skills. Again, companies will ask for Business Analysis with experience in Supply Chain Logistics or Life Insurance or Express Delivery or Human Resources or Commercial Credit or Finance/Accounting. Well, I have worked in all of these business ‘domains’ and more without needing to change how I do my job. In the end, the business people being served by Information Systems – executives/sponsors, managers, end-users --- are the ones who need to know their business; what I need to do is be able to quickly understand their business in order to gather and document their Information Systems Requirements.

Finally, you may ask how technical a Business Analyst needs to be. My basic recommendation is you need to understand what technology can do in order to deliver the solutions that meet the Requirements, but you don’t need to know how the technology will do it. I started as a PL1 and IMS programmer before moving to Business Analysis; since then, I have done Requirements for systems implemented on mainframes, minis and PCs, using environments from TSO to OS2 to Windows to Browsers; again, the technology to be used to did not really change how I did my job; in fact, the best Requirements are those that can be implemented in multiple technical environments.

And about certification for Business Analysts, we can now look to the International Institute of Business Analysis, at www.iiba.com . It is being created and developed following the appropriate ISO standard for professional certification organizations and, much like the PMI, is developing a Body of Knowledge for Business Analysis and certification/testing based on that BOK. If you consider yourself a Business Analyst, it is imperative you seek out the IIBA, and highly recommended that you join.

So, Business Analysts deliver Information Systems Requirements; if you navigate back through this blog, you will see how it is done. (It is the accepted Blog format for entries to be LIFO, so I would recommendyou can make your way back to my first entry http://businessanalysis56.blogspot.com/2005/07/welcome-to-business-analysis.html and then work your way forward. I have recently learned about a website/service called squarepusher.com that may be useful in turning these blog entries into a standard website, so I will keep you all informed on my progress there...)

Thoughts for the New Year

In no particular order:

• I still have a ton of material from the Business Rules Forum, and I still have to figure what I want to say about it here, maybe some attributed highlights from the sessions?
• If you consider yourself a Business Analyst, you need to join the International Institute of Business Analysis, www.iiba.com ...don't wait any longer
• Process Models: how do they get so big? If you have one Role/Swimlane doing many sequential tasks, don't have one process model 'box' for each task, put them all in a single procedure document and refer to it from the Process Model.
• Why do some Business Analysts believe they also have to be Project Managers and Testers as well? I would assume it makes you more marketable, but they are very separate skillsets from Business Analysis... and if a lot of you keep doing it, then companies will still keep asking for them in Business Analyst job descriptions.
• Why don't IT/IS magazines really write about Business Analysis? Are we that un-sexy?

...more later.

Business Rules Forum

I am back from the Business Rules Forum, last week in Orlando. I have a lot of material to make use of, so I thought I would start with giving an overview of the major points themes of the conference:

- Business Rules has its origins in Expert Systems as well as Data Modeling.
- Business Rules and Business Processes are becoming more integrated than ever. BR approaches can be used to manage the ‘decision diamonds’, and simplify the maps themselves.


- Most common questions: who should document Business Rules? Is it Business Analysts? What is a Business Analyst?... I met a few people who are founding the Jacksonville FL chapter of the IIBA, and mentioned the existence of the IIBA in a few sessions.

- Some participants were evangelists who see Business Rules as the center of business and systems; others see Business Rules as apart but integrated with all the other ‘artifacts’ of business requirements, especially as organized by the Zachman Framework.

- The Zachman Framework was itself a common subject across many presentations, capped by a closing presentation by John Zachman himself. While his framework is methodology and artifact independent, he does however see Business Rules as a valuable addition to the Business Model of Row 2 of the Framework, mainly in the Motivation Column.

To see the overall agenda for the forum, you can visit http://www.businessrulesforum.com/

Requirements and Architecture

Are my Information System Deliverables equal to artifacts that that can be organized by the Zachman Framework?

Yes and No. For those of you unfamiliar with the Zachman Framework, visit its website… http://www.zachmanframework.com/

Let’s see what columns I have covered with my deliverables:

Data Model is “what”.
Business Process Model is “how”.
Use Cases may also be “how”, and also partially “who”.
Events of the Business Process Model are “when”.
Business Rules are “why”.

That leaves “where”, which may need to be stated explicitly when multiple business locations are involved; this may require a requirements deliverable for an information systems network.

From a Zachman perspective, my deliverables may be seen as weak in the “when” and “who” columns. I am usually comfortable with these areas as they are, as “when” and especially “who” are often found more in systems design then system requirements. Overall, if you have read my earlier posts, you will notice that the words “what” and “how” have a different meaning from Zachman when describing Information System Requirements (what), versus Information Systems Design (how).

You can also see that some of my deliverables would be considered as row 2 artifacts, while others are row 3. If you feel the need to provide artifacts for both rows, so much the better; if not, I think my deliverables, plus a location/network deliverable, will usually suffice for defining a complete set of Information System Requirements.

Now, I do say this in the context of being a Business Analyst responsible for defining Information Systems Requirements, without expecting there to be an overall Architecture in place. If you are lucky enough to be working in an environment that does provide an overall Architecture, I humbly submit my favourite deliverables as candidates for use as architectural artifacts.

Integrating Requirements Deliverables

Some of the requirement Deliverable integration possibilities have been touched on in the previous postings. Listed together, they are:

- Process Maps identify all steps of a process, and a Process Step can indicate when a Use Case is used in the Business.

- Use Cases can include the Declarative Requirements for the Information System/Solution.

- A Data Model will document all data items used within the scope of a set of Use Cases, and is cross-referenced in the Use Case for the data items used by the latter.

- Business Rules can also be documented across the scope of the Business being analyzed, including both the set of Use Case and the overall Process Map, as a Business Rule may be invoked at different points and times with the Business Operations. Use to date has shown they can then best cross-referenced in:
o In the Use Cases whose execution is impacted by one or more Business Rules
o In Process Maps at Decision Points, as Business Rules may play a role in deciding which path within a Map should be followed in any one execution of the Process

I have a diagram showing the relationships, but my blog site does not want to accept an upload of it. I will keep trying, but in the meantime, contact me at dwwright99@hotmail.com and I will send you the diagram (as a bmp file).

Business Rules

As a concept, Business Rules are not new, to the Business or IT; what is new is the focus on separating them from other forms of documentation so they can better defined and managed. Business Rules are similar to Process Models/Maps in that they are subject to more frequent change than other aspects of the business, frequently enough that if rules are hard-coded in an Information System, the effort and elapsed time to change the system can be too large to be tolerated by the business over time.
So, just as generic Process ‘systems’ are emerging to support rapid process change, so are Business Rule Systems and Vendors that support Business Rule Management and Change independently of the information systems that uses them.

What is a Business Rule?
A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern (an Information Systems) project are atomic – that is, they cannot be broken down further.
“Defining Business Rules ~ What Are They Really?”, Copyright ©2001, the Business Rules Group.

I would add the word ‘declarative’ to the definition, as in “a business rule is a declarative statement that defines…” emphasizing that Business Rules do not imply and process, procedure, flow or other ‘system’ structure. If Business Rules are separately defined and managed, they can then be used as needed by any process/procedure/flow that needs a rule’s guidance or constraint.

The paper with the above definition is available at http://www.businessrulesgroup.org/first_paper/br01ad.htm
It includes an example case study of a fictitious car rental company with many defined business rules; here is a sample:

Rental reservation acceptance
- If a rental request does not specify a particular car group or model, the default is group A (the lowest-cost group).
- Reservations may be accepted only up to the capacity of the pick-up branch on the pick-up day.
- If the customer requesting the rental has been blacklisted, the rental must be refused.
- A customer may have multiple future reservations, but may have only one car at any time.

So, please go read that article at the Business Rules Group website (I want to avoid any charges of plagiarism of that site on my site).

To ensure that Business Rules are meaningful and clear, they are always based on a defined set of ‘Terms and Facts’, which are used as the language of the Rules. Terms from the above examples include rental request, car group, reservation, branch, and customer. An example of a fact would be "a customer may have multiple future reservations": it’s when you add the constraint "but may have only one car at any time" that you have a rule, using that fact and the relevant terms.

Defining terms and facts can also be seen as a role of an Entity-Relationship Data Model, such that the Entities/Attributes and Relationships of such a Data Model can readily be used as the Terms and Facts for defining Business Rules. The two types of models are different in some ways, but they are similar enough that if you have both, you can easily use one to drive the creation of the other.


So, now we have covered all the Requirements formats that I commonly use:
· Declarative Requirement Statements
· Use Cases
· Data Models
· Process Models
· Business Rules

… and I have already touched on some aspects of how these formats can be inter-related and integrated. I will review all those and add some more aspects in my next post on Integrating Requirements Deliverables.

Process Models - are they bad for Requirements?

I am not aware of the origin of Process Models as we see them today, but their profile was certainly raised by Hammer and Business Process Re-engineering; you certainly had to define your Business Process before improving/re-engineering it. For myself, the one aspect of Process Models that does not get enough attention is defining & understanding the Events in the business environment (external or internal) that kick-off the execution of a Process; know your Events, as they come in handy in many ways when defining Information System Requirements

As a format for documenting Information System Requirements, process models can have a negative impact on the resulting system. The process as it exists at the time of documentation has often been ‘hard-coded’ in the delivered computer system; when the process needs to change, the system cannot support a different process, and the business starts to adapt or create work-arounds to get the work done despite the constraints of the system.

This situation occurs frequently because it is not recognized that some aspects of the business are less stable than others. It has been shown that the process of a business, especially the order of separate steps, is the least stable aspect of a business; at the other end of the scale, the data items and their definitions as used by a business are the most stable aspect of that business. In between the two ends of the scale fall things like specific procedures (units of work) and business rules.

So, automation of the current business process should not be an Information System Requirement. In fact, more generic process and workflow software have been developed over the years to specifically support rapid change in process, adding or changing or re-ordering process steps as needed.

Where Process Models play a role in documenting Information System Requirements is to provide a context for Use Cases. Most steps in a process map will state that some work is done in that step, before the process flow continues; often this work involves use of an Information System, which can be documented as a Use Case. As stated in earlier posts, the Use Case then provides context for Declarative Requirement Statements, as well as a cross-reference to data items and their definitions in a Data Model.

Just a few years ago, this would have been the last ‘format’ that would have been described in this document. However, a new emphasis on methods and formats for documenting Business Rules has recently emerged, the topic for my next posting.

Data Requirements

Data Models are used to define the data needed for an Information system to use and/or control, and often form the basis for the definition and creation of databases. The most common format used to capture data requirements is the Entity-Relationship Diagram, which I believe originated with Clive Finkelstein and was most popularized by James Martin’s Information Engineering Methodology.

A Web Search on Entity-Relationship Diagrams or on Data Models will return thousands of hits, as I think that Data Models as a requirements format are more popular than even Use Cases. Here are two interesting links I found today:

1) Data Modeling: Finding the Perfect Fit
An Introduction to Data Modeling
by Tim McLellan
Copyright 1995. All Rights Reserved.
http://www.islandnet.com/~tmc/html/articles/datamodl.htm


2) Applied Information Science
(Data) Modeling Methodologies
http://www.aisintl.com/case/method.html


In my use of data models for Requirements, the main component is the Data Entity, a subject of interest to the Business, associated by the business relationships between them. Each entity contains data items/attributes that relate to or describe the Entity. Each attribute belongs only to one Entity, so duplication of Requirements is reduced.

Entity-Relationship data models are also commonly classified as ‘Conceptual’ or ‘Logical’, in that they are intended to communicate the data requirements of the Business. Such models can then be transformed into a ‘Physical’ Data Model that is used to design a database.

If a Data Model is used in conjunction with Use Cases, the latter’s data items can be defined by a cross-reference to the Data Model. As a result, a data item used in multiple use cases will be defined only once, eliminating duplication and inconsistency.

Use Cases

I am probably a relative new-comer to use cases, after working in analysis and requirements through Structured Analysis and Design in the eighties, and Information Engineering in the nineties. I found one author’s description of them almost aesthetically appealing, that each one is a case (or example) of the use of a system.

After that, I have seen many variations and permutations and various ‘uses’ of use cases; either that is a testament to their flexibility, or a condemnation of their vagueness. If you are new to Use Cases, be aware that different flavors of use cases are out there, being promoted and being used. When I am feeling the need for some rigor or consistency, I always go back to Alistair Cockburn (pronounced ‘coburn’) at http://alistair.cockburn.us/

Overall, I have seen and used two basic types of use cases:

- A multiple-step interaction between Actor and System, which relates to user interface design, and capturing the required functionality the system must provide to support the interaction. I saw this a lot when working with co-workers who were OO designers and programmers.

- A single step or occurrence format, where an Actor initiates the use case, which is provided some input and/or pre-conditions, and it executes a set of actions (calculate something, retrieve or store something else) that produces a result of interest to the Actor. (There may be multiple Actors, too.) The set of actions that are first defined are those that will normally execute, if no exceptions or other variations occur. I call this the ‘happy path’, as I am sure some author or instructor called it that, but I can’t recall who. However, if it is known that one or more exceptions/variations from the ‘happy path’ could occur (due to certain input values or combinations of pre-conditions), these are documented as alternative paths. Creators of these types of use cases don’t like to see path selection in their use cases, no “IF-THEN-ELSE” statements; use your alternatives instead.

Finally, both of the above types differentiate between the use case itself as the definition or template of the ‘use of the system’, and Scenarios, which are specific instances of the use case given one set of possible input values or pre-conditions; changing the input values produces another scenario, so a large number of scenarios could be defined for one use case, all of which will help the Testers of the information system developed based on the use case(s).

As you might expect by now, I mainly use the second type of use case as part of documenting Information Systems Requirements. They are extremely valuable as, if nothing else, a widely-accepted format for documenting the results of Analysis; anything that effectively assists in communicating Business Requirements to one or more audiences is something that should be used(!).

Now, they are not perfect, and they are not the ultimate format for documenting Requirements… they are only one format of many (five at last count). One issue I had with use cases early on was identifying them in the first place: what was the scope of each use case? How many use cases do you need? There will definitely be more than one. What I can say now is that one way use cases can be identified is by there relationship with Process Models, and I will describe this in a future post.

However, once you do have a set of use cases defined that cover the scope of the business you are analyzing, you can use them to organize the Declarative Requirements Statements I described in my last posting. I often start an Analysis effort by creating a list of High-Level Requirement Statements based on initial discussions with the business subject matter experts; if the these people want a new or enhanced system, they will tell you what they want from that system, which you can capture as Declarative Requirement Statements.

Once I have moved ahead to capture the necessarily detailed description of the business in use cases, I then allocate those Declarative Requirement Statements to the use cases that will actually support the Requirements (if you end up with Requirements that don’t match up to any of your use cases, you might be missing some use cases.) Detailed analysis will also support the definition of more Requirement Statements, again associated with particular use cases.

It might be argued that the detail provided in a use case supersedes the need for Requirement Statements, but I believe they still play an important role in communicating the essence of the use case. Designers/Developers will look to the use case detail for their understanding of the Requirements, but the Requirement Statements are often preferred by Testers as documentation of what they must test, and the Statements provide trace-ability from the Analysis through Design/Development to Testing.

So to this point, we have covered Declarative Requirement Statements and Use Cases, including how the two can be associated with each other… it must be time to discuss Data Requirements… in my next post.

Declarative Requirement Statements

The Declarative Requirement Statement format is a direct assertion of one “...property that is essential for an IT system to perform its functions.” They are ‘declarative’ in that they do not imply any order or flow upon the information system. Such statements are usually part of a larger group or list of Requirement Statements, and can be documented at various levels --- from High-Level Requirements that are often documented first in a project, to detailed statements used as input to Design and as the source of Test Cases.

The common structure is: “…the System must .”

Variations on this structure include:

• Referring to the “Solution’ instead of ‘System’, as an information or other type of ‘System’ is not always what is needed to meet the Requirements of the business.
• Variations on the verb ‘must’, such as ‘shall’ or ‘will’; a ‘must’ statement is often interpreted as a mandatory requirement, while statements using other verbs mean the requirement is optional or ‘nice-to-have’. If multiple verbs are used in a set of Requirement Statements, the specific meaning of the use of each verb should be clearly defined.

Examples:

“The System will provide security that a Manager can only view salary data for their own reporting staff.”

“The System will calculate the monthly payment for a loan application, given the
• Interest Rate,
• the Amount Borrowed,
• and the Number of Payments & Payment Frequency”

Presenting large numbers of Requirement Statements can be a challenge, and grouping them by common attributes is one means of organizing the statements; one very common classification is the grouping of requirements as Functional or Non-Functional.

Requirement Statements can also be given a context by associating them with other documentation methods, such as Use Cases. This will be the topic of my next post.

Documenting Information System Requirements

To support their understanding, the key aspect of all Information System Requirements is that they be documented; this usually means they are written down in some way. Many authorities on Requirements will say that if a Requirement is not written down, it does not exist; on the other hand, each authority tends to have its own favourite format (original or adopted) for documenting Requirements. Since the 1970’s, many different formats (and the systems development methodologies they were often part of) have been published and used. Over time, several format/methods have survived and are commonly used; for example, most analysts and developers are familiar today with use cases.

It is also now apparent that no one format is sufficient to represent all Information System Requirements. Since information systems can do many things –- calculations, store data, produce reports, support/enforce proper business practice --- it is necessary to recognize that the means of representing the requirements need to vary as well. As such, no one format captures all the requirements for information systems, but using several formats collaboratively, virtually all requirements can be documented and related to each other.

The following formats are those that I am commonly using to document Requirements:

· Declarative Requirement Statements
· Use Cases
· Data Models
· Process Models
· Business Rules

I will be looking at each format in future posts, followed by my thoughts how to use all of them in collaboration to fully document Requirements for Information Systems.