Category Archives: Foundation series

The foundation series articles provide an introduction to topics that are directly relevant to the other discussions at Tyner Blain. They provide background and context to people who want to read the other articles and appreciate the ideas in them. Topics generally cover business analysis, requirements, and product management.

Foundation Series: Inside A Scrum Sprint

Photo of students in a classroom, learning scrum

People who already use Scrum will only find one new thing in this article – a way to communicate what happens inside a sprint that has proven effective for me.  People who are new to Scrum who wonder “how do things work inside a sprint?” will see how things work in a way that avoids hyperbole and is easy to map to what they already understand from traditional software development processes.

Continue reading Foundation Series: Inside A Scrum Sprint

Foundation Series: SaaS Economics (Software as a Service)

foundation series classroom
There are a bunch of new* ways of selling software these days.  SaaS (Software as a Service) has been in the consumer space for a while, and is making significant inroads into the enterprise software space today.    If you’re considering purchasing or using software, you should understand what SaaS means and how it is different from the software products of the past.*
Continue reading Foundation Series: SaaS Economics (Software as a Service)

Foundation Series: The Difference Between Correlation and Causality

classroom setting
One of the most common mistakes people make when looking at data is to jump to conclusions about the data. We all live in a world of cause and effect. It is only natural that when we see data that appears to show cause and effect, we assume that it does. But it often doesn’t. This article shows the difference between cause and effect relationships and correlated data.

Continue reading Foundation Series: The Difference Between Correlation and Causality

Foundation Series: Intro To Utility Curves

economics class

Utility is an abstract concept usually relegated to economics. What is it? How does it work?

Definition of Utility

The economic definition of utility is

An economic term referring to the total satisfaction received from consuming a good or service

The Free Dictionary

That doesn’t helps us very much – but visuals make this concept strikingly clear.

Consider money. Everyone likes money. People derive satisfaction, or utility from money. The more money they have, the more satisfaction they get from it.

utility of money

Note that the law of diminishing returns is a factor here. As someone acquires more money, the same size of increase in money does not result in the same size increase in utility. $10,000 would provide a lot of satisfaction to someone working at minimum wage. It would provide much less (but not zero) satisfaction to a billionaire. That’s the law of diminishing returns.

Looking at another concept – leisure time. When someone increases their leisure time, it increases their satisfaction.

utility of leisure time

Again, we have the law of diminishing returns. An extra hour of leisure time in a week is very valuable to a single parent working two jobs and raising three kids. That same hour is less valuable if the person has no responsibilities or time commitments.


While both graphs make sense, what they can’t tell us is if someone would rather have more leisure time, or more money. When we present this as a tradeoff, we need a way to describe how people make those tradeoffs.

Our intuition is that people with a lot of free time would rather have more money, and people with a lot of money would rather have more free time. That’s good intuition. When we graph leisure time versus money, we have a utility curve.

utility curve of time vs money

Economists also refer to this as an indifference curve. For someone who is on any point on the curve, they are indifferent to being on any other point on the same curve. When a person has very little money, they will trade a lot of leisure time for more money. When they have a lot of money, they will trade a lot of it for a small increase in leisure time.

This is one of the reasons our economy works. People with a lot of time sell something cheap (their time) to people with a lot of money, who will pay dearly for something that is expensive to them (their time).

Not everyone has the same shape of utility curve.

utility curve shapes

Some people inherently like money more than time, or vice versa. Or a person’s situation is such that they temporarily shift their values. Each individual has a unique curve at a unique point in time. And for that person, all points on the curve provide equivalent satisfaction.


OK, understanding tradeoffs is nice, but what we want to understand more is how to improve the human condition. Products are not very compelling when people are indifferent about buying them. How do we make people want to buy our products?

People want to increase their utility. If someone is indifferent to trading an hour for a dollar, they would be excited to trade half an hour for a dollar. Conversely, they are uninterested in trading two hours for a dollar. Graphically, in addition to being indifferent to all points on their curve, they are excited about all points above their curve, and uninterested in moving to a point below their curve.

increasing utility

Rational people (and economists make a point of excluding irrational people from most of their work) will at least be content, and usually prefer to increase their utility.

Why Indifference Curves Never Intersect

You’ll notice that the two curves in the figure above are never cross each other. Indifference curves never intersect, because by definition, all points on the same curve represent equivalent satisfaction. If two curves were to overlap, then that would create a graph (for a single individual) that looked like the previous graph (with red and green curves).

