Ariel Krakowski Term Paper

Industrial Development Prof. Kelly

Software Requirements and Planning

The 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, some web 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 plans combined 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 throw away 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 numerous studies 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 a group with a certain amount of technical proficiency? What it will do? What specific actions will it allow the user to perform? What results will he 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. According to 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 rigorous requirements 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

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 major rework. 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 have been formulated, they will be able to be used to communicate with all the relevant parties. This will 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 Requirements The 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 full requirements process can include five steps of engineering (READ): Elicitation Discover requirements by consulting stakeholders. Analysis and Negotiation Checks if requirements meet certain criteria, such as consistency, completeness and feasibility. Documentation Write the full requirements for communicating with all parties. Validation Check if the requirements describe the system well and look for any potential problems. Management Manage the requirements throughout the process. To track and develop complex requirements, can use a Database Requirements Management Tool, which provides 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, a requirement might state4: The user shall be able to perform a search of all the listings in the database or search 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 of development 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 tools that are now available to create a high-fidelity throwaway prototype. The parts that cannot be built in the prototype should be simulated, and certain things that cannot be prototyped will need to be written. But basically everything that can be protoyped should be prototyped. The prototype should be complete:
2 3

Inspired Kindle location 1548. 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

It should not be a paper prototype but a realistic representation of the proposed user experience. 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 should represent 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 basis for 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 into detail. 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 writing long 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 writing requirements for consumer web applications. Each approach has advantages and disadvantages, and some will be more suitable for certain projects 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 requirements The obvious benefit of full text requirements is that since everything is spelled out, people should 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 how much 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 this problem 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 relevant parties 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 end up defining the wrong product.

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 a general 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 hard choices being made correctly.5 It may not be worth it to spend all the time writing long requirements 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. For example, 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 be necessary 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 was upgrading their walkie-talkie feature in cell phones to work on 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 was necessary 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 regular requirements, 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 prototype The 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 may not 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. (As the 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 6

See gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.php See Code Complete ibid.

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 prototype until 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 while to 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 some changes 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 on what 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 is misguided.7 This 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. If a 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 for each 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.

See searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UI-during-the-requirements-phase-Amistake 8 See Inspired Kindle Location 1161.

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 stageddelivery 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 a product will often need to be adjusted as the product is developed, so it is unnecessary to spell them out in full detail beforehand. Full use cases and simple prototypes combined can together satisfy much of what requirements need 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 written requirements 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 should aim 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 they need to know about a product. This approach can work for a wide range of web software products. As long as it is not some sort of 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 is developed 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 basic structure 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

See joelonsoftware.com/uibook/chapters/fog0000000065.html for the importance of user stories and use cases.

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 longer requirements system, but this is becoming rarer. This is partially due to the spread of the Agile methodology. 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 predictive This makes it difficult to state at the beginning of a project what the detailed requirements are. o Agile methods are people-oriented rather than process-oriented This means they 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 older system 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 are unnecessary. It may help to look at a related example in order to compare the benefits of extensive planning with 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 to select 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 create takes too much time to write a full plan, which would be better spent building something. Too long to read No one has time to read such a long plan, probably not even the judges. Not flexible enough Since the text is so long, it takes a while to modify, especially if there are connected parts. (This is the problem of tight coupling.) Unrealistic Before beginning web product, it is hard to know exactly what shape it will take, 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 for shorter 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
10

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

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. Roman Pichler, 2010-03-11 Getting Real: The smarter, faster, easier way to build a successful web application by Jason 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. Goldsmith searchsoftwarequality.techtarget.com/answer/Defining-a-User-Interface-UIduring-the-requirements-phase-A-mistake