Documenting Requirements — the Tools you will need to be successful.

November 2, 2010

I wrote previously about an approach that I have used to manage requirements.  Subsequently, I have been asked to elaborate on the tools and rationale, so here goes…

As previously discussed, “requirements” consist of a wide variety of inputs from numerous internal and external stake holders.   Yet all requirements suffer from 2 problems — (1) It is impossible to address all of your open requirements in a given software release, and (2) things change.

So, that very carefully defined requirement from that key customer that was documented in year 1 may be significantly different from what that same customer needs in year 2 (or year 3).  You obviously don’t want to spend time developing something that doesn’t meet a business need and you also don’t want to lose any of the knowledge about that requirement that you have collected from this customer (and others).  Lastly, if you are going to reconnect with a customer to review the details of a particular business need — you MUST have a good understanding of what they have said before — or they will dismiss you as a waste of their time — which is not helpful on many fronts.

In other words for every requirement, you need some method to gather, track, and maintain its “definition” and the features that you will need to address it over time.  A document management system (such as Alfresco) is an ideal tool for this purpose.

You may ask — “but why not use a source code control system like Subversion or CVS?”   The simple answer is “they are not the right tools”.   Source code control systems are designed to help multiple people work on source code files that often overlap with one another.   Thus, these systems have sophisticated tools for identifying the differences between two versions of the same source code file and allowing them to be merged together.  In my experience, these tools do not work with documents — especially Microsoft Word documents — and can even corrupt the formatting and content in some cases.  In addition, source code control systems typically require each user to maintain a local content repository that must be synchronized on a regular basis to ensure that each user is always looking at the most current copy of a document — which is counter-intuitive, at best, for most non-Engineering personnel.

By contrast, a document management system is designed for editing, sharing, and managing “documents”.  It uses a simple check-in and check-out model that allows users to view any accessible document but requires all updates to be done using an exclusive write approach.  A document management system also provides tools for managing the maturity of each document so that preliminary feature ideas can be shared with some people and more mature feature definitions can be shared with others.   (Have you ever had a situation where a very early version of an idea was sold to a new customer by an overly aggressive sales person?  If so, then you should appreciate the ability to control when requirement and feature information is shared with different audiences.)

In other words, a document management system is the best tool for “managing documents” whereas a source code control system is the best tool for “managing source code”.  (Apologies if this seems redundant.)

You also need a method to plan a software release that will (hopefully) include numerous features that each address one or more requirements.  You need a method to select which features will be included in each release and a way to obtain estimates from Engineering on what it will cost to develop each feature.  You also need the ability to iterate the definition of each release numerous times — adding or subtracting different features — trying to get the “perfect” balance between features, schedule, and Engineering capacity.

You also need to capture all of the assumptions and dependencies that Engineering identified while creating their estimates for 2 very important reasons:  (a) Engineering spent time (and money) creating these estimates and if a particular requirement isn’t addressed now, it may be later.  You don’t want to pay twice for the same thing. (b) If you know how each estimate was derived, you are much more able to verify previous estimates or anticipate problems with current estimates, based upon$ its assumptions and dependencies — even if your Engineering personnel change over time.

You could plan each software release using a spreadsheet — but why would you want to?   Do you really want to continually update the spreadsheet, circulate it to numerous internal people, and then consolidate all of their inputs?   And even if you want to operate this way — do you really have the time?  Or are you assuming that you will get each release planned perfectly the first time?

This is where an issue tracking system (such as Jira) can (help) keep you sane.  You can use a field (such as “Specification”) to include a link to the relevant requirements document within your document management system.  You can use another field (such as “Target Release”) to designate the features that you want Engineering to review and have them include their estimates and assumptions in other fields — based upon the information on the feature and its underlying requirement(s) maintained in your document management system.  So when you generate a report (or Excel export) for a given software release — you will be able to immediately determine whether you have under or over defined the release based upon your Engineering capacity.

You are almost done — all you need now is a “plan” for this release.   If you are using the waterfall method, I suggest creating a project plan with Microsoft Project using the feature, dependencies, and estimate information from your issue tracker.   Update it regularly (I suggest weekly) and provide copies to all team members.  (I suggest using a PDF print driver so that you can easily share the project plan with everyone without requiring them to have access to Microsoft Project.)

If you are using Agile, I suggest using the GreenHopper plug-in for Jira — or something similar — to plan each sprint.

