Analyzing the Problem

1. Waniwatining Astuti, M.T.I Analyzing the Problem

2. The five steps in Problem Analysis • Business Modeling • System engineering of software – intensive systems Development teams tend to forge ahead, proiding solutions based on an inadequate understanding of the problem to be solved.

3. A. The five steps in problem analysis Key points : • Problem analysis is the process of understanding real – world problems and user’s needs and proposing solution to meet those needs. • The goal of problem analysis is to gain a better understanding of the problem being solved, before development begins • To identify the root cause, or the problem behind the problem, ask the people directly involved. • Identifying the actors on the system is a key step in problem analysis.

4. The specific steps that must be taken in order to achieve the goal are listed below • Gain agreement on the problem definition. • Understand the root causes – the problem behind the problem. • Identify the stakeholders and the users. • Define the solution sysem boundary. • Identify the constraints to be imposed on the solution.

5. Step 1. Gain agreement on the problem definition • The problem statement Example : problem statement format

6. Step 2. Understand the root causes – the problem behind the problem. • Quality data demonstrates that many root causes are simply not worth fixing • Fishbone diagram • Pareto chart

7. Problem to solve & technique applied Problem to solve technique applied Lack of profitability total quality management Cost of nonconformance fishbone diagram Too much scrap pareto chart Inaccurate sales order new software solution

8. Step 3. Identify the stakeholders and the users The following questions can be helpfull in this process • Who are the users of the system? • Who is the customer (economic buyer) for the system? • Who else will be affected by the outputs the system produce? • Who will evaluate and approve the system when it is delivered and deployed? • Are they any other internal or external users of the system whose needs must be addressed? • Who will maintain the new system? • Is there anyone else who cares?

9. Understanding the needs of the users and other stakeholders is a key factor in developing an effective solution.

10. Step 4. Define the solution sysem boundary. • We defide the world into two interesting classes of things : • Our system • things that interact with our system Input system output

11. How do we find these actors? Here are some helpful questions to ask • 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? • What over external system will interact with the system?

12. Step 5.Identifying the actors on the system is a key step in problem analysis • Potential sources of system constraints • Economics • Politics • Technology • Systems • Environment • Schedule and resources

13. B.Business Modeling Key Points : • Business modeling is a problem analysis technique especially suitable for the IS/IT environment. • The business model is used to help define systems and their applications. • A business use-case model, consisting of actors and use cases, is a model of the intended functions of the business. • A business object model describes the entities that deliver the functionality to realize the business use cases and how these entities interact.

14. In these contexts, it would be helpful to have a technique to determine answers to an even broader set of questions such as the following. • Why build a system at all? • Where should it be located? • How can we determine what functionality is optimum to locate on a particular node in the system? • When should we use manual-processing steps or workarounds? • When should we consider restructuring the organization itself in order to solve the problem?

15. The Purpose of Business Modeling In any case, the purpose of business modeling is threefold: • To understand the structure and dynamics of the existing organization • To ensure that customers, end users, and developers have a common understanding of the organization • To understand how to deploy new systems to facilitate productivity and which existing systems may be affected by that new system

16. Using Software Engineering Techniques for Business Modeling With the right choice of business modeling technique, some of the work products, such as use cases and object models, will be useful in the solution activity. Business modeling is not something we recommend for every software engineering effort. Business models add the most value when the application environment is complex and multidimensional, and when many people are directly involved in using the system.

17. Business Modeling Using UML Concepts • One of the goals of business models is to develop a model of the business that can be used to drive application development. Two key modeling constructs that can be used for this purpose are a business use-case model and a business object model.

18. Business use-case model A business use-case model, then, consists of business actors and business use cases, with the actors representing roles external to the business (for example, employees and customers) and the business use cases representing processes Examples of a business use-case model might be "Deliver electronic pay stub to employee." "Meet with customer to negotiate contract terms." Examples of business actors are "Customer" "Employee" "Software developer"

19. Business object model A business object model may also include business use-case realizations that show how the business use cases are "performed" in terms of interacting business workers and business entities. To reflect groups or departments in an organization, business workers and business entities may be grouped into organizational units.

20. From the Business Model to the Systems Model

21. C. Systems Engineering of Software-Intensive Systems Key Points • Systems engineering is a problem analysis technique especially suitable for embedded-systems development. • Systems engineering helps us understand the requirements imposed on software applications that run within the solution system. • Requirements flowdown is primarily a matter of ensuring that all system requirements are filled by a subsystem or a set of subsystems collaborating. • Today, the system design must often be optimized for software costs rather than for hardware costs.

22. What Is Systems Engineering? According to the International Council on Systems Engineering [INCOSE 2003]: Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: • Operations • Performance • Test • Manufacturing • Cost and Schedule • Training and Support • Disposal

23. Pragmatic Principles of Systems Engineering Systems engineering provides eight pragmatic principles. • Know the problem, know the customer, and know the consumer. • Use effectiveness criteria based on needs to make the system decisions. • Establish and manage requirements. • Identify and assess alternatives so as to converge on a solution. • Verify and validate requirements and solution performance. • Maintain the integrity of the system. • Use an articulated and documented process. • Manage against a plan.

24. The Composition and Decomposition of Complex Systems A system in its environment

25. A system composed of two subsystems

27. Requirements Allocation in Systems Engineering Requirements flowdown allocates system functionality to subsystems.