I have set up a video channel for Business Analyst tips on YouTube.
There are 15 videos there at present including:

• 5 steps to better use cases – parts 1 and 2
• Business rules versus Technical Constraints
• Use Stories versus User Cases
• Business Analyst Career Paths
• and 10 videos on how a BA would start to work on a project

There are 10 different project types, so 10 different videos

I’ll be adding more over time, so let me know if there is something you want me to make a video about!

Here is the link again:
http://www.youtube.com/user/Wyyzzk

Pass on the link to other BA’s you know.

1. If you sign up for my free tip of the week (see the upper right of this page), you get some reports with example use cases in them, along with a year of tips on writing use cases, writing other requirements, and the Business Analyst (or Business System Analyst) career. Current Price: Free.
2. If you buy my new book Use Case Business Requirements Model – Home Mortgage Loans, you get a complete business requirements model for the home mortgage loan domain (banking), with 30 use cases, over 80 business rules and supplementary requirements, and many UML diagrams including use case, activity, class, and state.  More than example use cases, this shows you how to put a complete business requirements model together.  Current Price: $27 USD.
3. If you buy my book Applying Use Cases: A Practical Guide (2nd Edition)
   there is a large use case example in that book, especially in appendix E. This example is order processing for an online store.  (This is my Amazon associate link, so if you buy through here, I am paid a commission.) Current Price: about $45 USD.
4. If you buy my Basic Use Case Writing System (self study course, approximately 4 weeks), you get a lot of  example use cases.  The Basic Use Case Writing System includes 3 example projects with a total of 50 use cases. The 3 example projects are a research library user interface, cargo container shipping, and a conference management system. Current Price: $97 USD.
5. If you register for my Business Analyst Fundamentals class (instructor led, IIBA certified, 10 weeks), you get a lot of examples of all kinds of requirements. The Business Analyst Fundamentals class is my premium class where I give you pretty much everything I have written on the subject of the Business Analyst role, sample artifacts, templates, etc.  If you are serious about being a Business Analyst or Business System Analyst, this is the class for you. The next class starts in February 2011. Current Price: $970 USD.

That list of places gives you a number of places where you can find example use cases that I have written. I am sure other people also provide example use cases. I have not gone to look for them, so do not know their quality.  I trust my own work   so I know these are good examples.

Geri

I posted some articles on the site today that were in my email list or somewhere on the blog or somewhere on my hard drive

These are on the Use Case page and Determine Requirements page. I also added new sections to the BA Skill Matrix for SDLC and Tools. So go explore and see what is new!

Enjoy!

Geri

An interesting question came up in another forum, and I would like to address it here because I think it is a common one.

I am currently struggling introducing use cases into a large product development organization and a prime obstacle I am facing is that one use case should be all sort of things to different people. For Product Managers it should be dead simple focusing on high-level application functionality and scenarios (probably close to user stories), for the Developer it should be much more detailed and written with great rigor (scenarios described with activity diagrams); not to mention the Usability team who see use cases as Alan Cooper in About Face. I am wondering how to address all this. In architecture we came up with the View Points. I am wondering which way is better: (a) providing different perspectives on one use case by filtering some portion of its description, or (b) deriving more detailed use cases from one higher-level use case. Although it may lead to duplication, I intuitively bend towards solution (b). It provides better separation of concern. Any thoughts on this?

I think use cases are a wonderful tool. I have been using them, writing about them, teaching them to other people since sometime in 1996. But they are only one tool in my toolbox.

I think of it this way – a use case is not a kind of information, it is a form of information, a template, a way of structuring information. If you are describing a process, a procedure, a sequence of steps, then a use case works very well. But other forms may be better at describing your information. A use case is a poor choice for sequences with a lot of decision points (for example). In that case, I would look at activity diagrams, flow charts, or state machines to describe the information.

When choosing the form I will put my information/requirements into, I think about the information itself (as I just described), but also the people who will consume the information and what form will make it easier for them to consume it. When I was working on an embedded system with a bunch of electrical engineers, I used a lot more state charts, which I do not use at all with my IT business stakeholders. There is nothing wrong with producing the same information in different forms – user stories for the project sponsor, state machines for the engineers, for example.

While use cases started out as a way to describe telephone switching networks (see Jacobson’s early work in the 70′s for example), they have become a tool for describing user driven behavior. I have used them for embedded systems, but in that case, you really need to be careful about what is driving the system. It is very likely not a person, so the use case should be focusing on the actor/thing that is driving the process/behavior of the system. That may be hardware or another system, or even a clock.

So the answer to the question is, figure out the best form of information for each audience and create the appropriate documentation/diagrams/whatever. Just like the different Architectural Views Ponits, we have different views of requirements for different audiences, and those different views will probably not all be use cases.

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

What kinds of forms have you used for presenting requirements to different audiences? Do you write use cases for everything? Do you maintain different versions of the use cases for different audiences? Or do you maintain your requirements in different forms – user stories, use cases, sequence diagrams, state diagrams, flow charts – for different purposes?
=====================================
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.ResourcesForBusinessAnalysts.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

I would love your feedback on it.

You can find the document here: What Are Requirements

Geri

When working on a project, you want to consider what kind of information you have, and what form is the best for documenting that information. These are two different things. A use case is a form of documentation that can be used for a variety of purposes. Sometimes a use case represents requirements, and sometimes it does not. So do not confuse the kind of information with the structure or form of the information.

Sometimes the easiest thing to do at first is to think of everything as information. As you collect and categorize information, you can decide which things represent requirements of the solution, and which things are other kinds of information. Often when I start a project, I am not sure what I have at first. I’ll collect a lot of information, then I will start to see patterns and categories to that information. As I structure the information into these patterns and categories, the process helps me to determine which things are requirements and which are other kinds of information. After that, I decide what form of documentation to use to communicate that information. I start with the information first, then I decide how to structure that information, what forms to put it in.

A number of companies I have worked for were very focused on use cases. Everything was a use case, the only requirements they had were use cases. But this was causing problems, because all the requirements were not use cases, and they were using use cases for purposes other than requirements. Needless to say, people at these companies were very confused. So instead of focusing on how the requirements were structured (use cases), I focused everyone on the kind of information they were collecting. This information represents context or scope, but that information looks like future state. Once I had determined what kind of information they had, then I guided them to appropriate forms of documentation. I did have use cases for both context and requirements, and I had other kinds of requirements documents as well. This approach cleared up a lot of confusion at those companies.

I have used state machines for analysis and for detailed design. I have used use cases and activity diagrams for context as well as for requirements. A component diagram can represent a logical or a physical model. If you know what kind of information you have, you can make a separate decision about the form you use to communicate that information. Typically the form you use will depend on the audience (or consumers) of the information.

Here are some ideas of what I think of as kinds of information vs forms of information. You may not completely agree with the two lists, but I hope they lead you to thinking about the kinds of information as being separate from the forms of information.

Kinds of information

• Context
• Scope
• Problems
• Solutions
• Requirements
• Future State
• Needs
• Wants
• Dreams
• Wishes
• Constraints
• Limitations
• Risks
• Technology
• Bug Reports
• Feature Requests

Forms of information

• Use Cases
• Shall Statements
• Test Cases
• User Stories
• Scenarios
• User Interface Designs
• Wireframes
• FURPS
• Prototypes
• Flow charts
• Activity diagrams
• State machines
• Truth tables
• Report Specifications
• Data Dictionaries
• Data Models
• Domain Models
• Object Models
• Business Requirements
• Business Rules

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

Now it is your turn.

Do you see that kind of information and form you put it in are two different things? What kinds of information do you work with? What forms of information do you work with?

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

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

Have you noticed the examples of requirements elicitation on my blog? In one case, I had a bit of a contest, using a game to elicit information. You can see this technique by looking in the category Online Game on the blog. Then I had a survey to elicit information. You can see that survey by looking in the category Survey on the blog. Today I am going to use the information from the survey to show you another technique you might use when developing requirements. That technique is writing Personas (or Personae for you Latin fans).

You write a Persona when you want to understand your customers better. This Persona is a story you will tell about a typical (but not real) customer. The Persona is a composite story about your typical customers, made very lifelike.

In looking over my survey, I find that 75% of you who responded are working Business Analysts. You are looking for a wide variety of information, but typically in shorter forms such as tips and examples, rather than classes. You are typically alone in front of your computer when looking for information, and could be anywhere at any time of the day or night. You are looking for an online, interactive, multimedia experience. So let’s take that information and develop some Personas.

I started off by imaging a relatively young person with some work experience who is really comfortable with the computer and internet, and who readily goes online to find information at any time a question arises. Now I imagine some real people and write their stories.

© Christophe Baudot . Image from BigStockPhoto.com

Karen Carmichael is 27 years old. She graduated from a U.S. college with a B.A. in Sociology and a minor in Information Systems. She has worked as a Business Analyst for a large bank in Chicago, Illinois for the 5 years since graduation on a wide variety of software projects. Karen is single and loves sports. She is a member of her company’s softball team in the summer, and an avid football and basketball fan in the fall and winter.

Karen feels that she received a fine education in college, but working on real projects for a major corporation is quite different from her school projects. She has many peers at her bank that she can talk with, but often situations arise that are not easy to resolve.

Karen is quite comfortable with a computer and searching for information on the internet. She really likes to be able to open up a search engine and find the answer to any question right away. The problem with search engines is that she often gets a lot of unrelated information in response to her queries. Karen has a number of sites bookmarked on her computer for her favorite sports teams. She wants to create a similar set of bookmarks for sites that have information for Business Analysts. When she has a question, she can just open a web browser and select a couple of those sites to find the information she needs.

© Mateusz Zagorski. Image from BigStockPhoto.com

Raj Reddy is 32 years old. He graduated from a prestigious Engineering College in India with a B.S. in Computer Science, and worked as a programmer in India for 3 years. He then came to the US and completed an MBA with the goal of managing software projects. He has been working as a Project Manager for a major health insurance organization in San Francisco, California for the last 5 years, taking on roles of increasing responsibility. Raj is married and his wife is in India. He wants to return to India to join his wife and family, and to bring what he has learned about software development to some of the smaller companies in his home state.

Raj plans to be a consultant and carry a computer with a wireless card everywhere he works. He wants to be able to quickly find information on the internet to help him in his job. This will include information about Business Analysis, because he often finds that the roles of Project Manager and Business Analyst overlap, so he needs to know how to do both jobs.

When he is not as busy with work, Raj likes to continually learn new things. It is hard for him to sign up for classes, because he may not be available for every class meeting. So having the classes online in a self-study format is a great solution. He wants to be able to study the material whenever he has time, and does not want to have a deadline for when he has to complete the class. Raj is a friendly guy, and fears he will miss the daily interactions with people at work. He is looking for an online community that he can access any time he is online to chat with other Business Analysts.

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

Now it is your turn.

Post a comment and let me know – does either profile seem like you? Which one and why?

Try writing one or more personas about your customers so that the people and their needs are more real to you.

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

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

With all the focus on Use Cases, it can be easy to forget that they are not the only kind of requirements. Use Cases are very good for some kinds of requirements, but really bad for other kinds of requirements. One of our challenges as Business Analysts is to determine the right way to document the requirements for a particular project.

When starting on a new project, one of the first things I want to find out is “Who or what is driving the requirements for this project?”. I was really reminded of this when I read Richard Denney’s book “Succeeding With Use Cases: Working Smart to Deliver Quality”, a book I highly recommend.

If the project is being driven by changes in processes, then Use Cases probably make a lot of sense, since they are good at describing processes. But you could also use User Stories, Scenarios, Flow Charts, or Test Cases to describe processes. Which you choose will depend on corporate culture and the software development process that is used on your project.

In this case, find out what is driving the process change. If the process change is coming from the way that people work, then you can find requirements by talking to the people or watching them work. If the process change is coming from a technology change, then you may need to start working on the requirements by learning about the new technology. I worked on one project which was to design software to run on hardware that tested IC chips. The source of my requirements was the tests that had to be run on the IC chips. I documented those tests as Use Cases because that is what the customer wanted me to use for requirements.

If the project is purely a change in underlying technology, then a lot of your requirements will be the non-functional requirements (often called FURPS). You might have to write these requirements as formal “Shall” statements. Look over a template for a Supplementary Specification for ideas of the kinds of requirements you might need.