That’s all for now.  I hope this has been helpful.   As always, comments or questions are welcome.


Mobile platforms and business — part 2

August 7, 2010

Sometimes you write a blog entry where your point is quickly understood.  And then there are those “others”…

My earlier post on mobile platforms and their use by businesses probably falls into the second category… But I still think the point is worth discussion, so here we go again…

Many companies issue smart phones or provide the back-end infrastructure to enable their employees to use their favorite Blackberry, iPhone, Android, or Windows Mobile device to manage their email, contacts and schedules.  I think we can all agree on this point.

However, this is just a small percentage of the business opportunities that exist for mobile devices.  Consider two examples:

  • I was recently visiting a friend in a major Boston-area hospital who was scheduled to have some surgery performed.  In the 30×30 foot room there were provisions for 6 patients — and each patient area included 2 laptops.  In addition, there were 3-4 laptops on mobile carts that were wheeled from one patient area to another to record data collected by medical professionals.  And on this floor, there were over 10 additional rooms just like this one.  In other words, a single floor in this hospital had approximately 160 laptops — and each laptop’s sole purpose was to provide access to the back-end servers.  In other words, the laptops were nothing more than terminals.  Imagine how many laptops must exist in the entire hospital.
  • Last month I had the “opportunity” to have my car repaired and spent some time chatting with one of the technicians.  He said that they spend several hours each week in e-learning courses which are often very frustrating to watch.  Apparently each video course is on a laptop in a room far away from the cars — so it is difficult to connect the instructions in the video with the relevant parts in the car.  He said it would be much easier if he could view the video while he was actually under the car.

These examples have a few things in common:  (1) Windows laptops are the primary device being used, (2) only a very small portion of the laptop’s capabilities are being used, and (3) the portability of the device is very important.

Thus I ask — What prevents a company from using an iPad (or similar device) instead of the much more expensive Windows laptops?

I think the answer is “infrastructure”.

Companies can only afford to support a certain number of devices, because each new device requires its own set of back-end support software, trained support personnel, spare parts, etc.  Thus, Windows laptops are often used in situations like this because the company already has many years experience supporting Windows computers, including laptops.

Thus, as the consumer market for mobile devices continues to get more and more crowded, I believe that the device manufacturers will include more capabilities designed to make their devices acceptable to business environments.   In fact, I don’t believe they have any choice.  Consumers are notoriously price-conscious and manufacturers must achieve a certain profit level to stay in business.   Therefore, the manufacturers will do more to make their mobile devices acceptable to businesses, but only a few of these manufacturers will be successful.

The key question then becomes “Which mobile devices will businesses embrace?”


Which mobile platforms will businesses embrace?

July 31, 2010

Each day it seems like there are 10 new applications for your iPhone, iPad, Droid-phone, etc.  And as you might expect, Windows-based tablets, according to Steve Balmer of Microsoft in a recent CNET article, are due out later this year (2010) with a bigger push early next year.

Then there is the continued growth of e-readers from a variety of sources such as Amazon and Barnes and Noble, with some people projecting that they will replace paperback books in the near future.

And while each new platform may be attractive to one or more market segments of consumers — the real opportunity may be the level of adoption of a platform by businesses.

If you are a company like Airbus, Boeing, John Deere, Whirlpool or any other large manufacturing company, you have many thousands of employees and suppliers.  You depend on digital devices to communicate product design information and to facilitate the collaboration of your personnel — especially across geographies.   Today, the primary device is a personal computer, usually a Windows-based laptop.

But as we all know, laptops have their limitations and may be overkill in a number of situations.  For example, if you want to know whether a part is positioned correctly inside an airplane fuselage, you may want to refer to a digital image of the drawing (or 3-D model).  Trying to hold you laptop in one hand while you position the part with the other hand is awkward at best, especially if you have a large laptop.

What type of device is best (and most cost-effective) for this type of situation?

A laptop?  An iPad?  An e-reader?  Or perhaps just a Smartphone?   Many people would argue that “any of these might work, depending on the situation”.

However, since sharing digital data within a corporate environment requires secure high-speed communications, I believe the bigger question is “How many of these digital platforms will businesses decide to support?”

And given the cost of deploying internal networks with ever-increasing bandwidth and the costs of distributing and maintaining each platform — I believe that devices that can easily connect to existing internal networks and can quickly download content from existing servers through web-based clients are most likely to be adopted by companies.

