1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem

2 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Requirements Management Boeing 777 – 300,000 requirements > 4 million loc 1280 embedded processors

3 Version /05/2004 © 2004 Robert Oshana Requirements Engineering The Problem Domain Home of real users and other stakeholders –People whose needs must be addressed –People who need “the rock” These people are not like us ! –Different technical and economic backgrounds –Speak in funny acronyms –Motivations that seem strange and unfathomable

4 Version /05/2004 © 2004 Robert Oshana Requirements Engineering The problem domain

5 Version /05/2004 © 2004 Robert Oshana Requirements Engineering “Features” A service that the system provides to fulfill one or more stakeholder needs Simple descriptions in the user’s language used as labels to communicate with the user how the system addresses the problem

6 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Problem/solution domains needs features Software requirements Problem domain solution domain

7 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Problem Analysis Some applications solve problems Others take advantage of opportunities in the market (existence of a problem may not be clear) –SimCity –Myst Problem analysis; the process of understanding real-world problems and user needs and proposing solutions to meet those needs

8 Version /05/2004 © 2004 Robert Oshana Requirements Engineering What is a Problem? “A problem can be defined as the difference between things as perceived and things as derived” – Weinberg Sometimes the simplest solution is a workaround or revised business plan, rather than a new system Changing the desire or perception may be the most cost effective solution!

9 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Problem Analysis The goal of problem analysis is to gain a better understanding of the problem being solved before development begins –Gain agreement on the problem definition –Understand the root causes – the problem behind the problem –Identify the stakeholders and the users –Define the system boundary –Identify the constraints to be imposed on the solution

10 Version /05/2004 © 2004 Robert Oshana Requirements Engineering 1. Gain Agreement on the Problem Definition Write down the problem and see if everyone agrees –Have the customer describe the benefits Seems simple but this step can cause much discussion and emotion

11 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Problem Statement Format ElementDescription The problem of Describe the problem affects Identify stakeholders affected by the problem the result of which Describe the impact of this problem on stakeholders and business activity benefits of Indicate the proposed solution and list a few key benefits

12 Version /05/2004 © 2004 Robert Oshana Requirements Engineering 2. Understand Root Causes Gain understanding of real problem and real causes “Root cause” analysis Total Quality Management techniques Ask people directly involved what the problems are!

13 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Fishbone Diagram Too much scrap Inaccurate sales orders Damaged in shipment Customer returns Finished goods Obsolescence Manufacturing defects Other

14 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Addressing the root cause Quality data demonstrates that many root causes are simply not worth fixing

15 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Sales order problem statement ElementDescription The problem of Inaccuracies in sales orders affects Sales order personnel, customers, manufacturing, shipping, and customer service the result of which Is increased scrap, excessive handling costs, customer dissatisfaction, and decreased profitability benefits of A new system to address the problem include; Increased accuracy of sales orders at point of entry Improved reporting of sales data to management Higher profitability

16 Version /05/2004 © 2004 Robert Oshana Requirements Engineering 3. Identify the Stakeholders and the Users Stakeholder; anyone who could be materially affected by the implementation of a new system or application Many stakeholders are users Others are indirect users –Affected by the business outcomes that the system influences Non-user stakeholder needs must also be identified and addressed

17 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Questions Who are the users of the system? Who is the customer (economic buyer) for the system? Who else will be affected by the outputs that the system produces? Who will evaluate and bless the system when it is delivered? Who will maintain the system?

18 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Users and stakeholders of new system UsersOther stakeholders Sales and order entry clerks MIS director and development team Sales order supervisorChief financial officer Production controlProduction manager Billing clerk

19 Version /05/2004 © 2004 Robert Oshana Requirements Engineering 4. Define the solution system boundary Boundary defines the border between the solution and the real world that surrounds the solution inputs system outputs

20 Version /05/2004 © 2004 Robert Oshana Requirements Engineering System boundary World divided into two parts –Our system –Things that interact with our system

21 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Actors Someone or something, outside the system, that interacts with the system I/O users Our solution Other systems I/O System boundary

22 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Finding actors Who will supply, use, or remove information from the system? Who will operate the system? Who will perform any system maintenance? Where will the system be used? Where does the system get its information?

23 Version /05/2004 © 2004 Robert Oshana Requirements Engineering System Perspective Sales Order clerk Billing clerk Shipping clerk Production foreman New sales Order entry Legacy System With Pricing data System boundary

24 Version /05/2004 © 2004 Robert Oshana Requirements Engineering 5. Identify the constraints to be imposed on the solution Constraints are restrictions on the degrees of freedom we have in providing a solution Various sources of constraints –Schedule –ROI –Budget for labor and equipment –Environmental issues –Operating systems and databases –etc

25 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Constraints Constraints may be given to us before we start or we may have to actively elicit them Should understand the perspective of the constraint Should understand when the constraint no longer applies to the solution The less constrained the better!

26 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Potential system constraints SourceSample considerations Economic What financial or budgetary constraints are applicable? Are there costs of goods sold or any product pricing considerations? Are there any licensing issues? Political Are there any internal or external political issues that affect potential solutions? Interdepartmental issues? Technical Are we restricted in the choice of technologies? Are we constrained to work with existing platforms or technologies? Are we prohibited from any new technologies? Are we to use any purchased software packages?

27 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Potential system constraints SourceSample considerations System Is the solution to be built on our existing systems? Must we maintain compatibility with existing solutions? What operating systems and environments must be supported? Environmental Are there environmental or regulatory constraints? Legal? Security requirements? Schedule and resources Is the schedule defined? Are we restricted to existing resources? Can we use outside labor? Can we expand resources?

28 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Summary – 5 steps of problem analysis 1.Gain agreement on the problem definition 2.Understand root causes 3.Identify stakeholders and users 4.Identify the system boundary 5.Identify the constraints on the system

29 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Hotel example