Requirements and Product Planning

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.

View the full paper on Scribd