In other words, I think that the corporate “hand-held device” market could easily be dominated by Microsoft — IF they are able to produce high-quality, high-performing, and easy-to-use products and get them to market in sufficient quantities in a timely manner.

What do you think?

Would you trust your cloud provider to provide anti-malware protection?

July 4, 2010

The popularity of cloud services continues to grow.  The key players are companies like Google, Amazon, and Microsoft who are each spending a ton of money improving and promoting their services.

For companies who do not have the ability (or desire) to build and support their own web-based applications, a cloud-based architecture offers many advantages, including:

  • Scalability
  • Integrated database services
  • User authorization and permission services
  • Pay for what you need

However, there are a number of risks with a cloud-based application, including:

  • Large, visible, popular systems can attract malware attacks from bad guys.
  • Proprietary services make it difficult to change cloud providers.
  • Little visibility into how the internal services actually work and even less control.

And now there are a number of advocates for anti-malware capabilities in the cloud, including Phil Wainewright’s recent column and John Viega’s latest book  “The Myths of Security: What the Computer Security Industry Doesn’t Want You to Know“.   Their argument is pretty simple — the threats are in the cloud, so that is where the threat protection should be.  Frankly, I think their argument makes a lot of sense.

However, if your company has acquired cloud services from one of the key players — THEY decide what services are available to you.  And given the history of these companies and their propensity to build their own capabilities, it is very likely that they would develop their own anti-malware tooling and integrate it into their cloud platforms.

Thus the key question — Would you trust your valuable data and the future potential of your company to a cloud platform provider who has little, if any, history in successfully protecting its users from malware attacks?

I think that this issue has the potential to severely impact the growth of cloud-based computing, but will probably be ignored until the first major breach of a cloud — then the lid will come off and the finger-pointing will begin.

What do you think?

Evolving from service-oriented s/w products to a common product platform

June 16, 2010

A potential client wanted advice on evolving their service-oriented software products to a common product platform. Their plan was to revise their application using a popular cloud computing toolkit, migrate all of their customers to this new product version, and retire their current offerings.  So, with all of the attention that cloud computing is getting these days, I thought I would share some of what we talked about and see what your thoughts are…

First, two quick definitions so that we can start on the same page:

Service-oriented products — You host customized versions of your software for each of your customers, typically using a single instance for each customer.  As a result, you may even have situations where different customers are using different versions of your software.   Since each customer’s data resides on a different system, the risk of co-mingling data between customers is low.

Common product platform — You host a single generic (or common) version of your software that is shared among multiple customers and configured to provide them with individualized capabilities and user interfaces.  You use enhanced security mechanisms to ensure that data from your customers is not co-mingled.  Once a user logs into your system, you use their login credentials to present them with a customer-specific user experience.

The key advantages of a service-oriented product approach are that (a) each customer gets exactly what they need, (b) data co-mingling between customers is nearly impossible, and (c) you can roll-out additional capabilities to selected customers very easily — which makes it easy to do specialized testing and to write contracts for individualized capabilities.

However, service-oriented products also have (a) increased maintenance, development, and upgrade requirements because everything must be applied to each implementation individually, (b) severe scalability issues as you get more and more customers — each with their own implementation, and (c) escalating cost issues because each new customer is a new installation without any of the economies of scale that normally come with commercial software.

Thus, it’s easy to see why many software companies start by offering their products as a service and then want to evolve to a common product platform over time.