For example, if I am installing COTS (commercial off-the-shelf) software, then I do not need Use Cases for how the software works. I might need Use Cases for how we will use the software in our company, if that information is not obvious. But I really need to know other kinds of information, such as how many users will use it at a time, what response is required, how many transactions per second it will have to handle, how many records will it have to store and process, and what kind of security is required to use it. I will have to talk with the folks in Enterprise Architecture to find any restrictions on where or how it can be installed. There may be a need for a new server, so I have to find out the contraints such as what platforms are allowed, or how much money we can spend on it.

In embedded systems, you may find that truth tables or state machines do the best job of describing the requirements. In this case, there is probably no human interaction, and the processes are all closely related to the hardware and how it works. A truth table or state machine is a good way to describe the different states of the system and how it is allowed to change.

Here are some ideas for kinds of things I have seen used (successfully) as requirements for different kinds of projects. Consider these to see if they are appropriate for your projects:

• Use Cases
• Shall requirements
• Test Cases
• User Stories
• Scenarios
• User interface designs
• FURPS requirements
• Prototypes
• Flow charts
• Activity Diagrams
• State Machines
• Truth Tables

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

Now it is your turn.

How do you decide what kinds of things to use for requirements on your projects?

What other kinds of things have you used for requirements for your projects?

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

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

• How would you start writing out a test plan?
• I want to know the IT skills for a business analyst who is starting as a fresher?
• What are the best practices to follow when you start on a new project? What are the most important factors one should address, are there any templates/checklist available to streamline your entry into the new environment?
• How do you transform business requirements to functional requirements, to the level that the developers can start coding from it?
• Where do you start creating a Requirements Plan?
• Do you have any tips for documenting requirements for a web application? Including creative comps.
• How do you propose handling request for an example of an SRS when interviewing for a BA position?
• To what degree is it appropriate for BA to get involved in screen design? I find it useful bringing Visio mock-ups to the meetings with focal points. Then I reuse those in screen specification document that goes to developers.

There were a few other questions asked as well. To hear all the answers, go to the teleseminar page using this link, and you will find the recording posted for the call. It is in MP3 format. You can download it, or you can listen to it online.
Ask Geri A Question

Enjoy!

Do you like this idea? Is it useful to you? Would you like me to schedule more of this type of teleseminar? Leave a comment below and let me know what you think.

Geri

Some of you may be working on systems with many complex relationships between the parts. These complex systems may be described as a system of systems, or may be described as a product line, or perhaps both at once.

In these cases, you will often find that the requirements of a large, overall system are shared among a number of related projects, each of which implements some well-defined part of the overall system.

In this environment, it is really good to have a team of Business Analysts who work collaboratively on all the requirements of all the projects. Another approach is to have one or more Business Analysts work on the shared requirements, then have Analysts on each project work on the detailed requirements for that project.

If you do not have that kind of relationship between Business Analysts in your company, it is good for everyone to work informally with the Analysts on the other projects to share work as much as possible. This will lead to greater consistency and will avoid wasted effort in developing the same requirements multiple times.

You can use tools such as DOORS or Rational Requisite Pro to show the relationships between the requirements in different projects. For example, you might define a ReqPro project for a set of common requirements that all the projects share, then put a folder in that ReqPro project to store the requirements of one software project. That way, all of the related projects can see what is common and what is specific to a particular project. By reviewing the requirements of other related projects, a project team may find some similarities they can take advantage of.

If you have to keep one version of a set of requirements for one set of projects, and develop a new version of those requirements for another set of projects, then you would likely want to copy the first set of requirements, for example into a new ReqPro project, then edit the requirements in the new project. You can set up a trace relationship between the relationships in the two ReqPro projects.

I do not know DOORS, but assume you can set up similar structures in that tool.

A good book for project teams involved with complex projects is “Designing Software Product Lines with UML”, by Hassan Gomaa.

I have also written a paper with an example of a system of systems/product line approach to requirements. It is called “Requirements Structure in a System of Systems / Product Line Architecture. You can find it at:

http://www.writingusecases.com/wordpress/index.php/
report-requirements-structure-in-a-system-of-systems-product-line-architecture/

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

Now it is your turn.

Are you working on a set of complex, inter-related projects? Are some of the techniques suggested here or in the paper useful to you?

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

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