Author: Geri Schneider Winters

Another great question came from Adesh Sharma about whether or not he could write alternatives to alternatives in use cases.

There is no actual standard for the formatting of a use case, just guidelines and best practices. Your primary goal in writing use cases is communication. No matter how you structure a use case, if the readers do not understand it, then you need to change the use case.

In some cases, you will find that describing an alternative of an alternative makes a lot of sense, and actually improves the readability of the use case. In other cases, the use case will be more confusing.

Here is an example I created specifically to show the use of an alternative to an alternative. I think in this case it reads OK, and may be a reasonable way to .. this use case.

Place Order Use Case
Basic Flow of Events
=====================

1. The use case begins when the customer selects Place Order in the order processing software.

2. The order processing software displays an order form to the customer.

3. The customer enters his or her customer id into the order form. If the customer does not have a customer id, go to the alternative "The Customer does not have a customer id", which is shown below.

4. The system uses the customer id to get the customer's account information from the customer database.

5. The system displays the customer's name and shipping address on the order form.

6. The customer enters a product code into the order form.

7. The system uses the product code to get the product description and price from the product database.

8. The system displays a description and price for the product on the order form.

9. The order form adds the price to the order total.

10. The customer enters credit card payment information into the order form.

11. The customer selects the Submit button on the order form.

12. The order form sends the information entered by the customer to the order processing software.

13. The order processing software verifies the information from the order form.

14. The order processing software saves the order as pending in the database.

15. The order processing software forwards credit card payment information to the accounting system.

16. The accounting system sends a confirmation to the order processing software.

17. The order processing software marks the order confirmed in the database.

18. The order processing software displays an order ID to the customer, and the use case ends.

Alternative: The Customer does not have a customer id
======================================================

1. The customer selects create account.

2. The system displays an account creation form.

3. The customer completes the name and shipping address fields.

4. If the customer is a corporate customer, include the alternative "Add Corporate Payment Information", which is shown below.

5. Otherwise, the customer enters his or her credit card information into the payment fields, and a billing address (if different from the shipping address), into the billing address field.

6. The alternative ends.

Alternative: Add Corporate Payment Information
===============================================

1. The customer selects enter corporate payment information.

2. The system displays a corporate payment information form.

3. The customer selects the pay period, one of Net in 15 days, Net in 30 days, or Net in 45 days.

4. The customer enters the accounts receivable address.

5. The customer enters a contact person for the account.

6. The customer enters the PO number for the invoice.

7. The customer uses the note field to enter any additional information that may be required on the invoice.

8. The alternative ends.

If my customer has trouble understanding this use case, I would rewrite it to incorporate the steps of "Add Corporate Payment Information" into the alternative "The Customer does not have a customer id" in this manner:

Alternative: The Customer does not have a customer id
======================================================

1. The customer selects create account.

2. The system displays an account creation form.

3. The customer completes the name and shipping address fields.

4. If the customer is a corporate customer, do these steps:

4.1. The customer selects enter corporate payment information.

4.2. The system displays a corporate payment information form.

4.3. The customer selects the pay period, one of Net in 15 days, Net in 30 days, or Net in 45 days.

4.4. The customer enters the accounts receivable address.

4.5. The customer enters a contact person for the account.

4.6. The customer enters the PO number for the invoice.

4.7. The customer uses the note field to enter any additional information that may be required on the invoice.

5. Otherwise, the customer enters his or her credit card information into the payment fields, and a billing address (if different from the shipping address), into the billing address field.

6. The alternative ends.

===============================================

Now it is your turn.

Do you have a situation where you need to describe alternatives of alternatives? What approach do you use to structure your use cases in that situation?

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.'s Resources for Business Analysts site at http://www.writingusecases.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

Author: Geri Schneider Winters

Many people write to me to ask how they can get started as a Business Analyst. Here are my thoughts on what you can do to get started in that career.

An Analyst (Business or System) is typically in a leadership role on a project team. So the hiring manager often wants someone with some years of experience for the job. This does not necessarily mean experience as an Analyst, but some years of experience and maturity.

I started out as a Senior Scientific Programmer, then worked as a Field Engineer in a sales organization, then became a Business Analyst. This gave me technical and communication experience, plus about 12 years of work experience before I started working as a BA.

I know other very fine BAs who started as Project Managers, Newspaper Reporters, or experts in their industry (banking, insurance, etc).

If you do not have years of experience, you can look for jobs that are related or that help you develop the skills you will need for an Analyst position. Skills that are important include:

