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

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 document 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

I get my best ideas for these tips from you, my readers. This tip is a response to a question from Pete McNally on how to document requirements for reports and whether or not those requirements should be use cases.

Use cases are really meant for describing a process or task. If you are going to use a use case to describe a report, what you really want to describe is what job or task a person is doing when he or she creates and views a report. Why is the person reading the report? What will the person do with the information?

For example, assume someone wants to look at an application for insurance. The person wants to create and view a report of all the applications waiting for approval. Why? Because the person is reviewing applications to decide if they should be approved or not. So creating and viewing the report is one part of a larger use case – Determine Insurance Eligibility. A step of that use case would be to get a report of all applications waiting for approval. Another step would be to select an application for review (with any rules you have for which one to select, such as pick the application with the oldest filing date).

Here is a bit of an example to illustrate this concept:

Determine Insurance Eligibility
================================

1. The use case begins when the Evaluator asks the system for a list of all insurance applications waiting for approval.

2. The Evaluator selects the application that has the oldest filing date.

3. The system displays the details of that application.

4. The Evaluator enters the applicant’s age and medical information into the Health Calculator.

5. The Health Calculator determines the health index for the applicant and displays the health index to the Evaluator.

6. The Evaluator enters the applicant’s age, city and state of residence, number and age of dependents, and the health index into the Rate Calculator.

7. The Rate Calculator calculates the rate to be charged for the insurance.

…. There would probably be other steps here.

Alternatives
============
Application is denied

Now, what about step 1? What does that list of applications (report) look like? For that, you would use a report specification.

A report specification is a document that describes a report. In this document, you will describe the information that the user will enter into the system, how the report information is obtained or calculated, and what information is displayed to the user. You might also include a page with the design of the report, showing the various fields and the layout of the report. You can include any rules or algorithms that are used to create the report. You can include restrictions on who is allowed to generate or view the report, or indications as to when the report is run (for example, whenever needed, every night, once a week, once a month, once a quarter).

If there is no process that you can describe that includes creating a report, or viewing a report, then you do not need a use case at all. Just use the report specification to describe the contents of the report. It does not make sense to me to write a use case like this:

Create Quarterly Sales Report
=============================

1. The use case begins when the Accountant selects Generate Quarterly Sales Report.

2. The system calculates and displays the report.

3. The Accountant selects Save Report.

4. The system saves the report.

This use case provides me almost no useful information, and the little information it does provide can be put into the report specification with the other information about the report. There is no point to this use case, so why bother writing it?

Alerts and notifications may similarly fit better into another format.

Remember that not all requirements are use cases. Use Cases are great at describing tasks or processes – but not everything is a task or process. Reports are better described with a report specification document.

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

Now it is your turn.

How do you describe reports, alerts, and notifications? Do you have a template for those types of requirements?

Do you see the usefulness of describing a task or process that includes creating and viewing a report?

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

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