Better Product Requirements Specifications

Better Product Requirements Specifications

Tathagat VarmaMindTek, 11-Mar-2004

ContentsBig Picture of The ProblemCommon Problems with RequirementsVolereMy Experiences with VolereReferencesQ&A

DisclaimerThis presentation is based on General good practices that I have seen, ANDVOLERE Requirements Specification Template. While there might be better methods than Volere, I have found this to be best in simplicity + effectivenessVolere Requirements Specification process is a complete process, and the template is just one part of it

Dilbert on Requirements

Making a Swing is a childs play ?

Software Horror StoriesThe British destroyer H.M.S. Sheffield was sunk in the Falkland Islands war. According to one report, the ship's radar warning systems were programmed to identify the Exocet missile as "friendly" because the British arsenal includes the Exocet's homing device and allowed the missile to reach its target, namely the Sheffield. From "The development of software for ballistic-missile defense," by H. Lin, Scientific American, vol. 253, no. 6 (Dec. 1985), p. 48 An Iraqi Scud missile hit Dhahran barracks, leaving 28 dead and 98 wounded. The incoming missile was not detected by the Patriot defenses, whose clock had drifted .36 seconds during the 4-day continuous siege, the error increasing with elapsed time since the system was turned on. This software flaw prevented real-time tracking. The specifications called for aircraft speeds, not Mach 6 missiles, for 14-hour continuous performance, not 100. Patched software arrived via air one day later. From ACM SIGSOFT Software Engineering Notes, vol 16, #3. See Story More More More

More Software HorrorThe manned space capsule Gemini V missed its landing point by 100 miles because its guidance program ignored the motion of the earth around the sun. From "The development of software for ballistic-missile defense," by H. Lin, Scientific American, vol. 253, no. 6 (Dec. 1985), p. 49. During the maiden flight of the Discovery space shuttle, 30 seconds of (non-critical) real-time telemetry data was lost due to a problem in the requirement stage of the software development process. StoryThe U.S. Social Security Administration systems could not handle non-Anglo names, affecting $234 billion for 100,000 people, some going back to 1937. From Internet Risks Forum NewsGroup (RISKS) , vol 18, issue 80

The ProblemBuggy software drags down US profits by about $60 billion a year. (Forrester)In the US alone, up to 60% of software developers are involved in fixing errors (~1998)A recent task force headed up by Howard Rubin and including Capers Jones found that fewer than 6% of organizations have clearly defined software management processes in place. Would any other industry get away with treating quality in this way?

The ProblemDoing it wrong the first time is industry's biggest single quality expense. The famous late Quality Guru, Philip Crosby estimates cost of bringing goods back into line with customer requirements can range as high as 40% of sales for many firms, with the industry average running close to 25%. In effect, firms are spending a quarter of their income patching up their own mistakes.A general survey of some 300 projects across car manufacturing, telecoms and aerospace industries indicated that the main cause of failures were management and requirements issues. Five of the top eight issues were related to poor handling of requirements.

The ProblemFor software projects, according to the Standish Group, 31% of software projects are cancelled before the product is delivered to the customers, while 53% cost 189% or more of their original budgets. 40-60% of the software defects and failures being attributed to poor requirements, thus reflecting extent of the problem and the need to identify, communicate and manage IS project requirements.

The Problem(QAI, USA) Failure to properly identify and manage requirements is the single most consistent cause of project failure, regardless of project size and organization. The requirements analysis process is defect prone for a variety of reasons. Post-implementation reviews of most information systems projects typically show that 60-75% of all defects encountered during a project, and embedded in the finished systems products, are defects in requirements.

Hidden FactoriesUnacknowledged rework due to defects is referred to as a hidden factory. In software development, hidden factories often make up for more than 50% of the effort of producing software. The discovery and elimination of hidden factories is a gradual process, beginning with the most obvious rework and continuing towards the less obvious.

COPR (Cost of Poor Reqs.)

Common Problems with RequirementsLack of User InvolvementLack of TrainingNot identifying Software Usability AttributesMaking bad assumptionsWriting implementation (HOW) instead of requirements (WHAT) Describing operations instead of writing requirements Using incorrect terms Using incorrect sentence structure or bad grammar Missing requirements Over-specifying

Lack of TrainingBecause the quality of any product depends on the quality of the raw materials fed into it, poor requirements cannot lead to excellent software. Sadly, few software developers have been educated about how to elicit, analyze, document, and verify the quality of requirements. There arent many examples of good requirements available to learn from, partly because few projects have good ones to share, and partly because few companies are willing to place their product specifications in the public domain. ..Karl Wiegers

Missing RequirementsUsing standards like Mil-Std-490 or IEEE P1233 can help ensure you dont miss out most of the requirements.At the minimum, include the following:Functional Reliability Performance Maintainability Interface Operability Environment Safety Facility Regulatory Transportation Security Deployment Privacy Training Design constraints Personnel