• Soft skills - listening, writing, meeting facilitation, communication skills in general, negotiation
• Domain knowledge - knowing a particular industry such as insurance, banking, or retail
• Technical skills - understanding software architecture, design, and development
• Leadership skills - project management, chairman or president of an organization

You do not necessarily need all of these skills to work as an Analyst. My own background is weak in any one domain (I know a little about a lot of domains, not a lot of one), but I have the soft skills, technical skills and leadership skills to be successful.

Some jobs you can look for include: junior analyst, reporter, sales person, marketing, technical writer, field engineer. These jobs involve a lot of the soft skills. You can work as a programmer and develop your career through the technical ranks (programmer, designer, architect). You can volunteer to lead an organization in your community to gain leadership experience. Take a junior job in an industry and work your way up. For example, if banking is your interest, take a job as a branch teller and work your way up through the ranks of the bank, taking on different roles, and really learning the business.

Definitely work with contacts, people you know in the business. Sometimes a project can use a junior analyst, but the position is not really advertised. If you know the senior analyst on the project, that person may be willing to bring you in to work with you personally.

Look for internships. For example, Safeway Inc. used to offer internships for Business Analysts at their corporate headquarters in Walnut Creek, California. I do not know if that program still exists. You may also find professional development programs at some companies. For example, Johnson and Johnson hires promising college grads into a 2 year professional development program where you work in 4 different parts of the company for 6 months at a time, learning the business. The goal is to put you into a leadership position at the company.

Look for large companies, and explore what options they have available. Check their websites and talk to people in their human resources department. Analysts work on larger projects, which are usually at larger companies. Banks and Insurance companies typically hire quite a number of analysts, but so do big retail companies (WalMart, Safeway, etc.) and companies in the defense industry (BAE Systems, Lockheed, Boeing).

===============================================
Now it is your turn.

Are you looking for a position as a Business Analyst? What have you done to prepare yourself to do that job?

Are you an experienced Business Analyst? What would you recommend to someone just starting out?

================================================
You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.'s Resources for Business Analysts site at http://www.writingusecases.com. This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

Author: Geri Schneider Winters

Alan Thompson wrote recently to ask, "How do we do a better job of estimating how long it will take to gather requirements?"

This is a question that often comes up, so I want to share my answer with all of you.

The bad news is that there is no good way to estimate the requirements gathering process in the general sense. You may be able to do a good job for specific projects, but there are too many variables to be able to have a good general purpose estimation method.

You can make some guesses based on the type of project it is.

If you are proposing a project that is a maintenance release, basically bug fixes and maybe a couple of new features, then requirements gathering is almost nothing. You just need to come up with the list of bugs that will be fixed in this release, and add details to the requested features. The amount of time for requirements gathering will be an estimate of how long it takes to detail the requirements for one feature (use your experience to estimate this) and multiply by the number of features. Determining the list of bugs to be fixed could be a matter of scheduling a one or two hour meeting of concerned stakeholders to settle the question of what is on and what is off the list of things to work on this release.

If you are proposing a project that is very well understood, then based on the number of requirements, you can do a fairly good estimate of the time it will take to document them and approve them. For example, I once worked on a project to automate the processes of loan application, loan approval, and loan buying and selling for a financial institution. The team knew their business very well, and we documented everything in 2 weeks. All the use cases, a basic business object model, a basic architecture, storyboards, and a draft of a plan to divide the work into 4 projects over 2 years. I had over 100 pages of documentation. The team was me and another 1/2 time person doing all the interviewing, documenting, and organizing of information, and about 10 people from the company who were involved part-time by being interviewed and reviewing documentation.

If you do have good, well-written, agreed on Business Use Cases, then then the time to write the detailed requirements should be the number of business requirements times the expected time to detail one of them. Which is basically a factor of the skill of the people interviewing and documenting the requirements. You may run into some cases where you find that the business use case was not as well thought out as you believed, and so the project use cases take longer to develop than expected. I would expect that situation to be the case fairly often the first couple of projects you try this approach, but the more experience you get, the better the Business Use Cases will be to begin with, and the less surprises you will find as you develop the detailed requirements.

Now you get to the hard projects - the ones that are not well understood or where the stakeholders disagree on the purpose of the project. In that case, any estimate of the time to develop the requirements is just a guess. You can look at past similar projects to find out how long requirements gathering took, and use those figures as a rough estimate. But I have watched stakeholders argue for months about the features and requirements for a project, not because the requirements were difficult to determine, but because they had a basic disagreement about the purpose of the project.

