• INCOSE Requirements Management Tools Survey - This survey, provided in table form, compares over 40 different requirements management systems based on how well they conform to over 75 common requirements. Information ranges from as early as 2004 to the summer of 2008, so you’ll have to bear in mind that some of the information may not be the latest and greatest. The INCOSE survey at least gives you a start and can save you quite a bit of preliminary information gathering work regarding the various tools available in the market, and some initial requirements. If you’re interested, here is a text version of the survey requirements.
  

• Forbes.com also provides a directory of requirements management tools that can be filtered by popular features. I’d refer to the INCOSE survey first, but there is some good information here as well.

• Seilevel’s Requirements Management Tool Selection - I’ve always enjoyed the Seilevel blog and message board as a resource for business analysis insight. In post linked above, Joy shares Seilevel’s process in selecting a requirements management tool to recommend to their clients. She also provides a useful comparison between three “heavy hitters” in the requirements management space - Telelogic (now IBM) Doors, Rational Requisite Pro, and Borland Caliber Analyst. I won’t steal their thunder and share their final recommendation here, but advise you to go have a read.

• Ralph Young has an interesting document on his site that outlines his process and requirements for selecting a requirements management tool. His document compares a few of the leading tools, but the document is from 2002, so it is more useful as a template to use to pattern a selection process than as a resource to decide between the listed products.

• In a separate post from the one mentioned above, Seilevel also shares their requirements for deciding on a 3rd party solution provider and describes how this process is different from the requirements process for home-grown software. My company has been following a very similar process in choosing our management tool.

I will probably have more to share as we continue our selection process, but hopefully these will make a good start. If you know of any additional, useful resources for evaluating requirements management tools, I’ll be grateful if you’d share them in the comments below.

Originally posted on JonathanBabcock.com as:

Requirements Management Tool Resources

Do you like to look at examples of others’ requirement specs and templates to see what you can learn? I do from time to time and thought I’d share a quick, simple tip that I use to find sample documents. Hopefully some of you will find it useful.

There are so many varieties and formats of software specification documents. Looking at samples from other companies and industries gives me an opportunity to compare the way things are done in “my world” to how they’re done across the world.

Once in a while I’ll find something - maybe the document layout, or just a concise turn of phrase - that someone else is doing that I like and will try to incorporate it into my work. Even if not, I find it interesting to observe the varying levels of specificity and requirement format/syntax that others use.

If you think that you, too, may be interested in taking a look at what others in the field are doing, an easy way to find hundreds of examples is to go to Google and type in:

Software Requirements Specification filetype:doc

It will bring up enough samples and templates to keep you busy for a while, and obviously you can tweak the search to bring back slightly different results.

For example, you might try a variations on the search string like “functional requirements” or “use case” or change the filetype to pdf (filetype:pdf) to bring up specs in pdf format.

Anyway, nothing groundbreaking here, but hopefully this will be useful to a few of you.

Originally posted on JonathanBabcock.com as:

Looking for Sample Requirement Specifications and Templates?

[S]omething or someone which exists outside the system under study, and that take part in a sequence of activities in a dialogue with the system, to achieve some goal: they may be end users, other systems, or hardware devices. Each use case is a complete series of events, described from the point of view of the actor.

Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.

To further clarify, the OMG in their UML spec describes an actor in the following terms:

Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances.

UML Superstructure Specification, ptc/04-10-02, October 8, 2004, p. 661 – emphasis mine.

I’ve found that it’s easy to identify the actors that are users of the system, but sometimes less evident to identify other systems or non-human participants in the use case dialogue. This can be especially true for those that are new to writing use cases.

I’ve always liked quick, little job-aids that help break down and simplify things. To that point, Miles and Hamilton provide a simple diagram for identifying actors in the book Learning UML 2.0 (Learning). I’ve made some minor tweaks to the diagram and included it below in case it might be of use to some of you:

Originally posted on JonathanBabcock.com as:

Quick Tip to Help Identify Use Case Actors

According to Chin, the determination is made by evaluating project environments and organizational stakeholders.

Project Types

For “Operational Project” environments, or “projects that are run with a regular frequency, are very similar to each other, and are critical to the day-to-day running of the business,” he tends to favor classic management methods.

For projects focusing on the development of new technology he favors agile methods. To clarify what he means by this type of project, he states:

I am not talking about a new product or application, but rather the development of breakthrough technology, upon which future products will be built… Technology development projects are very unique in nature. There is no template project teams can work from and, in fact, a project management template, or any template for that matter, may greatly restrict the team creativity required to create such a new technology platform.

For product or process development projects, which require more business and less technical expertise, he doesn’t see as clear break toward either, but potentially a blend of the two.

Organizational/Stakeholder Environment

Per Chin, the number and type of organizations and stakeholders involved in the project also influence the classic/agile balance. He indicates that classic project management is better suited for handling the complexities of intergroup coordination and accountability necessary in projects with several external stakeholders, stating “[w]hile it is not impossible to create a successful agile environment across multiple organizations, it will be significantly more challenging.”

He favors agile management most in projects under a single organizational or corporate umbrella, and states that this is the environment “where most technology projects that can benefit from agile PM reside, and thus, it is an area with a strong potential return.”

This array of project types and organizational environments combine to provide a matrix resembling the one below that can aid in deciding on the appropriate method of project management.

(Table adapted from figure 2-7 of Agile Project Management—How to Succeed in the Face of Changing Project Requirements by Gary Chin)

Conclusions

Obviously, there are holes to be poked in any simplified method of making complex decisions, and Chin acknowledges that, “[d]eciding to employ agile PM is not a simple, black-and-white question.”

For all its simplicity, I did find the agile/classic matrix to make quite a bit of sense. At the very least, the approach Chin used provides some useful insights that can help in deciding which management method best suits your situation.

If you get the chance, pick up the book. Chin provides much more detail on the topic in his book than I have in this simple summary. He includes several other factors that may influence the classic/agile question, and tackles numerous other agile project management topics.

So, what are your thoughts? Would you agree on the factors used? How would your decision matrix differ from Chin’s? As always, I’ll look forward to your input.

Originally posted on JonathanBabcock.com as:

Choosing Between Agile and Classic Management Methods

I’ve said it before, and I’ll say it again: It’s good to be a business analyst!

Not long ago, CIO.com ran an article entitled, Why Business Analysts Are So Important for IT and CIOs. The article has apparently piqued the interest of many business analysts as I’ve seen it mentioned in various blogs and discussion groups.

It is exciting that reliable research firms like Forrester are producing reports such as this that acknowledge the value of the BA role and provide such a positive outlook.

I wanted, first, to point out the article to those of you who may not yet have read it; second, to share some of my own commentary on passages that I found particularly interesting. So, here we go:

What is clear: The most successful business analysts are the ones who blend the temperament and communications savvy of a diplomat with the analytical skills of an intelligence officer. And business analysts are a hot commodity.

I found the comment on the mix of skills interesting - and hey, when is the last time you were told you were a “hot commodity?”

The best candidates are business-oriented business analysts who want more direct control over how business processes are automated, and IT-oriented business analysts who want to move from IT into the business.

I really like this passage because I’ve argued time and time again that the business analyst role is not just a software development and IT role. Corporate business units benefit from having a trusted adviser who understands how technology can be applied to solve business problems. The business and IT both benefit when an analyst can get engaged with decision makers early to help them define business problems and articulate their needs in the form of business objectives and requirements; not solutions.

To ensure that the business technology analyst role is coherent, supported and ultimately attractive, CIOs should establish a forum in which these folks can share best practices, such as a business technology analysis center of excellence.

Wow. I found this to be a very interesting idea. I can see consulting companies doing something like this, but I wonder how many typical companies with IT shops and BAs actually have such a center of excellence, or are moving in that direction? I’d be very interested to hear of them, and how it is working out.

Finally…

In the end, the more business technology analysts that are working in the business, the better off the CIO and IT function will be—no matter if the BT analysts are reporting into IT or the business side. That’s because those IT-savvy analysts, who will have a more in-depth understanding of and more expertise in technologies, will “ultimately help the business make better decisions when it comes to its interactions with IT,” contend the Forrester analysts. And, “CIOs have new allies in the business.”

What a fun and informative read. If you haven’t, go read the article. I’ve only touched on a few of many good points, and there is lots of other interesting insight in the comments section.

Hopefully this won’t be the last article of the kind, and I’m confident it won’t be. It really is good to be a business analyst.

Originally posted on JonathanBabcock.com as:

It’s Good to be a Business Analyst II

Jim Highsmith, in the book Agile project management : creating innovative products, thinks that the reason projects tend to have so much documentation and so few results is that:

[T]here is a fundamental flaw in many people’s understanding of documentation—documentation is not a substitute for interaction. When a customer and a developer interact to jointly develop specifications and produce some form of permanent record (documents, notes, sketches, feature cards, drawings), the documentation is a by-product of the interaction. When the customer sits down with a product manager and they write a requirements document that gets sent to a development group, then the document has become a substitute for interaction. In the first scenario, the documentation may be valuable to the development team. In the second, it has become a barricade to progress. Little knowledge is either gained or transferred. Furthermore, as interaction decreases, the volume of documentation often increases in a fruitless attempt to compensate.

Highsmith, James A. Agile project management : creating innovative products. : Addison-Wesley Professional , 2004.

I especially appreciate the point that no knowledge is transferred when “sending a document” takes the place of actual interaction. And it especially hits close to home as one of the key functions of the business analyst is to facilitate the transfer of knowledge. How successful can we truly expect to be by substituting thick documents for actual dialog?

I think I can safely say that my most successful projects (and best spec docs) have been jointly owned among business and technology stakeholders with me there – not to pass out completed documents, but to help elicit requirements and facilitate dialog.

Thanks for the insight, Jim. Good stuff.

Originally posted on JonathanBabcock.com as:

Documentation is No Substitute for Interaction

Here are some of my recent findings of interest that I wanted to share in case others of you may be in the same boat.

Martin Fowler specifically addresses the question, “What is the difference between UseCases and XP’s stories?“:

Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories… break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP’s release planning process. Because these uses of requirements are different, heuristics for good use cases and stories will differ.

Mike Cohn, whom I’ve cited before on the topic of user stories, provides insight on a format for articulating user stories that he has found to work well.

I advocate writing user stories in the form of “As a <type of user>, I want <some goal> so that <some reason>.”

For example, “As a corporate finance user, I want to know yearly how much in taxes are due to the state treasury so that the company can comply with state tax regulations (and avoid penalties for non-compliance).”

I think this format could be just as beneficial in a non-XP environment as a mechanism for requirements elicitation. In fact, I’m going to use the spreadsheet form of which he provides a sample for use in one of my new projects. I plan to ask my stakeholders to put themselves in the place of the user (in at least one case, the stakeholder will actually be one of the users) and let them state, from a first-person perspective, what they need to be able to do, and the value of being able to do it.

Too often as I’ve written traditional SRS documents I’ve either been asked or wondered to myself what was the value of a given requirement or set of requirements. With this format, we’d include a statement of business value with each user requirement. Good stuff.

For your reference, and contrasts them with traditional requirements.

In summary, here is what I’ve gathered so far based from my readings on user stories (much of this is derived from ExtremeProgramming.org’s useful description of user stories) :

1. User stories are primarily used to estimate development time, as opposed to use cases which focus on how users (actors) interact with a system.
2. User stories focus on user needs and are technology/implementation detail agnostic.
3. User stories become acceptance test scenarios.
4. User stories are typically written on cards and not diagrammed using the UML as are use cases.
5. User stories are an alternative to the traditional SRS document full of “shalls”. When it comes to detailed functional, system and quality requirements, those are worked out between developers and the customer.
6. User stories are most often identified with the XP (extreme programming) approach to release planning and development, which is a form of agile development.

I am a student as much as a practitioner of requirements analysis, and am always open to new information in tips. If you have any additional information or personal feedback on user stories or extreme programming or other agile methods, then please share. I’m always interested in learning more.

Originally posted on JonathanBabcock.com as:

More on User Stories

If you’ve ever doubted the need for requirements elicitation for an ERP project, you need to read this. Apparently a company is suing an ERP software vendor because the software it was expecting to work in a promised date did not work even more than one year late (shocking!). It’s a very interesting read. Among other things, the plaintiffs refer to prototypes or mock-ups as a form of deception by demonstrating “fake software.” In any case, the moral of the author’s story is that, “even when buying a COTS system (an ERP is a big COTS), you do need the expertise of requirements engineers.”

While on the legal theme, have you heard that the State of Indiana has made use of a waterfall methodology a criminal offense?

“Waterfall software development lifecycles have terrorized technology projects in this state for too long,” Governor Mitch Daniels said at a simple signing ceremony held at a meeting of the Central Indiana chapter of the Project Management Institute (PMI). “This bill will end the tyranny of big upfront planning, big upfront design, and litigation style change management.”

It’s a fun read. I actually did “LOL”. Before you go calling your whole team to your cube to tell them about it, please bear in mind that the article was, in fact, penned on April 1.

Here is an interesting take on what a “dev guy who has done app maintenance, DBA work, testing and performance analysis” wants to get from the business analyst. He is fairly detailed in describing his expectations of what delivery teams need from the BA in order for:

the developers to build the application

the DBA to understand the data model

the operations guy/gal [to understand] what kind of information they would get at run time

the testers to write their test scripts

the performance tester to determine what are their targets

the trainers to write a course on the application

the stakeholders to know what they are paying for

the BAs (both client side and your side) to understand what need[s] to be going on.

Lastly, many analysts are aware of the informative articles from IBM that describe software development and methodology, often in concert with their own software and service offerings. Here’s an informative article from IBM on creating a system specification from the user’s point of view by using UML to create a user model. The article includes lots of examples and diagrams as well as links to related information.

Originally posted on JonathanBabcock.com as:

Weekly Digest - 8-17

I read a though-provoking article the other day by Tony Lock on why IT is still not communicating well with its business counterparts. Per Lock:

[F]ew organisations have formally established and monitored service levels reporting in terminology and language with which business users will be comfortable… But when it comes to measuring and reporting on IT’s contribution to either overall business goals or top line business value, the number of organisations with formal reporting processes in place drops to only one in five or even lower.

However, communication isn’t just about metrics and reports. He concludes,

The biggest benefits to the entire business and to IT departments themselves will come not directly from establishing and formally reporting on these matters in business terms but in establishing expressive two way communications between business and IT professionals.

Amen.

On the lighter side, here’s a fun graphic that compares the usability of an Apple product, a Google product, and “your company’s application.” Ouch!

I liked an analogy from Joe Shoemaker posted at Modern Analyst. In it, Joe compares the roles of customer, Business Analyst and Business Manager to a car buyer, salesperson and the buyer’s wife. It’s a quick, fun read and well-written. Do take a look. Also, parse through the comments. There’s some good dialog there as well.

I like to gather constructive quotes. Here’s a link to 21 Suggestions for Success. Some of them may seem a bit trite, I think at least a few are consistent with the subject matter of this blog. Here is a quick sample of my favorites:

“Work at something you enjoy and that’s worthy of your time and talent.”

“Be decisive even if it means you’ll sometimes be wrong.”

“Commit yourself to constant improvement.”

Requirements inflation? Nahh. Never heard of it. Thanks to Geek and Poke for the fun picture.

Originally posted on JonathanBabcock.com as:

Weekly Digest - 08-16

On this blog we’ve talked about the imprecision of natural language and the problems it can present in drafting requirements. Forget requirements - what would you think of a tool that could turn natural language into software code? Sounds crazy, doesn’t it? Well, there is already such a tool in the works, although it’ll probably still be a while before they’ve ironed out all the wrinkles.

Writing software has been relatively difficult since people began programming computers in the mid-1900s. Although programming a computer is eminently useful — it gives you fine control of a powerful tool — it requires learning a programming language.

Researchers from the Massachusetts Institute of Technology are aiming to remove this requirement. They have taken a step toward that goal with a language-to-code visualizer dubbed Metafor.

The visualizer uses natural language instructions to sketch the outlines of a program. It can be used as a programming learning tool and to provide rough drafts of programming projects, and could lead to more complete programming-by-natural-language methods.

Formal computer programming languages are difficult to write and inflexible, said Hugo Liu, a researcher at the Massachusetts Institute of Technology. This makes them “quite a pain to debug and maintain,” he said. “Hence the task of programming is rendered inaccessible to the general public.”

Natural languages like English, on the other hand, are universally accessible, said Liu. “Natural language is so semantically rich and flexible that if it could be computationalized as a programming language, maybe everyone could write programs,” he said.

I love the idea. Imagine being able to “code” your own software if you could just articulate what you want in natural language. While the notion seems surprising, I suppose I’ve seen development tools trending this way for a while. I remember being on a project a while back that implemented a rules engine. The notion there was that the business wanted to be able to make changes to promotions and to product portfolios whenever they wanted to, and not to have to wait for a scheduled software release with all of its overhead. This package was to make it so a business owner could make these changes via a relatively simple user interface.

So, while there are obvious implications to software developers here, what do developments like this mean to the business analyst? How will these jobs be affected if/when the day arrives that any old Joe can develop applications? What do we need to do to ensure that our skills aren’t marginalized as new tools simplify what were previously complex tasks requiring specialized training?

I don’t claim to have the answers, but I suppose it is something we should all be considering. What are your thoughts on the tool? On it’s implications? What other revolutionary tools have you heard of that will soon change the way we solve business problems? As always, I’ll be interested in reading your comments.

Originally posted on JonathanBabcock.com as:

New Tools - and Their Implications