However, this “evolution” also brings a number of key challenges, as follows:

  • Product Capabilities and Complexity — It is pretty easy to create a software product that can be customized.  The Development team removes the standard routine and plugs in the new, highly customized routine and Voila!, the product now does something significantly different.  “Plug-Ins” like this have been used for years in a wide variety of applications.  However, creating a framework that allows multiple plug-ins to be executed, based upon the user’s profile is much more challenging to architect, develop, test, and deploy.  And you also have to identify all of the places in the framework where a plug-in is necessary.   Lastly, since multiple customers will be sharing the same software instance, your framework has to be sufficiently robust to allow a plug-in for one user to fail gracefully without impacting any of the other users on the system.
  • Company Culture — If your company has been selling highly customized product versions for a while, you have an entire culture devoted to this concept.  So just imagine the conversation when a key sales rep wants “just one more” highly customized product version so that they can bring in a huge order near the end of your fiscal year.  And of course, how will your company handle a number of “just one more” situations?
  • Customer Migration — Even if the capabilities of your common product platform encompass all of the capabilities from all of your customer-specific product versions AND you have migrated all of your customers’ data into the new system, migration will still be an issue for your customers.  At the very least, they will have to retrain all of their users and their system administrators will have to understand how the platform has been configured for them.
  • Product Development Process — Every software product fails at some point in its life.  With a service-oriented product, the failure is normally limited to a single customer implementation.   With a common product platform, a failure will most likely affect multiple customers.  Thus, you may need to re-evaluate a number of aspects of your product development process to ensure that failures of this type are caught during the design, development, and testing of the system.  In some cases, you may need personnel who have different skills / experiences than your current staff so that you can prevent problems before they occur.
  • Product Architecture — Every “technology stack” that is used to develop and deploy a software application has a certain amount of capabilities and a number of limitations.  This is especially true with cloud computing platforms where many of the architecture elements of the system are provided by others and cannot be changed by you.   Thus, you need to verify that your common product platform can be implemented using the technology stack that you have selected (or your cloud computing partner is provided).  You should also cross-check your planned product roadmap against the technical limitations.  You don’t want to spend a ton of money (and time) building a common product platform using a new technology stack only to find out that you will reach a dead-end in 3 years — or just about the time you get all of your current customers happily (you hope) using your new platform.

In summary, evolving from a service-oriented software product to a common product platform can be very challenging.  However, the rewards are worthwhile and you can reduce much of your pain if you (a) take the time to create good quality plans, (b) consistently execute your plans, and (c) clearly communicate among all of the internal participants.

Finally, your customers are your most important asset.  So while you are developing your common product platform, you MUST continue to aggressively support their customized versions and help them see the benefits they will derive from the common product platform once it is available.  You don’t want to EVER announce that you are getting out of the customized software business in favor of a not-yet-available product platform and hope that your customers (and your competitors) will wait patiently for your to execute on your vision — because they won’t.

Just ask all of those customers who used to buy Prime minicomputers how “patient” they were when Prime announced they were going to minimize their hardware efforts in favor of software…

What technologies are you thankful for?

May 31, 2010

This Memorial Day, I spent some time remembering just how lucky I am to live in the United States and how the sacrifices of many others, including some people I know, have helped to make this possible.   I hope you did too.   The dedicated and brave men and women of the US military who have enabled this life that we all enjoy are certainly worthy of our respect and appreciation.

Then it occurred to me — a large number of similarly dedicated pioneers have been responsible for the technology that we use everyday — you know, the stuff that we often take for granted.   I don’t mean to imply that these technology pioneers have sacrificed anything close to what our military personnel have done.  However, a moment or two of appreciation for the efforts of our technology pioneers is appropriate — especially since some of this same technology is relied upon by our military personnel to keep themselves, and us, safe.

So, here’s a list of some of the technology that I’m thankful for (in no particular order):

  • BBN — for their work on Arpanet which eventually became the internet.
  • Xerox Labs — for their user interface and user interaction work (including the “mouse”) that established the basis for the way we use computers today
  • IBM — for defining and publishing the specifications for the Personal  Computer so that a multitude of vendors could create interchangeable parts that all worked together.
  • Intel — for all of the CPUs that have been incorporated into the countless personal computers and embedded systems.
  • Microsoft — for providing a multiple window operating system with a consistent user interface that made it easier for millions and millions of people to use computers.
  • Apple — for providing truly easy to use computers and forcing others to spend even more time improving the ease of use of their computers (and applications).
  • Cisco (and all of the other networking companies) — for providing high-speed network equipment that makes it possible (and affordable) for individual people to have high-speed access to almost everything on the internet.
  • Google (and all of the other search companies) — for making it possible for individual users to “find” almost anything.
  • HP (and other printer companies) — for making it possible for companies and individuals like me to easily and cheaply print almost anything that you could imagine.
  • Computervision (and the other early CAD companies) — who made it possible for companies to digitally design, modify, and manufacture a wide range of products much more quickly and accurately than before.
  • CJ Date (and other early relational database proponents) — who did the research that resulted in the relational database products that nearly every system that we use today rely on.
  • NASA — for developing the technology that put all of the satellites we depend on in space.

I’m sure this list is nowhere near comprehensive, but now it’s your turn.  What technologies are you thankful for because they have helped define and/or shape your life, environment, or even your profession?

%d bloggers like this: