jump to navigation

Why my eCommerce company is dumping Points.com, and why you should not do business with Points.com August 8, 2013

Posted by HubTechInsider in Ecommerce.
Tags: , , , , ,
add a comment

1. Points.com generated oceans of irate customer service requests from our customers, many of whom reported to us that they either never received their points / miles, they were the victim of unexplained points reversals at the hands of Points.com, and / or their frequent flyer accounts were closed without explanation by Points.com. As the application’s administration interface is so rudimentary, basically only providing an interface which afforded us the opportunity to buy points from Points.com, our ability as a small Shopify merchant to keep up with returns, issues with the Points.com application itself or the points of integration between Points.com and our product database began to curtail our normal business customer service activities. Some examples of the types and number of these customer complaints are within the links below. Points.com provided no customer service liaison, no knowledge base, we were never assigned an account manager, and the ignored all of our emails requesting a merchant service manager contact at the company. We were told repeatedly that Points.com does not administer the loyalty programs they claim to power / represent on their logos and graphic files, which we found was extremely misleading to our customers, who were confused and came to us looking for assistance, which we, in many cases and quite frustratingly, were unable to provide.

2. One of the issues regarded with the most amount of trepidation by merchants, large and small, online and off, is the issue of what is known as “Passive spend”. This is where a consumer enters a merchant’s place of business, either online or offline, and completes a transaction. The passive spend occurs as the customer receives a loyalty reward, either in the form of points or miles — for a purchase they would have performed anyway. in other words, by participating in the Points.com program, as a merchant you are effectively discounting every single item in your store, sending a certain percentage of every sale to Points.com in the form of purchased points, many of which, or even most of which, the customers will never redeem. Many customers are not participants of the loyalty rewards programs in question and so they received a coupon code via email that they didn’t know what to do with. Points.com is like many of the points / miles awarding companies out there on the internet: they simply buy points from the airlines. United, Delta, American Airlines: they all sell points to anyone who cares to buy them. So Points.com, rather than speaking for the airlines, is simply a middleman, leveraging points arbitrage and counting on passive spend to boost their bottom line. The only problem? You need the merchants to drive the discount or award in the first place. The points awards come out of the merchants’ pockets. Points.com never even gave us one courtesy telephone call at any point during our business relationship with them. No matter what Points.com implies in their corporate advertising, make no mistake: this points industry is driven by merchants, and what the merchants giveth, the merchants can take away. And tshirtnow.net decided to pick up our playing chips and go home.

3. The Points.com integration with our eCommerce site, tshirtnow.net, (in continuous operation since 1994) was supposed to provide our customers, upon completion of their orders within our site, a redemption code that they could use with any of the participating loyalty programs. We performed a study using our CRM system which resulted in a report that showed a customer service inquiry regarding this coupon code every 1.3 completed transactions, which is an unacceptable rate of CS inquiries regarding an application whose singular purpose is to send our customers their redemption code. Keep in mind, the actual redemption of the points in question occurs after the customer has not only received the code via email from Points.com, but have entered it into their loyalty program’s customer portal. In other words, the sending of the code is but the tip of the iceberg of the customer’s interaction with their loyalty program, and in consideration of the above point #1, namely poor to nonexistent merchant support from Points.com, you can see that each completed transaction had the potential to create dozens of follow-on CS emails and telephone calls from irate customers, with a limited facility for our personnel to assist.

4. We were informed via email that upon an alleged annual program review of Points.com merchants, tshirtnow.net would no longer be able to participate in the Points.com program. No reasons for this were given, and it was unclear to us if this was one program / airline, or the entire Points.com program, or if this originated with Points.com iteslf. Based upon my experiences in the points / miles industry (http://www.linkedin.com/in/paulseibert1) , I was skeptical of this originating in some sort of annual review, not only because the calendar timing was odd for this, but also due to the fact that in my experiences, airlines and other loyalty programs opt merchants out on a case-by-case basis. This notice from Points.com had all the appearance of a retaliatory move by Points.com due to our requests for customer service and an account manager or merchant liason. We were however told that Points.com was working on a new product that would be oriented towards merchants like us. During this entire episode, we were still receiving system maintenance emails which had all the indications that we were still integrated, at least programmatically, with the Points.com program. Indeed, we are *still* receiving these emails. I may post some of the Points.com system maintenance bulletins here on HubTechInsider.com, however I think sight of even one or two of the myriad Points.com system failure notices would scare even the hardiest of entrepreneurs away from using their system. My repeated emails and telephone calls requesting clarification were ignored.

5. Points.com is an integration with our eCommerce site. We needed time to figure out where the integration code existed within our code base, and remove the code. There was markup on our front end UI pags that also had to be removed which dropped points.com tracking cookies, etc. This all took time, and the Points.com documentation was nonexistent. The developer that had integrated Points.com into the Tshirtnow.net web site, Mr. Steven Brown, passed away in Florida while on vacation and this event not only complicated the identification and removal of the code in question but brought all new development on our site to a halt as our entire development team attended the funeral services in Florida and the burial in Jamaica. Needless to say, our patience with Points.com’s nefarious business practices had worn thin even by the time we returned back to Boston only to be greeted by the highly threatening letter from Points.com’s corporate council, threatening every thing under the sun from copyright infringement lawsuits to multiple lawsuits from their individual participating airlines. I have worked with nearly every single one of their participating airlines on loyalty program integrations, and I know the chance of that happening is about the same as a snowball’s chance on the quad of the University of Alabama in July. We will sit here holding our collective breaths. I advise all eCommerce merchants to steer clear of this Points.com company.


I am in receipt of your threatening emails and correspondence from your general counsel. I will remove the two graphic images from our web site. As you are aware, Tshirtnow.net is a former customer of Points.com.

As a very small understaffed company, we have some difficulty at times in removing links, graphics, etc. – as undoubtedly do many of your Shopify merchants. Points.com is a large multinational corporation that is located outside the state boundaries of the Commonwealth of Massachusetts, and apparently has little experience or expertise in dealing with cottage industries such as Tshirtnow.net.

I intend to publicize this bullying behavior of Points.com, and publicize it widely. Certainly we have the ability to review your behavior and the performance of the Points.com application multiple times in an extremely negative fashion via means of the Shopify (and other eCommerce platforms) marketplace, and I intend to reach out to my corporate contacts at Shopify and their developer and merchant advocates and marketplace Ombudsman directly in order to lodge a formal complaint against you and your company’s (“Points.com”) pejorative communications and business practices with regard to small Shopify merchants. It is the fervent belief of this longtime Shopify merchant that your large multinational corporation, Points.com, have misrepresented yourselves as a viable vendor to such eCommerce operations.

Please forward to me the contact information of your corporate counsel so that they can receive the formal demand letter from our corporate counsel, whom have advised us that under the general laws of the Commonwealth of Massachusetts, our company has rights that will be vigorously defended in the litigation system of the Commonwealth. The judges and juries within the court system of Commonwealth of Massachusetts have a long history of defending small local businesses against the unfair business practices of large out-of-state multinational corporations such as Points.com.

As entitled under the general laws of the Commonwealth of Massachusetts, consider this correspondence as our official demand for written enumeration of the reasons behinds the termination of our Points.com account, which was effected without any prior notice.

Be aware that all information and communications between myself, our company and Points.com, shall be made public, as will all of your threats, written, electronic, verbal or otherwise. I have been in contact with several members of the online press and eCommerce review sites, and I have been asked to sit for a local television station so that they can interview me in order to review your Points.com application and present our side of the story. This television program and the resulting video file will be distributed worldwide and search engine optimized in such a way as to become heavily viewed on YouTube and easily discoverable when eCommerce vendors search for information about Points.com.

I am also contacting the office of the Attorney General of the Commonwealth of Massachusetts in order to file a formal complaint against Points.com regarding your multinational corporation’s business practices within the Commonwealth of Massachusetts.

– Paul

Take a look for yourself at the same types of complaints about Points.com that our miniscule, understaffed, underpaid (you guys are awesome!) and overworked customer service staff has been fielding about our (former) integration with the Points.com application for months on end:


The most important rule for managing your Agile project team’s velocity [VIDEO] May 1, 2013

Posted by HubTechInsider in Agile Software Development, Product Management, Project Management.
Tags: , , , , , ,
add a comment

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software developmentAgile project managementmanaging software teams, designing web-based business applications, running successful software development projectsecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurshipecommercetelecommunications and software development, I’m a PMO Director, a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

More Articles From Boston’s Hub Tech Insider:

How to optimize your web based software application for the mobile web August 7, 2011

Posted by HubTechInsider in Mobile Software Applications, Product Management, Project Management.
Tags: , , , , , , , , , , , , , , ,
1 comment so far
Image representing iPhone as depicted in Crunc...

Image via CrunchBase

The mobile web is where the action is in 2011.  We have all seen the polls and the statistics: people are spending more and more time accessing the web through their mobile smartphones and mobile tablet computers. The mobile Web grew 110 percent in the U.S. last year and 148 percent worldwide as measured by growth in pageviews.

Including devices such as the Kindle, the iPhone and other smartphones, web-enabled tablets, GPS systems, video games and wireless home appliances, the growth of the mobile web has been exponential — and we’re still just at the beginning of this cycle. Morgan Stanley’s analysts believe that, based on the current rate of change and adoption, the mobile web will be bigger than desktop Internet use by 2015. The proliferation of better devices and the availability of better data coverage are two trends driving growth; having better services and smaller, cheaper devices has led to a huge explosion in mobile technology that far outpaces the growth of any other computing cycle.

Global 3G penetration is expected to hit 21% this year. In Japan, where the U.S. looks to find its mobile roadmap for the future, 96% of mobile subscribers already have 3G coverage. In Western Europe, the penetration is around 54%, just slightly above 46% in the U.S. In developing and/or economically depressed areas, including the Middle East, Africa, parts of Asia, Eastern Europe and South America, 3G penetration is still in the single digits. 3G access is a key point in the success of the mobile web, providing very usable surfing speeds for mobile web usage.

In addition, mobile e-commerce is ramping up faster than online e-commerce, now making up 4% of total retail sales. In certain categories, such as computers, consumer electronics, music, movies, tickets, video games and books, online sales account for between 45% and 20% of the total retail market. Japan’s Rakuten shows how the mobile share of e-commerce is growing as well, from 10% of e-commerce in 2006 to nearly 20% now.

Video now accounts for 69% of mobile data traffic, and the overlap between mobile users and social web users continues to grow; more and more users are accessing the social web from a mobile device. Real-time technology and location-based services are expected to drive mobile retail, and a very interesting fact is that the average iPhone user only spends 45% of his on-device time making voice calls.

Some more mobile web usage statistics and facts:

  • More people have mobile phones than Internet-connected PCs (4 billion) 

  • SMS penetration ~50% and fully mainstream (82% of users <24 y.o.)

  • 82 million Americans can recall seeing advertising on their phone over last 3 mos. (approx. 30% of 270m adult phone users)

  • 25% of phone users (65 mm) are accessing the mobile web but 80% of iPhone users are

  • 40% of Twitter users use the Internet on their phones (76% if you include WiFi) (Pew)

  • Internet Advertising Bureau survey found that 62 percent of agencies, media planners and advertisers believe mobile ad spending will continue to grow and emerge in marketing budgets

  • Mobile device is increasingly becoming small, portable PC experience with an Internet browser experience similar to that of 2000/2001 (just diff’t form factor)

  • In 2007, eMarketer reports that US advertisers spent $900 million on mobile, and double in 2008 to $1.7 billion

  • 21 million iPhones + ~20 million iPod Touches = 40-45million iPod-like devices

  • 50,000 apps from iTunes App Store and Nokia, RIM, MSFT and others now w app stores; 1 billion+ app downloads to date

  • 70% of people sleep with their mobile phones (Zumobi)

  • More than 60 million mobile views per month for New York Times; one of 4 apps pre-loaded on the Palm Pre

  • Joseph Porus of Harris Interactive: “”Mobility could be recession-proof and be one of the strongest ways of effectively marketing in tough economic times”

  • 35% of mobile advertising campaigns cost less than $10,000 (Forrester)

Mobile Device Product Categories & Feature Sets

There are four primary mobile device product categories in widespread use today, and each of these four mobile device product categories is typically configured by the device manufacturers with a certain base set of features and functionality. The four mobile device product categories, listed with their typical bandwidth usage per month, are:

  1. Feature Phones:  Feature Phones such as the Motorola Razr are used primarily to make calls, and they consume little bandwidth even for web activities because they have stripped-down web browsers. Feature phones and their users tend to consume around 100 Megabytes of data downloads a month, using 4 MB of voice calls an hour, and 4 to 5 MB of web browsing per hour.

  2. Smartphones: Smartphones such as Research in Motion’s popular Blackberry are used for phone calls, email, and light web browsing. Smartphones and their users tend to consume around 185 Megabytes of total monthly data downloads, utilizing 4 MB per hour for voice calls, and 4 to 5 MB of web browsing.

  3. Superphones: Superphones are advanced smartphones, including Apple’s iPhone and Motorola’s Droid, that make it easy for people to surf the web and watch online videos, leading to much higher bandwidth use. Superphones and their users tend to consume around 560 Megabytes of total monthly data downloads, using 4 MB per hour for voice calls, 40 MB per hour for web browsing, 60 MB per hour for internet radio, and 200 MB per hour for YouTube videos.

  4. Tablet Computers: Tablet computers such as Apple’s newly unveiled iPad are likely to send data use even higher. The iPad will chew up even more bandwidth than the iPhone because of its larger screen. Tablet computer and iPad users tend to consume 800 to 1,000 Megabytes of total monthly data downloads, using 50 to 60 MB per hour for web browsing, 60 MB per hour for internet radio, and 300 to 400 MB per hour for YouTube videos.

If your web based application or site is not optimized for the mobile web, you are falling behind and losing out on transaction revenue, sales, data, customers: you name it.

There are many methods and techniques that can be used to optimize your web based application or site for the mobile web. In this article I will describe how I optimized a commercial b2c ecommerce application for the mobile web, and then I will go into more details as to how you can use the same techniques I used on the http://www.tshirtnow.net mobile site and also how you can use different techniques to optimize your own web-based mobile application or site.

For the tshirtnow.net mobile site, I utilized a technique to present a mobile-optimized version of the tshirtnow.net web site to mobile browser users such as those surfing the web site on an iPhone, iPad, or Android mobile phone, and the regular version of the tshirtnow.net web site to users who were accessing the web-based b2c tshirtnow.net ecommerce application from regular web browsers on a desktop or laptop computer with a browser like Google Chrome or Microsoft Internet Explorer.

But using a special CSS stylesheet that is optimized for mobile browsers, along with the reglar tshirtnow.net CSS stylesheet, we are able to automatically detect what type of mobile browser platform the user is currently accessing the tshirtnow.net web site with. Using the CSS information contained in the tshirtnow.net mobile cascading style sheet (CSS), we are able to render the exact same html content which represents the different pages on the site such as product detail pages, order status pages, and the home page with different formating and styles, and even content sections, all just by using CSS.

The advantages of this technique are rather obvious. First of all, there is no need to recreate dozens or even hundreds of static html content pages, as the exact same content and pages can be cleverly re-purposed simply by providing for planned degradation of the user’s web experience according to what type of mobile device and mobile browser platform they are currently using.

Secondly, the use of CSS to provide a mobile optimized experience allows for the use of special CSS tags and techniques which can provide iPhone and iPad iOS orientation (landscape or portrait) and touch detection, intelligent web page scaling, special mobile OS (iPhone, iPad iOS or Android, Blackberry, HP WebOS) controls and rich media player capabilities, and phone/web integrated telephony. I will go into much more detail about some of these advanced CSS capabilities and I will provide more information about them as well as links to more resources on the web later in this article.

I encourage readers of this article who have not already done so, to read my previous article, a Glossary of mobile Web Terminology, for references to some of the terms I will use throughout this article. Knowing mobile web terminology will also assist you in creating wireframes and mockups for mobile web applications, and will be a great boon to your mobile application software specifications as well.

The tshirtnow.net mobile web site

For tshirtnow.net, I utilized a mobile optimized CSS style sheet. It detects which type of browser platofrm the user is accessing the tshirtnow.net web site with, and then serves that user either the regular tshirtnow.net home page, or the mobile optimized tshirtnow.net home page. Here is what most users see when they access the tshirtnow.net web site with a normal desktop computer browser:

And here is what a user accessing the same tshirtnow.net home page using mobile safari on an Apple iPhone would see:

The mobile version of the tshirtnow.net home page, as seen on an Apple iPhone (iOS)

As you can see, iPhone users see a gently degraded web page, which contains many of the most important, but not nearly all, of the controls, links, graphics and content of the normal tshirtnow.net home page. This mobile-specific version of the exact same web page is presented to the user not though the use of another web page, but simply through the use of the mobile-optimized style sheet.

Here is another example of how the tshirtnow.net b2c ecommerce web application is able to detect a mobile browser user and serve up content optimized for mobile from the exact same html page. Here is what the order status page looks like to a user accessing the tshirtnow.net web site from a regular desktop computer browser like Microsoft Internet Explorer or Mozilla Firefox:

And here is what a user accessing the same tshirtnow.net order status page using mobile safari on an Apple iPhone would see:

The mobile version of the tshirtnow.net order status page (iOS)

You can see that not only has the check order status button been dynamically resized in order to accomodate the smaller screen width of the iPhone mobile safari browser, but also that the hairline css curved corners border around the order number and email address input form fields has been resized too. All of this dynamic width modification, including the button graphic itself, which is rendered using standards-based css, happens on the fly from one set of html pages.

If you perform platform-specific css coding into your mobile stylesheet, which I will demonstrate how to do later in this article, then you can take advantage of such features as iOS iPad and iPhone orientation detection and dynamic adjustment, touch interface enhancements, and CTI, or Computer Telephony Integration features like click-to-call:

iOS platform-specific controls like this iPhone selection dial are supported natively through CSS

A typical b2b or b2c web-based ecommerce application that provides content pages that are driven by databases and displaying and presenting the results of database queries can produce thousands of individual web pages. To provide a mobile-optimized version of each of these pages is a prohibitively expensive and time-consuming endeavor that is beyond the performance envelope of most software development organizations.

The skillset needed to perform heavy CSS manipulations and platform-specific mobile optimizations may not be present on your current software development team. J2ee and other types of system and application software programmers may not have the requisite ability to manipulate and create a mobile optimized CSS stylesheet, and the necessary experience required to effectively develop and test platform-specific and progressively enhanced mobile CSS may not be present on your current team.

By utilizing a mobile CSS stylesheet to render the same content pages, you have provided a way to render those thousands of dynamic, database-driven web pages on the fly, and ready for your mobile web users. For example, here is one of the many thousands of product detail pages on the tshirtnow.net ecommerce site, as it would appear to a normal desktop web browser:

And here is what a user accessing the same srv tshirt product detail page using mobile safari on an Apple iPhone would see:

A mobile version of a tshirtnow.net tshirt product page (iOS)

You can see that the mobile version of the tshirtnow.net product detail page contains less content, and the content that is displayed on the mobile version of the product detail page is in a different location than the content on the regular, desktop browser version of the tshirtnow.net product detail page. All of this is performed not through HTML manipulations or server side includes, but is instead accomplished exclusively through the use of CSS.

Product detail page features such as tags are specially presented on Apple iPhone iOS through CSS

Because of this use of CSS to render mobile versions of the same html content pages, all scenarios have been accounted for, opening up the entire tshirtnow.net web site, all products, all static html content pages, all dynamic interaction controls such as search engines and results pages, are made available to mobile web browsers using this technique.

If instead the decision had been made to create unique, static html pages for mobile browsers, then a detection mechanism such as WURL or user-agent string detection would have had to have been employed in order to serve up unique html pages. The program to create many thousands of unique pages for all of the major functions, plus a unique mobile template for all of the product detail pages, would have been extremely cost and resource intensive.

Tips for Handheld CSS Style Sheets

Handheld media stylesheets should be as small and compact as possible because of download time.

What can you do to simplify your site and make it more usable in mobiles? First, eliminate some of these problematic items from mobile display.

  • Eliminate floats and frames

  • Eliminate columns – one column with the content first is the best option

  • Eliminate scripted effects such as popups or pop out menus in favor of plain old HTML and simple text menus

  • Eliminate decorative images that slow down the loading process. Use display:none to remove anything that isn’t absolutely necessary, such as links to external resources. Remember, however, that devices that don’t understand CSS won’t do anything withdisplay: none. Any essential images need to be reworked for the small screen and the width and height attributes need to be included in the HTML.

  • Eliminate nested tables and layout tables. If you have tabular data, consider finding a way to present it in a linearized alternate display.

Once you’ve simplified through elimination, start building the rules you need to add. Consider these ideas.

  • If you’re not already using relative measures, switch to ems or percentages rather than pixels

  • Reduce margins, paddings and borders to suit the small screen

  • Use smaller font sizes for headings and paragraph text

  • If you have a long navigation list at the start of the page, add a skip to main content link, or move the links to the end of document flow. Keep the number of clicks required to get to content as minimal as humanly possible. Without a mouse or keyboard, most mobile users have to click laboriously through any top navigation.

  • Make sure your color combinations provide good contrast between foreground and background colors, particularly for devices with fewer color options.

Sample Handheld CSS Stylesheet

/* mobile styles */

@media handheld {

html, body {

font: 12px/15px sans-serif;

background: #fff;

padding: 3px;

color: #000;

margin: 0;


#sidebar, #footer {

display: none;


h1, h2, h3, h4, h5, h6 {

font-weight: normal;


#content img {

max-width: 250px;


.center {

width: 100%; !important;

text-align: center;


a:link, a:visited {

text-decoration: underline;

color: #0000CC;


a:hover, a:active {

text-decoration: underline;

color: #660066;



/* iPhone-specific styles */

@media only screen and (max-device-width: 480px) {

html {

-webkit-text-size-adjust: none;



Resources for testing your mobile applications

As with any other type of Web design, testing is a big part of the process. However, testing websites for mobile devices brings additional challenges, and fortunately, there are some tools available that were created especially for these purposes:

Opera Mini Browser Simulator


The Opera Web browser comes with a feature that is of use to QA – the Opera Small Screen Renderer.

This tool can be used to test any Web page and see how it will look in a tiny window like on a cell phone. To use it:

 Download the latest version of Opera.

    1. Go to the page you want to test.
    2. Hit Shift-F11.
      The screen will switch to a narrow version of the page.
    3. When you’re done testing, hit Shift-F11 to toggle back to normal view.

Apple iPhone Safari Debugging and Testing Tips & Instructions:


 W3C mobileOK Checker:


ready.mobi mobile site automated checker & reporting tool:


 Blackberry Device Simulators:


 Nokia Mobile Phone Simulator:


OpenWave Phone Simulator:


iPhoney iPhone Simulator for OS X:


 How to setup desktop Safari on Windows and OS X to emulate iPad and iPhone:


 Mobile Phone Web-based Emulator:


 BrowserCam Cross-Browser Device Screen Captures:

(Instantly see mobile pages in any browser on device operating systems)


W3C Mobile Test Harness:


 Cameron Moll’s Mobile HTML & CSS Styling Test Pages:


Patrick Griffith’s Handheld Media Test Page (Test to see if handheld device interprets media=”handheld”):


 Good, General Mobile Web Testing Resources Available Here:


Apple iPhone / iPad / iOS Resources

Apple iPhone Developer Center:


 iUI Interface Library / Framework Documentation:



 iPhone Web HTML Application Home Screen Icons, Viewport Adjustments:


 Touch Interface Detection:


 iPad Orientation Detection CSS:




 Preparing Your Web Content for iPad:


iPad CSS How To:


 Building an iPhone App using jQTouch & PhoneGap, without Objective-C:




Blackberry Developer Zone:


Blackberry Browsers Stylesheet and CSS Support Information:


How to target the Blackberry browser:


Blackberry Device Simulators:


 RIM Blackberry Developers Reference Guide: Blackberry Browser HTML, CSS and JS Information:


 RIM Blackberry Browser CSS Reference Guide:


RIM Blackberry Browser Content Design Guidelines:


In the BlackBerry Documentation for Developers, there is a documentation for the BlackBerry Browser, including CSS Reference – BlackBerry Browser. There is no specific mention of CSS3, but that document lists supported CSS properties.

There is also a BlackBerry Widget web standards support page that states 4.7.1 and 5.0 have partial support for CSS 3 color and full support for CSS 3 marquee, CSS 3 media queries, CSS 3 namespaces and CSS 3 selectors.

Opera Mini 5 Optimization:


Opera Mini Browser-based Simulator:


How to serve the right content to mobile browsers:


 W3C CCS3 Media Queries Specification:


 Mobile Device Support through JavaScript & CCS Media Queries:


 Safe Cross-Platform, Cross-Device Media Queries:


HTML & CSS For Mobiles:


Mobile CSS is a reality:


CSS Discuss: Handheld Style Sheets:


Mobile Style Guides:


You can try acid3.acidtests.org and http://www.css3.info/selectors-test/test.html on the respective browsers to check some compatibility, but that may not be an exact determining factor of full compatibility. However I don’t think any of the mobile browsers currently fully support CSS3.


Both iPhone and Android systems use WebKit as the rendering engine in their mobile browsers. I believe Blackberry are moving to Webkit as well at some point. This engine has some of the best support for parts of CSS 3 available at the moment, as well as quite a lot of proprietary extensions.

I would recommend researching what is available in WebKit, and then testing.

A great resource for support tables is http://www.quirksmode.org where PPK is doing more and more mobile browser testing to answer just these kind of questions.


An Introduction to the Mobile Web:


The Mobile Phone Directory –  Phone Specifications, Glossary of Terms:


Mobile Web Glossary from the BBC:


WURFL — Wireless Universal Resource File —  (SourceForge):






Wikipedia Entry – Microbrowser:


Wikipedia Entry – Mobile Phone:


Cameron Moll’s Mobile Web Design Series:

Part 1: http://www.cameronmoll.com/archives/000415.html

Part 2: http://www.cameronmoll.com/archives/000428.html

Part 3: http://www.cameronmoll.com/archives/000577.html

Making Small Devices Look Great:


The Pros and Cons of Developing a Mobile Version of Your Website:


Bulletproof Mobile Device Detection:


A List Apart: “Return of the Handheld Stylesheet”:


A List Apart: “Put Your Content in My Pocket” (iPhone information):


A List Apart: “Understanding Progressive Enhancement”:


Progressive Enhancement for Mobile Media Queries:


Server-Side Scripting for Bulk Mobile Site Page Re-engineering:


Mobile Browser / Mobile Web Usage Statistics







Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

What are some good books on User Interface design? How do you define user interfaces in your software specification documents? The Hub Tech Insider User Interface Design Bookshelf July 31, 2011

Posted by HubTechInsider in Agile Software Development, Ecommerce, Mobile Software Applications, Product Management, Project Management, Social Media, Software, Uncategorized.
Tags: , , , , , , , , , ,
add a comment
Screenshot of Glade Interface Designer

Image via Wikipedia

The Hub Tech Insider User Interface Design Bookshelf: Essential UI Design Books for IT Directors, Project Managers, Program Managers, Software Requirements Engineers, Business Analysts, User Interface Designers, Graphic Designers, Interaction Designers and Information Architects.

Some of the tools that I typically use to produce wireframes and mockups to specify software that is under development include traditional desktop personal computer graphics application software packages such as Adobe Illustrator and Photoshop, business graphics and diagramming packages such as Microsoft Visio, and many others, including some on the Mac OS X and Linux platforms.

But no matter which software program you use to prepare your wireframes and mockups, you still need to have the knowledge surrounding what types of controls are available, and the wisdom to know the most apropos situations in which to use those software controls.

It may be surprising to many people that are not involved in the software industry, but it is not always system and application software programmers who are the most familiar with these types of user interface interactivity patterns and controls. User interface designers, graphic designers, and information and interaction architects are usually the ones who specify these types of “Web 2.0” controls.

If you are writing software specification documents, I recommend that you become as familiar as possible with all of the different types of rich internet application controls and interaction patterns that are examined in detail within these books. Programmers and project and program managers will benefit as well.

A great amount of time and effort will be saved if everyone on the project team has familiarity with these fundamental web interface and interaction patterns. Having a common vocabulary with which to communicate to each other in design and development meetings will pay dividends throughout the course of the software development lifecycle.

The ability to suggest an interaction pattern or a type of control that can preserve screen or page real estate, for instance, can make the critical difference in getting a software system design specified in a limited amount of time. Having knowledge of user interface best practices and common user interaction patterns in-house, on the project team itself, can not only save money in avoidance of expensive user interface consultants and UI design firms, but it can also ensure that the tricky question of post-implementation compliance amongst your development team and programming staff.

I have compiled a list of books that in my opinion merit a place on any professional user interface designer’s bookshelf. If you are looking to stock your User Interface library, you really can’t go wrong with this list of books.

I feel that IT Directors, Product Managers, Program Managers and Project Managers, as well as Graphic Designers, Information Architects, and Interaction Designers and Usability Engineers (read this article if you need help understanding what these job titles mean) could all benefit from reading several or all of these books.

I have found in my professional career that having advanced knowledge of User Interface design techniques and best practices aids me greatly in producing high quality project plans and functional specifications for web based applications and their related software development projects. Mockups and wireframes that incorporate the various design patterns outlined in these books have greatly increased my ability to communicate and develop project related deliverables and artifacts for complex and cutting edge user interfaces, particularly those that include social media platform integrations and RIA, or Rich Internet Application, frontends.

The more knowledge that you acquire in your professional career on a software development team, and the more you know about user interfaces for web based applications, the more value you will be capable of delivering to both your employer and yourself in the form of expanded career opportunities.

Web Form Design: Filling in the Blanks

By Luke Wroblewski. Rosenfeld Media, May 2008.

Web Form Design: Filling in the blanks, by Luke Wroblewski

Anyone who designs anything for the web needs a copy of this. It makes it so nice to not have to think about designing forms. I can spend my time on more interesting design challenges. This book doesn’t leave my desk.

Forms make or break the most crucial online interactions: checkout, registration, and any task requiring information entry. In this book, Luke Wroblewski draws on original research, his considerable experience at Yahoo! and eBay, and the perspectives of many of the field’s leading designers to show you everything you need to know about designing effective and engaging web forms.

I have found this book to be the most practical, comprehensive and data-driven guide for solving form design challenges and I consider it an essential reference.

The Smashing Book #1


The Smashing Book #1

This book is available exclusively from Smashing Magazine. This book looks at Web design rules of thumb, color theory, usability guidelines, user interface design, best coding and optimization practices, as well as typography, marketing, branding and exclusive insights from top designers across the globe.

This book contains ten carefully prepared, written and edited stories that are based upon topic suggestions and wishes of Smashing Magazine’s readers. The topics covered here are fundamental and so the content is highly practical.

The Smashing Book #2


The Smashing Book #2

This book shares valuable practical insight into design, usability and coding. It provides professional advice for designing mobile applications and building successful e-commerce websites, and it explains common coding mistakes and how to avoid them. You’ll explore the principles of professional design thinking and graphic design and learn how to apply psychology and game theory to create engaging user experiences.

Designing Web Interfaces: Principles and Patterns for Rich Interactions

By Bill Scott & Theresa Neil


Want to learn how to create great user experiences on today’s web? In this book, UI experts Bill Scott and Theresa Neil present more than 75 design patterns for building great web interfaces that provide interaction. Distilled from the author’s years of experience at Sabre, Yahoo!, and Netflix, these best practices are grouped into six key principles to help you take advantage of the web technologies available today. With an entire section devoted to each design principle, Designing Web Interfaces illustrates many patterns with full-color examples from working websites. If you need to build or renovate a website to be truly interactive, this book will give you the principles for success.

Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition

by Steve Krug


Five years and more than 100,000 copies after it was first published, it is very difficult to imagine anyone working in web development or design that has not read this classic on web usability, but people are still discovering it every day. In this second edition, Steve adds three new chapters in the same style as the original: wry and entertaining, yet loaded with insights and practical advice for novice and veteran alike. Don’t be surprised if it completely changes the way you think about web design.

The three new chapters are entitled: Usability as common courtesy (why people really leave web sites), Web accessibility, CSS, and you (making sites usable and accessible), and Help! My boss wants me to ______. (Surviving executive design whims).

In this second edition, Steve adds essential ammunition for those whose bosses, clients, stakeholders, and marketing managers insist on doing the wrong thing. If you design, write, program, own, or manage web sites, you must read this book.

Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems


It’s been known for years that usability testing can dramatically improve products. But with a typical price tag of $5,000 to $10,000 for a usability consultant to conduct each round of tests, it rarely happens.

In this how-to companion to Don’t Make Me Think: A Common Sense Approach to Web Usability, Steve Krug spells out an approach to usability testing that anyone can easily apply to their own web site, application, or other product. (As he said in Don’t Make Me Think, “It’s not rocket surgery”.)

Information Architecture for the World Wide Web: Designing Large-Scale Web Sites


Saul Wurman first used the term Information Architecture in his book of the same name. His book was mostly lots of really pretty pictures of media and webs compiled from a graphic design perspective; they were beautiful but never really dealt with the information end of things. Rosenfeld and Morville get it right. They show how to design manageable sites right the first time, sites built for growth. They discuss ideas of organization, navigation, labeling, searching, research, and conceptual design. This is almost common sense, which is often overlooked in the rush for cascading style sheets and XML.

The Elements of User Experience: User-Centered Design for the Web


From the moment it was published almost ten years ago, Elements of User Experience became a vital reference for web and interaction designers the world over, and has come to define the core principles of the practice. Now, in this updated, expanded, and full-color new edition, Jesse James Garrett has refined his thinking about the Web, going beyond the desktop to include information that also applies to the sudden proliferation of mobile devices and applications.

Successful interaction design requires more than just creating clean code and sharp graphics. You must also fulfill your strategic objectives while meeting the needs of your users. Even the best content and the most sophisticated technology won’t help you balance those goals without a cohesive, consistent user experience to support it.

With so many issues involved—usability, brand identity, information architecture, interaction design— creating the user experience can be overwhelmingly complex. This new edition of The Elements of User Experience cuts through that complexity with clear explanations and vivid illustrations that focus on ideas rather than tools or techniques. Garrett gives readers the big picture of user experience development, from strategy and requirements to information architecture and visual design.

Forms that Work: Designing Web Forms for Usability

by Caroline Jarrett and Gerry Gaffney


Forms are everywhere on the web – used for registration and communicating, for commerce and government alike. Good forms make for happier customers, better data, and reduced support costs. Bad forms fill your organization’s databases with inaccuracies and duplicates and can cause the loss of potential or current customers. This book isn’t about just colons and choosing the right widgets. It’s about the entire process of making good forms, which has a lot more to do with making sure you’re asking the right questions and in such a way that your users can answer than it does with whether you use a drop-down list or radio buttons.

If your web site includes forms, then you need to read this book. In an easy-to-red format with lots of examples, Caroline Jarrett, who runs the usability consulting company Effortmark Ltd.(http://www.usabilitynews.com), and Gerry Gaffney, who runs the usability consulting company Information & Design Proprietary Ltd.(http://www.uxpod.com), present their three layer model – appearance, conversation, and relationship. You need all three for a successful form – a form that looks good, flows well, asks the right questions in the right way, and most importantly, gets users to fill it out.

Designing good forms is trickier than people think. This book explains exactly how to design great forms for the web. Liberally illustrated with full-color examples, it guides readers through how to define and gather requirements to how to write questions that users will understand and want to answer, as well as how to deal with instructions, progress indicators, and error conditions.

I found that this book provides proven and practical advice that will help designers avoid pitfalls, and produce forms that are aesthetically pleasing, efficient, and cost-effective.

The book is filled with invaluable design methods and tips to help ensure accurate data and satisfied customers, and includes dozens of examples, from nitty-gritty details (label alignment, mandatory fields) to visual design (creating good grids, use of color).

Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points


by Matthew Linderman and Jason Fried

Let the 37signals team show you the best way to prevent your customers from making mistakes, and help them recover for errors if a mistake does occur. This book doesn’t leave my desk either.

The folks at 37signals have created an invaluable resource: tons of ‘best practice’ examples for ensuring that web users can recover gracefully when things – as they inevitably will – go ‘worng’ !

In this book, you will learn 40 guidelines to prevent errors and rescue customers if a breakdown does occur. You will see hundreds of real-world examples from companies like Amazon and Google that show the right (and wrong) ways to handle crisis points.

You can also use this book to evaluate your own site’s defensive design with an easy-to-perform test and find out how to improve your site over the long term.

About Face 3: The Essentials of Interaction Design

By Alan Cooper. Wiley 2007.

About Face 3, by Alan Cooper

Learn the rules before you break them. Please. Pretty please with a cherry on top? Get this book and read it if you are responsible for designing anything more than a simple web site. Good for Flex developers and Ajax developers as well. Lots of patterns that can be extrapolated for Rich Internet Applications.

Prototyping: A Practitioner’s Guide


Prototyping: A Practitioner’s Guide” is a terrific and comprehensive review of both the prototyping process and the tools involved. There’s really very little with which to find fault. I found that the book both validated my experience in prototyping and provided new techniques to try out, with many “Aha!” moments in both respects. The inclusion of case studies illustrating the techniques provide additional perspective and make the techniques more “real”. The review of each prototyping technique/tool, whether paper or software-based, includes links to additional resources like toolkits, sample images, and the like – these would be especially useful to someone just getting started with a particular tool. Speaking as a designer who’s typically relied on HTML prototypes and Visio, I must say my interest in Adobe Fireworks and, to a lesser extent, Axure is piqued. I think any UI/UX/IX designer, of any level of experience, would get something out of this book. Not that it would be useful only to them – analysts and software engineers will benefit from it as well.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

How do you write software requirements? What are software requirements? What is a software requirement? July 28, 2011

Posted by HubTechInsider in Project Management.
Tags: , , , , , , , ,
1 comment so far
Waterfall Model

Image via Wikipedia

What is a software requirement?

A software requirement, simply stated, is something that matters to someone who matters.

A software requirement may take the form of anything from a high-level, abstract statement of a service or constraint to a detailed, formal specification. Software requirements must serve many purposes during the software engineering process, and so this is the reason that there is so much variation in how they are written and presented.

My main approach to writing requirements can vary in format from project to project, but I tend to prepare a list of software requirements in a computer spreadsheet program like Microsoft Excel or Google Docs, or Open Office Spreadsheet. This requirements document is always dated, ranked, the source of the requirements is always noted for traceability, and it is usually accompanied and supplemented by a catalog of use cases and a functional specification document with mockups and wireframes.

What are the characteristics of good software requirements?

The IEEE has a standard, IEEE 830, that lays out the characteristics according to the IEEE of good software requirements:

1. Correct: The SRS, or software requirements specification, should correctly describe the system behavior. It is not productive to have a requirements document that describes implausible or impossible expected system behavior or user goals.

2. Unambiguous: Software requirements should be written in such a manner as they are not subject to different interpretations. The use of specific and appropriate language can help avoid ambiguity in interpretation.

3. Complete: the software requirements document should completely describe the system’s expected behaviors and feature set.

4. Consistent: Requirements for the system under discussion must not contradict each other.

5. Ranked: You must rank your software requirements for importance. Each software requirement has its own level of importance and criticality, and they are not all equal. By ranking the requirements, software designers ensure that guidance is given to the development team regarding effective prioritization.

6. Verifiable: If the requirement cannot be verified as having been met, then the requirement itself is written poorly. The requirements have to be testable.

7. Modifiable: The requirements must be easy to modify or change.

8. Traceable: The requirements must be traceable, and it is essential that traceability information has been provided, as the requirements document provides the starting point in the traceability chain. I have written elsewhere in this blog at length about the importance of software requirements traceability and have provided examples of software requirement traceability matrixes. Many software development organizations use proprietary CASE software tools and other methods to enforce traceability policies that stipulate how much traceability information regarding requirements must be maintained.

What are some wording and language best practices for software requirements?

I have many years of hard won expertise in writing software requirements. About this topic I have discovered many tips and tricks of the trade that can serve you well as excellent best practices. I suggest that you invent and use a standard format for all of your requirements and requirements documents, including use cases and functional specifications. You should take great care to use language in a consistent way when writing your software requirements.

I recommend that you use “Shall” when you are writing mandatory software requirements, such as “The system shall provide a facility for a store manager to enter an alternate shipping address onto the order confirmation page”.

I recommend that you use “Should” for desireable software requirements, such as “The system should enable the use of as many payment gateways as have been configured by engineering prior to the current release”.

Feel free to boldface or otherwise emphasize or highlight key parts of the requirement. This holds true for use cases ad functional specification documents as well.

I recommend that unless it is absolutely necessary, you should avoid technical language or implementation details in your requirements documents.

What do bad software requirements look like?

What makes software requirements “Bad” software requirements? Well, lack of specificity is one way requirements can be reckoned to be poor. Another way in which software requirements can fail to serve their purpose in the software development effort is when they are written in a way in which they are they are not verifiable. If, for instance, a software requirements engineer were to write a software requirement in which he or she stated the system under discussion was to be “completely reliable”, what exactly would they mean, and how would “reliable” be quantified? If a percentage is used in the writing of a software requirement, the whole or the baseline percentage and boundaries should be specified.

The following are some examples of very poor software requirements — you really don’t want to write software requirements which look like these, trust me:

“The system shall be completely reliable”

“The system shall be maintainable”

“Order rejections shall be less than 99%”

“The system shall be fast”

“The system should use artificial intelligence”

“The system should be totally modular”

What do good software requirements look like?

I have already mentioned IEEE standard 830, which can serve as a fundamental basis guide for you when you set out to write your own software requirements, but let me emphasize a few key points here before setting some example good software requirements before you.

Make sure that your requirements are traceable, verifiable, and specific. Ensure that when you write your software requirements that you quantify any specific qualities that you write about as desireable User goals or User Stories. Make sure you rank your requirements for software development and date them, notating the source of the requirement, the venue of the requirement’s origin, the primary internal and external stakeholders, and the DRI, or directly responsible individual, who is assigned to sheparding that requirement through development. Make sure that you use “Shall” for mandatory requirements and “Should” for optional, or “nice to have” requirements.

“The response time for the system to present the checkout page upon an order button click on a product detail page shall be less than 500ms”

“95% of all transactions on the public-facing webstore portal shall be processed in less than 4s”

“MTBF for the domain controller server shall be 5000 hours of continuous operation”

“The system shall present the closest 5 stores to the user on the map page, provided that 5 stores are within the user-defined search radius”

How do you rank software requirements?

For the most part, I generally advocate a three level rating system for software requirements: mandatory, desirable, and optional. The mandatory requirements cannot be sacrificed, desirable requirements are important but could be sacrificed if necessary to meet schedule or budgetary concerns. Optional requirements are ones which may not be developed, simply due to the fact that they have been rated as being “nice to have”.

Ranking of software requirements comes in handy when the development team needs to make tradeoffs. For example, if time or work force is limited, the development team’s focus can then be placed on the higher ranked requirements.

What is the role of the requirements document in the software development process?

The requirements document is the official statement of what is required of the system developers. The requirements document should include both a definition and a specification of requirements. However, the requirements document is not a design document. To the extent that it is possible, the requirements document should be a set of statements regarding what the system should do, not how it should do it. In the real world, the requirements document does tend to contain some design specifications, which can box in the programmers later if carried too far.

Precise software specifications provide the fundamentals for analyzing the requirements, validating that they are the stakeholder’s intentions, defining what the designers have to build, and verifying that they have done so correctly.

Requirements allow the system’s programmers and software engineers to know the motivation for development of the system under construction. Software requirements also help the engineers manage the process of evolving the software over time and across suites of related software products and web-based services.

Who typically uses software requirements documents?

There are a great variety of stakeholders, both internal and external, who utilize the requirements documents throughout a typical software development project lifecycle. Each of these stakeholders will have a different perspective on the requirements document and they will each put the requirements document to a different use:

1. Customers or clients: will desire to, as completely as possible, express how their needs can be met. They continue to do this throughout the software development lifecycle process as their perceptions of their own needs change.

2. Developers or programmers: will attempt to create a software design that will satisfy all of the requirements laid out by the system designers.

3. QA personnel and testers: will use the requirements document as a basis for writing and conducting the tests they will use to verify that the system functions as it was designed.

4. Managers and project leaders: will use the requirements document as a contract to bid upon the system and then control the production of the software throughout the software development lifecycle.

5. System and Maintenance engineers: will use the requirements document as evidence of what the designers of the system had originally intended for it to do, using this as a guide for continuing evolution and maintenance efforts.

What is software requirements engineering?

Software requirements engineering is a subset or subdiscipline of software engineering that is focused on determining and specifying the functions, constraints, and user goals of the software system being designed.

The software requirements engineering process begins with a discovery project or feasibility study which leads to a discovery project findings document or project feasability report. There are instances, rare though they may be, when a software development project feasability study will actually conclude that the best course of action for a development organization is to not move forward with the development project. Feasibility studies can help your discovery team uncover answers to questions such as these:

1. Is a new technology needed for us to develop the system under discussion? What expenses will be involved in acquiring this new technology or resources experienced in working with it?

2. What is the impact, in all aspects, of not constructing the proposed system?

3. What are the current problems the system under discussion is proposed to alleviate?

4. How will the proposed system allievated these concerns?

5. What will be some of the development and integration problems encountered by the system’s design and programming project teams?

Software requirements engineering is strongly influenced by computer science and systems engineering, however, as developing software is an art, not a science, and since developing software is a human endeavor not generally considered a “true” engineering discipline, software requirements engineering draws upon a number of different disciplines and fields of study. Particularly with respect to understanding the user goals and needs and desires of humans, individuals with a diverse background in anthropolgy, philosophy, cognitive psychology, linguistics and other liberal arts fields often make superb requirements elicitators and software requirements engineers. It is oftentimes business analysts who take the fore in requirements elicitation and gathering in many organizations.

Software requirements engineering for a software development project has a few typical phases:

1. Requirements elicitation and gathering is always a necessary step, as frequently primary internal and external project stakeholders do not know what they want, the requirements can be deeply “hidden” within a client organization, prior requirements may not be validated or verifiable, and even completely incorrect. This is the phase of the project which will largely determine the success or failure of the project.

2. Requirements modeling is a way in which the written, prose requirements are presented in another format. Although effectively doing this can prove difficult for novices, many techniques such as use case modeling, UML diagrams, user stories and user goals can help system designers and requirements engineers and business analysts represent the requirements in a more easily comprehensible or shareable form.

3. Analyzing requirements is the process whereby the requirements are checked for consistency, correctness, completeness, sufficient detail, and writing style and format.

4. Requirements change management is a requisite activity for business analysts and software requirements engineers, as requirements are changing all the time and this process is to be expected and prepared for.

What different types of software requirements are there?

Even though there are many different types of forms software requirements may take, in my own experience a requirements document may encorporate a few different types of requirements within the same document, sometimes subdivided into sections or categorized. I wanted to take some time to explain a little about each of the types of software requirements so that when you are discussing requirements with stakeholders internal and external, as well as your project team, you can more easily express what you mean in terms of what type of requirements and for what purpose you wish to write them.

There is quite a bit of overlap in the functions of each of the types of software requirements I’m about to discuss. Keep this in mind, and remember that one of the points of this excercise is to familiarize yourself with the lingo. Knowing what each of these terms for software requirements refers to can help you forget about classifying your requirements and instead focus on just getting the requirements down on paper (or rather into your computer spreadsheet program or requirements management database) quickly.

1. Functional requirements are generally written from a bird’s-eye viewpoint, or at a high level, although they can also be very detailed, and contain annotations and notes, as well as references to other materials such as screen and page mockups and flow diagrams. They can describe not only what the system under construction should do, but also what it should not do.

2. Nonfunctional requirements are boundary conditions or externalities to the system under construction which will effect the performance envelope or capabilities of the system once it is operation. These types of requirements may include things such as environmental constraints, compliance with federal and state laws or industry regulations, safety standards, timing constraints, quality or uptime properties, programming languages to be used, etc.

3. Design constraint requirements include nonfunctional requirements that relate to hardware limitations and industry standards compliance.

4. Logical database requirements include things such as required data models or database schemas, data entity relationship diagrams (ERDs) stipulating database requirements, data entities and their required relationships, data retention and data integrity constraints, as well as database requirements that specify data access frequency of use data and accessing capabilities.

5. Domain requirements are a type of nonfunctional requirement which has been dictated to the system designers by the application’s domain of operation. For example, a health care application software system may have data integrity and security domain requirements which are derived from the HIPAA health care industry standards regarding private health care information (PHI). Domain requirements may impose new functional requirements or boundary conditions on existing requirements.

6. System attribute requirements are functional requirements which include information regarding the desired system availability, reliability, maintainability, portability and security.

7. Interface specifications are yet another type of functional requirements for software systems which are defined in terms of specifying how the system should interoperate with other software systems. There are many types of formalized notation systems used to specify these types of interfaces, including UML, or unified modeling language diagrams. The interface specifications focus on defining the data entities to be exchanged with other software systems, their structures and representations, as well as defining the interfaces themselves.

7. Performance requirements quantify the desired performance of the system being constructed. Performance requirements are a type of functional requirement, and there are two major types of performance requirements, those that measure or stipulate the performance of static system objects, processes or events, and those that stipulate the performance of dynamic system objects, processes or events. Performance requirements for software system generally take the form of numerically expressed time constraints. A software system’s static performance requirements might include things such as the number of simultaneous users the system would need to support at any given moment of time, whereby a system’s dynamic performance requirements might include such constraints as the number of work orders that would need to be processed by the system within certain time periods for both normal and peak workload conditions.

How are software requirements validated?

It is important to ensure that the requirements for the software system under construction accurately represent not only what the software developers and programmers are building, but also what the customer or client originally desired. Validation is very important, as catching requirement errors early on in the software development lifecycle reduces expense greatly. Rectifying a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

The IEEE has developed another standard, IEEE 830, for best practices for validating software requirements. The IEEE 830 standard lays out some suggested process improvements and gateways, including:

1. Requirements reviews.

2. Manual systematic analysis of the requirements.

3. Software prototyping.

4. Using an executable model of the system in order to verify the requirements.

5. Test case generation.

6. Developing test cases from the requirements in order to validate that they are in fact testable and verifiable requirements as written.

7. Automated consistency analysis.

What is software requirements modeling?

There are a number of different techniques which can be used to model software requirements. Some of these software requirements modeling techniques I have discussed at length elsewhere in this hub tech insider blog, and some of the other techniques for modeling requirements I will explore in more detail within these pages in future articles. User stories, user goals, use cases, and UML diagrams are some of the techniques oftentimes used to model software requirements, but there are many others including formal methods, natural languages, and structured diagrams.

The reason that modeling techniques are used in addition to prose requirements is that English, or any other natural language, inherently adds difficulty to the process of communicating requirements for the poduction of software. These difficulties can include lack of precision and clarity of language to the improper mixing of functional and nonfunctional requirements. The needless overcomplexity of combining requirements until they no longer make sense, in a wierd amalgamation of needs, is a common problem, as is ambiguity of language.

How do you conduct a requirements elicitation and gathering session?

There are many common problems encountered when elicitating requirements for a software system to be constructed. Requirements elicitation is a process in which requirements engineers or business analysts work with customers in order to determine the proposed system’s operational constraints, services, and application scope. There are many people involved in most requirements elicitation and gathering phases of a software development project, and they are collectively known as project stakeholders. Project stakeholders may include domain experts, managers, engineers, end users, and other internal and external personnel.

One of the primary concerns of the requirements engineer is eliciting requirements from stakeholders who are not sure what it is they really want from the system under discussion. Stakeholders can in fact introduce many serious detrimental issues into the requirements gathering and elicitation process that you should be aware of. These can include expressing requirements in their own, often incorrect terminology, providing conflicting requirements, and the introduction by stakeholders of organizational politics and other bureaucratic externalities which may unduly influence the requirements. It is not at all uncommon for stakeholders to feel free to change the requirements at will in response to new stakeholders who may emerge mid-project, as well as shifting business environments. All of these detrimental factors must be carefully monitored and counteracted by the requirements engineer when necessary.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is  Tshirtnow.net.

How do you create a Competitive Analysis? What is a competitive analysis? July 24, 2011

Posted by HubTechInsider in Product Management, Project Management.
Tags: , , , , , , , , , , ,
add a comment

How do you create a Competitive Analysis document? What is a competitive analysis?

Competitive analysis documents can be found as a primary product management deliverable in most every industry, and even the simplest competitive analysis document displays two critical dimensions: the competitors and the criteria, or the competitive framework. The purpose of the competitive framework is to present the analysis data in a way that makes it easy to compare the various products, companies, or services across the different marketplace features or comparative criteria.

Elements of an effective competitive anlysis

Competitive analyses vary along two dimensions: competitors and criteria, and so it is common for most competitive analysis documents to provide a visual mechanism for representing two or more products or services side-by-side with the differences showcased. The specific nature of those differences will vary depending on the competitive criteria the analysis author has selected. These competitive anlysis documents can vary in size, with some much longer than others because they their authors have elected to highlight more product features or more marketplace competitors on the analysis document.

“Two-by-two” competitive analysis plot

Every competitive analysis document shares three essential elements: a purpose statement, the competitive framework, which is the competitors and the criteria, and the comparative data. The analysis document may also provide more details about the overall products, the competitors and their market positioning, or the method behind the comparative analysis results.

The purpose of the competitive framework is to present the data in such a manner as to make it easy for a reader or viewer to compare the products or service offerings across the different comparative criteria.

When the competitive framework takes the form of a table, the competitors or products can run along the top of the table and the comparative criteria along the side. The criteria can vary from the very general to the very specific.

A typical table competitive analysis

A different kind of competitive framework is known in MBA programs as the “two-by-two” graph or plot. The “two-by-two” plots competitors or products on a simple grid depicting only two comparative criteria.

In a two-by-two competitive framework, the number of criteria is down to two, so the analysis tends to be much broader than a traditional competitive framework. The “two-by-two” competitive framework is excellent at turning subjective information into objective information. Although it is technically possible for a “two-by-two” competitive analysis author to use real numbers and actually plot along the scale, most two-by-two presentations are ideal for very broad criteria that might not lend themselves to hard numbers. This type of plot is useful to help identify holes in a market or competitive landscape. Competitors that are clustered around certain areas of the two-by-two plot may indicate that there are opportunities for a competitive product or service to fill those vacuums.

A “two-by-two” competitive analysis plot

Some research organizations use a modified version of the “two-by-two” plot format. Sometimes you may see competitors plotted out on a single square, with “waves” or “bands” of features, strategies, or market postions illustrated as areas of the single square. This format is equally effective, and it has the advantage of being an excellent format for the creation of a catalog of different one square competive analysis plots, one for each area of focus within the competitive landscape. So you could for instance have a single square plot for market positioning, one for revenue or scale of business, one for pltting out competitors’ different revenue situations, etc.

An example of a “wave” or “band” single-square plot

Yet another competitive framework that appears in competitive analysis documents and especially comparisons of different sites or user interfaces: the “small multiples”. This term was coined by information architect and data visualization guru Edward Tufte. In Tufte’s “The Visual Display of Quantitative Information”, he states, “Small multiples represent the frames of a movie: a series of graphics, showing the same combination of variables, indexed by changes in another variable.” In other words, “small multiples” are a series of graphics that allow the viewer to easily compare similar sets of information. In the case of user interface design or information architecture for the web, or graphics design for print or interactive media, this approach is most effective for comparing online and offline page layouts or interactive storyboards.

“Small multiples” chart comparing web site detail pages

Sometimes a competitive analysis will take the form of a table, with various stages of detail added as comparative criteria for each competive category. Great care should be taken by the author of the competitive analysis document that the length of the analysis does not become too unwieldy. Consider breaking up long competitive analysis documents into sections or categories.

Try to use as many graphic elements as possible in your competitive analysis documents. Graphs, charts, plots and tables are all excellent ways to present your competitve analysis data, and you should leverage these artifacts into your presentations and marketing communications.

The data is of paramount importance in a competitive analysis. The data can be as simple as yes-no values, indicating whether a product or service or competitor meets a particular criterion, or it can be descriptive, going into some detail for each criterion.

Yes-No values are a very common way to provide differentiating data in a competitive analysis. You’ve seen these kinds of competitive analyses on infomercials where the product in question is lined up with “other leading brands.” For each feature, the product gets a check mark while its competitors get an X, to show you how versatile the product is.

Feature comparison table

Spelling out your process can help address any possible methodological inadequacies. You might want to spend some time in a section of your competitive analysis document rationalizing the selection of competitors and criteria to increase the impact and veracity of your conclusions.

Explanation of a competitive analysis methodology

Subscribe to HubTechInsider on YouTube

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

What is a Product Roadmap? What is an Engineering Roadmap? July 21, 2011

Posted by HubTechInsider in Agile Software Development, Project Management.
Tags: , , , , , , ,
English: Five-Year Technology Roadmap

English: Five-Year Technology Roadmap (Photo credit: Wikipedia)

What is a Product Roadmap? What is an Engineering Roadmap?

Product roadmaps can provide an organization, particularly a software development one, with the critical difference between success and failure when marketing and delivering software, services, or products to the marketplace.

While normally the purview of a product manager or director, another senior manager (project, program) or executive can also be charged with preparing and presenting a product or engineering roadmap, and when prepared properly, they can be extremely effective.

The benefits of roadmaps can include retention of key customers, business and channel partners, and engineering and product roadmaps can ably guide the strategic planning and engineering efforts of a company.

As amazing it may sound, I have frequently encountered, within the development organizations I have worked at within the Boston area, a lack of types of artifacts I am about to describe. The lack of product and engineering roadmaps that are accessible to viewers, easy for presenters to use in their slide decks and demos, and visually compelling enough and understandable enough so that audiences can grip the feature sets and timelines shown to them is a major cause of planning and project failure.

It is easy to visualize, once we have gone into a bit more detail regarding the different types of product and engineering roadmaps, how project and product planning attempts at companies without these types of deliverables (or the in-house skillset required to even prepare such artifacts) fail miserably. Computer programmers are not the best resources, in general, to call upon to produce these types of artifacts, nor are engineers who have been promoted to management positions. Typically the best preparers of roadmap documents will be from the business or management world, or have a diverse skillset that may be based in engineering, but you definitely need people who can generate business documents quickly and effectively.

Having folks that are knowledgable and skilled with graphic design programs like adobe photoshop, Illustrator, and microsoft visio can speed the roadmap creation process tremendously. When you have found the right internal resource or team to create these roadmap documents, you will know it, as the right people will already possess some amount of experience with roadmap and business strategy content creation.

It is not enough, please keep in mind, for a company to “short shift” the production of these roadmap documents, because it is only through the repeated creation of roadmap documents, and through their constant updating and presenting to audiences internal and external, will your organization be able to increase its ability to produce roadmap documents quickly.

A complete catalog of engineering and product roadmap documents should be created: eventually. If your company cannot mount such a concerted document creation efforts due to staffing concerns, just create what you can. Cherry pick the type of roadmap document you think would create the most value for your own organizational requirements from my detailed list below.

An example of a roadmap from Microsoft

It could very well be that your organization’s needs for a roadmap document are clouded by the sales department or company management demanding an engineering or product roadmap (sometimes in support of sales efforts) under-the-gun. Never fear: I have not only provided the information you need, I have lots of examples and pictures of product and engineering roadmaps as well as Microsoft visio and excel templates for simple and complex roadmap documents. You can use these microsoft excel product roadmap template and microsoft visio product roadmap templates to create your product or engineering roadmap quickly, avoiding trouble just when you’re getting started.

If you are a product management professional, and you are tasked with the responsibility for the ultimate success of a product line or engineering effort for your company, it is of paramount importance that you produce a roadmap document that can drive strategy, provide a clear idea of where you are headed with your efforts or product(s), and can be shared easily with internal and external stakeholders and business partners and analysts, even the press.

A product or engineering roadmap document may be appropriate when you are called upon to support a pre-sales or sales effort for your organization. Demos, presentations, press releases, investor and business meetings are all very good occasions for product or engineering roadmaps to assure clients, partners, and employees that there is a consistent and cogent plan of action and guide for resource planning and engineering efforts.

There is a wide variety of different names and definitions for all manner of roadmap documents. The important principle to adhere to is you should find and adapt the type of roadmap document you are comfortable with and that you find works for you.

What are the different types of product roadmaps? What are the different types of engineering roadmaps?

Speaking generally, there are five major types of roadmap documents: Product roadmaps, platform roadmaps, market roadmaps, strategic roadmaps, vision roadmaps, and technology or engineering roadmaps. You can, of course, mix and match these roadmap types to suit your organization’s needs.

How do you create a product roadmap? How do you create an engineering roadmap?

There are eight steps I always follow when I am asked to create each of these types of roadmap documents – you can mix this list of steps with your own ideas and experiences in creating roadmap documents:

1. Decide upon which type of roadmap document you will use based on your individual requirement for a roadmap document.

2. Think about how much time and effort, as well as level of detail, you think will be required for you to invest, or that you care to invest, in the creation of your chosen roadmap document type.

3. Brainstorm about significant forces or trends that you might want to represent on your roadmap document. These could include technical breakthroughs, market forces, and moves the competition has made recently.

4. Elicitate the precise roadmap document requirements from the primary internal stakeholders in the project, and document and prioritize those requirements, being careful to estalish and maintain traceability.

5. Product Roadmap documents are intrinsically linked with time, so think about the timeline you want to use and represent in your document.

6. Think about the impression your strategy will make and how you want to present that strategy in your roadmap document. This is one of the central purposes of the document you are preparing, to show that you have a strategy and are planning to implement it well and to schedule.

7. Sometimes I create an internal roadmap document and distribute it to the primary internal stakeholders within my organization for review and commentary. After gathering the project team’s comments regarding the internal roadmap, there is a good basis on which to draft the external roadmap document.

8. This colloborative approach is critical to obtaining buy-in from senior management as well as the roadmap document project team. This method also prevents surprises and last-minute revisions. Discussions surrounding the creation of roadmap documents can help solidify the company’s direction and clarify the intents of management to employees very effectively.

Prioritizing product and engineering roadmap features

There are probably potentially many features you could choose to highlight as a part of your product or engineering roadmap document. But in the interests of brevity and clarity, you will need to prioritize the features that are included in each of your upcoming product or service introductions or software releases and shown on your roadmap.

I have always found that a prioritization matrix document is the best bet for effective and colloborative feature selection for inclusion in a roadmap document. Microsoft Excel or another computer spreadsheet program works very well for preparing this type of document. The matrix should hold information regarding such components as startegic importance, tactical importance to the current release cycle, customer desireability level, retain revenue threat from customer dissatisfaction, revenue impact, source and date of the feature, planned release, etc.

Themes can be used to categorize major feature trends that you begin to see emerge from your prioritization matrix. Categorize like features into themes and then select one or a few major themes to represent graphically on your roadmap documents.

Timed release cycles use the timescale along the edge of your roadmap document to show when features will become available. This type of roadmap document is driven by time and not by features. Once the release interval is decided upon, then the feature list is divided up amongst the releases those features are planned to become available with.

The golden feature technique is one where each release is governed mainly by one important or central feature. Once you have selcted the golden feature for each release of a product or service that you are attempting to show on your roadmap document, then you will be able to focus the audience’s attention on that one feature, and highlight it in all your continued planning efforts for that release.

Using multiple roadmap documents

Combining a few or several different types of roadmap documents can greatly enhance your presentation, showing that you know where your company is headed and why it is that you have choosen to pursue a certain strategy. A vision roadmap could be used to open your presentation, showing trends in society at large that are afecting your marketplace. A technology roadmap could then be shown to your audience that reflects how your company and it’s products are capitalizing on technology trends within the marketplace. Then it is time for you to show off your internal and external product roadmaps, and perhaps your engineering roadmap that shows your planned releases and when certain feature sets will become available.

Showing multiple product lines on roadmap documents

You may need to show a few or several of your product lines on a roadmap, in order to visually represent how each of your product lines will evolve in accordance with a technology or marketplace trend. This is very easy to accomplish; simply create a roadmap document for one of your product lines or services,and then use that one product line as a template for showing the others on your single roadmap document.

I have found that it is helpful in many cases to create a prioritization matrix such as the one I mentioned elsewhere in this article regarding features to show on your roadmap documents. You can also create a product line prioritization matrix that can be used for discussion and colloboration with your internal stakeholders.

A product roadmap showcasing multiple product lines

Try and decide upon which projects, products, or services your company is undertaking that are the most important to your company, which ones should be funded and resourced, and which ones should be cut. Revenue potential, market positioning, strategic importance to the company, and interdependencies can and should be plotted out on this matrix. Once you have decided which products you want to represent on your roadmap document, it is a simple matter to modify your format to include multiple product lines on a single roadmap.

Five tips for creating product roadmaps

Here are a few more best practices that I have discovered throughout my career of preparing product roadmap documents.

It is essential that you realize from the outset that when working with a technical (programmer) audience in certain working environments, there may be a fair bit of resistance or friction originating within internal departments or product groups at your own company that you will need to overcome.

Many internal stakeholders may take umbrage at the point in the release cycle that certain features are slated for release on your roadmap document, they may assert strongly or even rudely that your presentation is false or feature sets you are publicly committing to will not be available.

It is important for you to always be ready to provide reasoning why the roadmaps are necessary, and why managing without such documents, at certain levels of business, becomes untenable.

1. Make sure that you colloborate early with your team. Your chances of being able to secure ultimate buy-in from the different internal constiuency groups within your company goes up markedly if they have been included from the roadmap document project’s outset.

2. Always use code names on your roadmap documents until they have been approved by the senior management team for release to the public at large. You cannot be sure that your roadmap documents will not be leaked out, even by senior managers. You can revise the code names to final product and project names when they are approved.

3. Minor releases and localized, international releases are sometimes not shown on product or engineering roadmaps, and they should be included, as they frequently enter into the follow-on conversations.

4. Create roadmap documents for an internal audience that are very specific in information and dates; roadmap documents intended for an external audience should be worded in more vague language and terminology.

5. Present your roadmap documents as uneditable adobe .pdf documents — this will prevent other parties internal to your company from taking the roadmap documents and altering them – these alterations can emerge unpleasantly later during the project(s) as a committment made to a client or customer by a senior manager or executive, so take care to avoid this scenario.

Examples of internal and external roadmap documents

Product roadmaps

Microsoft SQL server product roadmap

If you need to show your audience when your product’s new features will be available, what the theme or main and secondary features of the product release or next few releases will be, then an effective product roadmap should be your tool of choice.

Internal product roadmaps can be used to communicate budget, resource planning, project priority, and release planning to employees and department heads. They are extremely effective for driving efforts to obtain funding from senior management or corporate action committees.

An example of a product roadmap

External product roadmaps can be used to support funding efforts from investors or investment groups, business partner meetings. External product roadmap documents and slides can be used to reinforce public press releases and press conferences, analyst meetings and conference calls or webcasts, clients and channel partner webinars. It is oftentimes apparent that external roadmaps have been recast in a more vague tone as a result of internal roadmap feedback, which is generally a good thing.

Platform roadmaps

A platform roadmap

A platform roadmap is used to showcase what will be n the works for the platform or PaaS (Platform as a Service) that a particular company has under development. They are used to communicate that company’s overall platform strategy and the availability of APIs (Application Programming Interfaces, basically plug-ins to amd from the company’s platform software) and development tools for the company’s platform or PaaS.

If a company has developed and is supporting a platform in the marketplace currently, you can be sure that they have a platform strategy that relies on partners and clients working closely with them. The need to communicate the platform’s strategy in a clear and focused manner is very important. Examples of platforms include Salesforce.com (Force.com), Windoes (Windows Azure Cloud), Amazon S3 and Ec2, Google, Apple Mac OS X, Apple iOS, Hp WebOS, and many others.

Vision roadmaps

A vision roadmap example

There are times when at the onset of a demo or presentation, it is necessary to highlight for your audience how your product or products fit into a movement or trend within society in general or your company’s inductry in particular. This is a fantastic way in which you can build excitement and marketplace momentum for your company’s products or services by visually demonstrating how you fit into the big picture.

Marketing roadmaps

Microsoft Windows OS roadmap

A marketing roadmap communicates to your internal and external stakeholders what market segements your products and services are targeting, and how you plan to enter any of those markets in which you are not currently competing. As such, these types of roadmaps include information on the demographics and opportunity size of each marketplace, and information regarding how you plan to develop products and services to address each market. The timescale involved on marketing roadmaps can span years.

Marketing roadmap example

A marketing & strategy roadmap

Technology and Engineering Roadmaps

Technology and engineering roadmaps chart out major technology trends that exist in the marketplace, and show how your company’s products and services coordinate with those trends over time. Engineering roadmap documents are used to communicate feature sets that will be available in certain releases. The approximate release dates of each of the company’s upcoming product releases will be shown.

A technology roadmap

It is very common for a software development organization to create and maintain multiple engineering roadmaps, suitable for showing to various segmented audiences of internal and external stakeholders and directly responsible individuals. These engineering roadmaps are super tools for updating major clients and customers of your release cycle and aid greatly in the change management process.

A Microsoft Technology Roadmap

Engineering roadmaps also provide your internal development groups, qa, testers, programmers, business analysts, and product, program and project managers, as well as senior management, with a view into the development life of the company. A development organization that fails to produce such planning artifacts is essentially flying blind, and as they scale up (if they do scale up) as their business improves, they will find they lack the requisite skills needed to plan effectively and manage their clients’ expectations for quality products, software and services well.

Product roadmap template

Engineering roadmap template

I have included in this article many pictures and descriptions that you can use to create your own highly compelling product roadmap documents. They should serve as an excellent guide for not only the different types of roadmap documents that exist out here in the marketplace, but also how to place multiple product lines and services on a roadmap document.

Keep in mind, these are living documents, and should be continuously maintained and updated. Do not succumb to the programmer’s maxim “You can’t plan the future”. Remember: Plans are worthless, planning is priceless. The activity of creation, the discussion that surround the roadmap process, are all essentially components of effective long term product planning and corporate strategy.

Roadmaps can be used to share information with internal teams, external constituents or as a planning tool for the Product Management team, but whichever you choose, you have to figure out whether you are going to make the focus of the roadmap strategy or release calendar. If it is strategy, your timeline can be vague — quarters or years. If it’s release calendar, the near-term has to be pretty specific: exact date or month, but the future can be more nebulous.

I have include a few simple microsoft visio and microsoft excel roadmap document templates to get you started. By all means, you should feel free to use the illustrations and prose contained in this article, as well as any graphics or business drawing tools that you are comfortable with, to create your own formats and presentations. Some of my favorite programs for creating these types of artifacts with include adobe illustrator, photoshop, microsoft visio, microsoft excel, and coreldraw. I also have a big bag of Linux and Apple Mac OS X tools that I use to create roadmap documents in addition to the ones I have just mentioned. Product management software such as Accept, Accompa, FeaturePlan, FocalPoint and others can also assist you in creating roadmap documents. If you need help or advice, I am always available via email or social media like LinkedIn. If we’re not connected on LinkedIn, please send me an invitation to connect. And good luck with your roadmaps!


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is  Tshirtnow.net.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

What is UML? What is Unified Modeling Language? July 17, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , , , , , , , , , , ,
add a comment
A collage of UML diagrams including use case d...

A collage of UML diagrams including use case diagram, class diagram, activity diagrams, sequence diagrams, deployment diagram,component diagrams, composite structure diagram, package diagrams. (Photo credit: Wikipedia)


What is UML?

UML is an acronym for Unified Modeling Language. UML is widely accepted as the de facto standard description language for the specification and design of object-oriented software systems. UML is a family of “languages”, or diagram types, that attempt to bring together the “best in breed” software specification techniques for describing software systems. Users and practicioners of UML can choose which members of the family are the most suitable for their application domain.

Personally, I have become associated with UML through my years and years of specifying software products. Several of the UML diagram types that I will discuss below are among my primary tools for communicating application and system requirements and software designs to programmers.

I do not advocate, nor do I personally practice, an over-attachment to UML. Like many of these project management and requirements management techniques, there is a time and a place for the proper introduction of these types of UML artifacts into the software development process. Programmers may be unfamiliar with the UML diagram types and symbology, and so if you are a business analyst, project, program or product manager, and you are using these types of project deliverables with a new staff of engineers, be prepared to explain the UML diagram type you are using, keep the introductions down to one or two different new UML “Languages”, or diagram types, at a time.

I also recommend that if you insert UML diagrams into your functional specification documents, and I recommend that if you have invested the time to properly prepare UML diagrams that you do leverage them into your spec docs, make sure that you include an explanatory prose component into your accompanying functional specification document’s text.

There are nine different types of UML languages, or diagram types:

1. Use Case.

2. Sequence.

3. Collaboration.

4. Statechart.

5. Activity.

6. Class.

7. Object.

8. Component.

9. Deployment.

Five of these diagram types render behavioral views, the use case, sequence, collaboration, statechart and activity diagrams, while the remaining four diagram types are concerned with architectural or static aspects of the software design.


How does UML help in specifying a software design?

UML is a graphical language that is based on the premise that any software system can be described in terms of interacting business entities and that various aspects of these entities and their interactions, can be described visually using one or more of the above nine types of UML diagrams.

Use Case diagrams represent and document the dialog between external (to the system under discussion, as in an embedded system) actors and the system.

Sequence and collaboration diagrams describe interactions between objects.

Activity diagrams illustrate the flow of control between objects.

Statecharts represent the internal dynamics of active objects.


What is UML 2.0?

UML 2.0 is a revision to Unified Modeling Language that incorporates several improvements to UML. UML 2.0 is only just now beginning to supplant UML as the de facto standard.

A shorthand description of UML 2.0 is that it is designed for more rigor of specification, and it can sometimes be too much, or too much of a fine-grained distinction to bandy about when in an actual day-to-day, working software development environment. You are very likely to be working with only a subset of the UML languages, or diagram types, I outlined above at any one given point in the development project.

UML 2.0, when the diagrams are laid out in a software program such as VisualUML or others, can actually be used to generate working object code. If the business analysts have developed their proficiency enough with UML diagramming software, they can actually construct and output from these programs working java (or other programming language) object code.

In order to obtain this level of integration with application programmers, UML 2.0 had to have more access to a more robust and constrained specification language. The improvements to UML 2.0 include:

1. New base classes that provide the foundation for UML modeling constructs.

2. Object constraint language, a formal method that canbe used to better describe object interactions.

3. An improved diagram meta-model that allows users to model systems from four viewpoints:

a. Static models (e.g., class diagrams)

b. Interaction (e.g., using sequence diagrams)

c. Activity (i.e., to describe the flow of activities within a system)

d. State (i.e., to create FSMs, or Finite State Machines, using state charts)

UML has always been used to not only specify software systems for systems and application programming, but also specification for embedded systems as well. This emphasis on the notion of time and state is evident in the way that sequence diagrams are implemented in UML, and indicates the special considerations that were undertaken to support embedded systems design in the original conception of UML.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

What is pattern-based software development? What is pattern-based design for software projects? July 17, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , , , , ,
1 comment so far

UML class diagram describing the Prototype des...

Image via Wikipedia

What is pattern-based software development?

What was the original impetus behind the development of software development patterns, and why do we need them? Why did programmers invent patterns for software development?

Well, developing software is very difficult, and developing software that can be easily reused is even harder. the designs for sections of software code should be general enough solutions to be able to address future problems and requirements flexibly while still being specific enough in order to address the current problem at hand. Programmers that are experienced at designing software systems know better than to design their system using one-off problem solutions, and instead reuse patterns that they have grown familiar with through prior use in similar situations and scenarios and reuse these solutions as a basis for their new designs. The basic fundamental principle of software engineering known as the “Principle of generality” predicts and encourages this behavior.

What’s so great about programmers using pattern-based development on software projects?

For one thing, it is absolutely fascinating to sit in a meeting room with a group of programmers who have been working all together on a software development project using patterns for a few months. The rate of information exchange is extremely high, with a idea mentioned by one programmer, and a few others simultaneously finishing the first programmer’s sentence with an exclaimed, unison word like “Bridge!”, and then one of them scribbling lines of code frantically on the whiteboard as the rest nod in compliment.

The language of the programming team using patterns is mysterious and magical, almost like incantations spoken in some artful black language. Many computer science instructors contend with conviction that the teaching of patterns and the learning of them speeds the learner’s adoption of the principles of object oriented software technology. It is undeniable that the learning of patterns improves the programmers’ development vocabulary.

Software design patterns also help in finding appropriate objects, in determining the apropos object granularity and in designing a software system that is architected from the outset to better adapt to change. At the design level, patterns enable large-scale reuse of software architectures by capturing the expert knowledge of pattern based development and distributing it throughout the development team.

It is generally acknowledged that these are the two most important benefits: the way in which they form a vocabulary for articulating design decisions during the normal course of development conversations among promgrammers. This can also come into play during the close programming work of so-called “pair programming“, among those who have found it to be useful for them.

When you are working with a group of programmers who are either working in pairs or as part of a group using pattern-based development, you frequently hear talk like “I think we need a strategy here”, or, from one programmer to the rest of the group, “Let’s implement this functionality as an Observer”.

Programmers’ familiarity with pattern-based development has also become a kind of hiring shorthand. Whenever a talented programmer leaves a software development team I am leading, and we need to replace him or her with anther programmer, I use the “Do we need a programmer familiar with design patterns” question as a line of demarcation for recruiting and hiring decisions. The answer is *not* always to hire an expensive programmer intimately familiar with design patterns, either.

It is fashionable in development manager circles to use design patterns as a hiring demarcation line as well, as in the following exchange:

“So…regarding design patterns: what would you say is your favorite design pattern?”

“Well, the factory, I guess.”

“Yeah…OK…thanks for coming down.”

What does a software development pattern look like?

A pattern is a problem-solution pair that can be applied in a similar fashion in new contexts; the pattern is complete with advice on how to apply it in the new context. It is important to note that the formal definition of a pattern is not consistent in the literature.

There are three types of patterns:

1. An architectural pattern occurs across software subsystems.

2. A design pattern occurs within a subsystem but is independent of the language.

3. An idiom is a low-level pattern that is programming language-specific.

Each individual pattern is compromised of four elements:

1. A name. Some of the names of the software design patterns can be rather whimsical: “flyweight”, and “singleton”. The whimsy is to serve the purpose of making the patterns memorable to programmers.

2. A problem description. The problem part of the pattern describes the problem and its context, as well as specific design issues such as how to represent algorithms as objects. The problem statement may also speak about when it is best to apply this particular pattern and may also describe class structures that are symptoms of an inflexible software design.

3. A solution to the problem. The solution part of the design pattern does not desibe any one particular concrete design or implementation, but only describes the elements that make up the design, The solution only provides a general arrangement of objects and classes which can be used to solve this type of problem.

4. The consequences of the solution. This part of the design pattern describes the results and inherent risks and trade-offs associated with applying this particular design pattern. It may include the impact of this design pattern on space and time, programming language and implementation issues, or include notes on software flexibility, system extensibility, and portability. These consequences are critical for evaluating alternative software design patterns.

What is the history of software design patterns?

The concept of design patterns was first introduced by Christopher Alexander for use in architecture and town planning. He realized that architects encounterd the same sorts of problems when engaged in the design of buildings and once an elegant architectural solution to these common problems was discovered, it could be repeated over and over again. In 1977, he wrote a book, published by the Oxford University Press, called “A Pattern Language”, in which he stated:

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”

Design patterns as an idea were first applied to computer software programming in the 1980’s, when the infamous “Gang of Four” book, “Design Patterns: Elements of Reusable Object-Oriented Software” popularized the use of design patterns. Ward Cunningham, Kent Beck, and Jim Coplien were some of the initial practicioners and popularizers of software design patterns.

What are the “Gang of Four” software design patterns?

The “Gang of four” book first introduced this set of patterns into the software programming world. The book lays out 23 design patterns for software development, and it was first published in 1995. Building upon the work of Kent Beck, Christopher Alexander, and others, the gang of four set out to redirect all of the effort being put into “rengineering the wheel” in software development teams all over the world and redirect it into something much more useful.

The book was an instant hit with computer programmers, selling over half a million copies since its publication in 1995 and undoubtedly influencing the thoughts and code of millions of computer programmers worldwide. Many computer programmers can vividly remember buying their first copy of the book and in addition many computer programmers look upon their reading of the book as a rite of passage. It can be a difficult book to get through, and it is not infrewunt for even advanced computer programmers to have to spend several readthroughs in order to extract the desired effects out of their investment of time in the gang of four’s words. The book did two very important things for programmers:

First, computer software programmers were introduced to the world of design patterns, where each pattern is a prepackaged solution to a common design problem. The book encourages programmers to look at their code and to find and identify common solutions to common problems. Programmers should give each solution a name, and they should talk about what each solution is good for, and when to use each solution, and when to reach for something that is a more appropriate solution. If all of these solutions are documented well, then over time more and more programmers will become better and more effiecient programmers, and this knowledge can be distributed throughout the developer community in the most direct and sane way.

Secondly, the book describes 23 software design patterns that are organized into three groups based on the intention for their use: creational, behavioral, or structural:

1. Creation design patterns are associated with object creation and their intent is to allow programmers to create software objects without actually knowing what they are creating beyond the interfaces themselves. There is a fundamental principle in computer programming, known as information hiding. When programmers code using interfaces to object creation and objects, then they are following this fundamental principle well.

As described by Gamma, Helm, Johnson and Vlissides, the “Gang of four”, these creational patterns include the abstract factory, the builder, the factory method, the prototype, and the singleton.

2. Structural design patterns are concerned with organization classes. Structural design patterns are static in nature; they are not designed to change. As laid out by the Gang of four, structural design patterns include the adapter, the bridge, composite, decorator, facade, flyweight, and proxy.

3. Behavioral design patterns are concerned with runtime or dynamic system behavior of the program, and they help define the roles of software objects and their interactions. By their dynamic nature, behavioral patterns are designed to change, and are not static and contain very little “structural” code. The gang of four describe behavioral software design patterns called the chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template method and visitor.

In the years that have followed the publication of the gang of four book, and as I will get into in more depth here in a moment, many different sets of alternative design patterns have been proposed. the original gang of four patterns – the 23 patterns I wrote of above – really stick to the old school, middle ground of object-oriented software design. Smaller than a database system, but larger than just a simple hashtable. They focus on some very key questions that face all programmers that are tasked with building an object oriented software system: how do you know what types of objets to create, how many, and how? How should these objects relate and interoperate? What should they know about each other? How should they be coupled together? How can programmers swap out parts that are likely to change frequently with the most efficiency?

What are some of the situations in which a software design pattern might be used?

Each individual situation which is faced by software programmers will have an individual solution tailored for that specific situation. If this were not the case, then a piece of complete, reusable software code could be used, instead of the rough problem-solution description of a design pattern.

It is not difficult, however, for me to illustrate a few of the scenarios and what type of design pattern could potentially be used to address this situation:

If a programmer is faced with a situation in which there needs to be one and only one instance of a class in the application – the single class that everybody uses. This would be a scenario for the singleton pattern.

If a programmer needs to include code from another programming language to best solves the problem at hand, then the programmer could use the Interpreter design pattern in order to use that code programmed in another language directly.

If a programmer is faced with a scenario in which an object needs to be created according to a complex, precise, and changing, set of parameters. In this circumstance, perhaps the builder pattern would be best to utilize.

If a programmer or development team is faced with a scenario where they have objects which need to take on additional responsibilities at runtime in addition to their established responsibilities, then the decorator design pattern made be called for.

Are there any other popular sets of software design patterns?

There are indeed many other sets of software design patterns. For instance, Martin Fowler laid out a very popular set of software analysis design patterns in his 1996 book, “Analysis Patterns: Reusable Object Models” , and there was also a set of software architecture and design patterns laid out in the excellent and well-read book, also published in 1996, “Pattern-Oriented Software Architecture, Volume 1: A System of Patterns“.

But one of the most popular and well-known, regarded, and most-used set of software design patterns was popularized by Craig Larman in his 2002 book, “Applying UML and Patterns“. He called them the GRASP patterns, for general principles in assigning responsibilities, and they are a fairly high-level set of patterns for software design. There are nine GRASP patterns for software design:

1. Creator.

2. Controller.

3. Expert.

4. Low coupling.

5. High cohesion.

6. Polymorphism.

7. Pure fabrication.

8. Indirected.

9. Protected variations.

I will select one of the GRASP patterns I have listed above and describe what the pattern actually is in terms of the name of the design pattern, the problem the design pattern is trying to solve, and the solution for the problem as implemented using the design pattern.

For instance, a scenario that would be best served by the Creator design pattern would be one in which the problem is that it is unclear who should be responsible for creating a new instance of a class.

The solution as proposed by the Creator pattern would be to assign this responsibility to a class B to create an instance of class A if one or more of the following is true: (a) B aggregates A objects, (b) B contains A objects, (c) B records instances of A objects, (d) B closely uses A objects. B has the initializing data that will be passed to A when it is created.

How about design patterns in the Ruby programming language?

You probably realized that I wasn’t going to write an entire article of this length and depth without pimping Ruby. Design patterns are particularly easy to implement in Ruby, partially because of similarities between Smalltalk, the programming language used by the Gang of four to illustrate their programming examples in their design patterns book, and Ruby, and partly because of syntax peculiarities inherent in the Ruby programming language.

Ruby’s absence of static typing lowers the overall number of lines of code to begin with, and the Ruby standard library (if you have been paying attention, you recall the difference between code libraries and design patterns) makes it possible to implement many of the most common design patterns in Ruby with a single one-line include.

Other design patterns are essentially built into the Ruby programming language itself. For instance, a Command object in the canonical Gang of four sense is a state-aware code wrapper, something very closely approximated by a Ruby construct known as a Proc, or a Ruby code block object. This is not to say that although a simple Command construct can be implemented in Ruby with a single one-line include, if we add more complex state and behavior information to the block, the implementation will not need some additional Ruby code. As I stated earlier in this article, and without equivocation, design patterns do not lead to direct code reuse, this is the work of software libraries.

The main point I am trying to promote is that because design patterns are the common idioms of object-oriented software code, a good or great programming language should make design patterns easy to implement, or even make the use of them nearly a transparent excercise, as if the design patterns’ usage was inherent in the use of the language itself.

Ruby works marvelously well in a pattern-based software development environment because:

1. Static typing reduces code bloat and overhead. Common patterns can be implemented in less code. You can turn a class into a singleton with a simple “include singleton” command.

2. Ruby has code closures, which means that chunks of code can be passed around complete with their associated scope within a program without having to construct entire classes and objects whose only purpose is this scope and code transferral.

3. Ruby classes are real objects, so any runtime operation that can be applied to a Ruby class can be used to implement the logical intent of any of the design patterns. A Ruby class can be modified by adding or deleting methods. A class can be cloned and the copy can be modified while leaving the original class unmodified.

4. Ruby has mixins, which in addition to the same inheritance of other programming languages, is a simple yet sophisticated way in which Ruby code can be shared among several Ruby classes.

One of the books I recommend all Ruby programmers read is “Design patterns in Ruby“, by Russ Olsen, with a foreword by renowned Ruby programmer Obie Fernandez.

In the book, you will learn why there are only 14 patterns in Ruby instead of 23 original Gang of four patterns, and you will also find out about three new Ruby-specific design patterns that have a great deal of usefulness in Ruby.

Are there any drawbacks or negatives to using pattern-based software development?

Well, actually, there are several drawbacks to all of this talk of pattern-based software development.

One of the main drawbacks, and one of the most important thing for technical project managers and business stakeholders as well as senior managers to keep in mind, is that patterns do not lead to direct software reuse.

Direct reuse of sections of software code is for software libraries. Patterns do not create or promote software libraries of reuable plug-and-play software code, but rather lead to reuable design, architectures and techniques which can be converted by computer programmers into unique program code.

Even though the cutesy names of software design patterns may lead you to believe that they are also simpe to learn, they are not. It is easy enough to master some of their names, and to also memorize their structure visually, but it is not very easy to see how they can lead to actual design solutions. This can take even very experienced computer programmers years and years of practice, education and working experience.

Integrating the use of software patterns into an actual, real-world development organization’s daily development life and regular deployment cycle can be a daunting task. The integration, aside from the demands the aforementioned education and training can take on a development staff compromised of computer programmers unfamiliar with the software design patterns described above, is a very labor-intensive activity.

A software development team’s programmers may experience pattern overload, whereby in their unending quest to use pattern-based techniques, they have become an obsession rather than as an effective and efficient means to an end. Aa mentioned above, software design patterns are no silver bullet, and do not lead to direct code reuse, but rather provide another approach to systematically solving software design problems that are commonly and frequently encountered by software development teams.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

What are the qualities of bad software code? How can you tell if your software project has bad code? July 12, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , ,
1 comment so far

Image via Wikipedia

What are the qualities of bad code? How can you tell if your software project has bad code?

Troubled software projects and bad code are facts of life in the software business. Today’s applications, system software, even embedded and operating systems programming is increasing being outsourced or at least distributed.

The need for being able to quickly evaluate the quality of software code, describe any known issue in simple aterms and then execute on a planned approach to rectify these issues is greater than ever.

A common vocabulary for project teams, refactoring engineers, and project managers and stakeholders is of a fundamental assistance in manageing software development projects.

You may find yourself sitting in a meeting or conference room or perhaps on a conference call with a group of computer programmers who are discussing some sections of code, or if you are particularly unlucky, perhaps an entire application of software development project, that is troubled using some of these below listed terms. After each of these negative, “bad code” terms I have tried to describe what is meant by each of these terms for bad software. After each description, I list the term for the opposite, positive “good code” quality contrary to the bad code quality.

1. Fragility: When changes in the software code cause the system to break in places that have no conceptual relationship to the part that was changed. This is a sign of poor design. The opposite of fragility is known as robustness.

2. Immobility: When the code is hard to resuse. The opposite of immobility is known as re-usability.

3. Needless complexity: When the design is more elaborate than it needs to be. This is sometimes also called “Gold plating”. The opposite of complexity is known as simplicity.

4. Needless repetition: This occurs when cut-and-paste of code segments is used too frequently. The opposite of repetition is known as parsimony.

5. Opacity: When the code is written in such as manner as it is not clear. The opposite of opacity is known as clarity.

6. Rigidity: When the design is hard to change because every time you change something, there are many other changes needed to other parts of the system. The opposite of rigidity is known as flexibility.

7. Viscosity: When it is easier to do the wrong thing, such as a quick and dirty fix, than the right thing. The opposite of viscosity is known as fluidity.

In order for your software development project to feature the opposite, more desirable positive qualities to the ones listed above, your project must exhibit a good software architecture, solid software design, and effective coding practices.

For further reading on this topic, I highly recommend the excellent book by R.C. Martin, “Agile Software Development, Principles, Patterns, and Practices“, Prentice-Hall, Englewood Cliffs, NJ, 2002.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

What is software traceability? What is a software requirements traceability matrix? July 12, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , , ,
add a comment

What is Traceability in software development?

In my experience working on custom software development projects, the number one cause of project failure is inadequate requirements. When programmers code either without requirements or with inadequate requirements, nothing good ever comes of it.

The relationship between the requirements, the source of those requirements, and the system design that is ostensibly being built to enable those requirements, is what code traceability is all about.

I think it is very important to point out that regardless of the software development lifecycle process model you and your team happen to be following, be it a traditional “Waterfall” type software model or a so-called “Agile” fixed-iteration development lifecycle, documentation and code traceability is paramount.

If your software has provided for a high level of traceability, then the requirements can flow down through the design and code and then can be traced back up at every stage of the process.

This makes it a simple matter to trace a coding decision back to a design decision to satisfy a corresponding requirement.

In embedding systems software engineering, traceability is vital because hardware constraints can act as limiting factors on design and coding decisions that may not be as easily associated with a requirement as in a non-embedded system design.

When even a basic “traceability matrix” is not provided for on a software project, then the lack of a traceability path from design and coding decisions back through to the requirements can lead to severe difficulties in extending and maintaining the system.

What is a software traceability matrix?

A software traceability matrix document can take many different forms, but one of the most common forms is a table-like document that serves simply as a graphical representation of all of the cross referenced links between project deliverables and artifacts, and the code.

This cross referenced table is constructed, usually using a spreadsheet application program, by listing the relevant software documents and then the doe unit as columns, and each software requirement as a row.

An example of a software requirement tracing matrix.

If you use a spreadsheet program, then you can create multiple matrices sorted and cross-refernced by each column as needed. For example, you could provide a traceability matrix sorted by test case number, which could serve as a very apropos appendix to the test plan.

The traceability matrices should be updated at each step in the software life cycle. For example, the column for the code unit names, things like procedure names, object classes, etc., can not be added until after the code is developed.

What are the elements of a good traceability matrix?

A traceability matrix is a document, sometimes in the form of a table, that will provide a cross reference between all the documentation and software code in a system.

At a very minimum, a good traceability matrix will provide links, or cross references showing the associations between the following elements:

1. From the requirements to the stakeholders who first proposed these requirements, with the dates they were first proposed.

2. The associations between any dependent requirements listed.

3. From the requirements through to the system design, or functional specification document.

4. From the design to the relevant code segments. (oftentimes referencing the technical specification document).

5. From the requirements to the test plan document.

6. From the test plan to the relevant test cases.

What is requirements traceability?

Software requirements traceability is the ability for a project team to provide references that document the relationships between the software requirements, their sources, and the system design. If software requirements traceability has been provided well, then the requirements can be linked to their source, to other requirements, and to design elements.

Requirements traceability links between the different requirements, source traceability links these requirements to the stakeholders who proposed those requirements, and design traceability link from the requirements to the system design documents.

The software requirements document, sometimes referred to as the SRS, or software requirements specification document, MUST be “traceable”, because the software requirements provide the starting point for the entire traceability chain.

It is very common within professional project management organizations, or PMOs, to enact and enforce traceability policies which codify how much information regarding requirement relationships is required to be maintain, and the format in which this information is to be presented. There are a number of open source and proprietary open-source tools which can be used to help improve a software organization’s requirements traceability.

A traceability matrix sorted by requirement numbers that correspond to a numbering scheme

The overarching goal of software traceability and software traceability matrix is to ensure that for critical software, nothing falls through the cracks. Ultimately there is a way of mapping for each requirement which test cases exist to cover that requirement and the functional specification.

As shown in the sample traceability matrix above, one way to show the traceability from requirements through design and testing is through the use of an appropriate numbering system throughout the documentation for the system. For example, a requirement numbered would be linked to a design element with a similar number (the numbers don’t have to be the same so long as the annotation in the document provides traceability). The main intent here is to show that all the appropriate documents and project deliverables are connected through referencing and notation.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

How does GPS work? July 6, 2011

Posted by HubTechInsider in Definitions, Hardware, Microprocessors, Technology.
Tags: , , , , , ,
1 comment so far
Artist Interpretation of GPS satellite, image ...

Image via Wikipedia


How GPS works

Well, dear reader, here we both are again: time for another Hub Tech Insider primer on one of the most fundamental technologies driving today’s revolutions in mobile commerce, location-based services and applications, smartphone features, and so much more.

You know that I’m talking about GPS, the Global Positioning System.

You also realize, if you have been to this blog before, that you are about to get a complete rundown on the nuts-and-bolts of GPS technology from its nascent conceptual underpinnings through today’s location-aware mobile applications.

But first, a history lesson (you should have been expecting that too from me, Dear Reader):

The challenge of navigation: a brief history

The magnetic compass arrived in Western Europe from China sometime in the 12th century. The compass was a seminal invention in the history of navigation, providing orientation – however most travelers still depended on familiarity with the region through which they were traveling, using sight navigation perhaps supplemented with some rudimentary observation of the stars.

The magnetic compass of course could not determine a person’s position. The use of the stars was the primary method used to determine position. Devices such as the astrolabe, the quadrant and the sextant provided navigators with important new sources of navigational and positioning data, and they opened up new territories to exploration, as they enabled the traveler to easily determine latitude, which is the distance above or below the Earth’s equator.

Being an experienced sailor, and also as a result of my time involved in a naval military career, I have received training with the above three navigation instruments. Using a sextant to navigate can be fun, but the learning curve can be quite steep, particularly for beginners. And there is also a major problem with using these instruments to determine a precise location: when navigating using the stars as a visual point of reference, there is no way to determine your longitude, which is the distance east or west around the globe.

Accurate latitude without accurate longitude position information led to many great naval disasters – the navigators of wooden sailing ships on the high seas, and their Captains, did not accurately know their own position. Easy and accurate measurement of longitude was so important to navigation at sea, that in 1714, Queen Anne of Great Britain, then the world’s most preeminent sea power, established a reward of 20,000 pounds sterling (equivalent to 1.9 million pounds or $2.8 million dollars in year-2000 dollars), to be paid to the first person or persons capable of developing a practical method of determining longitude at sea.

This first sea-worthy, highly accurate chronometer was developed by John Harrison (1693-1776), a carpenter, in 1761. His struggles and tribulations suffered during the decades-long gestation period for his device were chronicled in the excellent movie “Longitude“, which I highly recommend.

Incidentally, the key innovation of Harrison’s seaworthy chronometers, which were later designated as models H1, H2 &  H3, was dubbed the “Grasshopper Escapement“.

In 2008, world-renowed physicist Stephen Hawking (yes, that’s right, the wheelchair-bound, Cambridge, England-residing, computer-voiced supergenius, we all know who he is) unveiled the Corpus Clock, a very unique clock, the work of horologist (a horologist is a clock-maker, or someone who studies chronology. Horo is Greek for “Hour” or “Time”) John Taylor, who has built a disturbing public timepiece[VIDEO]  which utilizes an ‘upgraded’ type of grasshopper escapement. If you are like me, and love to fool around with electronics and electric circuits, you already know John Taylor as the inventor of the thermostatic switch, used in umpteen millions of household appliances.

Harrison’s chronometer also incorporated two other mechanical engineering advances: a gridiron pendulum that consists of lengths of brass and iron arranged in such a way that the length of the pendulum from pivot to bob is always constant, regardless of the temperature. The grasshopper escapement described above, in concert with the other features of the Harrison chronometer, such as lignum vitae (a self-lubricating wood) rollers mounted on non-corroding brass spindles, helped to virtually eliminate friction from the Harrison device.

A British Captain leaving on a long sea voyage would set the Harrison chronometer to the exact same time kept in Greenwich, England. This is the origin of what is known as GMT, or Greenwich Mean Time. GMT is a way of universally telling time across the world. For example, the Eastern Standard time zone, within which Boston is located, can be refferred to as “GMT-5”, which means the time in Boston will be five hours behind the time in Greenwich, England. While I’m on the subject of GMT, know that GMT is referred to as “Zulu” in the U.S. military.  As in “United States Navy SEAL team 6 will deploy to HVT#1 compound in Abbotabad, Pakistan at 0530 Zulu”.

On the high seas, the Captain or Navigator of the vessel would then be able to determine the local time by observing the position of the sun. The difference between the local time and the time in Greenwich, which was maintained throughout the voyage accurately by the Harrison chronometer, could then be used mathematically to derive (24 hours of time is equivalent to 360 degrees of longitude) the ship’s distance from Greenwich, which is longitude.

In 1772, Captain James Cook used a Harrison-styled (for more on the fascinating backstory on Cook’s voyage, I again recommend the movie “longitude”) chronometer to explore and accurately chart the Pacific ocean for the British Admiralty. The Harrison chronometer was a huge advance in navigation, but it only worked in fair weather when the position of the sun in the sky could be observed to determine local time. This restriction was removed with the invention of radio.

Radio signal navigation

The first equipment to be used for radio navigation arrived in 1912, but it suffered from accuracy problems. Pulse radar, developed during World War II, made it possible to measure the short time differences between transmitted and received radio waves. This is the same principle used by police speed trap radars: the equipment sends out a radio pulse and measures the time it takes for the pulse to travel to a vehicle, bounce off it, and arrive back at the radar gun. The time difference tells the radar’s computer the car’s distance from the gun.

The GPS system uses a constellation of 24 active GPS satellites orbiting the Earth

The early radio navigation systems used this same principle of sending radio waves and measuring time differences. In many of the early systems, radio signals were sent from two towers, at exactly the same time, traveling at the same speed. The navigator’s radio receiver would then detect which of the two radio signals arrived at the navigator’s position first, and then would measure the amount of time that would elapse until the arrival of the second radio signal.

The navigator would be aware of the exact positions of the two signalling towers, the speed of the radio waves and the time difference between them when they arrived at the navigator’s position. If the radio waves had reached the navigator’s position at exactly the same time, expressed as [Delta] t=0, the navigator’s position would lie exactly between the two signalling towers. If instead the second radio signal arrived two time units before the first signal, then the navigator would know that their position would be closer to the second signalling tower than the first one.

Two radio signals give the position of the receiver on a line between two radio sources

Of course, this is only a one-dimensional position fix. A one-dimensional position fix is not very useful, but if three radio signalling towers are used, then the radio navigation system is capable of delivering a two-dimensional position fix. As in the previous example, the navigator’s receiver records which signal arrives at the receiver first and the time differences between the first signal and the others. Using this knowledge of the signalling tower’s positions, the speed of the three radio signals and the difference, or delta, in the arrival times of the signals, the receiver calculates a two-dimensional position.

Adding a third radio signal source allows a two-dimensional position fix to be calculated


GPS is radio navigation using satellites instead of signalling towers

GPS uses radio waves to determine position, just as in the early radio-based navigation systems like the ones described above, but with an important twist. Land based signalling towers are replaced by satellites orbiting 20,200 kilometers (12,552 miles) above Earth.

These satellites do not transmit radio pulses, however. Instead, the GPS satellites transmit a sequence of numbers that enable a GPS receiver to measure its distance from each satellite instead of its position betweenthe satellites.

Alright, Dear Reader, you know this is the point in my discussion where I’m really going to start breaking it down for you. Remember, in GPS, as in many technological wonders of our modern age, God is in the details. Stay with me, as this technical discussion will reward your dedicated attention span to this article by giving you a more complete understanding of how your GPS receiver operates and solves for position.

I am going to simplify some of the details of the transmitted number sequences in order to provide to you an easily comprehensible example, no hate emails please. This is my disclaimer.

Starting at a known time, t0 in the example I am about to describe, the satellite broadcasts a number sequence. For the purpses of illustration, let us say that the satellite in question sends the number 10 at t0, the number 23 at time t1, etc., and this satellite continues to send a different number each time segment without repeating itself for a millisecond.

GPS satellite sending and GPS receiver detecting a transmitted number sequence

The GPS receiver already has the exact same number sequence stored in its electronic memory and “knows” the exact time when the satellite began to transmit its number sequence. At time t0, the receiver starts at the beginning of the number list in its memory and advances one number for each time segment.

When the GPS receiver detects that number 10 has arrived from the satellite, it notes it is at number 42 in its own list, which means it took seven time segments for the radio wave carrying the numbers to get from the satellite to the receiver. If the radio wave travels 3219km (2000 miles) per time unit, the receiver knows the satellite is 22,531 kilometers (14,000 miles) away. This technique is known as ranging and requires exact time synchronization between the receiver and the satellites in addition to a known number sequence.

But, of course there is a problem with time, and to solve that problem, we need to use one of Einstein’s theories. And no, I’m not making this up.

How GPS bends time

The GPS system uses a constellation of 24 satellites that transmit this time-stamped information on where they are. By multiplying the elapsed time of reception by the speed of light, the GPS receiver can calculate position from each of the satellites it is currently receiving radio signals from.

Each GPS satellite is equipped with an atomic clock, the most accurate type of chronometer available.

For accuracy to within a few meters, the satellites’ atomic clocks have to be extremely precise – plus or minus 10 nanoseconds.

10 nanoseconds? I know, I know, Dear Reader: many of us, myself included, are aware of and can easily comprehend time divisions in the milliseconds. These types of chronological measurements are used in computer programming and applications. But nanoseconds are a much smaller unit used to divide time – and there’s a big problem besides the conceptual challenges associated with grasping such minute time divisions.

These amazingly accurate atomic clocks never seem to run quite right aboard these GPS satellites. One second as measured on each GPS satellite never quite matches a second as measured on Earth.

Wait a second: what the heck? Why not? I thought you said the atomic clocks were the most accurate form of chronometer available…why is it that there are these time differences?

Well, Dear Reader, the answer is that Einstein knew what he was talking about with that relativity stuff. Mind you, I’m not talking about Einstein’s much broader scientific theory of _general_ relativity, I’m speaking of Einstein’s early relativity predictions that were later proven to be observable in the cosmos.

Einstein, relativity, and GPS

Albert Einstein’s special theory of relativity predicts that a clock that is traveling fast will appear to run slowly from the perspective of someone standing still. The GPS satellites move at around 9,000 miles per hour, and this is enough speed to make their onboard atomic chronometers slow down by 8 microseconds per day from the perspective of a GPS receiver.

This is more than enough to completely corrupt the location data. In order to counter this effect, the GPS receiver adjusts the time information it receives from each satellite by using an equation:

GPS receivers use the above equation to correct for time incongruousness that results from Einstein’s theory of special relativity

The amount of time that has elapsed on Earth during the delta time interval of the satellites’ radio transmission segment is equal to the amount of time elapsed as measured on the GPS satellite in question divided by the square root of 1 minus the exact velocity of the satellite (around 9,000 MPH) divided by the speed of light, or 186,262 miles per second.


How GPS uses triangulation to solve for position

Solving for position using GPS satellite radio signals (corrected for time as detailed above) is accomplished by means of triangulation, which means if you know your distance from three fixed locations, you can calculate your own position. I have illustrated in my prior, simplified examples how a navigator can find their position in two dimensions.

In two dimensions, a GPS receiver measures its distance from satellite #1, which means the navigator is somewhere on the conceptual circle of potential positions that surrounds GPS satellite #1. Next, the receiver measures its distance to GPS satellite #2. The GPS receiver must then lie somewhere on the circles of potential positions that surround satellites #1 and #2. There are only two potential positions where the GPS receiver can be located, and each of these two potential positions is where the two circles of position potentialities intersect.

Triangulation is used to find position from GPS satellite receptions

The GPS then measures its distance from GPS satellite #3 and, just as before, the only potential positions for the GPS receiver are where the circles surrounding the three satellites intersect. Using triangulation, there is only one location on the Earth where all three position potentiality circles intersect, so at this point, the GPS receiver has calculated its position.

Piece of cake, right? GPS navigation sounds complex because it is, but fortunately the GPS receiver equipment performs these calculations with great speed and accuracy, hiding all the nasty math it takes to solve for position from the navigator.

GPS solves for latitude, longitude, and altitude too

The GPS system is really super because it uses these three intersecting spheres of position potentialities to determine a three dimensional position comprised of latitude, longitude, and altitude.

My examples above stress the importance of time synchronization and the satellites’ exact positions. This will help me explain the concept of Selective Availability, or SA, later in this article. For now, just remember that if the receiver is not exactly synchronized to the satellites or if it does not know the satellites’ precise positions, the position the GPS receiver calculates will be inaccurate.

Signals from just three GPS satellties are enough for a GPS receiver to calculate its position, but a fourth GPS satellite signal is used to synchronize the time between the satellites’ highly accurate onboard atomic clocks and the less accurate quartz chronometer onboard the GPS receiver itself.

If radio signals from only three GPS satellites are available, one signal must be used to synchronize time, leaving only two signals to calculate a two-dimensional position.

The knowledge of the GPS satellites’ exact positions is the other vital aspect of positioning with GPS signals. A GPS receiver would not be able to accurately determine its own position with simply the radio signal time difference information from the GPS satellites, it must also know the exact positions of the GPS satellites in order to determine its own location on the Earth. Each satellite knows its own position, as well as the positions of all of the other GPS satellites in the GPS satellite constellation, and each satellite sends this orbital position information down to the GPS receiver.

GPS satellite position information

As I explained above, the GPS receiver has a list of satellite positions that is transmitted to it from the GPS satellites, but how does it know the positions of the GPS satellites when the GPS receiver is turned off or is moved while the power to the GPS receiver is turned off? How will it know where the satellites are when it is turned back on?

If a GPS receiver has been turned off for more than six months or has been moved more than 300 miles while it was turned off, then its internal almanac is inaccurate and cannot be used. Fortunately, all the GPS satellites transmit an updated orbital position almanac with regularity.

When a GPS receiver is turned on, it initially performs a check on its latest received orbital position almanac. If the GPS receiver determines that this almanac makes no sense according to a set of predefined parameters, then the GPS receiver will wait until it receives a new almanac so it can then calculate its position.

This delay between when a GPS receiver is turned on and when it calculates its position is called Time To First Fix (TTFF). Sometimes solving for the first position fix reading can take a while, and the reason behind this is usually that the GPS receiver is waiting for a new almanac from the GPS satellites.

So far in my discussion of the GPS system, I have spoken only of two entities: the satellites and the GPS receiver users. The third component of the GPS system is ground control. Ground stations monitor the satellite positions, control the satellites and determine the overall GPS system health.

Ground control also maintains the up-to-date orbital positioning almanac that is beamed to the GPS satellites, and in turn, down to the GPS receiver units on the Earth.

The United States military, Navstar, WAAS, the ionosphere and Selective Availability

How’s the above for a section title heading? A mouthful?

The concept of the GPS system was conceived of in 1960 to increase the accuracy of intercontinental ballistic missiles. Just another example of your tax dollars at work for you Americans out there, and another example of military space technology come down to Earth in the form of some civilian technology innovations.

The U.S. Air Force began the development of the GPS system and called it the Global Positioning System. Soon afterwards, the other branches of the U.S. military became involved in the development of the GPS system and the Pentagon changed the system’s name to Navstar – a name that did not stick. The entire system cost nearly $10 billion to develop and was fully operational in April, 1995.

Eighteen satellites is the minimum number needed to cover the entire Earth, but the actual number of GPS satellties that make up the GPS constellation in orbit flunctuates between 24 and 29 due to factors such as maintenance of spare satellites and upgrading of GPS satellites.

The GPS system designers had to deal with an interesting problem that affected the accuracy of the radio waves being transmitted through the Earth’s ionosphere and down to the GPS receivers on Earth. The Earth’s ionosphere slows down the satellite radio waves and would potentially affect the accuracy of the position data determined buy the GPS receivers.

The GPS system designers used two techniques to overcome the error in the GPS radio signals introduced by the ionopshere, one for civilian GPS receivers, and one for military receivers.

You see, the GPS system was designed by the U.S. military, and there was a very valid concern that the system could be used by America’s enemies as well as the U.S. military. After all, any country or group could potentially receive the radio signals beamed down to the Earth by the GPS satellites. As these radio waves are simply radio broadcasts, there is no point-to-point secure radio transmission to ensure who is using the GPS system and for what purpose they are using it.

GPS satellites beam two types of radio signals down to the GPS receivers: Precision Code, or P Code, and CA Code, or Coarse Acquisition Code. The CA code was public, and any receiver could detect it. The P code was made so complex that only military receivers, known as authorized users, can detect and use it for navigation.

The CA code is transmitted at 1575.42 MHz, which is called the L1 frequency. Each civilian GPS receiver is programmed with with a model that reports how much the L1 signal slows down when it hits the ionosphere. Based on this model, the GPS receiver can correct for ionospheric interference.

The solution for military receivers is more complex, but this complexity brings with it more accuracy. The P code is transmitted on the L1 frequency and at 1227.6 Mhz, which is called L2. Radio waves of different frequencies slow down differently when they hit the Earth’s ionosphere, so military GPS receivers compare the delay between L1 and L2 to figure out how much they slowed down. Comparing two signals is more accurate than using an ionosphere model because the model may be slightly off for any given GPS receiver location, whereas the comparison of the L1 and L2 radio signals is always accurate.

WAAS, or Wide Area Augmentation System, correction data decreases the impact of an inaccurate ionosphere model in civilian GPS receivers.

Selective Availability, WAAS, and Differential GPS

P code is inherently more accurate than the CA code transmitted by the GPS satellties, so military GPS receivers are generally accurate to 1 meter, or 3.3 feet. The CA code provides accuracy to about 15 meters, or 49.2 feet, which is less accurate than the P code, but still accurate enough to be deadly in the hands of the wrong people, so the GPS system designers decided to limit the usefulness of the CA code by making it deliberately less accurate than it was designed to be. The policy of deteriorating the CA code accuracy is called Selective Availability (SA).

Selective Availability randomly introduced position error into the CA code. The deliberate error changed the accuracy of a civilian (unauthorized) receiver from 15 meters (49.2 feet) to somewhere between 15 meters (49.2 feet) and 100 meters (328 feet). Selective Availability was a nuisance and as GPS use spread, many people complained. As a result, on May 2, 2000 the U.S. military eliminated SA at the behest of the U.S. government. Civilian GPS receivers are now nominally accurate to 15 meters, or 49.2 feet, as a result of this SA elimination.

While SA was still being enforced, some clever people developed a way around it using a technique known as Differential GPS. DGPS detects and eliminates the random error of SA and makes civilian receivers accurate to approximately 5 meters (16.4 feet). Since the removal of SA, DGPS is still used because it still increases civilian receiver accuracy, but is quickly being replaced by WAAS.

The FAA, or Fedral Aviation Administration in the United States determined that GPS is not accurate enough to be used for aviation, so it has added a form of differential GPS called WAAS to increase accuracy.

WAAS is more accurate than current DGPS services, it is available for locations in the U.S., parts of Canada and Mexico and it is free. GPS receivers equipped with WAAS have increased accuracy, from 15 meters (49.2 feet) to 3 meters (9.8 feet). unfortunately, the WAAS correction signals are most easily received in flat, open spaces, so you may not be able to pick tthem up in mountainous terrain.

Still more to come from the Hub Tech Insider on GPS – Build Your Own GPS

In upcoming articles, I will delve much deeper into DGPS, or Differential GPS, and illustrate for you some of the very innovative ways in which DGPS has been employed in applications such as coastal sea or littoral navigation, and even how it is used to keep track of the maintenance needs of huge public works such as dams and bridges.

I am also really excited about an upcoming feature I am hard at work on, a more hands-on article in which I will demonstrate how you can build your very own, battery-powered GPS receiver. I will then take you through some very basic computer programming code, written in a language called Processing, also known as Wiring, which is very similar to the C computer language. (C is one of my favorite computer programming languages, I must admit. Any computer programming language that utilizes a C-type syntax, I enjoy working with – except Java. No hate mail.)

The built-from-scratch GPS unit I will demonstrate how to build is portable, battery powered, and includes a bluetooth module for communicating wirelessly with your PC. You will be able, once you have followed my complete and detailed instructions for constructing this GPS device, to poll the GPS module for data, known as sentences in GPS parlance, to extract location data in the NMEA protocol. NMEA stands for National Maritime Electronics Association, and the NMEA protocol is fundamental to digital, programmatic interactions with GPS modules.

As you can well imagine, I intend to break it all down as usual, and I think it will be fun to finally post some of my terrible computer programming code. As you know, I am not a professional programmer, but a PMO Director, but for some strange reason, ever since I was a little, tiny tiny nerd boy, I have been programming computers. I just don’t talk about it too much, because programming computers is just something I have always done, not something I hang out my shingle on, so to speak.

Anyways, don’t worry, just like the code I write for ecommerce sites, this GPS code is simple, easy to follow, and always, always runs. When you see the latitude and longitude information flowing from this device wirelessly onto your PC, you will be very happy. There is nothing like getting involved hands-on with technology to increase your understanding of difficult tech concepts, and I hope you will have as much fun building your own wireless bluetooth GPS module as I did.

Homemade, battery-powered GPS unit with Bluetooth module on a solderless breadboard

I will also show you how to run this GPS code on multiple platforms, such as Linux and Mac OS X, not just Windows PC machines. I always like to get my code running on all three platforms if possible – I will demonstrate how to get your development environment running for Processing coding on all three types of personal computer systems.

You probably already know that a complete glossary of GPS technology terminology is in the works too here at the Hub Tech Insider.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of  Tshirtnow.net.

What is NFC? What is the smartphone mobile payments technology known as Near Field Communications? March 6, 2011

Posted by HubTechInsider in Ecommerce, Mobile Software Applications, Telecommunications, Wireless Applications.
Tags: , , , , , , , , , , , , , , , , ,
add a comment
An NFC mobile phone (Nokia 6131 NFCmesso) inte...

Image via Wikipedia

It has been several years now that I have been reading and hearing about mobile phone toting consumers being able to purchase soft drinks from vending machines through the use of SMS texts to the vending machine.

The possibilities of a mobile digital wallet, a North American equivalent of European Smartcards and mobile SMS payments systems, to be used as a payments service for smartphones, certainly include the hypothetical future displacement of the cash register as the payment method of choice for consumers on the go.

NFC, or Near Field Communication, may perhaps have such a potential.

Since the middle of December, in and around Portland, Oregon, Google has been handing out hundreds of NFC kits to local businesses as part of an NFC trial they are calling “Hotpot”.

The Google Hotpot kits include special NFC-capable window decals. NFC is a low power technology that beams and receives wireless information from up to four inches away. When consumers with NFC-equipped telephones such as the latest models of Android operating system cellular phones, scan a NFC-equiped window decal, they will be presented with information on their mobile device such as business hours, reviews, and more.

The hope is that the increasingly mobile consumer will willingly engage with local merchants using this new technology, allowing merchants to interact with the generations of consumers growing up with texting and mobile smartphones in their pockets.

2011 is really shaping up to be the year of NFC, with Google considering building an NFC-based payment service in the U.S. that could make its debut later this year. The technology would let customers pay for items by passing their smartphone over a small reader. A single NFC chip would be able to hold a consumer’s bank account information, gift cards, loyalty cards, and coupons, say the two people, who requested anonymity because the plans aren’t public. Google’s NFC scheme includes an advertising component that would allow merchants to beam a coupon or other reward to customers while they are shopping.

Of course, advanced smartphone owners can already complete mobile transactions by downloading payment applications. Paypal’s iPhone iOS application, for example, lets PayPal users transmit funds to other PayPal account holders. But NFC technology could potentially streamline such transactions. Users of advanced smartphones equipped with NFC technology don’t need to launch an application; they simply wave or tap their smartphone against a small reader device and enter a PIN number on it to authenticate their purchases.

A Google NFC network offering would encounter stiff competition from the start from the likes of companies such as Verizon, AT&T and T-Mobile, the three of whom in November 2010 formed a joint commercial venture called ISIS that plans to launch an NFC-based payments service by 2012. Visa is also field testing several mobile payment technologies, including NFC, and plans a commercial rollout later this year. It is rumored that PayPal, a division of eBay, may test an NFC service in the second half of 2011 as well.

Silicon Valley is hard at work on NFC technology too, with Apple having filed a patent for a process to transmit money between cellular telephones using NFC. Apple recently hired NFC expert Benjamin Vigier away from mFoundry, a startup that helps banks build mobile payments applications. If the next iPhone does come equipped with an NFC chip, then perhaps Apple will process mobile payments through Apple’s iTunes store.

The increased competition and jockeying for position in the NFC space is undoubtedly due to the high stakes involved, as the prize for whoever wins the NFC race is a dominant position in a small but fast-growing market that could displace the cash register in time. A leading market research firm, IE Market Research, estimates that by 2014, NFC-based payment systems will account for a third of the $1.13 trillion in worldwide mobile transactions.

In mid-December, Google, whose former CEO, Eric Schmidt, has said that NFC will “eventually replace credit cards”, in December 2010 bought Zetawire, a Canadian startup with several NFC patents to its name, including a novel method for diners to split up and pay a restaurant bill using their smartphones. If Google does decide to launch an NFC payments network, they would have the built-in advantage of its very large and rapidly expanding installed user base of Android smartphone owners. Every single day, around 300,000 people activate Android telephones, and they accounted for more than 25 percent of the new smartphones shipped in the third quarter of 2010, according to the Wall Street Journal.

The latest version of Google’s smartphone operating system, Android, capable of reading NFC tags is dubbed Gingerbread. Later this year, software updates to Android will let Android smartphones transmit information using NFC as well. In December 2010, Google introduced its Nexus S smartphone, based on Android Gingerbread and carrying an NFC chip onboard. In January 2011, Starbucks announced that customers would be able to start using a bar-code application on their smartphones to purchase coffee in some 6,800 of its stores.

There are obstacles to widespread consumer adoption, however. For an NFC-based payments network to really work, Google needs to convince not just Android smartphone owners but also local merchants who must install NFC readers to process mobile payments. Hotpot, which Google has been promoting heavily, introduces merchants to the NFC technology. NFC is already in heavy use in parts of Asia and Europe.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies,software developmentAgile project managementmanaging software teams, designing web-based business applications, running successful software development projectsecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurshipecommercetelecommunications andsoftware development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of TwitterMiners.com & Tshirtnow.net.

How many online stores are on the Shopify ecommerce platform? What are some interesting shops on Shopify? Who are the top Shopify merchants? February 27, 2011

Posted by HubTechInsider in Ecommerce, Startups.
Tags: , , , , , , ,
1 comment so far

Image via Wikipedia

Per Shopify Corporate numbers dated 31 December 2010, there were 11,323 active merchants using Shopify as their ecommerce solution.

Those stores had over 2.7 million customers, who placed 1.6 million orders in 2010, generating $124 million in sales within that year, which was double the sales on Shopify stores in 2009.

Year over year, the raw numbers and percentage increases of Shopify merchants’ stores, total online sales through the Shopify platform, and total number of online orders placed on the Shopify platform from 2009 to 2010 were:

1. Number of Shopify merchant stores: 6,656 (2009) -> 11,323 (2010) [a 70% YOY increase]

2. Sales through Shopify: $59 million (2009) -> $124 million (2010) [a 110% YOY increase]

3. Number of orders processed through Shopify: .69 million (2009) -> 1.6 million (2010) [a 132% YOY increase]

I have been using Shopify since the early days, being one of the top RoR, or Ruby-0n-Rails, ecommerce applications. I have found it to be stable, easy to use, fast and dependably reliable. It is easy to customize and develop for. Very quick and easy to get started, and a store gets up and running quickly. I am available to share all that I have learned about running Shopify. Feel free to drop me an email.

Paul, Hub Tech Insider, Shopify Merchant.

visit my Shopify store: http://www.tshirtnow.net

Check out this great article:

Why the Shopify Platform is a big deal for application developers

Other Top Shopify Merchants:

Tesla Motors
Foo Fighters
Amnesty International
Evisu Jeans
Robin Piccone
Bento & Co.
Madsen Cycles

The Indianapolis Star Tribune

Cuba Gallery
Moka Joe Coffee
Dodo Case
Sugar Baking
Kindred Market
Peridot Lovers
unotre store
Alpine Exposures
Pattern Head
Gold Cart Tires n More
Raw Crunch
Good as Gold
The Heads of State
Designing Obama

Operation Phoenix
La Patate
Love Your Home For Less
Alfresco by Design
Cush Potatoes
Clothing + Kindness
Dan 300
The Hull Design
Jues Textileinzelhandel
A Piedi
The Boat Safe
Beacon’s Closet
StarBlu Luxury Resort Wear
Independent Origins Trading Company
Trix & Dandy
Dem Collective

Magen Biosciences, a Waltham, MA-based company focused on novel dermatology treatments, is acquired by the contract research firm PPD for $14.5 million December 18, 2010

Posted by HubTechInsider in Acquisitions, Biotech, Health Care IT, Pharmaceuticals, Startups.
Tags: , , , , , , , , , , , , , ,
add a comment
Image representing Magen BioSciences as depict...

Image via CrunchBase

Magen Biosciences, a Waltham, MA-based company focused on novel dermatology treatments, will be acquired by the contract research firm PPD for $14.5 million. The firm was founded in 2006 by a well known group of biotech entrepreneuers and investors, including Rich Aldrich, founder of RA Capital, David Fisher, chief of dermatology at Massachusetts General Hospital, and Christoph Westphal, co-founder of Sirtris Pharmaceuticals. Having raised $17 million in seed and Series A financing from a syndicate of backers including ARCH Venture Partners, TVM Capital, and IDG Ventures (now Flybridge Capital Partners), the purchase price is unlikely to result in an exit for Magen’s backers.

Back in 2008, Magen inlicensed for an undisclosed sum a number of derm compounds from Eli Lilly that showed positive anti-inflammatory and anti-proliferative results in preclinical studies. It’s a good thing they did: those compounds were the primary reason for PPD’s interest in the biotech. The buy-out gives PPD an entrée into the specialist field of dermatology. In a press release announcing the news, PPD CEO Fred Eshelman noted that dermatologic treatments generally have a “more straightforward path to regulatory approval.” That’s certainly part of the logic behind moves of another specialist drug maker, Valeant, which is trying to brand itself as a derm power-house thanks to the recent acquisitions of Coria Laboratories, Dow, and DermaTech.

Oracle acquires Cambridge based eCommerce software provider Art Technology Group, Inc (ATG) for $1.0 Billion in cash November 22, 2010

Posted by HubTechInsider in Acquisitions, Ecommerce.
Tags: , , , ,
add a comment

Oracle acquires Cambridge based eCommerce software provider Art Technology Group, Inc (ATG) for $1.0 Billion in cash.

Cambridge, MA based ATG provides high end eCommerce software that is used by more than 1,000 customers globally. By combining forces, Oracle and ATG expect to help businesses grow revenue, strengthen customer loyalty, improve brand value, achieve better operating results, and increase business agility across online and traditional commerce environments.

“Driven by the convergence of online and traditional commerce and the need to increase revenue and improve customer loyalty, organizations across many industries are looking for a unified commerce and CRM platform to provide a seamless experience across all commerce channels,” said Thomas Kurian, Executive Vice President Oracle Development. “Bringing together the complementary technologies and products from Oracle and ATG will enable the delivery of next-generation, unified cross-channel commerce and CRM.”

“The addition of ATG, which brings market-leading products used by some of the largest and most well-known retailers and brands, furthers Oracle’s strategy of delivering industry-specific enterprise applications,” said Bob Weiler, Executive Vice President, Oracle Global Business Units. “This acquisition builds upon our dedication to offer the most complete and integrated suite of best-of-breed software applications and technologies required to power the most demanding companies in the world in every industry.”

ATG’s revenue for the third quarter of 2010 grew to $50.3 million, a 16% increase over third quarter 2009 revenue of $43.4 million. Oracle will pay $6.00 per share in cash for the company. The transaction is subject to stockholder and regulatory approval and other customary closing conditions and is expected to close by early 2011.

What is EDIINT? What is AS2, and how does it differ from AS3 or AS4? November 2, 2010

Posted by HubTechInsider in Definitions, Manufacturing, Supply Chain Management.
Tags: , , , , , , ,
add a comment
Internet Map. Ninian Smart predicts global com...

Image via Wikipedia

What is EDIINT? What is AS2, and how does it differ from AS3 or AS4?

EDI, or Electronic Data Interchange, is a format used by large enterprises for exchanging digital information about purchase orders, invoices, and other business supply chain related information with other companies, businesses, and enterprises.

EDIINT stands for EDI over INTernet.

One of the concerns and needs of the large business enterprises using EDI for electronic transactions throughout the 1990’s was the burgeoning requirement from these enterprises to be able to exchange EDI formatted data streams over the public Internet, securely. Towards the late 1990’s, EDIINT using a secure digital transmission conduit over the public Internet, called AS1, technology was standardized and released by the web standards bodies.

The AS1 protocol leveraged SMTP (standard Simple Mail Transport Protocol, or Internet email) as the foundation for exchanging communications. During this early phase of EDIINT deployments and AS1 protocol adoption, several software vendors emerged, offering to eliminate the de rigeur (for the time) VAN (Value-Added Network) fees that were commonly levied against large enterprises by the VANs then in existence. The development of the AS1 protocol, which allowed transfer of EDI messages and transactions securely over the public Internet, should have enabled these large enterprises to use AS1 to connect point-to-point with each other securely over the public Internet without need of VANs or their fee structures.

But although the ideal of AS1 was certainly promising, the promised elimination of VAN network access fees never really materialized, and the AS1 protocol unfortunately did not encounter widespread adoption and acceptance by the larger enterprises’ IT organizations. Several common reasons were behind this shunning of AS1 by corporate IT departments. One reason was the fear of larger enterprises that moving away from the liability endemnification of the VAN networks to transmissions over the (albeit secured) public Internet using AS1 was not quite ready for wholesale adoption by large scale enterprises in mission critical transaction environments. Another reason was some corporate IT departments were fearful, with considerable justification, of overloading enterprise email servers with EDI traffic as a result of the AS1 protocol’s dependence upon secured SMTP packets, which would route through corporate Microsoft Exchange or other SMTP email servers. In addition, SMTP email did not encorporate enough feature robustness to ensure the real time delivery of SMTP email and, more critically, enforce the non-repudiation features of the EDI standards then in common use.

The next incarnation of EDIINT emerged in 2001 with the new AS2 protocol superceding the earlier AS1. AS2 was designed from the start to address the same needs and requirements of the earlier AS1 protocol, but with the major distinction that AS2 was based upon the HTTP protocol instead of AS1’s reliance on the SMTP protocol. AS2’s use of HTTP instead of SMTP provided a more direct and realtime connection for transmitting EDI data between companies. The use of HTTP, combined with the growing acceptance of the Internet as a serious venue for international commerce, led to AS2 gaining a much stronger foundation upon deployment and saw AS2 gain a significant foothold into corporate IT departments in terms of adoption and implementation that AS1 had never enjoyed. But although interest in AS2 was greater than it had been for AS1, AS2 still did not reach mainstream wholesale adoption from large corporate enterprises.

Walmart and the adoption of AS2

The lack of enthusiasm at the corporate level for AS1 and AS2 adoption largely came about because of the lack of a “Market Maker”, or a powerful intermediary enforcing adoption and deployment of AS2 for EDIINT. Two companies were required to decide together to use a protocol such as AS1 or AS2, as either protocol necessitates coordination on both ends. This meant that although an enterprise might make the decision to work with a significant partner or primary systems integrator to deploy AS2, for most of that enterprises’s supplier, customer and vendor business relationships, the payoff would hardly be worth the effort.

All of this changed overnight in 2002 when Walmart announced that their entire EDI transactions and transmissions program would be moving over to the AS2 protocol and that *all* of their suppliers were expected – required absolutely, in typical Walmart fashion – to follow suit. Walmart’s decision was the tipping point for AS2’s widespread adoption and deployment across many industries and enterprises of various scale. Walmart’s reputation as a supply chain industry thought leader, as well as their renowned strong-arm tactics with their suppliers and vendors, forced other large enterprises to follow their lead. Walmart’s dictat led to positive feedback loops and various other network effects as a large number of Walmart suppliers fully AS2 enabled led to a growing ecosystem of AS2 -enabled vendors and supplies in the marketplace. Thus it became even easier for recalcitrant suppliers to justify jumping into the EDIINT, AS2 pool. AS2 enabled suppliers were able to easily extend their transactional AS2-based EDIINT systems into a vibrant community of AS2 enabled enterprises. As a result, by 2003 AS2 became one of the most popular data protocols for EDI transmissions within North America.

Europe and the Odette File Transfer Protocol V2, or OFTP V2

Despite the rapid spread of AS2 in the United States, Canada and Mexico, however, AS2 adoption lagged in Europe. The major reason for the discrepancy of AS2 adoption rates between North America and Europe was the lack of a European market maker ala Walmart in the United States. Without a key champion like Walmart driving the rapid adoption of AS2 in Europe, AS2 usage has taken a much longer time to spread into Europe’s major enterprises.

Into this vacuum, a new standard has emerged in Europe which may supplant the adoption of AS2 entirely if enough enterprises of scale in Europe decide to adopt it. The standard’s name is Version 2 of the Odette File Transfer Protocol, or OFTP V2, and it is a very similar protocol to AS2 in the fact that it leverages both the public Internet and HTTP for connectivity. In Europe, large automotive enterprises such as Volkswagen, Volva and PSA are driving the adoption of OFTP V2 in an industry-wide effort to reduce costly VAN networking fees. This wave of automotive suppliers supporting OFTP V2 should follow a similar pattern, although perhaps on not quite as large a scale, to the adoption of AS2 in North America by retail suppliers and vendors in response to Walmart’s urgings and data integration requirements.

Future EDIINT Standards: AS3 and AS4 and SOA

Future standards likely to emerge within the next iterations of EDIINT are likely to include AS3, which is based upon FTP, and AS4, which is based upon web services. Each of these newer variants contains benefits not available to users of AS2, for instance, AS3 does not require an ‘always on’ connection and could potentially handle large files better than AS2. AS4 can integrate with SOA (Services Oriented Architecture) software infrastructures with relative ease, something that is prohibitively difficult at present with AS2. Despite these technological advances, if a large enterprise or company is trying to determine which protocol is more apropos to use for EDI transmissions, they are likely to choose AS2 despite its limitations simply because the large community of companies already using AS2 versus trying to forge an uncertain path trailblazing the use of AS3 or AS4 in the absence of a market maker as mentioned above.

So until another market maker emerges to drive the adoption of AS3 or AS4 as Walmart did with AS2, AS2 will continue to be the de facto standard for EDI transmissions over the Internet. Instead of companies and large enterprises across different industries moving to AS3 or AS4, AS2 is instead adopting features that address the benefits available in those other standards. For example, an effort is under way to add “Restart” capability to AS2 that was announced recently, and this would provide some of the better support for larger file transfers that we have seen in AS3.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies,software developmentAgile project managementmanaging software teams, designing web-based business applications, running successful software development projectsecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurshipecommercetelecommunications andsoftware development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

What is a User Story? How are they used in Requirements Gathering and in writing User Acceptance Tests? October 3, 2010

Posted by HubTechInsider in Agile Software Development, Definitions, Project Management.
Tags: , , , , , , , , , , , , , , , , ,
add a comment
user stories image

Image via Wikimedia

What is a User Story? How are they used in Requirements Gathering and in writing User Acceptance Tests?

User Stories are short conversational texts that are used for initial requirements discovery and project planning. User stories are widely used in conjunction with agile software development project management methodologies for Release Planning and definition of User Acceptance Criteria for software development projects.

User Goals, stated in the form of User Stories, are more closely aligned with Business Priorities than software development Tasks and so it is the User Story format which prevails in written statements of User Acceptance Criteria.

An Agile Project Team is typically oriented to completing and delivering User-valued Features rather than on completing isolated development Tasks.These development Tasks eventually combine into a User-valued Feature).

User Goals are not the same things as software development Tasks. A User Goal is an end condition, whereas a development Task is an intermediate process needed to achieve this User Goal. To help illustrate this point, here are two example scenarios:

1. If my User Goal is to laze in my hammock reading the Sunday Boston Globe newspaper, I first have to mow the lawn. My Task is mowing; My Goal is resting. If I was able to recruit someone else to mow the lawn, I could achieve my Goal without having to do the mowing, the Task.

2. Tasks change as implementation technology or development approaches change, but Goals have the pleasant property of remaining stable on software development projects. For example, if I am a hypothetical User traveling from Boston to San Francisco, my User Goals for the trip might include Speed, Comfort and Safety. Heading for California on this proposed trip in 1850, I would have made the journey in a high technology Conestoga wagon for Speed and Comfort, and I would have brought along a Winchester rifle for Safety. However, making the same trip in 2010, with the same User Goals, I would now make the journey in a new Boeing 777 for updated Speed and Comfort and for Safety’s sake I would now leave the Winchester rifle at home.

· My User Goals remained unchanged, however the Tasks have changed so much that they are now seemingly in direct opposition. User Goals are steady, software development Tasks as stated on SOWs (Statements Of Work) are transient.

· Designing User Acceptance Criteria around software development Tasks rarely suits, but User Acceptance Criteria based on User Goals always does.

A User Story is a brief description of functionality as viewed by a User or Customer of the System. User Stories are free-form, and there is no mandatory syntax. However, it can be useful to think of a User Story as generally fitting this form:

“As a <type of User>, I want <Capability> so that <Business Value>”.

Using this template as an example, we might have a User Story like this one:

“As a Store Manager, I want to search for a Service Ticket by Store so that I can find the right Service Ticket quickly”.

User stories form the basis of User Acceptance Testing. Acceptance tests can be created to verify that the User Story has been correctly implemented.

User Story Card

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies,software developmentAgile project managementmanaging software teams, designing web-based business applications, running successful software development projectsecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurshipecommercetelecommunications andsoftware development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

%d bloggers like this: