I found a college paper of mine on Requirements and Product Planning, so I figured I’d publish it online. You can view it on Scribd here or embedded at the bottom. Here’s a full outline (lightly edited) that I wrote before writing the paper:

Requirements and Product Planning Outline

Short product design plans combined with prototypes and diagrams are usually more effective means for finding and communicating the plan of a product than detailed written requirements.

Finding and communicating the right requirements are the most important part of a project. It is therefore crucial to find the right approach.

The earlier you mess up, the worse is it is. The early decisions decide the direction of everything. So if you make wrong choice and only discover later, you will have to throw away a large amount of work. Studies showing how crucial the requirements stage is.

Definition of requirement – what the product must do to solve a user’s need.
A full requirement answers these questions (Motorola):

Who it is for (E.g. The world, doctors, 54-year olds)

What it will do (E.g. Actions, results..)

Describe the full user experience and accurately represent the behavior of the software

Additional questions – Where, When and How well.

The purpose of requirements:

To accurately describe user experience and software behavior so all parties can understand it.

The requirements should be able to be communicated to customers, engineers, marketing and any other parties so they all know what the product will be.

To aid in finding the right product and refine until satisfactory

Sometimes will want to adjust the product, so need to specify first and then refine the requirements before building the actual product.

Ways to find ideas and determine the requirements

Market research tools and their limitations

Customer surveys and interviews

Analytics, data mining and social analysis

Site visits and focus groups

Usability testing.

Competitive analysis

This research may help gather data, but it will not determine what features or product to build. To determine what to build need to go beyond that.

Ideas and testing them with users

Need to determine how technology will be used to solve certain problems and what the user experience will be.

To do this, need to recognize the problem and understand what potential technology can be used to solve it.

This is how practically all successful tech companies built their products, not with market research. For example:

The Google founders invented a new algorithm to ranks search results which made them more relevant and higher-quality than what existed before.

Facebook developed a successful social network by figuring out what people would want most long-term in such a site. For example, they placed certain restrictions on users (like a real-name policy or set profile page) that helped them become successful.

They didn’t use market research, they were able to figure out what people would want and how to do it with technology.

Ideas are nice, but need to verify if they will work, since gain nothing from products that people do not want (at least in capitalist countries!)

As mentioned above, a primary purpose of requirements is to be able to refine product early in game to avoid large costs later.

Approaches to formulating and communicating requirements:

Full, formal text requirements (Motorola book)

This used to be the standard corporate practice in big companies.

These formal requirements are similar to an engineering process of e.g. a bridge or building.

In full, it can include five steps of engineering:

Elicitation – Discover requirements by consulting stakeholders.

Analysis and Negotiation – checks if requirements meet certain criteria, such as consistency, completeness and feasibility.

Documentation – for communicating them.

Validation – Check if it describes the system well and if there are problems.

Management – Manage the requirements. To track and develop complex requirements, can use a Database Requirements Management Tool, which provides various benefits. (Motorola)

Full prototype (Inspired book)

Create a throwaway prototype (using tools that make it fast) to show the various activities that will be possible. Parts that cannot be built into prototype should be simulated.

“Realistic representation of the proposed user experience”

Comprehensive coverage of the site – Prototype “should represent the functional requirements, the information architecture, the interaction design, and the visual design of the user experience.”

Another possibility is to use an evolutionary approach. Develop a very simple version of the site and then use that as basis for the actual site. However, if the foundations of the site are not well-designed, the site will always have problems.

Proposed middle approach

Short product design description, combined with wireframe/prototype to show overall idea and diagrams or visual representations (such as UML). Instead of full text requirements, can just use “Use Cases”.

Comparing the effectiveness of different approaches:

For discovering the right features and product, and testing them

For communicating to relevant parties (so they know what to do)

Each approach analyzed:

Full text requirements

Pros – Everything is spelled out. People should know what specifically needs to be done and when meet the criteria.
Sometimes it is necessary to have very specific requirements – for example, if very specific critical criteria need to be met, such as software for a bank or nuclear plant.

Cons – Takes time to create, complex, but may be difficult to understand. Cannot test with users.
The fundamental issue with full requirements is that they assume “It is possible to determine a stable set of requirements before system design and implementation starts.” With many web products nowadays, that is not exactly true.

Full prototype

Pros – Clearly shows how it works and this can be used to communicate well with all parties. Can also test product on actual users before building the real thing.

Cons – Can take a while to make and is redundant with later efforts. Additional problem is if it does too many details such as the UI, it will be describing “How” to do it before the “What” that requirements are supposed to be focused on.

Proposed best way – Compromise, but focused on the lean way – Minimum prototype, minimum product design plan (focused on use cases), clear diagrams, etc. to show all aspects of product.

Pros – Can efficiently create it, it can communicate effectively, can help find the right ideas, more flexible, allows for some testing before create product.

Why this approach is better than long detailed text requirements:

This approach fits better in web age as opposed to box shipped stuff. Since can iterate and develop new features quickly, do not have time for long requirement process.

Use cases and prototypes (and software tests) combined can meet the needs of requirements. The use cases describe the overall needs and the prototype can show the different parties what the product will do to meet them. Additional details can be shown with basic charts, but extensive detail is not necessary.

Outlines and visual charts are better since they communicate the ideas more quicker than long text. They can also be made more quickly, since one does not need to “textualize” the ideas by turning them into paragraphs.

However, this approach has some of the cons of each approach above, so need to find right balance. For example, can make sure prototype is built quickly with a focus on just communicating what the product will do.

While standard practice may have been to follow more formal and longer requirements system, this is becoming less common. Part of the reason for this is the overall differences between agile and traditional development methods:

Agile methods are adaptive rather than predictive.

Agile methods are people-oriented rather than process-oriented.

As mentioned, this is partially due to changing nature of web products where everything must move much faster. There is much less reason to use a complex formal process for developing products (especially consumer ones) on the web. Some companies may be used to older methods, or they may be developing products where it is important to get everything right. But this approach is no longer needed for most consumer software products.

In April 2012, the JOBS Act was signed into law, but the SEC has been slow to implement it. The first part of the act will finally become active tomorrow, which will allow startups to publicly announce that they’re fundraising. However, they will still only be able to raise money from accredited investors, i.e. rich people.

Phase III of the JOBS Act will allow crowdfunding – ordinary people will be able to invest small amounts of their income in startups (see Crowdfunding passes in the Senate). This will help many small companies and startups raise money from a large number of people. Currently, a person or company can raise money on a site like Kickstarter, but can only offer backers rewards (like their product or tshirts), but not equity in the startup. Imagine how many more people will be interested in backing startups if they can hope to get rich from doing so! This will raise the risk of scams though, which is why there will be various regulations on crowdfunding once it is (eventually) implemented.

Startups will be able to raise money from the public, and could also use their “crowd” of investors to help to do things for their company. For example, a company could perform market research with their crowd investors, or ask them to help promote the company’s product on social media. Quirky uses its crowd to help decide what physical products to create, so tech companies could consult with their crowd to help decide on new features for an app.

Perhaps a company’s crowd could be consulted with to work on a specific task, such as creating some icons for a site or improving its SEO. Crowd investors will want to be compensated for large tasks that they do, but it could still be easier to hire someone already invested in the company than an external consultant. In fact, maybe this work could be an alternative form of crowdfunding – instead of investing in a company, people could contribute work and get a share of equity. This would differ from standard employment for equity since it the work would be distributed to a large number of people. While this could make collaboration more difficult, many open-source projects have been successful with a large number of contributors, so perhaps startups can do the same thing.

I don’t think crowdfunding is good for startups. For startups, having large numbers of investors is bad, and having inexperienced investors is bad. So having a very large number of inexperienced investors is the worst scenario possible.

While too many ordinary investors could be a nuisance, a large group could by filtered through a crowdfunding site and can offer more value than standard rich investors. This may be why Paul Graham accepted the crowd-sourced startup FundersClub into Ycombiantor. Startups may even start crowdfunding because of the product and marketing opportunities it will provide.

I’ve written about learning programming before and created a module on it on Learneroo.com, but its also useful to have one post that helps you get started programming. I wrote such a post recently on Lifehack:Guide to Learning Programming

I’ve written many posts on Zappable about education and technology, but I was always interested in doing more than just writing. I recently began working on such a project, one that will let people learn in a more interactive manner:

In previousposts, I wrote about the creation of an automated store machine in the 1900′s. In the chart below, I have jumped ahead to when the actual machine is first installed. I think this chart can help people get an overview of certain concepts by seeing them in physical form. I created the rough sketch below with a pencil, but when I get better drawing software I will be able to create a digital version, which will be updated with color and more.

Machine Overview
While initially the main purpose of the machine was so the store owner could track inventory, many new features were added. This picture focuses on customers who which to view the inventory/catalog information themselves.
The customers enter their information by punching holes into a “HTTP” card they are viewing. This card then goes into the Router which cuts it up and sends it to the appropriate controller. For example, if a user asked to views product #43, the router will pass “43″ to the Product Controller’s viewing arm.
The controller will then send this information to the Active Record Player, which will send back the relevant data, as seen in the previous post. In this case, it would send back a copy of product card #43. The controller’s Action View will then take over and combine the data with the relevant templates to create a page. This will involve cutting up the data-card and inserting the information into the correct location on the “view product” catalog page. The page will then be combined with some general headers and some styling layers from the assets box, and then the whole thing will be pressed into a single page and sent back to the customer.

This is part two in a series about a mad engineer and the machine-framework he created in the early 1900′s. Any resemblance to modern frameworks, living or dead, is purely coincidental.

In the first post of this series, the store owner, Jim Blackford, outlined the basic requirement he would need for Version 1 of the Automated Store Machine. We’ll quickly review his requirements:

Blackford: Well, I want to keep track of my inventory. So I guess it should let me create inventory records and store them well. The I should be able to access them at any time to read them, update them, or delete them. And it should keep track of how much inventory I have, and let me modify that when I get a new delivery or sell an item.

Dr. Hanson: Crud, that’s a lot of work. But me and my assistant can get started on building that machine. We’ll keep you posted on our progress…

Part II – In The Hanson Basement.Dr. Hanson discusses his plans with his assistant, Dave Kemp.

Dave: What up doc?

Hanson: We have a new project. I met with Mr. Blackford, and he needs a machine to track his inventory.

Dave: An inventory machine? How will that help you achieve world domination?

Hanson: This machine will not just be focused on tracking inventory. For Mr. Blackford’s own sake, we will need to make it extendible so we can add new components to help with his store. But my plan for this machine is greater than that. Once we complete this machine, we will look at the principles of its design and use them to build other machines for all sorts of purposes. Ba-Ha-Ha!

David: How will you do that?

Hanson: We will need to work out the details. But we will use solid engineering patterns that will then be able to used when building other machines. After all, what is the purpose of any calculating tabulating machine? It needs to store and retrieve data in an easy fashion, and perform simple operations on the data. Once we have the right design worked out, everyone will want our machine! They will no longer need to have their own Personal Hodgepodge of Pasta built from scratch, they will be able to start out with solid architecture.

The US government warned about using Java due to a vulnerability that was being exploited to install malicious software. Oracle has since released a ‘patch‘, but people don’t really need to run Java applets that much anymore. I don’t think these vulnerabilities are relevant to other software that runs on the desktop or phones.

Also, an exploit of Ruby on Rails sites was published last week. While a patch was released, some sites won’t update quickly enough. This will probably cause an increase of hacked websites as hackers find vulnerable websites. I wonder if it was really necessary for people to publish the vulnerability so quickly.

College costs have been rising at a ridiculous pace, despite the poor economy and their poor results. A group of people create an infographic on this topic and sent me the link to share: College isn’t cheap. It shows how many college graduates are stuck with school-debt, but cannot find jobs. I think there are big problems with getting people into so much debt when there’s no guarantee their degree will help them.

Meanwhile, the Wall Street Journal reports that colleges have finally begun cutting tuition increases and offering more scholarships. This means they need to cut back on some programs. However, there are much greater changes that will need to happen, such as greater use of technology in education.

This is a the first post in a story about a mad engineer and the machine-framework he created in the early 1900′s. Any resemblance to modern frameworks, living or dead, is purely coincidental.

Dr. Victor Hanson was a brilliant mathematician and engineer, though a tad crazy. He had invented a machine that could perform various calculations, but it had not sold well, and anyways he wanted to create something more ambitious. He decided to take out an ad in a newspaper to see if anyone needed his services:

Jim Blackford had been running his store without too much problems for some time, but he was getting a bit bored dealing with the same tasks every day. He wished he had some way to automate some of these processes. One day, when reading the paper, he noted an interesting ad…

A week later, in a restaurant in New York:

Blackford: Dr. Hanson, I presume?

Hanson: Yes, nice to meet you. I can now tell you about my automated machine services. I built machines that can calculate and tabulate numbers, but I’m thinking of branching out into other areas. What kind of machine do you need?

Blackford: I’m tired of dealing with the same manual tasks while running my store. It would be nice if a machine could just take over various operations for me. Though I’m not sure how that would be possible considering our pre-digital age and all.

Hanson: Nothing to worry about, I cans create analogue machines. Now what specific requirements do you need in your machine?

Blackford: Well it would be nice if I could receive some automated help to keep track of all inventory, process transactions, display brochures to customers, and maybe hand them products from higher shelves too.

Hanson: Wo, not so fast! Let’s focus on the most essential features you need first and later we can iterate on that. What is the most basic important thing you are looking for when shopping for automated store-running machines?

Blackford: I guess some way to keep track of all my inventory.

Hanson: OK, so let’s focus on that. What exactly do you want the machine to do?

Blackford: Well, I want to keep track of my inventory. So I guess it should let me create inventory records and store them well. The I should be able to access them at any time to read them, update them, or delete them. And it should keep track of how much inventory I have, and let me modify that when I get a new delivery or sell an item.

Hanson: Crud, that’s a lot of work. But me and my assistant can get started on building that machine. We’ll keep you posted on our progress…

Stay tuned for the next post where Dr. Hanson builds a first version of his machine.