1. Analyzing the Problem : Concepts and Techniques 3

2. Requirements Engineering Team Skill 1 - Analyzing the problem. Team Skill 2 - Understanding user needs. Team Skill 3 - Defining the system. Team Skill 4 - Managing scope. Team Skill 5 - Refining the system definition. Team Skill 6 - Building the right system.

3. Problem Analysis Definition: the process of understanding the real-world problems and users needs and proposing abstract solutions to those problems. Goal: gain a better understanding, before development begins, of the problem to be solved. Avoid to jump to conclusions by identifying the root cause of the problem. Identify the sources of information for system analysis.

4. Team Skill #1. Analyzing The Problem  The Five Steps in Problem Analysis.  Business Modeling.  Systems Engineering of Software Intensive Systems.

5. Ch 1: The Five Steps in Problem Analysis Step 1: Gain Agreement on the Problem Definition. Step 2: Understand the Root Causes--The Problem Behind the Problem. Step 3: Identify the Stakeholders and the Users. Step 4: Define the Solution System Boundary. Step 5: Identify the Constraints to Be Imposed on the Solution.

6. The Five Steps in Problem Analysis Step1 : Gain agreement on the problem definition  Write a simple and clear definition of the problem description  Establish an order of importance for all features of the system  Come to an agreement with all stakeholders  Resolve conflicts by negotiation

7. Step 1: Gain Agreement on the Problem Definition. simply write the problem down and see whether everyone agrees The first step is to gain agreement on the definition of the problem to be solved. One of the simplest ways to gain this agreement is to simply write the problem down and see whether everyone agrees. It is helpful to write down in a standardized format which we call “The Problem Statement”.

8. The Problem Statement ElementDescription The problem of affects The result of which Benefits of

9. The Problem Statement ElementDescription The problem ofDescribe the problem. affectsIdentify stakeholders affected by the problem. The result of whichDescribe the impact of this problem on stakeholders and business activity. Benefits ofIndicate the proposed solution and list a few key benefits

10. The Problem Statement - advantages What are the advantages of the Problem Statement? need-to-have nice-to-have When you write down the “The Problem Statement”, you will be able to classify the requirements into need-to-have requirements and nice-to-have requirements. electronic funds transfer that would improve the cash flow of the company The primary goal of the new system is to provide electronic funds transfer that would improve the cash flow of the company. After a raucous discussion, it became clear in the application of electronic funds transfer: need-to-have: security nice-to-have : emails, voice transmission

11. The Five Steps in Problem Analysis Step 2 : Identify the root causes of the problem  Make sure that the problem identified is the real problem  Sometimes, a problem hides other more important problems  Addressing the wrong problem leads to failure  A problem can have several causes: Some might be eliminated by non-software solutions Some might need contradictory solutions More than one solution might be needed  This part of the analysis requires input from extremely knowledgeable, insightful and experienced persons.

12. Step 2: Understand the Root Causes “” SACO is a company that sells a variety of inexpensive, miscellaneous items of home and personal use. The company realizes a slide in turnover and profits. It decides to identify the problem. After investigation, it concludes that the problem is due to production waste or “scrap”. Next step is to get into the root cause, or the problem behind the problem in scrap. This is to determine what factors contribute to the scrap problem.

13. The Problem Behind the Problem – fishbone diagram Improper sales orders Finished-goods obsolescence Manufacturing defects Damaged in shipment Customer returns other Scrap

14. Addressing the Root Cause The system study team is justified in proposing a replacement for the existing sales order entry system. It prepares the problem statement of new sales order system as follows: ElementDescription The problem ofImproper and inaccurate sales order. affectsSales order personnel, customers, manufacturing, shipping, and customer service. The result of whichIs increased in scrap, excessive handling costs, customer dissatisfaction, and decreased profitability. Benefits ofA new system to address the problem include Increased accuracy of sales orders at point of entry Online sales transaction Improved reporting of sales data to management higher profitability

15. The Five Steps in Problem Analysis Step 3 : Identify stakeholders and users  Stakeholder: anyone who could be affected by the new system or has input to provide in the implementation of the new system  Complex problems always involve the input of different stakeholders that have different viewpoints on the problem. Users: will use the system Managers: will pay for the system, or will manage the users IT people: will install, manage and maintain the system External regulators: will impose constraints on the system operation System developers: will implement a solution to the problem  Forgetting one of these might lead to major rework later on, or even to project failure.

16. Step 3: Identify the Stakeholders and the Users stakeholder A stakeholder is anyone who could be materially affected by the implementation of a new system or application. How do you identify the stakeholders? The answer to the following questions will identify the stakeholders: 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 and deployed? Are there any other internal or external users of the system whose needs must be addressed? Who will maintain the new system? Is there anyone else?