When I work as a consultant, the requirements gathering phase is always time and materials. I will not do fixed bids on that work, because my experience is that there is too much variation in that phase for me to be able to do a good job estimating it. All contractors I know who do this work feel the same way, though some have done fixed bids because that was the only way to get the contract. They have almost always been burned by it, because something happened to extend the requirements gathering phase well beyond what was expected.

Another approach to reduce risk is to go with a true iterative approach. In this approach, you identify and specify just a few requirements, write and test the code, and demonstrate it to the customer. Determine what works and what does not work. Make a list of fixes, add a couple of new requirements, and develop the next bit of code. This way, you are only working on a small piece of the project at a time, which is relatively easy to estimate. But then, you do not have an estimate of overall cost to give upper management. You can use historical records of similar projects to get an idea of overall cost for your project.

All estimation methods ultimately depend on your experience and an estimate of how long it will take to do some small task. Then various formulas are applied to turn the time to do a small task into the time to do the whole job.

In the book "Applying Use Cases", I have a copy of a paper that shows a use case estimation method, but it is more designed for estimating the project after you have written the use cases. It is based on what are called Use Case Points, and is similar to the method of estimation with Function Points. But if you review that, you might get some good ideas for coming up with your own formula for estimating the requirements gathering phase at your company.

===============================================

Now it is your turn.

Do you have a need to estimate the requirements gathering phase on your projects? What method do you use to estimate that phase?

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.'s Resources for Business Analysts site at http://www.writingusecases.com. This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

Author: Geri Schneider Winters

Almost every project will have to deal with requirements that change. I can imagine some maintenance type projects that are so well defined (fix this list of bugs) that there are no requirements changes for the lifetime of the project. Or perhaps the project is so short (a couple of hours) that there are no requirements changes. But all other projects will have some amount of requirements change.

You could argue that XP projects do not have to deal with this. In XP, a developer works directly with a customer to implement a small amount of functionality. So that small amount of functionality will probably be completed without change. But as soon as the customer sees the results of that functionality, they will want something more or something different.

This is one approach to dealing with changing requirements. Define a small amount of functionality, write the code for that, and demonstrate it to your customer. Get their feedback. Now define another small amount of functionality. This could be any combination of new features and changes to existing features. Write the code for that small amount of functionality and demonstrate it to your customer.

Sound familiar? It should. This is a brief description of a basic iterative development process. XP is an iterative development process, as are RUP and EUP. All iterative or spiral processes were defined for the purpose of dealing with the problem of requirements that change throughout the project.

The key to this is to *not* define all the requirements at once, but to only define enough of the requirements to be able to write some code so you can demonstrate it to the customer.

"But", you say, "even though my company does iterative development, I am required to write all of the requirements at the beginning of the project and to get them signed off by the stakeholders before any development work is complete."

Basically, you are describing a process that is waterfall at the beginning, followed by a series of development releases. This is really a modified waterfall. I think what drives so many companies to this process is that upper management wants an estimate of project cost up front, and to estimate the cost of the entire project basically requires you to describe all of the requirements of the project at the beginning.

