requirements and product planning

7/29/2019 Requirements and Product Planning

1/8

Ariel Krakowski Industrial Development

Term Paper Prof. Kelly

Software Requirements and PlanningThe first step in any software project is planning. One must determine what problem the software

team will be dealing with and how they will solve it. Once the basic idea and plan has been

found, it is necessary to communicate the details with the engineers and other relevant parties.Before beginning to implement any project, the software team will need to have a clear picture of

what they are trying to accomplish. There are many different approaches to finding the right idea

to build and to communicating the plan with everyone else. In the past, companies often

developed rigorous requirements before beginning to implement any project. Currently, someweb companies skip writing any requirements at all. This paper will discuss the different

approaches and what type of projects each one is most suited for. For many types of modern web

applications, long rigorous requirements are unnecessary. Instead, short product design planscombined with prototypes and diagrams are effective means for finding and communicating a

product plan.

Finding and communicating the right requirements are the most important part of a project. This

is because the early decisions in a project decide the direction of everything else. If you realize

the requirements are wrong before beginning the project, you can adjust them at a very small

cost. However, if you make wrong choice and only discover that later, you will have to throwaway a large amount of work. Many studies have demonstrated that it is far more expensive to

change plans later in a project than early on. In one study, they found that 75-85% of costs are

due to rewriting requirements (Motorola). In Code Complete, Steve McConnell cites numerousstudies that show that purging errors early on can be 10 to 100 times cheaper than having to fix

them later.1 This demonstrates how crucial it is to try to get good requirements before beginning

an actual project. Requirements are clearly quite important, but what specific criteria should they

try to meet?

The main goal of a requirement is that it defines what a product must do to solve a users need.

Full requirements will answer all of these questions about the product (Motorola):

Who is it for? For example, is it just for a specific market such as doctors, is it aimed at agroup with a certain amount of technical proficiency?

What it will do? What specific actions will it allow the user to perform? What results willhe be able to get? Although there is some dispute about the best way to specify

requirements, all sides agree that they need to describe what a product will do. Accordingto Inspired, good product specs / requirements should describe the full user experience

and accurately represent the behavior of the software.

In addition to these questions, sometimes requirements should answer other questions when

relevant, such as where and when the product will be used. In addition, more rigorousrequirements will specify how well the product will need to perform in order to be considered

complete.

1 Chapter 3. Measure Twice, Cut Once: Upstream Prerequisites


2/8

What will these requirements accomplish? As mentioned above, good requirements will be able

to determine most of the plan for a product so the right one is built without requiring majorrework. The requirements can be refined to help find the right product plan before going ahead

and building the actual product. The customers or engineers will be able to look at the

requirements and discuss possible changes in them at the beginning. Once the requirements havebeen formulated, they will be able to be used to communicate with all the relevant parties. Thiswill let the engineers know what to build, and allow other parties, such as marketing and the

customers, know what to expect.2

Three Approaches to RequirementsThe purpose of requirements is clear, but what specific form should they be written in to meet

their goals? The traditional approach is to write full formal requirements. This is similar to the

engineering practices in other disciplines, such as when building a bridge or building.3

The fullrequirements process can include five steps of engineering (READ):

ElicitationDiscover requirements by consulting stakeholders.

Analysis and NegotiationChecks if requirements meet certain criteria, such asconsistency, completeness and feasibility.

DocumentationWrite the full requirements for communicating with all parties. ValidationCheck if the requirements describe the system well and look for any

potential problems.

ManagementManage the requirements throughout the process. To track and developcomplex requirements, can use a Database Requirements Management Tool, whichprovides various benefits. (Motorola)

These requirements are often written in as a long textual document as they answer the different

questions in detail and specify what the product will do. A basic way of formulating them is to

specify with shall and shall not statements what the product will do. For example, arequirement might state

4:

The user shall be able to perform a search of all the listings in the database orsearch a specific category.

Often, requirements are focused more on what the system will do than on the user, and they can

go into more detail. However, it is generally important that the requirements not go into specific

details of how the product will be implemented, since this can confuse separate parts ofdevelopment together. It is best to stay focused on what can be specified at this stage.

An entirely different approach to requirements is suggested by Marty Kagan in Inspired. Instead

of writing full formal requirements, he proposes creating a working prototype to demonstrate the

features the product will have and what actions it will enable. He suggests using modern toolsthat are now available to create a high-fidelity throwaway prototype. The parts that cannot bebuilt in the prototype should be simulated, and certain things that cannot be prototyped will needto be written. But basically everything that can be protoyped should be prototyped. The

prototype should be complete:

2 Inspired Kindle location 1548.3 Motorola and Code Complete discuss this analogy in some more detail.4 Example based on www.cs.umd.edu/~atif/Teaching/Spring2010/Slides/3.pdf


3/8

It should not be a paper prototype but a realistic representation of the proposed userexperience. This will allow it to completely communicate the idea for the product.

The prototype should not just demonstrate the basics of the site. Instead it shouldrepresent the functional requirements, the information architecture, the interaction design,

and the visual design of the user experience. This will allow it to be comprehensive and

reduce the need for any other documentation.An alternative to the throwaway prototype approach is to use the evolutionary approach. This

involves developing the prototype as a very simple version of the site and then using that as basisfor the actual site. This can work in certain instances, but it too risky as a general approach. The

prototype is meant be built quickly, so it wont be built in the most sound manner. If the

foundations of the site are not well-designed, the site will always have problems.

Another possibility is to take a middle approach. Instead of just using a prototype as

requirements or writing long formal written requirements, one can use a balanced combination.

One can create a basic prototype that shows the basic features of a product without getting intodetail. Everything else can be described in short written or visual form. One should write the Use

Cases, short written product descriptions, and other basics about the product. Instead of writinglong descriptions of what the product will do, one can use visual representations or UML

diagrams to demonstrate it. This flexible combination may be the best approach for writingrequirements for consumer web applications.

Each approach has advantages and disadvantages, and some will be more suitable for certainprojects than other ones. We will examine how effective each approach is in meeting the purpose

of requirements. How well does it help the group discover the right features and product? How

well does it enable communication with all the relevant parties? For what type of project is it

most ideal?

Formal text requirementsThe obvious benefit of full text requirements is that since everything is spelled out, peopleshould know specifically what needs to be accomplished for the product to be complete. While

shorter requirements or diagrams might be somewhat ambiguous or leave certain details out, full

written requirements should cover everything. The studies mentioned earlier make it clear howmuch time and money is saved when one doesnt need to make as many changes later on in a

project. If the requirements are not detailed, it is possible that the developers may build

something incorrectly which will need to be fixed. Detailed requirements hope to avoid thisproblem by specifically spelling out everything that is to be done.

There are many issues with formal written requirements. They take time to create since one has

to go through every detail. Once they are written up, they take a lot of time for the relevantparties to read them. One cannot just look at them to know what they say but instead has to

actually read though all the paragraphs. It is difficult to test requirements with actual users.

While they may feel they know what they want in a product, no one actually knows until they

use the product. Written requirements do not allow for any way to test the product, so it may endup defining the wrong product.


4/8

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. (READ). In reality,

this is often not the case, particularly for modern web products. The requirements can provide ageneral plan, but the product will normally need to be modified and not every detail in a plan

will be followed. It is very difficult to make all the correct decisions now before the actual

project has begun, and this may mean that they will not reflect reality and not lead to the hardchoices being made correctly.5

It may not be worth it to spend all the time writing longrequirements when the actual product could end up looking significantly different from the initial

plan.

These issues mean that formal requirements are probably not the correct approach for many

modern web products, particularly consumer ones. However, there are certain software products

where it is necessary to have very specific requirements.6

If very specific critical criteria need to

be met, then one cannot leave the project open to the ambiguity of lighter requirements. Forexample, if one is writing software for a nuclear plant or medical device, it will be necessary to

meet very rigid criteria. There is no room for getting a product out quickly and then modifying it

when peoples lives depend on the software. Even for less life-threatening cases, it can benecessary to meet very specific quality goals for a product. For example, an operating system

needs to work well with many different kinds of software and hardware, so it needs to be built to

meet very specific criteria.

Sometimes it may also be very difficult to prototype a product or even to show any

demonstration of what it does. The product may be within a specific technical area that can only

be described in formal detail. A specific example of this category was when Motorola wasupgrading their walkie-talkie feature in cell phones to workon the standard CMDA network.

They outsourced the work to a third-party to create the actual software implementation, but the

Motorola team needed to write the specifications. They needed to give very specific details to

explain how the features would work on the new network. This was actually a case where it wasnecessary to go beyond describing what the product will do and instead go into more detail

about how it would be done. This was so the third-party would be able to go ahead and create the

product. This type of project couldnt be prototyped and it required more detail than regularrequirements, so the formal approach was necessary. Cases like those are not the standard web

software project and they will often need actual written requirements.

Full prototypeThe advantage of building an actual full-fledged prototype is that it can quickly and clearly

demonstrate what the product will actual look like and do. Instead of having the various parties

read through a long description of the product, they can just look at the prototype. While it maynot spell out every detail that needs to be met behind the scenes, the goal of the prototype is to

show all the relevant parts of how the final product should look. This will give the engineers

something they can quickly refer to as they build the product. While written requirements are

supposed to be clear, they can often be more ambiguous than an actual demo of the product. (Asthe saying goes, a prototype is worth a thousand requirements.) The prototype can also be tested

on actual users before the actual product is built. This will allow crucial refinement of the

5 Seegettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.php6 See Code Complete ibid.
http://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.phphttp://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.phphttp://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.phphttp://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.php


5/8

product before going ahead and building the product. Written requirements attempted to prevent

many changes by spelling things out, but how do they determine if the actual plan is good? The

prototype approach actually allows real testing and feedback. One can then modify the prototypeuntil is satisfactory and only then begin working on the actual product. This can make a real

difference in reducing the amount of later-stage changes on a project.

The prototype approach faces a number of issues. One problem with it is that it can take a whileto build a full prototype, and some of that work is redundant with later efforts. While it can be

done quicker now than before, it still will consume a larger amount of time than other

approaches. It hopes to save even more time later by getting the plan right now, but somechanges will be needed later no matter what, so it might be worthwhile to just get started on the

actual project. Also, it may be difficult to demonstrate certain features in a prototype, even for

web apps. This may cause certain requirements to be very vaguely defined or they be left out

entirely. Even for a web project, the team needs to have a certain plan for what they are doing.An additional issue raised with doing a full prototype is that this can cause too much of a focus

on the wrong things, such as UI details.This will change the requirements from describing

What the software will do to How it will do it.

This may cause the engineers to lose focus onwhat it important at this stage and end up specifying details that should really only be dealt with

later. Robin F. Goldsmith attacks this focus on the UI and even the whole prototype approach as

getting ahead of where one should be in a project planning: In medicine, prescription prior to

diagnosis is malpractice. The UI is a prescription; and thinking it will lead to proper diagnosis ismisguided.

7This may sound a bit exaggerated but it helps illustrate the issue of focusing on the

wrong details too early on.

Relying on the prototype approach cannot work in the critical software cases mentioned above.

However, there are many areas where it may work well. Some consumer web products can be

quickly prototyped and the product can be built based on that. These areas will benefit greatly

from user feedback since often it is figuring out what people want that is the hardest challenge. Ifa medical product accomplishes its goal, people will want it, but one might build a consumer

web product that no one actually wants.8

Building actual prototypes can help a group determine

what product users will want before they go ahead and build the actual product.

The balanced approach

A balanced approach between a prototype and short requirements tries to use what works foreach aspect of a project. By building a basic prototype one can demonstrate the basic idea of the

product quickly to all the relevant parties. This can allow the developers to keep a picture of the

overall product and be able to look up certain details when necessary. The basic prototype can be

built quickly, but it can still be tested on actual users so they can get a feel for the final product.This balances the need for testing with being able to do things quickly. No prototype will be able

to fully determine how people will like the final product, so it may not be worth the time it will

take to build an advanced prototype. Many of those details are just specifics of how the product

will be built, but the requirements stage should be focused on what will be built.

7 Seesearchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-

mistake8 See Inspired Kindle Location 1161.
http://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistake


6/8

For consumer web products this combination approach beats the formal requirements approach.

Formal requirements work for critical projects, and they may have fit well in the age of boxed

software. When software was sold on CDs, it may have been necessary to follow a staged-delivery process, with formal requirements at the beginning. However, in the age of the web,

companies can iterate and develop new features quickly, so there is no need or time for a long

and rigid requirement process. The balanced approach is more flexible. The exact details of aproduct will often need to be adjusted as the product is developed, so it is unnecessary to spellthem out in full detail beforehand.

Full use cases and simple prototypes combined can together satisfy much of what requirementsneed to do. The use cases describe the overall needs and the prototype can show the different

parties what the product will do to meet them.9

Additional details will be able to be shown with

short general descriptions and charts and diagrams, but extensive detail is not necessary.

Outlines and visual charts are often better than long text requirements because they make it

quicker and clearer for the readers. The stakeholders can understand the diagrams quickly

without having to read a long document. A visual depiction can also be clearer than a writtenrequirements text, since it demonstrates what something should be like without requiring any

textual interpretation. In addition, visuals can frequently be made more quickly, since one does

not need to spend time turning the ideas into text, but can instead chart them out using a

diagramming tool.

Since this third approach is partially a combination of the above two approaches, it has some of

the pros and cons of each, so it is important to find the right balance. A simple prototype shouldaim to offer the important parts of a product, but by taking much less time than a full prototype.

It should also avoid the problem of describing too much how and just focus on the simple

representation of what the product will do. Things that cannot easily be shown in a prototype

can be written in a short and easily modifiable form so people can quickly understand what theyneed to know about a product.

This approach can work for a wide range of web software products. As long as it is not some sortof mission-critical product, this approach offers enough structure and flexibility for many

different projects. It can be used for a simple project, such as creating a simple web-app for

displaying pictures, or for a large project, such as creating a new social network. As an example,we can suggest a new product and show how the requirements will be created using this

approach. Lets say one wanted to create a new website for people to create and share interactive

educational material. Long written requirements would try to specify everything about the

product before it is built, but this is not necessary, and the project will need modifications as it isdeveloped and the team receives feedback. The full prototype approach will spend a lot of time

building a prototype of the site, when some of that time could be used in making the actual

product. Instead, a balanced approach would make a simple version of the site so the different

stakeholders can get an idea of what it will do and provide feedback. It would show the basicstructure of how content is created, shared and viewed on the website. The prototype will then be

able to be refined somewhat, and other details will be able to be written in a short form. These

could spell out more details about how the user accounts will work and what tools will be

9 Seejoelonsoftware.com/uibook/chapters/fog0000000065.htmlfor the importance of user stories and use cases.
http://www.joelonsoftware.com/uibook/chapters/fog0000000065.htmlhttp://www.joelonsoftware.com/uibook/chapters/fog0000000065.htmlhttp://www.joelonsoftware.com/uibook/chapters/fog0000000065.htmlhttp://www.joelonsoftware.com/uibook/chapters/fog0000000065.html


7/8

provided to create content. Simple diagrams and pictures will show more aspects of how people

will sign up for topics and what kind of content they will be able to create. The overall process

should be able to be quick and be able to communicate clearly what the product is about.

The quicker approaches to requirements and to software development itself have become much

common recently. Traditional practice may have been to follow more formal and longerrequirements system, but this is becoming rarer. This is partially due to the spread of the Agilemethodology. There are two basic aspects of Agile methods that make them not well-suited for

the formal requirements process (READ):

o Agile methods are adaptive rather than predictiveThis makes it difficult tostate at the beginning of a project what the detailed requirements are.

o Agile methods are people-oriented rather than process-orientedThis meansthey rather rely on getting feedback than following a specific requirements

procedure.As mentioned above, these changes are 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 on the web, especially consumer ones. Companies that still use the oldersystem of requirements may just be doing what they are used to, or they may be developing

products where it is important to get everything as planned. So the area of dispute is not actually

so large, since the right approach depends greatly on what type of project is being developed.

However, for a large number of web products today, extensive formal requirements areunnecessary.

It may help to look at a related example in order to compare the benefits of extensive planningwith a shorter, more prototype-based approach. In May 2010, I entered the Syms Business Plan

competition. As part of the competition, I had to write an extensive and detailed business plan

about all aspects of my proposed business. I described a web startup that would create a selective

directory of the top websites on the internet by combining human editors with algorithms toselect the sites. For the competition, I didnt just have to describe the product, but also needed to

write many other categories, such as sales projections and a marketing plan. This type of plan has

many weaknesses, especially for a web startup:

Too long to createtakes too much time to write a full plan, which would be better spentbuilding something.

Too long to readNo one has time to read such a long plan, probably not even thejudges.

Not flexible enoughSince the text is so long, it takes a while to modify, especially ifthere are connected parts. (This is the problem of tight coupling.)

UnrealisticBefore beginning web product, it is hard to know exactly what shape it willtake, and one definitely cannot make a 5-year revenue projection!

A better idea for such a competition, at least for web-based companies, would be to ask forshorter plans. This is something Syms did for recent competition. One idea would be to have a

general Business Model diagram instead of a long specific Business Plan. This is what Stanford

professor Steve Blank argues for.10

The business model describes certain essential elements of a

10http://steveblank.com/2012/02/16/who-dares-wins-the-2nd-annual-international-business-model-competition/
http://steveblank.com/2012/02/16/who-dares-wins-the-2nd-annual-international-business-model-competition/http://steveblank.com/2012/02/16/who-dares-wins-the-2nd-annual-international-business-model-competition/http://steveblank.com/2012/02/16/who-dares-wins-the-2nd-annual-international-business-model-competition/http://steveblank.com/2012/02/16/who-dares-wins-the-2nd-annual-international-business-model-competition/


8/8

product without getting into complicated projections. In combination with basic prototype, it

would be able to communicate idea and also test it out and refine it. This is very similar to the

overall approach that is ideal in writing requirements.

Bibliography:

Inspired: How to create products Customers will Love. Marty Cagan, 2008-06-04(Inspired)

Requirement Management Fundamentals (Motorola) Requirements Engineering and Agile Software Development. Frauke Paetsch, Dr. Armin

Eberlein, Dr. Frank Maurer. (READ)

Agile Product Management with Scrum: Creating Products that Customers Love. RomanPichler, 2010-03-11

Getting Real: The smarter, faster, easier way to build a successful web application byJason Fried, Heinemeier David Hansson and Matthew Linderman

Code Complete. Steve McConnell, 2009-11-30 Prof. Van Kelly, email communication. The Process of Designing a Product, by Joel Spolsky

joelonsoftware.com/uibook/chapters/fog0000000065.html

Defining a User Interface (UI) during the requirements phase: A mistake? By Robin F.Goldsmithsearchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-

during-the-requirements-phase-A-mistake
http://www.joelonsoftware.com/uibook/chapters/fog0000000065.htmlhttp://www.joelonsoftware.com/uibook/chapters/fog0000000065.htmlhttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-A-mistakehttp://www.joelonsoftware.com/uibook/chapters/fog0000000065.html

requirements and product planning

Documents