17. Users and stakeholders of our new sales order entry system Usersstakeholders Sales order entry clerksMIS director and development team Sales order supervisorChief financial officer Production controlProduction manager Billing clerk

18. Five steps of problem analysis Step 4 : Define the system boundary  Any software system has to interact with its environment  System boundary describes an envelope in which the solution is contained.  System is divided as: The system itself and its functionalities The things (outside the system) that interacts with the system  Actors: Supplies, uses, or modifies the information in the system Someone or something, outside the system, that interacts with the system  Later on, this early information will direct how the system interfaces will be defined.

19. Step 4: Define the Solution System Boundary We divide the world into two classes: Our system Things that interact with our system I/O Our system System boundary users Other systems

20. Actors How do we identify these actors? The answer to the following questions will identify the actors: Who will supply, use, or remove information from the system? Who will operate the system? Who will perform any system maintenance? Where will be the system used? Where does the system get its information? What other external systems will interact with the system? actor An actor is someone or something, outside the system, that interacts with the system.

21. Our new sales order entry system new sales order system Billing clerk Production foreman Sales order clerk Shipping clerk Legacy system with pricing data System boundary

22. The Five Steps in Problem Analysis Step 5 : Identify the constraints on the system  Constraint : a restriction on the degree of freedom we have in providing a solution  They are as important as requirements : they direct what the system should not do, or what the system should not be.

23. Step 5: Identify the Constraints to Be Imposed on the Solution constraint A constraint is a restriction on the degree of freedom we have in providing a solution. What are the potential system constraints? SourceSample considerations Economical  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 internal or external political issues that affect potential solutions?  Interdepartmental problems or issues?

24. SourceSample considerations Technical  Are we constrained to work within existing platforms or technologies?  Are we prohibited from any new technologies?  Are we restricted in our choice of technologies?  Are we to use any purchased software packages? 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?  What other standards might we be restricted by? Schedule and resources  Is the schedule defined?  Are we restricted to existing resources?  Can we use outside labor?  Can we expand resources? Temporary / permanent?

25. Our new sales order entry system SourceConstraintsRationale SystemAn exact copy of sales order data must remain on the legacy database for up to one year. The risk of data loss is too great; we will need to run in parallel for up to one year. SystemThe applications footprint on the server must be less than 20 MBs. We have limited server memory available. TechnicalThe system must be developed on existing server and host; new client hardware for users may be provided. Cost control and maintenance of existing systems. EconomicalFixed staffing resource; no outsourcing. Fixed operating costs as per the current budget. TechnicalNew OO methodology to be used.We believe that this technology will increase productivity and increase reliability of the software.

26. Summary After that, we have :  A good, general understanding of the problem and its causes  Identified the stakeholders whose collective input and judgment will determine the nature of the system  A notion of the boundary of the system and its interface with the exterior  An understanding of the constraints imposed on the system

27. Ch. 5: Business Modeling Definition:  A problem analysis technique especially suitable for the IS/IT environment. Goal:  To help define systems and their application domains.

28. Business Modeling What is Business Modeling?. Business Modeling is to answer the following questions:  Why build a system at all?  Where should it be located?  How can we determine what functionality is optimum to locate on particular system?  When should we use manual-processing steps or workarounds?  When should we consider restructuring the organization itself in order to solve the problem?

29. Business Modeling What is the purpose of Business Modeling?. The purpose of Business Modeling is twofold:  To understand the structure and dynamics of the organization.  To ensure that customers, end users and developers have a common understanding of the organization.

30. Business Modeling When to use Business Modeling?. Business Modeling is not something that we recommend for every software engineering effort. For example,  If you were building an additional feature to an existing telecommunication switch, you would not consider Business Modeling.  On the other hand, if you were building a new system such as Online sales order entry system for SACO, we could have used business modeling.

31. Business Modeling Applying Software Engineering Techniques for Business Modeling  Using the same techniques or very similar techniques for both business domain and software domain  Using UML concepts

32. Business Modeling What technique can be applied to Business Modeling? The UML provides Business Modeling. There are two key modeling constructs that can be used for this purpose:  Business use-case model.  Business object model.

33. Business Models Business Use-Case Model  A model of the intended functions of the business  Consists of actors and the use cases  Describes who (or what other system) is involved in this business activity and how this activity takes place  Could represent a preliminary version of the use case diagram as developed in the Use-Case driven approach  Its primary goal is to show how things are working now, not what the system should be

34. Business Models Business Object Model  Describes the entities and how they interact to deliver the functionality to realize the business use cases  Entities: Business workers: users, other systems Business entities: anything that business workers produce or use in their business activities  Could represent a preliminary version of the object diagrams (sequence and class diagrams) as developed in the Use-Case driven approach

35. Business Models Taken together, the business use-case model and object model:  Provide a overview of how the business works;  Allow the developers to focus on the areas in which systems can be provided;  Help the developers to understand what changes in the business process will have to take place.

36. Business Modeling and Use Case driven Approach Business modeling clearly fits in the use-case driven approach It provides a first overview of the problem domain. It forces a first draft using simple terms that belong to the problem domain:  Forces early stakeholder implication  Forces problem domain understanding by the software developers Question: How can these models be integrated in the use case driven approach, or to an object-oriented design methodology? Translations from business models to the system model  business workers -> actors  behaviors of the workers -> system use cases, functionality, scenario  business entities -> entity classes

37. Business Modeling When to use business modeling?  The application environment: Complex (requires problem domain analysis) Multidimensional (several sub-problems are concerned) Many people are directly involved in using the system (user centered application)  Not for every software engineering effort

38. Summary By discussing the business modeling, we defined:  Why you might need to model the business  How to use UML for business modeling  business modeling, the business use-case model, and the business object model  How you can define software applications and derive software requirements from models of the business.

39. Ch. 6. Systems Engineering of Software Intensive Systems What is Systems Engineering?. Systems Engineering is a problem analysis technique that helps us understand the needs of the problem space and the requirements that are to be imposed on the solution. The system engineering discipline is based on another process, the successive decomposition of complex systems into simpler ones.

40. Systems Engineering of Software Intensive Systems What are the Principles of Systems Engineering? There is a basic set of 8 Systems Engineering principles: 1.Know the problem, know the users, and know the stakeholders. 2.Use effectiveness criteria based on needs to make the system decisions. 3.Establish and manage requirements. 4.Identify and assess alternatives so as to converge on a solution. 5.Verify and validate requirements and solution performance. 6.Maintain the integrity of the system. 7.Use an articulated and documented process. 8.Manage against a plan.

41. Systems Engineering of Software Intensive Systems Explain the process of Systems Engineering. During the process of Systems Engineering, a complex problem ( or a complex system) is decomposed into smaller problems (or subsystems). Each subsystem can be reasoned out about successfully designed and manufactured, and then integrated to produce the solution system. The decomposition, or successive refinement, process proceeds until the systems engineer achieves the right results, as provided by quantitative measures that are specific to the specific systems engineering domain. In most cases this process continues until a large number of subsystems are developed. The system Subsystem A B A-1A-2

42. The process of Systems Engineering - cont During the process of decomposition of a complex system into smaller subsystems, there are two subclasses of requirements: 1. Subsystem requirements 1. Subsystem requirements are those that must be imposed on the subsystems themselves but do not necessarily provide a direct benefit to the end user. 2. Interfacerequirements 2. Interface requirements may arise the subsystems need to communicate with one another to accomplish an overall result. They will need to share data or power or a useful computing algorithm. Subsystem ASubsystem B A to B interface

43. What will determine ultimate functionality of the system? Systems complexity has moved from hardware to software components. Why?  Cheaper, easier to change, lighter, etc. Nowadays, software, not hardware  will determine the functionality of the system  will determine the success of the system  will consume the majority of the costs of research and system development  will absorb most of the changes that occur during development  will be evolved over the next few years to meet the changing needs of the system The great majority of systems requirements are now software requirements, even though these are still hardware systems

44. Recommendations for doing a good job of Systems Engineering Develop, understand, and maintain the system-level requirements and use cases. Do the best possible job of partitioning and isolating functionality within subsystems (minimize requirements relationships). Develop software for the system as a whole if possible. Use common code on both sides of the interface when coding the interfaces: promote software reuse. Define interface specifications that can do more than would be necessary to simply meet the known conditions.

45. 1.Analyzing the problem 3.Managing the system 3.Managing the system 2.Understandin g user needs 4.Defining the System 4.Defining the System 6.Building the right system 5.Refining the system definition Business Modeling System Engineering of soft. Intensive sys Five steps in problem statement 1.Gaine Agreement on the Problem Definition 5.Identifiy the constraints to be Imposed on solution 5.Identifiy the constraints to be Imposed on solution 4.Define the solution System boundary 3.Identify the Stakeholder s and the users 2.Understa nd the Root Causes Problem Behind Problem 2.Understa nd the Root Causes Problem Behind Problem Effective Requirements Management Effective Requirements Management Summery

46. Problem Analysis Summary Various techniques can be used in problem analysis  Problem analysis A general method used to gain a global understanding of the problem  Business modeling To build a model of business infrastructures  Systems engineering To analyze embedded systems (software controlling/using hardware)  Use-case driven approach A general technique based on OO technology

47. Problem analysis Five Steps :  Gain agreement on the problem definition  Understand the root causes of the problem  Identify the stakeholders and users  Determine the boundaries of the solution  Understand the constraints

48. Business modeling Business Use-Case Model  Describes who (or what other system) is involved in this business activity and how this activity takes place  Could represent a preliminary version of the use case diagram as developed in the Use-Case driven approach Business Object Model  Describes the entities and how they interact to deliver the functionality to realize the business use cases  Could represent a preliminary version of the object diagrams (sequence and class diagrams) as developed in the Use-Case driven approach

49. Systems engineering Composition and decomposition process is very important- It has to take in account Requirements also have to be composed and decomposed as the system is specified Subsystem interfaces have to be clear and flexible Development process has to take into account the physical constraints of the apparatus in which it is embedded

50. UML vs. Requirements Modeling UML: Unified Modeling Language A software analysis and design methodology mainly based on diagrams Requirements Modeling in UML: The Use-Case-Driven Approach Use cases are used to describe the externally visible requirements of a system They can be used later on in system design Developed by Booch, Jacobson and Rumbaugh of Rational Software (www.rational.com)

51. Use Case driven approach - The Process Inception Phase:  Project description agreement  Project risks  Context of the project  Scope of the project Elaboration Phase:  Detailed definition of all use cases  UML diagrams modeling scenarios  Use case diagram(s)

52. Inception Phase Project description agreement  Identify the problem and its root causes  Write a short textual description of the problem to be solved, and the key features of the system  Should not describe solutions  From a paragraph to a couple of pages for a complex project  Every stakeholder has to agree on the project description Project risks  Look at the system from many viewpoints Other systems, marketing, technology, users, managers  Identify things that can go wrong User resistance, inexperienced developers, system dependencies

53. Context of the Project Define what is inside the system, or system functionalities  Represented as use cases in the UML Define what is outside the system and interacts with the system  Represented as actors in the UML

54. Context of the Project Identify actors on the system  An actor is represented by its role, not its individuality  Actors are always external to the system Users Other software systems Hardware devices Data stores

55. Context of the Project Describe actors  Customer: a person who orders products through the system.  Shipping company: UPS, FedEx, DHL.  Shipping clerk: user of the system who packages, labels and ships orders.  Inventory system: software that tracks the company inventory. Customer Shipping Clerk SupplierShipping Company Inventory System

56. Context of the Project Identify use cases  What are the services used by the actors?  Who stores, accesses or deletes information in the database?  Startup, shutdown, diagnostics, installation  Maintenance Go through all the actors and identify how they can use the system

57. Context of the Project Order-processing use cases  Customer: place order, send catalog, get status on order, return product, cancel order, register complaint  Shipping clerk: print mailing labels, calculate postage  Inventory system: give product information, update product quantities Place Order Cancel Order Send Catalog Calculate Postage

58. Scope of the Project Estimate what could realistically be implemented considering factors such as:  Time frame available  Budgetary envelope  Physical resources available The system description, risk analysis and assumptions must be met End of the inception phase Next step: adding details and structure

59. Elaboration Phase Define Use Case:  Use case: A coherent unit of externally visible functionality provided by a system unit.  Used to define a behavior without revealing the internal details.  A use case describes what the system does, not how it does it. Scenario: flow of events describing how a use case is realized. Each use case has a primary scenario. Eventually also has a set of alternate scenarios. Pre-conditions and post-conditions are stated.

60. Define Use Cases (Flow of Events) Place Order Use Case Pre-conditions: A valid user has logged into the system Primary Flow of Events: 1. (start) The customer selects Place Order 2. The customer enters its address 3. The customer enters the product codes it wants to order 4. The system provides the items description and prices, and a running total 5. The customer enters its credit card number 6. The customer clicks on submit 7. The system validates the information, saves the order and forwards the transaction request to the accounting system 8. (end) When the payment is confirmed, the order is marked as paid Alternate Flow of Events 1: In step 7, the system prompts the user to correct any incorrect information Alternate Flow of Events 2: In step 8, if the transaction is refused by the bank, the order is marked as pending Post-conditions: The order has been saved in the database

61. Scenarios: Diagrams Complex scenarios are better expressed using diagrams. The UML provides two kinds of diagrams:  Activity diagrams for a high-level description.  Sequence diagrams for more in-depth analysis.

62. Order-Processing Use Case Diagram Customer Shipping Clerk Supplier Shipping Company Customer Representative Place Order Cancel Order Send Catalog Calculate Postage Get order status Return Product Deliver Product Send Us Product