(Side note: Another way to estimate project cost is to compare what you know about this project to similar projects in the company's past, and use the final amount of the cost of the previous project as the estimate for the current project. Of course, this requires that the company keep information about previous projects in such a way that it can be found later.)

In this situation, your project must either adjust to each change as it comes along, or define a process to allow you to bundle a set of changes and deal with those changes at well-defined points in time in your project.

This latter way of doing things is preferred, since it minimizes the impact of change on your project team. An easy way to do this is to wait until the development team reaches the end of one of their cycles of development, and introduce the changes when the next set of functionality is being designed. This is less of a disruption on the development team than giving them changes whenever they are discovered.

Another issue arises when considering the impact of change on the project timeline and budget. If you are required to accept every requested change, your project will go over time and over budget. If you cannot exceed your resources, then you will have to add to the change process a mechanism for deciding how much the change will cost, and what the project will give up in exchange. You have to pay for changes somewhere in the project. Either you get more time and money to develop the product, or you pay for changes by not developing something that was originally planned.

This is just basic budgeting as we all practice it at home. If I have $5.00, I can buy a Venti Chai Soy Latte at Starbucks, or a Big Mac meal at McDonalds. But I do not get to buy both. I have to pick one or the other to spend my money on. The same is true on a project. If you have $10,000 to spend, then to add feature A which costs $10,000 you have to remove another feature from the project which costs $10,000. This is very easy to understand, but so many people want to believe that adding new features to the software is somehow free.

I have had fairly good success at positioning requirements changes in terms of cost (time and/or money). So instead of saying, "If you want A you have to give up B" or "We can't do that within our time and budget", I tell the customer "You have so much money to spend on the project and it is all allocated to development costs already. This feature you want will cost $10,000 to develop. Where do you want that money to come from? Can we add $10,000 to the budget, do you want to give up something else worth $10,000, or is this new feature not important enough to spend $10,000 on?"

Estimating the cost of the changes and presenting that estimate is part of my process for changing requirements. I do not tell the customer "No", I tell the customer the cost and the consequences and let the customer decide what to do.

===============================================

Now it is your turn. What is the approach to handling requirements changes at your company? There always is an approach, even if that approach is to try to ignore the change requests and hope they go away.

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.'s Resources for Business Analysts site at http://www.writingusecases.com. This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

Author: Geri Schneider Winters

Any project that is started is started for a reason. There is some problem to be solved, or some opportunity to be met or a challenge to overcome. No matter how you word it, there is a reason for this project. Along with the reason, there is some person or group of people who have that reason for wanting this project to happen. In this tip, we will look at the use of imagination to elicit the reason for the project.

You may think this is unnecessary. If the project exists, there must be a reason for it. Ah, yes. But is that reason well-defined? Does everyone agree on the reason for the project? If the purpose of the project is not written, it is very likely that different team members and stakeholders will have different ideas of what the project is about. And sometimes those differences will be so radical, that you will have no chance of project success unless you resolve those differences.

You may find that the reason for the project is described in a document that was used to get approval for funding the project. This could be a Request for Proposal or an Initial Project Request. But the information in that document is not necessarily accurate, detailed, or complete. It is a place to start to get information about the reason for the project.

Another thing you can do is ask the various stakeholders what they think is the reason for the project. Then you can write what they tell you in a Project Vision document_ But what do you do if the stakeholders disagree on the purpose of the project, or if you do not know who all the stakeholders are?

In this case, you might invite the stakeholders you know to come to a meeting of 1-2 hours duration. In this meeting, you will invite the stakeholders to use their imaginations to describe the project. As they share results, you will encourage them to discuss and come to agreement on the reason for the project. You may find by the end of the meeting that you have additional stakeholders to interview.

Be sure to include a meeting facilitator and a scribe in the meeting. You want to make sure to capture as much information as possible while you have the stakeholders together.

Here are a couple of ideas for stimulating the imagination to find out more about the reason for the project.

Ask the stakeholders to play a Future Think kind of game. They are to think to the future when the project is complete, and write a press release describing the product that is just being released as a result of that project. Here is a template:

some future date - location of your company - company name is pleased to announce the release of product name. This product has been created to Benefit to the directly affected stakeholders. With this product who and the problem being solved. Further, Benefit to indirect stakeholders. Ultimately, Benefit to the stockholders and end customers; financial benefit.

Here is an example press release:

"August 28, 2010 - Seattle, WA - Wyyzzk, Inc. is pleased to announce the release of Gee Whiz. This product has been created to eliminate the need for washing clothes. With this product, anyone who spends time washing clothes will no longer have to do so. Further, there will be no need to buy a clothes washer or dryer, nor to go to a laundrymat to wash clothes. And this is good for the environment because there will no longer be the need to use water and soap to clean the clothes. Ultimately, this will save a lot of money for consumers, will protect the environment, and will generate substantial dividends for our stockholders."

Another idea is to ask the stakeholders to pretend they are sales people who have to convince someone else to buy the product that was created in this project. Now when you are in sales, you have to think about the other person. So the stakeholders have to identify who they are selling to, what their problem is, and why this product is the best one to solve that problem. Remember there are always competing solutions, so what are they, and why is yours better?

You can play this imagination game by having the stakeholders write a sales script, but even better, use role playing. Have one stakeholder take the role of sales person and the other take the role of a skeptical customer. You can use a recorder or video camera to capture the dialogue, then review the recording later to find out exactly what was said.

These games provide a lot of insight into the thoughts and ideas of the stakeholders about the project. You will usually get much more detailed information from these kinds of exercises than you will get by asking a direct question such as "From your point of view, what is the purpose of this project?"

===============================================

Now it is your turn. Have you tried any of these kinds of exercises on your projects?

If you are working on a project where the reason for the project is not clear or the stakeholders disagree on the reason for the project, try one or more of these techniques for resolving the differences.

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use...

START BYLINE

* Article used with permission from Wyyzzk, Inc.'s Resources for Business Analysts site at http://www.writingusecases.com. This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE