Thinking about Software Requirements

Is your organization getting ready to think about its software requirements? Sometimes when organizations approach us about their software needs, we are struck by how poorly they have thought out what it is they are looking for. We cannot even guess from their few pages of notes what major pieces of functionality they are seeking, or why they are seeking a new system. Other times we find ourselves staring in dismay at a 100 page Software Requirements Statement detailing field lengths and report structures, to which we are expected to respond in detail. These guys have gone to a lot of effort. But both of these documents are nearly useless in the context where they are usually handed to us - where an organization's staff and ours are trying to decide if we are a good match for their critical software needs. It's not a problem of having to much or not enough of a requirements statement. The problem is misunderstanding what requirements are, and what they are for. Following a link in a sidebar of an article in the current issue of Dr Dobbs Magazine, a venerable developers journal, I found a great piece by Karl Wiegers - 10 Requirements Traps to Avoid -that should be a great help to anyone trying to write a requirements statement. Trap 1 is as far as we are going today. It involves failure to recognize the type of requirements you are setting down. Wiegers identifies three distinct levels of requirements. Business Requirements lay out the needs from the standpoint of organizational problems and goals. From this standpoint there is one actor - the org - with one set of needs. User Requirements look at the information system from points of view of the different staff roles within the organization, and specify what tasks each actor demands of the the software in order to meet the Business Requirements. Finally there are Functional Requirements - detailed descriptions of individual functions the software is going to perform in meeting each user requirement. For software selection, keep your focus on your organization, not on the application's buttons, checkboxes, and fields. If the task at hand is to distinguish between vendors, the statement of functional requirements is the wrong tool. Instead your starting point ought to be how the vendor and its software will help you address your key business requirements. Ask the vendor how their tools and their approach will help you meet your organization's articulated information systems business requirements, rather than have them check-off whether or not they have certain sorting abilities in a certain report you may not really need. A focus on the micro level can give you the feeling you are doing your due dilligence, but really you are taking your eyes off the prize, which is selecting the software that best supports your mission.

Nuggets from the Information Hailstorm

