Software-as-a-Service (SaaS) is quickly gaining credibility and market share against traditional packaged software.  This presents new opportunities for product groups and also new challenges to teams used to developing packaged software.    This article provides an overview of SaaS, how it differs from packaged software and specific new areas of focus from an end-to-end product perspective required to ensure a successful service.

Deciding what features to do in your next product release and beyond can be a difficult process.  There are always more requests than can be done, different priorities from various stakeholders, and even vastly different types of features that are competing for attention.   This paper discusses a framework and tools for assessing how to attack the problem and can be used in both traditional and Agile projects.

Painting a Picture of User Interactions

The typical product requirements process starts with a list of features or tasks intended for a specific release and then dives into defining Use Cases or User Stories for the user functionality. This can result in a disjointed solution being developed due to lack of an overall picture of what the user expects to be able to do, and context as to what they are trying to achieve. This article discusses a means of identifying the user need and conceptual functional solution in a high level narrative format called a Usage Scenario before diving into more formal detailed requirements methods. Usage Scenarios can significantly improve your requirements process independent of your development methodology (e.g. Waterfall vs. Agile).

Part 3 of the Product Requirements in a Nutshell Series

Parts 1 & 2 discuss the Requirements Process from traditional (waterfall) point of view and which focuses on documenting the features and functionality of the system to be built in advance of building the solution. The artifacts for this are the requirements docs and specs. At the complete other end of the requirements spectrum is the software development methodology of Agile/Scrum. The main thrust of this method is to AVOID the creation of the formal requirements documents and to use the actual product as the spec. This article explores the methodology and compares whether the common problems identified in Part 2 for traditional techniques are overcome by Agile.

For more background, see Part 1 – A Tour of Requirements Documents, and Part 2 – 4 Common Requirements Issues.

Part 2 of Product Requirements in a Nutshell Series

The main purpose of the Requirements process is to communicate to the technology team about a problem to solve and the envisioned features and functionality required to provide a solution. While on the surface this seems simple enough, the reality is there are several wrong steps to make along the way that can significantly reduce the value proposition that gets delivered to the marketplace in the form of the product.

This article is the second in the “Product Requirements in a Nutshell” Series and discusses four common issues that can arise in the development of Requirements and the potential outcomes that can result. For more background on typical Requirements documents, see Part 1 – A Tour of Requirements Documents.

Part 1 of the Product Requirements in a Nutshell Series

Despite all of the hoopla around new Agile software development methodologies, the vast majority of high tech companies (web-based software, packaged software, hardware/software systems) still use the traditional development methods that have been around for decades. In this traditional development world, there are usually the Requirements docs and Specification (Spec) docs. Depending on your industry and company, these two terms may mean the same thing and are interchangeable, or they may refer to entirely different pieces of the process.

This article is the first in the “Product Requirements in a Nutshell” Series and discusses some of the common variations in the documents names and purposes. For additional reading, see Part 2 – 4 Common Requirements Issues.