Know Your Requirements!

Often times at Algonquin Studios, clients ask us to improve on their current software solution. The existing solution is either out of date or it simply isn’t giving the client what they need. For the user, changing systems can be a scary proposition. People grow comfortable with what they are accustomed to however, following a routine that you’ve done for years is the safe route. For this reason, it’s very important to sit back and think about what the system needs to accomplish. We want to make sure we maintain the output they are expecting from the software they use on a day to day basis, but keep an open mind on how to get there. In order to ensure this outcome, we spend a considerable amount of time conducting requirements analysis.

During the requirements analysis phase, one of the most important parts of a project, we determine what exactly the client needs are and how we will provide that solution. Time and again we run into the same obstacle of getting the client to see the difference between “what your users have today” and “what do you need the software to accomplish.” Clients often want everything they have today, in addition to the improvements we will provide with our software. Unfortunately, this could cause unnecessary features to be included in the software and add additional costs into the project going forward (training, support, system complexity … etc.). Costs that could be used elsewhere, either for the company or to build out additional features that are needed in the new system.

So, when coming into these requirements meetings it’s best to come prepared. To be better prepared it’s most important to know what is needed, as opposed to going screen by screen showing us everything they have today. There are many other ways to be prepared for these meetings, here are a couple:

Question your users

As a client, when was the last time you asked your user base about the program they use on a day to day basis? Requirements and business needs are always changing over time. Depending on the size of the user base, and the software being used, these questions could vary (and there are many). In the end, the client should find a way to determine:

  1. Which features are being used the most?
  2. Which features are rarely (if at all) used and aren’t needed?
  3. Is there anything you need the system to do that it doesn’t do today?
  4. Does the system provide repeatable work that the software doesn’t handle, costing people time every day?
  5. Are there current features that need to be revised to accommodate current needs?

There are many ways to gather this data.

Is this software internal, used by only a handful of people in your office? Have a meeting to review the software and gather the information firsthand from the users. Come prepared to ask about features that work and those that don’t. Are there any that have lost value over the years?

Do you have thousands of users using the software across the United States? Setup online user groups and invite people to provide valuable feedback on the software. Depending on the capabilities of your software, you can limit the groups to certain sections of the software and provide questionnaires about those sections. This should help you gather all the necessary information to bring to your developers, so we can make sure we build you an efficient, quality application that suits all your needs.

Clearly Define the Inputs/Outputs

Frequently, a screen can be so overloaded that one loses focus on what exactly is needed. Determine all the inputs of the screen and make sure they are all required and are what you need. Next, identify inputs that are unnecessary or misused. Keep in mind that just because they exist today doesn’t mean they’re needed going forward. Additional inputs only cause more complexity.

As important as it is to define the inputs, it’s equally important to define the outputs. Outputs that are currently delivered may no longer be needed or efficient or may simply be delivered differently in the new software; Once again, this is often difficult for a client to understand. Asking a lot of questions in the requirements meetings about those features can help ease the process because in the end, the more inputs/outputs you have the more complex your system will be. Our team of consultants are really good at letting clients know if the value they’ll receive from a feature is worth the effort and, generally, we can determine this during the requirements meeting.

In the end, if the client does their part in determining what’s exactly needed out of a system in order to eliminate all the old, antiquated screens and logic, the better the software will be. This will ultimately save the client in the long run.


Learning From Your Data – Part 2

In part one of this post I reviewed the details of Data Visualization and how it can help you learn for the data that your systems already collect using a simple example. That bring us to the next point:

What about information that’s more difficult to examine?

In his book The Visual Display of Quantitative Information, Edward Tufte states that the “lack of quantitative skills of professional artists” is what makes creating a truly stunning and convincing data visualization difficult. This is why you don’t often see Data Visualizations as outputs of systems; it’s hard enough to design and create a Data Visualization to illustrate a specific point, let alone one that asks the viewer to draw their own conclusions.

Relationships between the individual data points in your system are everywhere. The simple ones, as we discussed, are easy enough to display. But if you can find ways to show the complex ones, you can make a real difference in a business. As an example, I’ll  reference another Visualization by Lee Byron, available on his site This one shows the relationship between words in a poem or limerick:


This Visualization shows the relationships between the phonemes and entire patterns of phonemes.

Byron shows a more complex example using a poem by Shel Silverstein:


These examples probably don’t relate to your business (unless you’re a poet), but they should illustrate how connections between data elements can have a massive effect on your ability to understand how and why something is working.

Where can I find examples?

Here are a few more examples that may show how this sort of Visualization can turn your data into an understandable tool to help you get ahead in your industry:

  • San Francisco – Home Prices
    • Great example of an interactive data visualization. Shows how multiple data visualizations working together can make data even more understandable.
  • Business Statistics 
    • Perfect example of displaying Progress % type KPIs
    • (Note: be sure to try the update button)
  • Cross Filter of Flight delays
    • Interactive example that shows how an data visualization can be used to hone in on the results/data you are looking to find. Think of data mining to determine what set of data fits a specific question that you have.
  • Slope graphs
    • Perfect example of displaying Change % type KPIs
  • Web Server Statistics 
    • Cool example for my industry
    • (Note: you need to use the +new button)
  • Crime in Portland
    • All around good example that shows lots of visualizations that display similar data (i.e. types of crime) by region.

Learning From Your Data – Part 1

Data Visualization is defined as “the study of the visual representation of data, meaning information that has been abstracted in some schematic form, including attributes or variables for the units of information.” But, to boil it down, the term means a graphical representation of data that can make understanding it easier.

I first learned about the concepts behind Data Visualization in the book The Visual Display of Quantitative Information by Edward Tufte. Tufte’s book illustrates (quite literally–there are tons of visual examples) the idea that a picture is worth a thousand words. When I first looked through the work nearly 15 years ago, I was overwhelmed and amazed by how Tufte so easily and simply relayed information using diagrams and I took away from the book a firm grasp on the idea that a graphical representation of data can very clearly articulate a point.

After becoming a software developer I learned about how the theory and practice of Tufte’s concepts can enhance a computer system. David McCandless has a bevy of great visualizations on his site, One such visualization, from McCandless and Lee Byron, is a graphic of Facebook post-break-up status messages by month:


As you can see, this simple graph very clearly illustrates some interesting results (February, March, November, and December are tough months for love) even though it displays the inputs of over 10,000 status updates.

So, how does all of this relate to Software Development? 

As a Development Manager at Algonquin Studios, I spend a lot of time meeting with my clients. The objective of these meetings is almost always to determine the final “outputs” of a system. These outputs can include things like reports, ESIs (external system integration), graphs, printable documents, and customer facing data views and can be thought of as the reason we’re building the system in the first place. If we never established the outputs for a given system all of the inputs–usually time-consuming data entry–would be a waste.

The most important outputs for a system are almost always tabular reports that can show information ranging from first quarter financials, a customer list, or employee performance over an extended time period. Basically, these are the types of reports that help run a business and there comes a point in almost any project when I’m asked to create an “Executive Dashboard” using information pulled from these reports. Because these dashboards can contain all types of information, from trends to warnings about productivity, their information can be displayed as general statistics and/or graphics.

So, how can we use the data in a system to dynamically draw a Data Visualization that will let the user draw their own conclusions about information that’s pertinent to the running of their business? Key Performance Indicators.

There are 3 basic types of Key Performance Indicators (KPIs):

  • Raw Numbers
    • Number of new customers
  • Change %
    • Percent increase in sales over last month
  • Progress %
    • Percent of monthly income target

Each of these basic types of KPIs are related to a goal and there are a set of work items that need to occur to move these items forward.

Each of these KPIs will have a few attributes.

  • Frequency
    • How often can this indicator be measured? Daily, weekly, monthly, bi-monthly or anually?
  • Target
    • Especially important for percentage-based KPIs. When have you hit your target?
  • Thresholds
    • When you want to consider this KPI under a lower threshold
    • When you want to consider this KPI in an “Acceptable” state
    • When you want to consider this KPI over an upper reasonable expectation

And all of this information be displayed in graphical form. Simple bar graphs, line graphs and gauges can tackle these Visualizations with effective results.

Check back for my next post in which I’ll continue this look at Data Visualizations with some more complex examples.