One of the more common uses I see my friends making of Twitter is to post a link to an interesting web-based resource. Since the one-line nature of the Twitter post limits the amount of effort that can go into polishing these "miniblogs", I'm getting a virtual hailstorm of information this way. And then there are all the articles, blogs, and videos that my Facebook contacts post every day. There's no way I can begin to keep up with the flood of valuable information my friends are incessantly calling to my attention. Here are some highlights form the past few days... 1. Grantmaking 2.0 link [via Holly Ross at NTEN]. Here's an article posted by Amy Luckey at GEO (Grantmakers for Effective Organizations) that talks about the use of collaborative web tools to strengthen the relationships between funders and organizations. 2. Fixing Wikipedia Articles link [via Michael Gilbert's weekly Nonprofit Online News] More and more often we find that wikipedia is the first place we are pointed to when seeking information about a person or organization online. Suppose you look up your NPO and find incorrect information in the article? What's the most effective way to correct the article? That's what this piece is about. Just changing it yourself is not always the most effective solution, since Wikipedia staff monitor the IP addresses of people making changes and will often disallow an edit from the organization the article is about. 3. Legal Guidance for e-Commerce link [via SBTV.com, which I learned about through a post by Tinu Abayomi-Paul] I'm sure all developers have this happen to them - you are involved in what seems to be the straightforward technical process of setting up an e-commerce site for a client, when the legal questions start. Is a credit card sale binding if the buyer is under 18? What is the legal force of terms and conditions the buyer agrees to by clicking a checkbox? I don't know the answers to most of these. I'm not a lawyer. But the American Bar Association has built a resource to answer your e-commerce legal questions. Built around the kinds of questions that need to be answered when designing and launching a new e-commerce site, safeselling.org is full of answers to questions I'm often asked. [You'll learn for example that courts may consider the size of the font your terms and conditions were in when deciding if they are valid!] image originally uploaded as http://www.flickr.com/photos/sookie/94778946/

Members Only Software for Free! for an Arts Org

We're doing it again. If you are a small arts organization, you might qualify to get our software for free. See the announcement on our web site for the details.

Risks and Benefits

The other day I followed a link on a friend's site to an article about How to Clean up a Broken Compact Fluorescent Light (CFL) Bulb. Turns out that because these increasingly popular bulbs - which use far less energy than old-fashioned incandescents, are made with mercury, there is a small risk of exposure any time one of them breaks. The article gives detailed instructions on how to clean up after such an accident. So often a piece of technology which is a solution to some major problem brings new risk of its own. In deciding to adopt the new technology, we need to weigh the risks against the benefits. Is wind power worth the risk to birds caused by those rotating blades? But the need to manage the risk continues after the decision is made. I often try to talk to our clients about risk management for the Information Technology advances within their organization. There are risks are attached to every positive step you make. Suppose your non-profit is emerging from a start-up period, where pretty much every department had its own little contact management solution, in excel, or access, or ACT. Now you're putting in a system that will provide integrated CRM and other functions for the entire organization. It's a great step forward for you. But it adds some new risks, because now you have a new single point of failure. Actually some of these possibilities could be disastrous. If the new system goes down, or becomes corrupt, or loses data, what will you do? Risks management writers discuss three angles on confronting problems like this. 1) Mitigation: Lowering the likelihood that the unwanted condition will occur. 2) Monitoring: Detecting as soon as possible if an unwanted conditions has occured. 3) Resolution: Managing the situation if it does occur. For example, suppose we identify the risk of accidental corruption of data through user error as something we are concerned about. Here's an example fresh on my mind - the other day a user of ours changed the last names of a good many of their contacts to LastName. Oops. How can we address the risk of this kind of accident? Mitigation might mean: making sure users are properly trained on risky database operations and that most users do not have access to perform them. Monitoring might mean maintaining a log of all database changes for a day that can be glanced at by the db admin for any peculiar activity. Resolution might mean having a plan and utilities in place for selective restoration so data can be loaded back from a backup without losing all the other valid data entry made that day. Risk Management should be included as a part of the planning for each of your technology projects. The book that many years ago sparked my interest in Risk Management is Waltzing with Bears, by Tom DeMarco and Timothy Lister.

Voice to Post

I'm playing with the Voice2Page system that I stumbled across today... It let's you add a voice message on any page -- using the telephone as the recording instrument. Once you have a message you can change it, like changing your voice mail, without touching the code on your page. Sort of cool.

8 random facts about myself

The lovely Soha El-Borno of the Wild Apricot blog tagged me to play the eight-random facts about myself meme. First the rules: 1) Post these rules before you give your facts 2) List 8 random facts about yourself 3) At the end of your post, choose (tag) 8 people and list their names, linking to them 4) Leave a comment on their blog, letting them know they've been tagged Then the facts: 1) One of my great passions is playing old-time fiddle. Every summer for the last seven years Doria and I have gone to Ashokan Southern Week for a musical vacation. Well almost - this summer we went to Ashokan Western-Swing Week instead. 2) While my usual whisky is Jack Daniels because it is better suited to my budget, I adore Talisker - the older the bottling the better. 3) I'm a great fan of the films of Peter Greenaway - especially Prospero's Book's, his envisioning of The Tempest, with the late John Geilgud speaking ALL the roles. 4) I devour mystery paperbacks - recently Doria and I tore through all of Lisa Scottoline's books in less than a month. 5) From 1972 to 1975 I worked at the Berkeley Free Clinic, in Berkeley, Ca. It was my first non-profit, but back then then we thought of it as an alternative institution. 6) In high school my friends and I put out a magazine called Odd. It was issued in a single copy, usually with elaborate covers made of an unusual material - foam rubber, or hinged stainless steel. Each issue passed from hand to hand down the subscription list until it was confiscated by the administration. 7) The first computer I ever used as an IBM 1130. It was about the size of a combined washer-dryer and had 16K of memory. The first program I wrote simulated traffic arriving at an intersection to determine the optimal length for the left turn early lane. 8) The first computer I owned was a TRS-80 Model III in 1981. I wrote a program I called Freelancers Assistant to track and bill my technical writing clients. One of them asked if he could by the program. Oh, this could get good, I thought. But I didn't really get into it full time until the company developing software for my sister's business went bankrupt, and she asked me to finish the project. Finally: here are the eight people I'm tagging. The West Coast Michael Stein: http://michaelstein.typepad.com/michael_stein/ Amy Kincaid: http://changematters.blogspot.com/ Marshall Kirkpatrick: http://marshallk.com/ Morra Aarons-Mele: http://womenandwork.org/ Peter Brinkerhof: http://missionbased.blogspot.com/ Susan Reynolds: http://susanreynolds.blogs.com/ Paul Hyland: http://www.paulhyland.com/ Kami Huyse: http://overtonecomm.blogspot.com/

The Dog Days of August

My Technorati page gives my bio as "I'm a big brown shaggy dog"! I'd like to change this -- some aspects are not quite true - but I do not seem to able to do a thing about it. Selecting edit my account, I see a text box for my bio. I delete the pooch blurb, and replace it with something somewhat more professional: I write for NGO staff trying to integrate technology more centrally into their strategic planning. And I write for the technologists trying to help them. So we explore new technologies, technology and organizational development, and issues of tech planning, purchasing, and troubleshooting. My company, Members Only Software, provides applications for a wide rage of non-profit clients, from major public policy think tanks to local YMCAs. But when I click save, woof! its back to the stuff about the brown dog. Bad Boy! Which reminds me -- if you have room in your homes, you should adopt a pet this week- (not me - I just checked my food bowl and its lookin' good) -- but the humane societies are bursting. And speaking of them, doesn't the US Humane Society deserve a big tail-wag for bringing focus on the abusive dog-fighting being run by some major sports figures. This is important work. And you can say you heard that it from me: I'm a big brown shaggy dog.

Now let me tell you what I want this thing to do....

A friend of mine likes to tell this story from his early days as a software consultant. His team had spec'd out a system for a client, and implemented it in somewhat more than three the time they'd included in the contract. Even though they'd lost their shirts, they were full of excitement as they delivered their shiny new application to the client. After the walkthru, the big guy tipped back in his seat, smiled, and said: "This is great. Now let me tell you what I want this thing to DO." The other night over Indian food I heard the same story from the other side of the desk. A friend who works with a non-profit here in DC was talking about the nightmare installation her group had been suffering through for a year now. They are still waiting for the developer to understand the sort of features they need to really support their workflow. He does deliver a new version every few weeks, but each change seems to break something else. "But I'll bet they're really sorry they agreed to do this for a fixed price" she concluded. I'm sure they are. But so is she. When Members Only Software was just starting out, we frequently sold our product in a fixed price engagement - basically saying "We will do what it takes to customize our application for your organization. We will do this for an amount of money we will agree on now, even though we have only a vague idea of what it is you will need." This approach created good clients, who had few special needs; and problem clients, who had many needs. Later we learned to charge for all of our time. We used to think this would make it difficult to give the client a clear project budget. But that's not true. It's easy to stick to a maximum figure - its just that in this reality the user may not be able to afford everything they would like. This reality encourages everyone to prioritize, and by setting a fixed number of hours to the engagement, makes it much more likely a defined project actually reaches completion. Amazingly, it also made all clients good clients. The ones with lots of special needs were suddenly sources of revenue, not drains on our time. This in turn was a benefit for our clients with smaller budgets, who could not afford customization but were excited to see the new features that would show up in our service packs as the fruit of someone else's custom need.