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
  • FURPS
  • 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?

 

Good Requirements

Author: Geri Schneider Winters

Consider all the different kinds of requirements you write – Use Cases, Business Rules, Security, Database, Performance, Usability, Reliability, Regulatory, “shall” requirements. Good requirements are well-defined. How can you determine if your requirements are well defined?

We often hear that good requirements are testable. This means you have some precise, unambiguous way of determining if the requirement has been met or not.

Of course, you can only define a test for a requirement if the requirement is well-defined! So we are back to making sure that the requirement is well-defined.

One approach is to use critical thinking.

Here is an example of a requirement:
“The system shall be easy to use.”

Think critically about this requirement. Is this a good, well-defined requirement? How will you test this requirement?

Think about that for a moment.

You can see that this kind of requirement is not testable in its current form.

First of all, a system that is easy for a person who has used computers for 10 years, may not be easy for someone new to computers. Is the system easy for someone with Windows experience, or easy for someone with Linux/Unix experience? What does “easy” mean? Does it mean easy to learn, or easy to use after you have learned it? Is it easy because everything is menu driven, or because everything is hot-key driven? Is it easy because it is like another popular software product? Is is easy because specific tasks can be completed in a specific amount of time? Is it easy for accountants to use because it is like other accounting systems? Is it easy for the general public to use because the interface is presented as a checkbook?

To make this requirement well-defined, you have to define who is using the system, and what that kind of person means by easy.

Often early in a project, the requirements will not be well defined. And that is OK at that stage of the project. But you can not produce code that meets the users requirements if the requirements are not clear and precise. The easiest way to make sure the requirements are clear enough to produce code from, is to ask “How will I test or verify this requirement?”

For use cases, many companies test the preconditions and postconditions and not the individual steps of the use case. They consider the individual steps to be guidelines to how the use case will work, not necessarily the actual precise steps. Other companies treat every step as a precise requirement. So the level of precision of the steps of your use case will vary depending on how the use case will be tested.

You might get the idea that you need to work closely with whoever is testing the code for the project. That is correct! Requirements and the tests for the requirements are closely related. They are so closely related, that some companies will ask the BA to write the requirements and test the completed product.

Some projects will start by having someone write the test cases first, then someone will produce the user requirements. This is called test-first design and is a very powerful technique for producting exactly the product the users want.

I know of one very large successful company that does not keep the project requirements once the tests for the project are written. They consider the requirements and the tests to capture the same information, so they throw away the requirements once all the tests for the project are written.

So test-first design is an approach to making the requirements clear, precise, and testable. Test-first design is a large part of the XP process, though is can be used with any process.

Of course, this assumes that the users know what they want! And that is often part of the problem. That leads to another technique for software projects – iterative development. The whole point of this technique is to solve the problem that the users do not know what they want.

You will write some requirements for the project, the requirements that seem to be the best defined. Then create code for those requirements, show it to the users, and ask if this is what they wanted. Typically some of it will be what the users want and some will not.

You will have meetings with your users to determine what to fix in the current product, and elicit another set of relatively well-defined requirements. Then build another version of the product and show it to the users again.

Iterative development assumes that some of the requirements are not clear, precise, and testable, and that they will not be until the users have seen the product and interacted with it.

Some iterative development processes are Rational Unified Process, Agile, and XP.

You can use techniques such as critical thinking, test-first design, and iterative development to improve the precision of your requirements, which will lead in turn to software that meets the needs of the users.

How do you make sure your requirements are well-defined?

Even if you are not responsible for the test cases for the requirements, try writing some tests for your requirements to see if the requirements are well-defined.