Author Archives: geri

Information – Kind of vs Form of

Author: Geri Schneider Winters

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
  • Prototypes
  • Flow charts
  • Activity diagrams
  • State machines
  • Truth tables
  • Report Specifications
  • Data Dictionaries
  • Data Models
  • Domain Models
  • Object Models
  • Business Requirements
  • Business Rules


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?


What is Analysis?

Author: Geri Schneider Winters

As Business Analysts, our job goes far beyond being a note-taker, in other words listening to people talk, writing down what they say and calling it requirements. Notice that the term Business Analyst implies that we analyze. We need to analyze requirements and information and that is some of the skill we bring to the table. Andrew Midkiff and I were having lunch the other day and discussing what analysis means to us as working Business Analysts. And we came up with at least a couple of different things that a Business Analyst should do that are called analysis.

Andrew thinks of analysis as Requirements Analysis. So I asked him what he meant by that. A lot of people use that term, but what do they mean? He said Requirements Analysis is looking at the information that you are provided and analyzing it. It is a process where you probe and question to tease out the actual business needs that require a solution. You should be asking these kinds of questions:

  • Where is there a lack of information?
  • Where do you have not enough detail?
  • Do the requirements as they are given to you make sense, i.e. are these truly things that are required of the solution?
  • Does the information you were provided describe actual “requirements” in a business sense or something else, such as solution?
  • As you compare all the requirements and use cases you have collected to each other do they make sense as a whole? Is this a cohesive, accurate description of the project?
  • Has the stakeholder given you true requirements of the system, or rather a description of how things work today?

In this kind of analysis we really want to probe and question. I remember one company I worked for, an insurance company, there was a project to create a system to use to input applications for insurance. They were going to store information about the subscriber using a unique identifier, which was a good idea. So there was a requirement – “The system has to uniquely identify the subscriber”. But then they were going to store dependents of the subscriber by first name, because they assumed that would be unique. I probed and questioned, I asked them does this make sense. I gave some examples. Look at the example of George Foreman who named all of his children George Foreman. In a more common example, my sister was married and had a daughter she named Heather. She was divorced, and remarried a man who had a daughter named Heather. So now there were two Heathers in the same family. In both of these cases we have direct dependents of the subscriber who have the same name. This shows that the requirement to identify dependents by first name was a poor one. The requirement was rewritten as – “The dependents of a subscriber have to be uniquely identified within that policy.” As an Analyst it is my job to question that kind of thing, to really think about what I am being told. To question it and probe and make sure it really does make sense.

In a different perspective from Andrew’s, when I think of analysis I tend to think of information analysis. This is where I like to use something like a class diagram to show pieces of information and the relationships between the pieces of information. And I like to use a state diagram to show a particular piece of information and its states. What I am looking for is how the information changes over time and what causes those changes to happen. I’m not so interested in finding all the attributes of the class (or piece of information), but rather I want to know what about that information causes changes in my business process (or what in my business process causes changes in the information).

When I do that information analysis, I’m really looking at a perspective that cuts across the use cases. The use cases each describe individual processes. Then the information analysis goes across those processes to show how each of those processes contributes to some change in the information. This is also how I’m finding more business rules or triggers about what happens in the business over time as information progresses through the company.


Post a comment and let me know – when you think of analysis, what do you mean by it?

Are your thoughts more like mine, Andrew’s, or something different?


Using Personas

Author: Geri Schneider Winters

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

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

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.


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.


Use Cases Are Not the Only Requirements

Author: Geri Schneider Winters

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


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?


IT Project Success Rates

We’ve all seen the surveys that talk about how miserable the industry is in general at doing software projects. Failure rates of up to 85% are commonly sited. Have you ever stopped to ask “What is the definition of failure?”. Scott Ambler did, and once you define failure (or success), you get a much different picture of the industry in general.

Think about it for a minute – how would YOU define success for your projects?

When Scott asked that question, here is the result based on 600 respondents:

In short, we appear to value delivering high-quality working software that meets the needs of our stakeholders in a cost effective manner while respecting the needs of the people involved with the project. This is more important to us than building something to specification on schedule and on budget, regardless of the toll it takes on the people involved.

This is a very different picture of success than the definition used by Standish Group’s Chaos Report … They define success as “on time, on budget, meeting the spec”, but that definition doesn’t seem to hold when we ask people what they actually value.

So specifically, how did the IT industry define project success? From Scott’s survey data:

  • Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.
  • Scope: 87.3 percent said that meeting the actual needs of stakeholders is more important than building the system to specification.
  • Money: 79.6 percent said that providing the best return on investment (ROI) is more important than delivering a system under budget.
  • Quality: 87.3 percent said that delivering high quality is more important than delivering on time and on budget.
  • Staff: 75.8 percent said that having a healthy, both mentally and physically, workplace is more important than delivering on time and on budget.

So using actual success criteria, what is the success rate of IT projects? Is it really only 15%? Well, it is actually much better than that. Again from Scott’s survey results:

Respondents reported that Agile software development projects have a 71.5% success rate, traditional projects a 62.8% success rate, and offshored software development projects a 42.7% success rate.

Notice, these are SUCCESS rates, not failure rates. Quite a different picture of the industry in general.

I think it is important to look at the data yourself. Some of the really interesting information to me is the differences in success definition between different kinds of project participants. For example, the success criteria as stated by project managers is very different than that expressed by the other project participants. It is also interesting to see that the business stakeholders place a very low value on the actual working environment, while that is of great concern to the development staff . What this tells me is that different members of the project team have different goals, which are often in conflict with each other. And what I find in my work, is that those different goals are generally UNSTATED assumptions being made by the different team members. So everyone talks about having a successful project, but no one talks about what that actually means.

I think Scott’s article and survey data are important to open up discussions within your organization about what success means to the various members of IT. You cannot move a boat forward if everyone is rowing in different directions, and you cannot effectively steer a project team to success if there is not agreement on what success means.


I encourage you to look over the report and the survey data and to start discussions in your organization.

For more information, see Scott’s article in Dr. Dobb’s Journal Defining Success and the actual survey data at IT Project Success Rates Survey: August 2007


Book on JAD

Sanjay asks: Please advise an excellent book or training in Facilitation/JAD in Toronto, Ontario, Canada.

While I do not know what is available in Toronto, there is a book I like very much for JAD.

“Joint Application Development” by Jane Wood and Denise Silver.

This book is out of print, but available used through Amazon and other booksellers.

Attracting Highly Skilled People to Your Team

Author: Geri Schneider Winters

I was recently helping a friend staff a fairly large project with a team of very experienced, very skilled people. I mentioned that people were really excited about the opportunity. He asked me “Why are they excited? What is it about this project that makes people want to work on it?”

That led us to a discussion about teams of highly skilled people and what motivates them to want to work on a project.

I believe several factors come into account. Very skilled people like to work on projects with:

  • Other very skilled people
  • Confidence in the success of the project
  • An atmosphere of mutual respect
  • A long enough duration to build relationships

Very skilled people like to work with other very skilled people. You might think, “It must be aweful having all those big egos together.” In fact, I have found the opposite. I have found that when someone is truly very good at what they do, they are very easy to work with. It is the people who are not really all that skilled, who are afraid someone will find out they are not all that skilled, who exhibit the “ego problems” on a project.

This does not mean everyone on the team has to be very skilled, but it does mean that several people should be at the same high skill level. Very skilled people love sharing ideas with other very skilled people. They are typically patient with someone who is really trying to learn. Very skilled people have very little patience with people who claim to be experts, but who are really not that good, and who refuse to listen to anyone else.

Another thing that attracts very skilled people is confidence in the management team. Everyone likes to be on a successful project. Very skilled people are no different. If they believe that the management team has the skills to be successful, and that the project has support from upper management, then they will be very interested in the project.