Using Incorrect TermsIn a specification, there are terms to be avoided and terms that must be used in a very specific manner. Authors need to understand the use of shall, will, and should:Requirements use shall. Statements of fact use will. Goals use should. All shall statement (requirements) must be verifiable, otherwise, compliance cannot be demonstrated. Terms such as are, is, was, and must do not belong in a requirement. They may be used in a descriptive section or in the lead-in to a requirements section of the specification.

Using Incorrect TermsThere are a number of terms to be avoided in writing requirements, because they confuse the issue and can cost you money, e.g.SupportBut not limited toEtc.And/OrThe word support is often used incorrectly in requirements. Support is a proper term if you want a structure to support 50 pounds weight. It is incorrect if you are stating that the system will support certain activities.WRONG: The system shall support the training coordinator in defining training scenarios.RIGHT: The system shall provide input screens for defining training scenarios. The system shall provide automated training scenario processes.The terms but not limited to, and Etc. are put in place because the person writing the requirements suspects that more may be needed than is currently listed. Using these terms will not accomplish what the author wants and can backfire.

Ambiguous TermsA major cause of unverifiable requirements is the use of ambiguous terms. The terms are ambiguous because they are subjective -- they mean something different to everyone who reads them. This can be avoided by giving people words to avoid. Specific words that should be avoided because they are vague and general are "flexible", "fault tolerant", "high fidelity", "adaptable", "rapid or fast", "adequate", "user friendly", "support", "maximize" and "minimize" ("The system design shall be flexible and fault tolerant" is an example). Other words that should be avoided are "and/or", "etc." and "may". Only one requirement per sentence !

So, what is the solution ?The focus must clearly be put on the customer and the objective must not simply be to satisfy, but to delight.

This can only be accomplished by providing the right system and executing the pertinent project(s) in the right way.

The provision of the right system is translated into providing a system to the customer that reflects both stated and implied requirements.

Doing things the right way can be achieved by validating and verifying requirements, for both external and internal customers, during the entire project life cycle.

Requirements DefinitionTranslate customer needs into a clear, detailed specification of what the system must do. The functions that the system must perform will be defined down to the subsystem (e.g., account administration). Focuses on understanding the business process flow, the business requirements, and the prioritization of requirementsAdditionally, during this phase, the technical infrastructure issues are reviewed as well to understand the environment requirements where the product will be operational.

VolereVolere (Voh-lair-ray) the Italian verb to want, or to wish Developed by James and Suzanne Robertsons of Atlantic System GuildAvailable at http://www.volere.co.uk or http://www.systemsguild.com/ Volere Requirements Process is described in Mastering the Requirements Process by Suzanne and James Robertson, Addison-Wesley, London, 1999. ISBN is 0-201-36046-2

