CMPS 115 - Requirements

1. CMPS 115 - Requirements Hats off to Brian Lawrence of Coyote Valley Software & Drew Downs of Process Focus Incorporated

2. Why Bother with Requirements? • If you know your software’s requirements, you can: • Set expectations • Establish a common understanding • Discover and test assumptions • Create a basis for risk management • Create a basis for system testing A good set of requirements vastly improves the chances that you will build the right software.

3. Why Bother with Requirements? - 2 • Top two factors in failure of system development contracts to meet schedule or budget [SEI] • Inadequate requirements specification • Changes in requirements • Top three causes of quality and delivery problems [Standish Group] • Lack of user input • Incomplete requirements • Changing requirements

4. Why Bother with Requirements - 3

5. Webster’s “Something that is required; a necessity.” From IEEE Standard 610.12-1990 1. A condition or capability needed by a user to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. 3. A documented representation of a condition or capability as in (1) or (2). “Requirements” Defined

6. Exercises • Someone asks you to provide, either by purchasing it for them or by building, a form of urban transportation for their city. What do you come up with? • Mary had a little lamb

7. This implies: Requirements always exist, since you have design choices Requirements are NOT the design choices themselves Many possible drivers of design choices exist Many people contribute requirements, not just customers, and some may not be aware that they are doing so Requirements may or may not be documented, but they are just as real either way Consider a “Requirement” as: “Anything that drives design choices.” Requirements happen, whether you plan them or not - better to admit it and know where you’re going

8. Purpose of All Requirements is to answer the questions: • Are we doing the right thing? • What makes us think so? • How do we know when we’re done?

9. Customer’s Requirements Customer (as opposed to user) wants or need Designer’s Requirements Ones brought by the system designers Accidental Requirements Arbitrary decisions made by the designers Genuine Requirements Ones users actually need and value There are many kinds of Requirements

10. Many Levels of Requirements Elicitation Customer Requirements System Architecture System Requirements System Design System Requirements allocated to Software Software Architecture Software Requirements

11. Elements of a Requirements Definition • Purpose of the system • Context of the system • Problem description

12. Purpose • Why are you bothering to build this system at all? • “Where’s the users’ pain?” • What customer’s problem are you attempting to solve? • Don’t build solutions and then go looking for problems they might solve

13. Problem and Context • There are two fundamentally different kinds of requirements • Your customer’s design problem to be solved • The context within which you are setting out to solve that design problem • Problem information and context information are managed very differently

14. The Context • Issues • Questions about the context • Assumptions • Statements about the context (often answers to the issues) • Choices • Assumptions which have been confirmed by an authority

15. The Problem • Answers the question “In what characteristic ways are we going to do what for whom?” • Comprises: • Users - Roles that people take • Attributes - Characteristics of the system • Functions - Actions the system is to perform • Formulate problem without reference to technology • Drive out technology by asking “What’s the essence of this?” or “Why are we doing this?” Managing the problem is about choosing what problem to solve, then making sure that you solve that and no other problem.

16. Why “No Technology?” By specifying in terms of technology, you are defining the problem in terms of a solution. 3. Specifying in terms of a solution may preclude discovering other, possibly better solutions. This is particularly true for long-lived systems. 2. Specifying in terms of a solution removes the ability to validate the system—all you can do is verify. 1. Specifying in terms of the problem rather than the solution shifts the basis of the negotiation from a positional negotiation to a principled negotiation.

17. Always Keep In Mind . . . • The Problem is always embedded in the Context • Shifts in the context can and often do dramatically redefine the problem • Always ask • What problems does this system solve? • What problems does this system create? • What environment is this system likely to encounter? • What kind of precision is expected in this type of product? • What did the system do that this one replaces?

18. Users “Any individual who could be affected in any way by the system we are building” • Described as roles - typically nouns • Lawyers • Honest people • Favored Users • Ones we are explicitly building something for • Disfavored Users • We put in something to explicitly prevent them from doing something • Ignored Users • We are not putting anything in for these users Overlooking an important user is usually a design catastrophe, which may be difficult or even impossible to overcome.

19. Functions • Actions the system must perform to be satisfactory • Typically verbs or verb phrases • “The game should . . .” • “The game should display the current score.” • NOT: “The game should have a blue background.” • Evident • Everyone can see them - announcing the current floor on an elevator • Hidden • As imperceptible as possible - movement in an elevator • How about producing lamb chops?

20. Attributes • My old dog and the new Sony Robodog have most of the same functions - they differ in attributes. • The Robodog is dead. My dog is alive. Mostly. • Attributes are the desired characteristic dimensions of the solution • Typically adjectives or adverbs • Attribute: ease of use (ergonometric, flexible display, easy to understand, foolproof), profitable (easy to sell, easy to package, easy to manufacture.) Response time (fast, slow, appropriate, consistent)

21. Types of Attributes • Defining • You must have these or you haven’t solved the problem • Distinguishing • You want to push these ones as far as possible during design • Blue Sky • “Figure the odds! I mean, we’ll do some tradeoffs.” Failing to understand which are defining and which are distinguishing attributes is a critical and COSTLY requirements failure.

22. Constraints/Performance • Constraints are measurable conditions placed on attributes. • Constraint for “ease of use” attribute: “This constraint is defined in terms of the number of times an experienced computer game player requires external assistance in playing the game. To test whether the constraint has been satisfied we will run the experiment using three students from the lab. The average number of external information requests must be less than three.” • Constraint for “Response Time” attribute: the game will respond to all mouse clicks on it’s board surface within 1 second of the click.” • Constraints are the boundaries.

23. Why Classify Requirements as Function, Attribute, Constraint? • Clarifies the requirements • Finds missing requirements • Identifies unnecessary or redundant requirements • Ensures that requirements are testable

24. Requirements Data Flow Derived from QSM 4

25. Defects in Requirements • Unclear or ambiguous • Incorrect • Missing • These are hard to find!!! • Not measurable or testable • Stated as a design, not a need • Cost of requirements defects: • Up to 100x if not found until test

26. Opinions about Requirements

27. Opinion # 1 “Requirements vary in importance & it’s essential to understand their relative value.” • Requirements represent the interests of the stakeholders of the system, including customers, end-users, system designers, and others. Requirements are nearly always in conflict. • A critical aspect of a managing requirements is making tradeoffs among them. • The term “requirement” is actually a poor choice of words.

28. Opinion # 2 “If we don’t meet customers’ expectations, we fail, even if we meet all our requirements.” • Many papers and books assume that the requirements may be found in requirements specifications and tools—those are only models of the requirements. • Never confuse the map with the terrain!!! • The real requirements exist in the minds of the stakeholders - and they may not be documented. • We construct models such as prototypes and requirements docs to help define the real requirements in peoples’ minds.

29. Opinion # 3 “The process of negotiating requirements is what results in shared understanding of a product.” • Frequently, requirements activities are characterized as being limited to gathering, tracing, modeling, or analyzing requirements, but not negotiating them. • Negotiating is the process of taking what we think we know about the customer’s needs and how they are valued, offering potential fulfillments and feeding back the outcome to our requirements. • Informed negotiators are more effective than uninformed negotiators.

30. Opinion # 4 “You can NEVER know all the requirements, but you can reduce your uncertainty a lot!.” • Fuzziness scale • Unknown and unaware • Aware but unspoken • Spoken but not written • Written • Explicitly negotiated, documented, and signed off • In every software project, some of the more fuzzy requirements always exist, and they always will.

31. Opinion # 5 The creation of a requirements documents is an effective communication process - but the requirements document is probably not an effective means of communication • Most of the value in producing a model or specification comes during its construction, not in its application later. • This is because most of the learning happens during construction. • Requirements specifications after the fact are mostly boring. • There are some notable exceptions (e.g. litigation)

32. Opinion # 6 The principle product of a requirements process is shaping the minds of the designers and users, not production of the specification • Customers should certainly participate in requirements definition, but remember that it’s the designers who are going to construct the system based on their understanding of the requirements, and no one else’s. • It’s crucial that the designers model the requirements, where the best understanding is forged. • Designers frequently believe that they haven’t signed up to participate in requirements modeling • Customers should NOT “own” the requirements.

33. Opinion # 7 Requirements don’t change; our understanding of them changes. • Genuine requirements don’t change all that fast, even in volatile environments such as Web development. • What does change is our perception of requirements, as we find out which are actually the genuine requirements, and which are not. • That said, expect that your understanding *will* change over time.

34. Opinion # 8 The more you know, the less you risk, so even a sketchy requirements effort is better than none. • The point of developing requirements is reducing uncertainty, not eliminating it. • You can get pretty good requirements even where there truly is considerable uncertainty. • Frequently people find it easier to say what they don’t like than what they do - so having something the customer can criticize can really help define what she *does* want

35. Bibliography • Andriole, Stephen J., Managing System Requirements: Methods, Tools, and Cases, McGraw-Hill, 1996. • Weinberg, Gerald M., Quality Software Management, Volume 1, Systems Thinking, Dorset House Publishing, 1992. • Gause & Weinberg, Exploring Requirements, Quality Before Design, Dorset House Publishing, 1989. • Hooks, Ivy, “Writing Good Requirements”, Proceedings of the Third International Symposium of the NCOSE, Volume 2, 1993 • Harwell, Richard, “What is a Requirement”, Proceedings of the Third International Symposium of the NCOSE, Volume 2, 1993 • Kar, Pradip, “Characteristics of Good Requirements”, Presented at the 1996 INCOSE Symposium. • www.incose.org • www.coyotevalley.com - Brian Lawrence • Again, this presentation was based on work by and with Brian Lawrence and Drew Downs.