Tag Archives: Foundation series

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)

Flashback: A Year Ago This Week on Tyner Blain [2006-01-20]


Brainstorming – Making Something Out of Everything


Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps).

Prioritizing Requirements – Three Techniques


The less we know about our client’s business, the more the requirements appear to be equivalent. We’ll talk about three different approaches to prioritizing requirements.

  1. Classical. Let stakeholders assign priority to the requirements.
  2. Exhaustive. Explore every nuance of prioritization and its application to requirements.
  3. Value-based. Let ROI drive the decisions. (hint: this is the best one – scroll down if you’re in a real hurry)
  4. [bonus]. A look at how 37signals prioritizes features for their products.

Foundation Series: Unit Testing Software

Unit Testing Class

Testing software is more than just manually banging around (also called monkey testing) and trying to break different parts of the software application. Unit testing is testing a subset of the functionality of a piece of software. A unit test is different from a system test in that it provides information only about a particular subset of the software.

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: Business Process Modeling


Business Process Modeling

Business Process Modeling (BPM) allows us to increase our understanding of business processes and improve communication with stakeholders and implementation teams. Business analysts will create diagrams that represent business processes. These diagrams can be used to elicit requirements, define scope, and improve communication within the team.

We use diagrams because they are intuitive. Diagrams can provide us with an easy to remember and understand visualization of a business process. These diagrams are a type of object oriented analysis (OOA) diagram. A BPM describes a business process, where an entity-relationship (ER) diagram describes business objects. The example in the previous link is an ER diagram.

A Simple Process Model

The easiest way to get a high level understanding of a business process model is to review the diagram for a simple process.
The following diagram represents a customer withdrawing money from their bank account. The customer convinces the bank that she is allowed to withdraw money, then requests the money, which the bank provides (after confirming that it is available). The customer then terminates the transaction.

The diagram does not show exceptions to the process, like having the wrong password, or not having enough funds in their account. Business process models can absolutely demonstrate these situations, and many others. We’ve kept this process simple, as it is an introduction to the concept.

The BPM Example Diagram

atm withdrawal diagram

Swim Lanes and Pools

The first thing you will notice about the diagram is that all the activities happen in one of two areas, labeled customer and bank. These two areas are called pools. While that seems like a silly name, there is a reason for it. There is a type of diagram called swim lanes, designed to show how different people or entities interact. Each person gets a swim lane in which all of her actions happen. In BPM, all of the swim lanes for a single company are grouped together in a pool. In our example, each pool has a single lane.

In our diagram, there are two pools – one for the customer, and one for the bank.

Flow Objects

Our diagram includes examples of three flow objects: events, activities, and gateways. Events are represented as circles. We have starting events (triggers) at the top of the diagram and ending events at the bottom. Activities are drawn as rounded rectangles. An activity can be a single task (like “confirm logout”), or they can represent an entire sub-process. Our simple example shows only tasks.

Gateways represent points in the process where the flow can separate or combine. The diamond is the symbol used to represent a gateway – and it is common to see it in a flow chart, showing how a decision can cause a process to go in one of two directions. The two examples in our diagram show flows combining, with a “+” symbol inside the diamond. This implies that both inputs are required for the process to continue. For example, the steps “Deliver Cash” and “Update Account Balance” must both be completed before the sytem can “Receive [the] Logout Command”.

Sequence Flow

The solid arrows that connect all of the items within each pool are called sequence flows. They represent the flow of the process from one flow object to the next. Notice that there are no sequence flows from one pool to another. These solid arrows can cross swim-lane boundaries within a single pool, but never across pool boundaries. Since our example has a single swim lane in each pool, we don’t see this.

Message Flow

The dashed arrows that cross the pool boundaries are called message flows. A message flow represents communication between two entities. In our example, the customer sends a message to the bank asking for $100. The bank sends a message to the customer in the form of $100.

A Lot More

There are a lot more details to BPM. We’ve left them out to keep the introduction simple (and “brief”).

BPMN Standard

There is a standard notation to use in business process modeling, called BPMN. Business Process Modeling Notation is the industry standard for drawing diagrams. By using the same notation, every diagram becomes easier to read. All of the official documents can be found at www.bpmn.org.

This site has tutorials, the official standard (BPMN 1.0 [Feb 2006]), and other documents. There is even a visio stencil ([removed dead links] [Update:  Thanks Andy!] The links to the visio templates you have are dead but I found the updates. Updated links as of 17-July-2012 are: Visio 5Visio 2002Visio 2003) that can be used to draw diagrams consistently with a minimum of fuss.

– – –

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

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.

Foundation Series: Basic PERT Estimate Tutorial

estimation classroom

PERT = Program Evaluation Review Technique

PERT is a technique for providing definitive estimates of how long it will take to complete tasks. We often estimate, or scope, the amount of time it will take us to complete a task or tasks. PERT allows us to provide not only an estimate, but a measure of how good the estimate is. Good estimates are a critical element in any software planning strategy. In this post, we will present an introduction to using PERT, explain how it works and how to interpret PERT estimates.

Continue reading Foundation Series: Basic PERT Estimate Tutorial

Foundation Series: User Experience Disciplines

requirements classroom

What the heck is UX?

UX, pronounced you-ex, is the shorthand for user-experience. It represents the science and art of tailoring the experience that users have with a product – in our case, software. UX is a relatively new term, rapidly overtaking HCI (human-computer interface) and CHI (computer-human interface) as the acronym du jour. In some circles it is known as human-factors engineering, applied to software design. There are several disciplines within this field, we’ll introduce each of them.

We talk about the different roles within this field in several posts throughout Tyner Blain. The following are introductory explanations for these roles.

Information Architecture (IA)

The study of information and it’s presentation to people. Also the study of how people interact with information. Many software packages allow users to manage complex information. Information can be presented in ways that make it easier for people to absorb and understand.

As a very simple example, imagine a website that allows you to research the cost of living in different cities in the USA. There are thousands of cities in the country. IA helps with designing a user interface that allows users to get information for a specific city. An IA specialist would recognize that cities can be organized by state. In fact, cities in different states can have the same name, like Springfield, Missouri and Springfield, Illinois. But two cities within the same state won’t have the same name. This insight can be applied to present a design where the user selects a state first, which then filters a list of the cities within that state.

A corporate internet may really be the combination of several different standalone websites – a company news bulletin or blog, an interface to the HR system, a download center for installing corporate-approved software, an email directory for the company, etc. IA specialists will determine how to organize all of these functions so that employees can intuitively find what they need and get as much benefit out of the site as possible.


The study of what makes software easy to use or hard to use. A usability specialist will look at the tasks that a user needs to perform, and analyze the most intuitive or efficient ways to perform them. Think of the sequence of steps that you take when adding a graph of data in Microsoft excel. There is a wizard that walks you through a series of questions in order to create the graph for you. A usability specialist determined the best sequence in which to ask and answer those questions.
Usability specialists will also make holistic assessments of how an application or suite of applications behave. This helps users gain competence or mastery of software more quickly. All of Microsoft’s applications use the same approach for opening and saving files (same menus, same shortcut keys, same dialogs, etc). This is the result of usability analysis.

A usability specialist will also be the person who determines how to make software great for novice and experts alike. This is critical to having successful software – the experts are the people who will promote your software for you, but they won’t become experts unless they survive the novice-user break-in period.

Graphic (or Visual) Design

Some people erroneously think of visual designers as the people who make software sexy. The can certainly do that, but graphic design is as much about creating emotions for the users, consistency of presentation, and establishing elements of brand as it is about sexy. This is what makes a Macintosh look like a Macintosh (while usability specialists make it great to use).

A graphic designer can create a set of consistent icons that make an application feel professional, and make the user feel whatever the designer wants. Graphic designers can make the user interface feel different enough to create a notion of uniqueness and branding (association of the images with the product or company), while also keeping them consistent enough with “everybody else” that users know what to do. Another technique is to create an affordance visually. An affordance is an image or element that suggests an action. A dial says “turn me” while a slider says “slide me.”

This can be very subtle and very powerful.

boring scrollbar

Think about scrollbars for a second. Most scrollbars have a pretty boring look. There are tiny up and down arrows at the top and bottom – which create an affordance that says “click on me and the window will move up (or down). That’s good design. There’s also a grey bar in the middle. In some user interfaces, the size of that bar is proportional to the amount of the content that is currently visible. This gives the user some insight into how much content is hidden – another good visual design. A user can also click and drag the grey bar up and down to move the contents of the window. There are no visible cues that this would work, a user would have to be shown that this works. Another example of “hidden” functionality is the ability to click in the light grey “background” of a scrollbar – it causes the contents of the window to page up or page down. Again, without training or an errant click, people would not know this.

cool scrollbar

If we make a tiny change to that scrollbar by adding a few lines in the center, we create a tactile effect – implying that the user can “grab” it with the mouse. This scrollbar screams “grab me”. Subtle, but powerful.

Interaction Design

Interaction Designers are a different breed.  They focus on the software at a higher level, using a goal-driven process to focus on the intent and objectives of the users.

– – –

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