VolereVolere is the umbrella that covers the collection of requirements resources, templates, process, consulting and training This presentation only focuses on Volere Requirements Specification Template (http://www.volere.co.uk/template.htm)

The Volere Process

Why Volere ?It has changed the way I look at projects, and has helped me to be 10 times more efficient and successful with gathering customer requirements, and conveying them to my development team. The framework has worked excellently, and we are establishing our own template which is based on your teachings." C. McKinnon - Program Manager, Microsoft Corporation We have only had to spend 53% of those dollars. Why? A much thorough job of requirements development was performed, resulting in the employment of less programming contractors. Without this concentration upon requirements, we would have consumed budget dollars employing additional programmers for the "normal" rework. John Capron, Worldwide Systems Technology Manager, IBM Enterprise Systems Group,Poughkeepsie, N.Y

Some users of VolereAmerican Express Aventis Pharmaceuticals BankOne Cesky Mobil Commonwealth Bank Cordis Europa NV Emirates Airlines ETAS GmbH Federal Express GEC Marconi Guinness UDV H&R Block Harvard Online Hewlett-Packard IBM Insurance Australia Group International Atomic Energy Authority Jaguar KMD Lloyds TSB Micron Computer Ministry of Defence

MobiFon National University of Ireland Nationals Air Traffic Service Nordstrom Nordstrom Optus Patni Computer Systems Ltd. (India) PixelPark Plymouth City Council PriceWaterhouseCoopers Rohde & Schwarz SBEI Finland sd&m Servcon South Africa Siemens Spacetec Swinburne University Telecom Italia Telemedicine, Victoria Legal Aid Wachovia Woolworths

Volere Requirements Specification TemplateThere are 5 major sectionsProject DriversProject ConstraintsFunctional RequirementsNon-functional RequirementsProject IssuesEach Section has some sub-sections / chapters, total 27

Project DriversProject drivers are the business- related forces. For example the purpose of the product is a project driver, as are all of the stakeholders each for different reasons.(01) Purpose of the Product (02) Client, Customer and other Stakeholders(03) Users of the Product

Project ConstraintsProject constraints identify how the eventual product must fit into the world. For example the product might have to interface with or use some existing hardware, software or business practice, or it might have to fit within a defined budget or be ready by a defined date.(04) Mandated Constraints(05) Naming Conventions and Definitions(06) Relevant Facts and Assumptions

Functional RequirementsSpecifications of the products functionalityActions the product must take check, calculate, record, retrieveDerived from the fundamental purpose of the productNot a quality for example, fast is a quality, and is therefore a non-functional requirement(07) The Scope of Work(08) The Scope of the Product(09) Functional and Data Requirements

Non-Functional RequirementsBehavioral properties that the specified functions must have, such as performance, usability, etc. Non-functional requirements can be assigned a specific measurement. (10) Look and feel Requirements the spirit of the products appearance(11) Usability Requirements the products ease of use, ad any special usability considerations(12) Performance Requirements ho fast, how safe, how many, how accurate the functionality be

contd(13) Operational Requirements the operating environment of the product, and what considerations must be made for this environment(14) Maintainability and Portability Requirements expected changes, and the time allowed to make them(15) Security Requirements the security and confidentiality of the product(16) Cultural and Political Requirements special requirements that come about because of the people involved in the products development and operation(17) Legal Requirements what laws and standards apply to the product

Project IssuesProject issues define the conditions under which the project will be done. We include these in the requirements specification to present a coherent picture of all the factors that contribute to the success or failure of the project.(18) Open Issues(19) Off-the-shelf Solutions(20) New Problems(21) Tasks(22) Cut-Over(23) Risks(24) Costs(25) User Documentation(26) Waiting Room(27) Ideas for Solutions

Capturing using Requirements Shell Card / Snow Card / Atomic Requirement Template

Fit CriterionAn objective measure that will enable testing to determine if the goal has been met by the product Some guideline for making goals measurable are:Specify each adverb and adjective so that everyone on the project understands the same meaning.Replace pronouns with the names of specific people or organizations.Ensure that the meaning of every noun is defined in one place in the specification

Fit Criterion: ExampleWe want to give immediate and complete response to customers ordering our goods over the telephone. We - Employees of XYZ Corporationwant to give immediate - during the course of a telephone calland complete - product availability and priceresponse - verbal information to customers - anyone who enquires about our productsour - supplied by XYZ Corporationgoods - products that we manufactureover the telephone

Requirements DescriptionA good requirement states something that is necessary, verifiable, and attainableNeed. If there is a doubt about the necessity of a requirement, then ask: What is the worst thing that could happen if this requirement were not included? If you do not find an answer of any consequence, then you probably do not need the requirement (i.e., it might just be a gold-plating)Verification. As you write a requirement, determine how you will verify it. Determine the criteria for acceptance. This step will help insure that the requirement is verifiable.Attainable. To be attainable, the requirement must be technically feasible and fit within budget, schedule, and other constraints. If you are uncertain about whether a requirement is technically feasible, then you will need to conduct the research or studies to determine its feasibility. Even is a requirement is technically feasible, it may not be attainable due to budget, schedule, or other, e.g., weight, constraints. There is no point in writing a requirement for something you cannot afford -- be reasonable.Clarity. Each requirement should express a single thought, be concise, and simple. It is important that the requirement not be misunderstood -- it must be unambiguous. Simple sentences will most often suffice for a good requirement.

Req. Desc. contdNASA has done the most pioneering work in this area. They deploy an Automated Requirement Measurement (ARM) Tool to assess the quality (not the correctness) of a requirements specification document. http://satc.gsfc.nasa.gov/tools/arm/

Reviewing RequirementsIrrespective of the SDLC (Waterfall / V-model / Spiral / etc.), Technical / Peer Reviews have an excellent ROI on the Development ProcessUse Fagan Inspection / Fagan Defect-Free Process, Gilb Inspection, etc.Involve Dev, QA, Stakeholders, etc.Use Metrics to exit the review

Testing RequirementsStart testing requirements as soon as you start writing them. First test is to determine if you can quantify the requirement by specifying its fit criterion. This fit criterion is an objective measure of the requirements meaning; it is the criterion for evaluating whether or not a given solution fits the requirement. If a fit criterion cannot be adequately specified, then the requirement is ambiguous, or ill understood. If there is no fit criterion, then there is no way of knowing if a solution matches the requirement.

My Experiences with VolereI used Volere template to prepare PRD for Gigabit-Switch Router1 Indian and 11 Chinese engineers (who had never earlier written in English !) completed the 280+ page PRD in little over 15 days.We identified around 1100+ requirements in the PRDWe wrote over 700,000 LOC of C code by 13 parallel teams (out of which 2 were outsourced)Development delayed by 2 months (dev team had 120+ engineers). We used our processes that were CMM Level 5 processesWe got around 50+ Change Request on the product. The RSI (Requirements Stability Index) was over 90%Within 4 months of starting the integration, we were having less than some 150 defects (in the total code base of around 2M LOC)This was by far the most successful project of this size (>5M US$) in the company

Referenceshttp://www.processimpact.com/articles/qualreqs.htmlhttp://www.stickyminds.com/sitewide.asp?ObjectId=6335&Function=DETAILBROWSE&ObjectType=COLhttp://www.spmn.com/lessons.html#fourhttp://www.odegard.com/enews/aug2003/dcopq.htmhttp://www.stevemcconnell.com/articles/art04.htmhttp://www.artima.com/weblogs/viewpost.jsp?thread=5446

Any questions ?

Thank you !!!