Interesting Articles from around the Internet

At OneSpring our employees often pass relevant articles around the company that they locate by way of Twitter or other news sources.

Here are four such articles that we believe are worth taking a look at, broken out by subject area:

Program Management

Agile Program Management
by ScrumAlliance

Requirements

Agile Analysis, Agile Testing: Synergies for Successful Software Solutions
by ebgConsulting

Requirements for the App – Tips and Tricks for the iPad World
by Remzil Kulkarni for businessanalysttimes

Visualization

A Taxonomy of Visualization Techniques
by Jeffrey Heer, Ben Shneiderman for acmqueue

Enjoy!

About the Author

Chris Staufer is a Sr. Visualization Analyst with OneSpring. When he’s not developing innovative ways to document requirements for federal and corporate customers, he enjoys practicing martial arts and spending quality time with his wife. Chris lives in Atlanta.

Never Solve the Same Problem Twice

With the advent of Agile and Requirements Visualization, complex software applications are being developed faster than ever before.  Business Analysts often find themselves in a chase situation where they must not only rapidly produce quality requirements, but quite often solve the same problem again and again.  Solving the same problem more than once can lead to duplicate requirements, which pose a significant problem for project teams in all phases of the Software Development Lifecycle.  This article outlines an approach for addressing this issue at the Enterprise level by developing a series of reusable requirement standards in the form of Requirements Design Patterns that can be leveraged by Business Analysts across the Enterprise.

A Design Pattern is defined by Wikipedia as: “… a formal way of documenting a solution to a design problem in a particular field of expertise.”  Think of a Requirements Design Pattern as a reusable “Requirements Widget” that has prior approval for use within the company, and that can be quickly applied to new situations.

Requirements Design Patterns typically have the following attributes:

1. ID: a unique identifier used when referencing a pattern
2. Version: for tracking changes and approvals
3. Name: name of the Design Pattern, such as “Login Widget”
4. Input: any inputs required for the pattern to function
5. Output: the expected output or result of applying the pattern
6. Description: a detailed description of the pattern, and any clearly defined inputs or outputs relevant to when the Pattern is applied.
7. Requirements Detail: the detailed requirements associated with the pattern.

Example:

ID: 1
Version: 1.0
Name: Login Widget
Input: Username, Password
Output: The user is logged in and taken to their homepage.
Description: The Login Widget is the form present at the top right corner of our corporate websites that allows a user to login to access their homepage.
Requirements Detail: [Detail for the requirements related to the Login Widget.]

A good practice is to review Requirements Design Patterns like any traditional requirements documentation, and then once approval is obtained, to version and track it in a central repository, where Business Analysts can easily access it across the Enterprise.  If your company leverages Visualization technology, requirements can often be documented in the Visualization itself, so that when the reusable component is applied to a new Model, the requirements are added automatically, resulting in significant time savings.

In the fast moving world of software development, it’s tempting to want to simply focus on only solving the problem at hand, rather than developing a solution that can be applied and leveraged by others to solve problems in the future.  Consider it a challenge on your next project to develop some reusable Requirements Design Patterns of your own, and then share and champion them; you would be amazed at the time and cost savings that can result in the future by developing a single reusable solution today.

About the Author

Chris Staufer is a Sr. Visualization Analyst with OneSpring. When he’s not developing innovative ways to document requirements for federal and corporate customers, he enjoys practicing martial arts and spending quality time with his wife. Chris lives in Atlanta.
 
 

Agile in the Federal Government

Agile is a value driven software development philosophy that is lightweight, fast and highly iterative. Agile has been around for over 10 years but has recently emerged in the federal space as a result of the governments 25 Point Implementation Plan which highlights modular software develop to control cost and scope. This realization has made Agile more popular than ever in DC. I am currently evaluating several federal agencies attempting to adopt Agile and have seen patterns emerge that require further analysis and reflection. One such item relates to how requirements are captured and managed within an Agile framework, not only at the development level but also across the organization. Traditional requirements definition and management does not fit well into an Agile model, however, this is the norm for how most large-scale software projects operate, especially if organizations have been following a Waterfall methodology for years.

There are two groups within organizations that must cooperate in order for Agile to work properly. The two groups are Business and IT. The business is primarily responsible for building the business case for a proposed software application, funding, organizational goals, and objectives. IT is responsible for building the application within the defined budget, time, and scope. The problem is that there’s a misalignment occurring between IT departments attempting to implement Agile and the business side that defines what needs to be built as well as internal processes that must be adhered to. In government software development, the business side of a federal agency is still responsible for producing the same artifacts they have always produced as well as passing the same Software Lifecycle Management (SLM) tollgates.   Organizations cannot successfully adopt Agile at the IT level without changing their mindset of how the business side functions. This paradigm has created a disconnect between organizations looking to adopt Agile within traditional business operations.

If you take a holistic approach to the problem then you will start to see patterns and processes emerge at all levels of the organization. One immediate opportunity occurs at the hand-off between the business and IT. The hand-off is when the business passes over their requirements specification for a software application to the IT team to build. If an agency passes traditional requirements specifications to an Agile team the results are typically negative. Most Agile teams will usually want to start over by creating a list of User Stories that covers the requirements specifications delivered to them. This creates a tremendous amount of rework and churn, which usually leads to frustration by the business because they have to rehash what they’ve already spent a lot of time putting together.

The solution is to come up with a decomposition model during the hand-off period. Decomposition is the process in which the business and IT decompose the requirements specifications together to convert requirements into the proper format for Agile. The goal should be for the business to get the requirements 70% complete, then use the decomposition phase to finish off the requirements together with IT. This does several things to improve the odds of a successful outcome while reducing risk. First, it allows the business to further analyze and synthesis the requirements they’ve defined thus far with technical experts. Second, it gets the developers engaged in the requirements discussion earlier as opposed to doing a single hand-off at the end of the requirements phase. Third, it allows team members to build relationships with one another. Fourth, it allows the team to address usability questions and requirements before development begins.

Agile cannot be rolled out in a silo; it must be woven into the organization at all levels. This won’t happen overnight but as long as we can start to identify and address these challenges, the closer we will get to producing more value for the organization and its user community. Bridging the gap between business and IT has been around for decades, however, the advent of Agile has escalated the issue. Change needs to occur at all levels of the organization in order to accomplish the benefits of adopting Agile.

About the Author
: Jason Moccia has over 14 years of experience in the software development field and is a co-founder and managing 
partner of OneSpring LLC (www.onespring.net), where he oversees the Federal business practice as well as Operations. OneSpring helps companies to work smarter by providing an entirely new approach to software requirement definition.  

So What’s This iRD Thing Anyway?

We’re working hard to overcome the status quo in software requirements. I truly believe there are many out there that have resigned themselves to just having to “deal with” the challenges of ambiguous requirements, slipping deadlines, reduced feature sets, and the like. There are reams of documentation that is expected to be read, understood, and approved.

Most of the time, the project team needs to seek this documentation from a central repository, such as SharePoint. While all the documentation may be there, it’s often left to each team member to determine what needs to be downloaded and read. Documents that support other documents are referenced, but the team member is left with the daunting task of trying to keep it all together.

What if there was one “document” that provided all of the information stakeholders needed? What if this document was delivered on a mobile device such as a phone, tablet or e-reader that could be taken anywhere? What if stakeholders, development, QA and others had a customized version with just the documentation they needed? What if the documentation was interactive with software visualizations, walkthrough videos, and collaboration?

Introducing the iRD™ or Interactive Requirements Document™.

Instead of disparate Word & Excel documents, Visio diagrams and other document types uploaded to some sort of repository, the iRD encapsulates everything in a very easy-to-use and very portable format that is targeted to each set of stakeholders. Because no two projects are exactly alike, the iRD is customized for the client, the project and the technology the iRD will be used with.

For example, we are currently delivering an iRD™ for the Department of Homeland Security which will be delivered via Apple iPads. Stakeholders will be able to view and comment on all project documentation, experience a high fidelity visualization of their software, watch walkthrough videos and much more all within a single experience. They will be able to take the entire project with them wherever they go. The feedback so far is nothing short of amazing.

Why settle for the status quo on your next project?

Common Software Tools for Business Analysts

Recently I read a LinkedIn IIBA blog post titled “Putting Together a List of BA Tools”.  As I read the blog, I quickly became fascinated by the quantity of tools that BA’s around the world use to conduct their day-to-day work.  Granted, the blog is not a scientific survey and there was not an equal representation across industries, but I wanted to share some of the numbers I crunched from the blog posts (data as of 02/28/2011):

• Number of Blog Responses: 70
• Number of Unique Industries Represented: 16
• Number of BA Tools/Products Recommended: 47
• Top 10 BA Tools/Products In Use (in order of frequency):
  • MS Visio
  • Enterprise Architect
  • Rational Requisite Pro
  • MS PowerPoint
  • MS Word
  • MS Excel
  • DOORS
  • Balsamiq
  • (tie) Axure, BizAgi, Blueprint Requirements Center, CaseComplete, FreeMind, HP Quality Center, iRise, Mindjet MindManager, MS Access, MS OneNote, Visual Paradigm
• Top 10 Industries That Use the Greatest Number of BA Tools/Products:
  • Management Consulting
  • Software Development
  • IT Outsourcing
  • Financial Services
  • Healthcare
  • Government
  • Pharmaceuticals
  • Industry/Energy/Healthcare Technology
  • Insurance
  • Utilities

The quantity of software products represented by this small and unscientific survey of Business Analysts speaks volumes.  It is obvious that there is little standardization, in terms of software tools, within and across industries.  It is also obvious that today’s Analysts must maintain proficiency in a very large number of complicated technologies.  There is a huge opportunity for thought leaders in Requirements Analysis to introduce new products that are (1) quick to learn, (2) effective across industries, and (3) integrate the best attributes and eliminate the worst attributes from the list of products above.

What software products do you use on a daily basis?  Are they ideal for the job or add frustration to your day?

Visualization is more than just designing screens

Visualization is sometimes used in the context of visualizing screen design only. In my opinion, it’s much more than that. Visualization is a concept, process, and a way of thinking about requirements. Not only can you visualize interfaces, you can also visualize business process flows, navigation, user flows, content structure, data flows, and more.

The idea behind visualization takes place more on the process side of the software development lifecycle. It’s the setting, people, skill sets, and structure around how you elicit your requirements. There are four key components that need to be in place to make it work well.

• It must be highly collaborative. Collaboration is critical throughout the project lifecycle. Working in a silo doesn’t foster the communication needed to be effective using visualization. It’s all about defining, designing, and building together as a group that drives solid performance. It’s critical to have a strong facilitator to lead sessions and to steer the group toward consensus.
• You must have the right talent. What I’ve seen work is the proper combination of software and hard skills. You have to have team members with good to great communication skills. A lot of the requirements are fleshed out through healthy dialog and debates. It’s important to have consultants that challenge ideas and make them stronger. What you don’t want are note takers that simply write down everything you want without bringing in their own ideas. It needs to function more like a partnership as opposed to a client to consultant relationship.
• If possible, you must have the right stakeholders. It’s important to have stakeholders and leaders that are emotionally and professionally committed to solving the problem. They need to be engaged in the project and make decisions quickly. If you don’t have this on your project, the chances of failing go way up. I would make this clear from the beginning if possible and try to get buy-in and commitment from the stakeholders early in the lifecycle.
• You must have the right technology. There’s a lot of technology coming on the market that help facilitate visualization. It’s critical that you find technology that supports your process and people. Don’t let the technology dictate your approach. You need to find the right fit. Cost, training, adoption, and organization change factors usually dictate the outcome.

About the author: Jason Moccia is the President, COO, and Co-founder of OneSpring. Jason has over 14 years of experience in the software development field. In addition to operating as President and COO, he also runs the company’s Federal side of the business. His philosophy of doing one thing better than any other company emanates throughout OneSpring’s core strategy. Jason has worked with numerous Fortune 1000 companies including but not limited to Ernst & Young, General Electric, SAIC, Florida Power & Light, InterContinental Hotels, Deloitte, and SunTrust.

The problem with upfront requirements

Prototyping and visualization technology is starting to improve the way companies define and build software applications. However, requirements management and documentation of those requirements is still antiquated. Most tools on the market are outdated and cumbersome to use. 83% of companies still rely on Microsoft Word and Excel to communicate requirements. OneSpring has worked on over 50 projects ranging from small $20K projects to over $2 million dollar requirements definition projects and has seen first hand what works and does not work.

Most companies follow a documentation centric path to defining software applications where a lot of time is spent writing out text-based requirements. In 2005 we discovered a disconnect exists between what a client said they wanted and what they actually received. We call this the Clarity Curve.

The Clarity Curve depicts the understanding stakeholders and users gain as they start seeing their software project come to life. The problem with this model is that there is a very high cost associated with it. In most cases, once the stakeholder sees what is being developed they typically want to make changes. Changing developed software is 100 times more expensive than catching changes upfront in the lifecycle before code has been written. This is the value proposition we have been successfully selling. Our goal is to create software that allows users to rapidly define, organize, and distribute better and more accurate requirements thus allowing companies to build the right software the first time.

The below illustration shows a traditional software development lifecycle. Notice the increase in understanding at the end of the cycle. It is commonly said that stakeholders and users don’t really know what they want until they can see and interact with it. This holds true for software development as it does for most products.

So how do you improve the Clarity Curve?

The goal is to shift stakeholder and user understanding to the beginning of the elicitation phase. By building visual models, visualizations, and rapidly documenting requirements, you can start to shift the curve to the left. The illustration below depicts what we always try to achieve on projects. This will help you reduce cost, increase clarity, and produce better and more usable software. Use visual representations of your requirements to improve understanding and consensus among your stakeholders.

About the author: Jason Moccia is the President, COO, and Co-founder of OneSpring. Jason has over 14 years of experience in the software development field. In addition to operating as President and COO, he also runs the company’s Federal side of the business. His philosophy of doing one thing better than any other company emanates throughout OneSpring’s core strategy. Jason has worked with numerous Fortune 1000 companies including but not limited to Ernst & Young, General Electric, SAIC, Florida Power & Light, InterContinental Hotels, Deloitte, and SunTrust.

What does product design got to do with it?

What is a product designer doing at OneSpring®? Okay I admit it – interface design was not my childhood fantasy.

I wanted to design cars. It didn’t matter if they were swoopy sportscars crouched low slithering over the street or burly SUV’s ready to tear up a woodland trail, I just knew I loved drawing new ones to capture peoples’ desire. Growing up near Atlanta my dream school was Georgia Tech. I wore Yellow Jackets swag to school at least once a week starting in fifth grade. When it was finally my turn to study on The Flats I was ready to be transformed into some kind of design wizard powerful enough to conjure up electrifying drawings, models and business cases for the next generation of awe-inspiring “futurecars.” Despite wanting to mesmerize the populace with automotive fireworks, I was lost as to how to realize such feats of enchantment. No problem. I would soon learn all I ever wanted to know about that. After a grueling undergraduate journey through deserts of history and literature, over treacherous peaks of calculus, chemistry and physics and through complex, endless swamps of design studios I emerged on the other side with plenty of new knowledge. All of it, however, served one new possession of singular importance – a process I believed in.

I know, I know – a process? Maybe it’s not glamorous, but stay with me. The kid who had wanted to brighten the eyes of millions with sweeping curves and tire smoke had mistakenly wanted to go it alone. I wanted to be the idea guy, the design guy, and the business guy…and all the guys who work for them! Since that naïve time I had become familiar with what it took to actually achieve in three “pick me up and use me” dimensions any sort of designed artifact. I’m here to tell you the first thing it takes is other people. What about the other people? Well, the minds of those other people – the same people a designer needs if he is to achieve his vision – cannot be utilized unless communication is clear. And if we want people’s minds working at maximum capacity, we need to maximize the communication. More on that later. Is that a question I see there in the back?

Where does OneSpring® come in, you ask? Well, as it turns out, I was looking for a job. Yes, those are the sad ramen-eating college senior violins you’re hearing. As I was looking around, I got an email from my academic advisor about a new Atlanta company doing something foreign to me called “user experience design.” Well, not a car company, but I was not too proud to inquire. A week’s passing had me sitting at coffee with a hip young professional this company had dubbed a “Visualization Designer.” That person explained to me a thing of singular importance driving OneSpring® – a process. It wasn’t just any process to them. It was their process, and they all believed in it. You’re seeing parallels, no? Well, I certainly noticed them. Turns out the same things it takes to realize designs in the product space are relevant to software design projects. How so? Well, read on.

Remember I told you there’d be more to come regarding the issue of communication? Here it is. Communication is the reason for this process. What I learned in school is a lesson inextricably baked into the methods employed at OneSpring®. Namely, that we cannot clearly communicate an idea or a concept to a broad range of people unless those people can see and interact with it. For a student of industrial design like I had been, it meant never presenting a new product concept by words alone. Teams of stakeholders needed sketches, renderings, models, prototypes – each more and more like the final implementation as the projects progressed. And when time came to pitch the concept to a jury of clients, there was nothing like a beautiful working prototype to cement ideas. In fact, it was this process of “show me, don’t just tell me” that I had fallen in love with in college.

Coincidentally OneSpring’s field of requirements definition relies on the exact same idea. Your team, whoever you are and whichever type of project you’re undertaking, is not capable of being “on the same page” until the project’s vision is expressed in a visual, interactive format. Your stakeholders, be they users, clients, developers, manufacturers, analysts, or designers cannot fully share a unified vision of your project unless it is present in the room with them able to be passed around and discussed openly. They must see it and interact with it together and share their thoughts. Only in this way can teams write authoritative requirements and developers build accurate systems which need no rework. OneSpring® calls it “visualization.” Now, as a “Visualization Designer” for OneSpring®, I call it common sense.

Webinar: Close the Requirements Clarity Gap

Are you happy with your IT projects? Do you find they never quite meet expectations? During this webinar, we’ll demonstrate how our JAM Session® helps our clients be more innovative, save time and money. We deliver this through gaining technology requirements clarity early using visualization.

Slides