Pick a single point on the “Money” axis. There are two intersections along the “leisure Time” axis – one each for the red and green curves. The red data point must have the same utility as the place where the curves cross. The green data point will also have the same utility as the place where the indifference curves intersect. This would require both the red and green data points (with different values for “leisure Time” and identical values for “Money” would represent the same amount of utility.

That would violate the premise that “more leisure time is always better, when all else is equal.” This also hilights a limitation of using utility curves – they only apply to monotonically increasing functions. Only when “a little bit more” is always better, can a utility curve be drawn.
Practical Application

This is fine, if theoretical. How do we use this as part of developing great software?

Now that we understand how people treat tradeoffs, we can look at prioritization of requirements. The key is to recognize that there are tradeoffs. As creators of software, we are faced with internal tradeoffs. We can only accomplish so much. We can only release a certain number of features in a given timebox. And we make those tradeoffs based on ROI, or our perception of the balance between costs and return.

Sometimes return is measured in purely financial terms. Sometimes, that return is measured in utility. Consider the decision process around a set of usability requirements. Should we make the application easier to learn, or faster to use?

A utility curve helps us visualize this tradeoff.

speed of learning vs ease of use

The answer is some of both. But we have to balance the need to get past the suck-threshold with creating word-of-mouth marketing and driving user adoption by designing for the competent user. Understanding that each user has their personal set of tradeoffs helps us make these decisions.

Foundation Series: Inbound and Outbound Product Management

Product Management Class

Inbound product manager or outbound product manager – what is the difference? We’ll look at the overall role, and the breakdown of responsibilities.

Product Manager Role Definition

More often than not, people talk about product managers without the qualifier of inbound or outbound. We wrote an article last spring where we discussed the role of the product manager. Michael Shrivathsan defined the role of product management as being split into six areas:

  1. Market Research
  2. Product Definition and Design
  3. Project Management
  4. Evangelize the Product
  5. Product Marketing
  6. Product Life Cycle Management

For more details on those six areas, check out our earlier article, as well as Michael’s article.

Everywhere At Once

The product manager is responsible for interacting with customers, marketing, and sales teams. This communication helps the product manager develop an understanding of the market. The product manager also researches the market – understanding competitors and existing products. From the understanding he gains, the product manager can identify needs and opportunities.

The product manager then works to turn this understanding of market needs into a set of requirements that drive the creation of a product.

Product managers shepherd the product through its life cycle. Product managers identify how the product will evolve and adapt to changing market needs. The product manager may drive the evolution of the product to compete in additional markets.

Product managers also help prepare the company to successfully sell the product. They define strategies for attacking the target market. They help the sales team understand what the product does, and how to position it against competitors. And they support the sales team in the field.

How do we split this up into inbound and outbound?

Inbound Product Management

The inbound part of of the job focuses on understanding what the product needs to be.
Inbound activities include

  • Understanding the market needs and our capability to meet them.
  • Defining a product strategy to meet those needs.
  • Planning the creation of the product, including documenting requirements.

Outbound Product Management

The outbound part of the job focuses on making sure that the product is a success in the market.
Outbound activities include

  • Defining a go-to-market strategy.
  • Preparing the sales team with an understanding of the product and market.
  • Supporting the sales team in execution with a focus on multi-customer activities.


Inbound product management is more about listening, and outbound product management is more about talking.

– – -Check out the index of the Foundation Series posts for other introductory articles.

Foundation Series: JAD Sessions

jad session

JAD is an acronym that stands for Joint Application Design. JAD sessions are collaborative meetings where the customers meet with developers to determine what the product needs to be or do.

JAD Beginnings

Chuck Morris and Tony Crawford of IBM created the idea of JAD sessions in the 1970s (Yatco). JAD sessions were designed to gather good requirements and specifications. JAD sessions are often referred to as JAD workshops. JAD has been used as a name to describe brainstorming sessions, formal requirements gathering sessions, and even interface design meetings.

Today, JAD is commonly used for strategic business planning, strategic IS plans, IS architecture definition, re-engineering business processes, detailed system design, process and data modeling, and project management.This might be the broadest application of JAD so far.

Mei C Yatco

Although different people use “JAD” in different ways to solve different problems, there is a common theme – JAD sessions are facilitated requirements gathering sessions.

JAD Benefit

JAD sessions are believed to reduce the time required to gather requirements and develop software. At the time of their creation, JAD sessions were certainly more cost effective than existing “build, feedback, fix” cycles. It isn’t clear if JAD sessions themselves are more effective than other requirements elicitation techniques. JAD sessions are probably best used as one of many tools for gathering requirements.

JAD Session Structure

A JAD session has a facilitator, a scribe, participants and observers.

  • The Facilitator – Guides the participants through the process of gathering requirements.
  • The Scribe – Diagrams models, takes notes, records information.
  • Participants – Business users and subject matter experts (SMEs) who contribute the content in the session.
  • Observers – Developers who observe the process.

There are 9 steps to a JAD session (wikipedia):

  1. Identify project objectives and limitations
  2. Identify critical success factors
  3. Define project deliverables
  4. Define the schedule of workshop activities
  5. Select the participants
  6. Prepare the workshop material
  7. Organize workshop activities and exercises
  8. Prepare, inform, educate the workshop participants
  9. Coordinate workshop logistics

More Reading

A top rated JAD book at Amazon is Joint Application Development by Jane Wood and Denise Silver.

[Update 2007/02/08.  I have really been enjoying the book that Kevin reccommended in the comments below – Requirements by Collaboration: Workshops for Defining Needs by Ellen Gottesdiener.  Thanks Kevin for the great tip!

Foundation Series: Data Dictionary Definition


What is a data dictionary and how is it used when communicating and managing requirements?


A data dictionary is a collection of the definitions of the structure of information that is relevant to a set of requirements. That’s a lot of words for a simple concept. We need to know (and constrain) a set of information about some business element when managing our requirements. We use a data dictionary to define what that information is, and any constraints on how it must be used.

Viewing The System

When using object oriented analysis (OOA) as part of defining requirements, we represent business concepts as objects and processes. For example, an order management system might define orders as having line items and customers. We can represent that information graphically with a UML diagram like the following:

uml diagram

In prose, we could also capture the same information as follows:

  1. The system shall include a representation of customer orders.
  2. Each order will have a single associated customer, and each customer can have multiple orders. Note that a customer is not required to have any orders.
  3. Each order will have at least one, and possibly multiple line items. Each line item is uniquely associated with a single order.
  4. Each line item represents a single product. Note that a product is not required to be represented in a line item. A product can be represented in multiple line items (even within the same quote).

While this diagram tells us about the structure at a high level, it doesn’t tell us enough information to go implement the solution. What exactly is a line item? What information does it contain? And what format must that information be in?

A Dictionary Entry

We could create a data dictionary entry for the line item object as follows:

Line Item

A line item represents a portion of a customer order that describes a product being ordered, as well as the quantity of that product being ordered. Each line item must include the following information:

  • A reference to the product being ordered, using the product ID per constraint X1. [Note, the constraint is imposed by the existing product data management system, with which our software is required to integrate.]
  • The quantity of the product being ordered, where the quantity is a positive integer. [Note, we would include a maximum value, if there were a constraint imposed by some other part of the system.]

Note that we have not specified that a line item includes a price. It is very likely that a line item would have a price, but we would be specifying implementation details if we did. Pricing may be done per product, or may be unique for each product for any given customer. Discounts may be applied based upon quantity of products in a line item, or dollar amount for an order. Discounts may be applied based upon all products ordered by a customer over a period of time. These different possibilities are a function of the requirements of the system.

When those business requirements are defined, they will dictate the ownership of properties by business objects. With that information, we can include the data as appropriate. For example, a list price property may be defined for the product object, or a customer-price may be defined for a line-item as a function of (product, quantity, customer). We would add that data as part of the business modeling. Note that this is a description of the problem domain, not a description of the implementation.
Another Data Dictionary Example

Here’s an example of a “Customer”

A customer represents the business or person for whom an order has been placed. Note that all character fields are to be represented in unicode 4.1.0 or later per corporate policy ABC. A customer has the following information:

  • Name. 50 characters representing the name of the customer.
  • Shipping Address 1. 100 characters representing the first line of the address to which all customer shipments are made.
  • Shipping Address 2. 100 characters representing the second line of the address to which all customer shipments are made.
  • Shipping Country. 50 characters…
  • Billing Address.
  • Customer Contact.
  • etcetera.

This list is intended to show all of the elements of information that must be present in the “customer object” to support the requirements of the system.

Further Reading

Joe, at Seilevel wrote a post back in March with a good explanation of data dictionary entries. As Joe points out, requirements can drive the need for specific information.

For example, my business users have told me that the number of decimal places of each weight value tracked by the system is very important for monitoring and reporting. It stands to reason that other objects and attributes might require the same level of specification. If you figure it out once, you can use it in many places.

Barbara, at B2T Training points out the importance of understanding the details of the data for a system. She also touches on the value of having that information in a separate document.

Many BAs document data as part of the business process or part of the Use Case. Our recommendation is that you document data in a separate part of the requirements package because it is often used in multiple places.


A data dictionary should be defined as a repository of all data definitions like the examples above. Those examples should be referenced in all requirements documents that rely on the defined objects. Requirements documents should not specify the content of the objects, they should defer to the referenced dictionary entries.

Some projects, especially migration projects, have many constraints tied to data formats and structure. These projects will have extensive data dictionaries, and multiple references to entries throughout the requirements document. Other projects will have far fewer constraints on data formats, but will still have explicit structural definitions for business objects (like our line item example).

– – –

Check out the index of the Foundation Series posts which will be updated whenever new posts are added.

Foundation Series: How To Read a Formal Use Case

Use case classroom

Use cases represent the activities that people do when interacting with a system to achieve their goals. Use cases are a very effective tool for communicating and documenting what a system is intended to accomplish. Formal use cases are use cases with a specific structure to represent the information. Knowing how to read a formal use case is important.

Formal Use Case

We wrote previously about formal use cases, covering the pros and cons with a brief overview, as part of our use case series. In this article, we focus on the elements of a formal use case, and how to interpret them.

When using a structured requirements approach to creating software, use cases represent the activities of classes of users, as they relate to the software being developed. Each goal, or market requirement, will have one or more use cases that support it. The easy way to think about it is that for a company to achieve a goal, someone has to do something (Make the Sale, Answer the Support Call, Update Account Information, etc). The use cases capture those somethings.
Here are the elements of a formal use case, with explanations:

Meta data

This is the information that identifies when the use case was first written and by whom. It may also include revision information, who made the changes, what was changed, and when and why it was changed. Revision history is a common meta data element in most business documents – we just normally don’t call it “meta data.” That’s an example of software jargon.


The title of a use case is more than just a heading like “My Summer Vacation.” The title is intended to provide enough information to identify what the use case represents without reading the use case. This can be useful when getting an overview of a planned project, validating requirements, or when scanning use cases as part of reviewing materials. The title should provide enough information for someone conversant in the domain, while being short. The ideal length is between 4 and 8 words and is a sentance fragment. Anything longer than a sentance is a horrible title. The format is subject verb object. Someone does something to or with something else.
Some examples:

  • Pilot performs pre-flight safety check.
  • Author adjusts plot element timelines.
  • Accountant reconciles accounts-receivable ledger.


A brief description of the activity represented in the use case. One to five sentances – no more than a single paragraph – describing the activity or process represented by the use case. The description does not include the full details, but does provide the “next level of insight” into understanding what the use case covers. Someone who is not experienced in the domain can get a base understanding of the contents of the use case from reading a description.
Some examples:

  • A pilot peforms an FAA mandated list of equipment and operational inspections prior to every flight. All inspections must pass before the flight is allowed to take off per corporate policy.
  • An author will review the timelines, or sequences of events for each plot and subplot within their novel. The author is assuring that the sequence of intended events is internally consistent, and achieves the desired pacing effects for the book. Any needed changes to the timeline are made.
  • Accountants regularly validate that the entries in the accounts-receivable ledger are consistent with the recent sales and current payments. This validation is required for all GAAP public reporting on a quarterly basis, and may be required more frequently for internal management accounting purposes.

Primary Actor

The primary actor is the person who is the subject of the use case, performing the verb of the use case on the object. A use case may have multiple actors but has one most important person. The term actor represents the person who takes action – not someone playing a role. Other actors may be involved, either as participants, or as infrequent or secondary performers of the use case.
Some examples:

  • Primary Actor: Pilot. Secondary Actors:Flight Crew, Sr. Maintenance Technician
  • Primary Actor: Author.
  • Primary Actor: Financial Accountant. Secondary Actor: Financial Accounting Manager


A trigger is the outside event that triggers the beginning of a use case. This is an event that initiates a use case. Many use cases do not have an obvious trigger – and the trigger will be documented as “User decides to do X.” This invisible decision represents the trigger.

Some examples:

  • Pilot receives flight plan.
  • Author initiates review of the novel.
  • It is the first day of the last month of the quarter.


Preconditions are the set of things that must be true for the use case to occur. These represent a contract of sorts – the use case will not happen unless all of the preconditions are met. If a situation is optional, it is not a precondition.

Some examples:

  • Flight plan has been approved.
  • None. (In our example, the author can review timelines before during or after completing a draft of the novel.)
  • Accounts receivable entries have been made in the ledger.


Post-conditions represent the other side of the contract. If the normal course (see below) of the use case has been completed, then these things must be true.

Some examples:

  • The plane has been confirmed to be safe and ready for the approved flight plan.
  • The timeline is updated to reflect the author’s desired result.
  • All accounting entries have been reconciled or identified as being incorrect.

Normal Course

The preferred, desired, or most common sequence of events that represent the use case. This sequence of events must be followable in the solution. If no alternate courses are defined, then this sequence of events must be followed (with no alternatives) in the solution. The normal course is documented as a series of single actor, single action sentences, each with a number.

An example:

  1. Accountant accesses current quarter accounts-receivable ledger information.
  2. Each of the following steps is repeated for every entry in the ledger.
  3. Accountant confirms transaction record matches appropriate other ledger (sales, billing, etc).
  4. Accountant updates ledger to indicate that the entry was confirmed.

Alternate Courses

Alternate course are supported alternatives to the normal course. Each variation is identified as an alternative, and each step that varies from the normal course will be explicitly defined within the alternative course. Each variant step is identified with a number, and all unidentified steps are explicitly defined to be the same as they are in the normal course.

An example:

A1: Incorrect ledger entry identified.

A1.3. Accountant confirms that the ledger record does not match the appropriate other ledger.

A1.4. Accountant updates ledger to reflect inconsistency.

A1.5. Accountant identifies proper value to reflect in the ledger.

A1.6. Accountant updates the ledger with the proper value.

A common naming convention is to begin the numbering with the letter “A” to represent that it is an alternate course, followed by a number indicating which alternative it is. In the example above, we have a single alternate course, “A1: Incorrect ledger entry identified”. In this example, steps 1 and 2 of the normal course are identical, steps 3 and 4 are replaced with new steps, and steps 5 and 6 have been added.

If another alternate course were defined, it would be numbered “A2”, and if it provided an alternate for step 3 in the normal course, that step would be numbered “A2.3.”


Another situation that happens with alternate courses is that a single step in the normal course can be replaced with multiple steps in an alternate course. To represent this, we add a letter, denoting that the steps are all combined to replace a single step. In the example above, we replaced step 4 and added steps 5 and 6. An alternate course may also be documented as follows:

Another example:

A1: Incorrect ledger entry identified.

A1.3. Accountant confirms that the ledger record does not match the appropriate other ledger.

A1.4.a. Accountant updates ledger to reflect inconsistency.

A1.4.b. Accountant identifies proper value to reflect in the ledger.

A1.4.c. Accountant updates the ledger with the proper value.

Exception Courses

An exception course identifies how the system should behave when something goes wrong in the normal course (or an alternate course). If there are multiple exception behaviors, they will be called out as separate exception courses.

An example:

E1: Unable to access accounts receivable ledger

E1.1. Accountant fails to access accounts receivable ledger information.

E1.2. System presents error message to accountant explaining access failure and reported cause of failure.

An exception course is identified with the letter “E”, and otherwise follows the same numbering conventions as the alternate courses.


Sometimes use cases are broken down into smaller, reusable use cases (such as login steps, using a search window to find an account, etc). A reference to another use case from the includes section indicates that the referenced use case is a subset of this use case.

An example:

The use case of “Accountant Prepares Quarterly Report” could include the use case of “Accountant reconciles accounts-receivable ledger”.


Each use case is written to support one or more market requirements (goals). The specific goals that are being supported will be identified as references, or traces.

Each use case is also supported by one or more functional requirements. References or traces to each of these requirements will be identified in this section. These references allow product / program managers to understand the impacts of changes and delays in implementation on the overall product delivery schedule.


All assumptions that are implicit in the rest of the use case will be explicitly documented here.


  • Pilot is certified to run a safety-check.
  • Airport allows pilot to run her own safety-check.


Any text that helps the author or potentially helps the reader is documented as notes. These are not requirements documented in the use case, any more than notes in the margin of a book are part of the book.


With this understanding, reading any formal use case will be a breeze.

– – –

Check out the index of the Foundation series posts for other introductory articles.