Requirements Analysis and Design Engineering

1. RequirementsAnalysis andDesignEngineering Southern Methodist University CSE 7313

2. Module 2 - Analyzing the Problem

3. Requirements roundtable • http://interactive.sei.cmu.edu/Features/1999/March/Roundtable/Roundtable.mar99.htm

4. 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

5. The problem domain

6. A more Realistic Problem domain

7. “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

8. Problem/solution domains needs Problem domain features Software requirements solution domain

9. Software as a team activity • “Software development has become a team sport” – Booch 1998 • COCOMO – capability of the TEAM has the greatest impact on software productivity

10. Requisite team skills for requirements management • Analyzing the problem domain • Understanding user needs • Defining the system • Managing scope • Refining system definition • Building the right system • We will discuss all of these !!

11. Different Skills • Working with customers • Software programming • Testing • Design and architecture abilities • Also requirements management

12. 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

13. 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!

14. 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

15. 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

16. Problem Statement Format

17. 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!

18. Fishbone Diagram Inaccurate sales orders Damaged in shipment Customer returns Too much scrap Finished goods Obsolescence Other Manufacturing defects

19. Addressing the root cause • Quality data demonstrates that many root causes are simply not worth fixing

20. Sales order problem statement

21. 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

22. 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?

23. Users and stakeholders of new system

24. 4. Define the solution system boundary • Boundary defines the border between the solution and the real world that surrounds the solution inputs outputs system

25. System boundary • World divided into two parts • Our system • Things that interact with our system

26. Actors • Someone or something, outside the system, that interacts with the system System boundary I/O Our solution I/O Other systems users

27. 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?

28. System Perspective Sales Order clerk Legacy System With Pricing data New sales Order entry Billing clerk System boundary Shipping clerk Production foreman

29. 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

30. 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!

31. Potential system constraints

32. Potential system constraints