Long project duration can be appealing, especially for contractors. It is very interesting to work on the whole project rather than just a few weeks at the beginning. You get to find out “how the story ends”. Also, a long project gives an opportunity to build relationships, especially with the other very skilled people on the team.

An atmosphere of mutual respect is critical. When the project team all respect each other and the stakeholders, magic can happen. A cohesive team will outperform other teams every time. An atmophere of mutual respect is vital to creating a cohesive team.

Will there be disagreements? Of course! And those disagreements will sometimes be loud, simply because you have a number of people with very strong opinions. But if everyone has respect for each other, those disagreements will be worked out without animosity and to everyone’s satisfaction.

Where have I seen these kinds of teams in practice?In musical theater with actors, on software projects with developers and with business analysts, in startup companies of various kinds, and on various kinds of team projects at universities. The basic appeal is common in all these situations. Very skilled people like to work on projects with:

  • Other very skilled people
  • Confidence in the success of the project
  • An atmosphere of mutual respect
  • A long enough duration to build relationships


Have you worked on a team with very skilled people? Have you had to put together a team of very skilled people? What do you think motivates them to join your team?


Career Paths for Business Analysts

Author: Geri Schneider Winters

People come to the job of Business Analyst in many different ways. Some people graduate from college and immediately start to work as a junior Analyst for a major corporation. Often a Business Analyst has some years of work experience in some related field before starting to work as an analyst.

You may choose to work for a company in the role of Business Analyst, or you may be a consultant and some of what you do is work as a Business Analyst.

Once you are working as a Business Analyst, what can you expect in terms of career growth? This will depend on the experience you bring to the job and your interests.

BA’s with more experience are generally assigned to larger and/or more complex projects. If you are an experienced BA, you will be often asked to mentor junior Analysts, and depending on your other
experience, you may also be asked to mentor the Project Manager, Software Process Engineer, QA group, or even the Project Architect or Designer.

Over time, you may be asked to work on a small project as both the Business Analyst and the Project Manager. This will introduce you to the job of the Project Manager. You may decide to gain experience and certifications through the Project Management Institute (PMI) and evolve your career into management. You could work your way up through the levels of management as far as your talents and desires take you.

You may decide that you really love the BA job. Over time, you will work on more complex projects with more responsibility. You may then choose to create an internal organization for other BA’s in the company, to provide guidance, internal training, and resources such as templates or guidelines for people in that role.

You might decide you really like teaching and mentoring, so go into jobs such as corporate training or consulting. You would work to train and mentor other Business Analysts in their jobs.

You might become very interested in software development processes and become a process engineer. This tends to be a consulting position. Few companies have software process engineers on staff, though you may find such as position as part of a corporate governance or continuous quality improvement organization.

With your strength in the soft skills of listening, speaking, writing, and meeting facilitation, you can look at other kinds of careers that may interest you more than writing requirements for software projects.

For example, if you really like learning to install and use software tools, you might become a tools person – someone who elicits the corporate needs for software tools, determines what tools are needed, and how they will be used to support corporate goals. You might also be involved in creating manuals and training for company personnel to show them how to use the tools in their jobs.

Maybe business is your real passion, so you use your soft skills to become a business coach. You work with people to discover the goals of their business and how to achieve these goals. This is often a position where you work with small business owners who want to improve or grow their business.

Consider a job as a Product Manager. Note that is product not project. A Product Manager is a marketing person who surveys the market and writes the business requirements for new projects. A Product Manager typically works closely with project teams to achieve good products that meet the needs of the marketplace.

As you see, with experience as a Business Analyst, you have developed a lot of skill in listening, speaking, writing, and meeting facilitation. You may have also learned a lot about a particular domain. You can use these skills to develop further as a Business Analyst, or to go into other jobs such as Project Manager (and higher management positions), Product Manager, Tools Person, Governance, Quality Improvement, Business Coaching, Corporate Training, Mentoring, and Consulting.

What are RUP, EUP, UP, OpenUP, EssUp?

Author: Geri Schneider Winters

RUP describes a process for developing software systems. It seems there are so many variations of RUP, how do you know which is best for you and your organization, if any? What do all those acronyms mean? Where are these things coming from?

RUP is the Rational Unified Process. This process is a combination of two earlier processes – the Rational Process and the Objectory Process. When Rational Software merged with Objective Systems in 1995, they began the work to merge their software development processes. This new merged process was released in 1997 as the Rational Unified Process or RUP.

RUP was designed to cover everything known at that time about how to develop software – from very large systems to very small systems. It was expected that users of RUP would customize it for their project and work environment.

RUP describes software development in terms of four phases: Inception, Elaboration, Construction, and Transition. RUP also describes software development in terms of nine disciplines: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.

Not everyone agreed that RUP was complete or correct. Scott Ambler in particular discussed a lot of what he thought was missing in the RUP. In 2005, he and his partners released a book called the Enterprise Unified Process or EUP. This book described the missing elements of RUP. In particular, Scott added a fifth phase – maintenance – to the project lifecycle.

Unified Process or UP, was a request for proposal issued by the Object Management Group. They were thinking of creating a standard for a meta-model process – or to put it another way, a description of how to create a process. This effort was abandoned, so there is currently no UP standard.

Some people use the term UP to refer to the core elements of RUP: risk managed, use case driven, architecture-centric, and iterative development.

OpenUP is a customized version of RUP which is designed for small and agile projects. OpenUP is an iterative software development process that is minimal, complete, and extensible. It is based on managing risk in an iterative development, use case driven, architecture-centric process.

OpenUP was donated by IBM Rational (I believe in 2005) to the Eclipse foundation and the open source communitee. You may download it free at Here you may also download EPF, the Eclipse Process Framework, which is a tool you can use to develop your own process or modify OpenUP. EPF is a free, open source subset of the IBM Rational tool Rational Method Composer.

EssUP – the Essential Unified Process – is a product of Ivar Jacobson International. It appears to have been released around 2006. EssUP is based on the idea of a Practice. These Practices are based on best practices from RUP, Agile, and process improvement. Practices are grouped into the categories of Iterative, Architecture, Use-Case, Component, Model, Product, Process, and Team.

For example, a Use-Case Practice describes the work flow of collecting requirements in a use-case driven approach. Along with the work flow, the Practice describes the competencies that are required to do the work of the Practice. So if your Use-Case practice requires the use of class diagrams, then one of the competencies required is that someone involved in this process has to understand and be able to produce class diagrams.

EssUP intends that a company would use the basic elements – Practices and Competencies – to describe their processes and to direct process improvement efforts.

RUP, EUP, UP, OpenUP, and EssUp are all variations of a risk managed, use case driven, architecture-centric, and iterative development process. RUP tends to be popular in large, high ceremony projects. EUP is popular with those involved with Enterprise level concerns. UP refers to the basic process that the rest are built on. OpenUP is an open source variation for small, agile projects. Finally, EssUP is a variation focusing on the practices and competencies of software development, each of which can be independently implemented at a company.


Keeping Your Brain Active and Healthy

I like to take a class every so often to learn new things and keep my brain active. July 9-15 I took a class for business owners to learn ways to improve my business. It was listed as an “intensive” and it really was! I worked at least as hard during that 7 days as I have in the past working on a software project near deadline (Sleep? Who needs sleep!). Jason was definitely feeling neglected!

The work from that class spilled over into the following week, so I’m really just now getting caught up with all the things I neglected during the class. It was quite worthwhile though. I learned a lot of really valuable things, and everything was recorded so I can go back and listen again any time I want.

Especially for those of us reaching middle age, continuing to learn and stretch our brains is extremely important to keep our brains healthy in our twilight years. If you haven’t read it yet, check out the book by Cathryn Jakobson Ramin called “Carved in Sand: When Attention Fails and Memory Fades in Midlife”. She is a journalist who researched all the current thinking about memory failure at midlife and beyond, and what you can do about it.

Exercise, take classes, play Sudoku – you aren’t goofing off, you are keeping your brain healthy!

Best –