INFO 627Lecture #21 Requirements Engineering and Management INFO 627 Analyzing the Problem Glenn Booker

INFO 627Lecture #22 Problems and Opportunities  We hinted that most systems are created for two reasons: 1. To solve problems; ways in which the current system doesn’t meet customer needs 2. To take advantage of opportunities; new product concepts, new features, new customer markets, etc.  We’ll focus on problem solving for now

INFO 627Lecture #23 Problem Analysis  Problem analysis is the process of understanding customer problems and user needs, and proposing solutions to fulfill those needs  A problem is the gap between how things are, and how the customer wants them to be Hence changing expectations can make some problems go away!

INFO 627Lecture #24 Problem Analysis Steps  Analyzing a problem can be done in five steps 1. Agree on the problem definition 2. Understand its root causes 3. Identify stakeholders and users 4. Define solution system boundary 5. Identify solution constraints

INFO 627Lecture #25 Agree on the Problem Definition  First need to gain agreement on the problem definition  Write down what the problem appears to be, and see if everyone agrees Or have each type of stakeholder describe the problem, then compare their views  Identify how fixing the problem will benefit the customer and users

INFO 627Lecture #26 Agree on the Problem Definition  May help to describe problem using a standardized format Search for “problem statement” Some “white papers” describe problems, especially those from vendors  Problem statement might include history, background, and motivation for solving the problem (example)(another)exampleanother

INFO 627Lecture #27 Agree on the Problem Definition  Basic problem statement outline is Describe problem Identify stakeholders affected by it Describe impact of problem on stakeholders and on business activities Describe proposed solution and key benefits  In short, why should we care about solving this problem?

INFO 627Lecture #28 Understand its Root Causes  Given the existence of a significant problem, now we need to solve it  One way is “root cause” or “causal” analysis – determine why the problem exists  Can use “fishbone” diagram Start with the problem, on a horizontal line Look for causes of the problem Then look for causes of the causes; repeat 1E p. 37

INFO 627Lecture #29 Understand its Root Causes  If you have trouble finding causes, see if there are any in common types: Data Communication Management Hardware Manufacturing Or whatever else may apply to your problem

INFO 627Lecture #210 Understand its Root Causes  In the context of software defect analysis, causes can be things like Variables Data Design Documentation Interfaces And so on…

INFO 627Lecture #211 Understand its Root Causes  Then analyze which of the causes are most significant (does that mean ‘frequent’ or severe’?)analyze  Graph with a histogram or Pareto diagram See second half of lecture 4, INFO630INFO630

INFO 627Lecture #212 Identify Stakeholders and Users  As discussed last week, we need to identify who will use the system, and who will be affected by its existence  Many stakeholders are also users, but not all

INFO 627Lecture #213 Define Solution System Boundary  At its simplest, every system takes in some form of inputs, and produces outputs  The key at this point is to identify who or what creates or accepts those inputs and outputs

INFO 627Lecture #214 Define Solution System Boundary  Most inputs and outputs are initiated by either an actor (user or stakeholder), or an external system  So we need to imagine (postulate, for now) what will and won’t be part of our system  Focus attention only on those things that will interact directly with our system Do you use the cash register at the grocery store

INFO 627Lecture #215 Define Solution System Boundary  Other systems might include: Legacy systems which remain in your organization (human resources database, accounting system, etc.) Vendors’ systems (only if your system interacts directly with them, such as downloading updates) Sensors for system environment (temperature, power supply, UPS, etc.)

INFO 627Lecture #216 Define Solution System Boundary Anything obtained automatically from the Internet (search results, stock quotes, etc.)  Include users of the system from remote locations (home, customer sites)  Remember that the system boundary only includes things over which you have control If you can’t specify its design eventually, then it’s outside your system

INFO 627Lecture #217 Define Solution System Boundary  Show system as a box with its name  Actors are stick figures  External systems are little boxes with their names  Arrows show direction of information flow 1E p. 43

INFO 627Lecture #218 Define Solution System Boundary  If new system includes other (e.g. legacy) systems, show system boundary with dotted line or oval  Please don’t include users inside the system boundary! (think about it)

INFO 627Lecture #219 Identify Solution Constraints  Constraints can be anything that limits how or when the system is provided Economic constraints, such as system development cost, or cost of the product Political, whether corporate, local, national, or international political issues or laws Technical, such as technology choices, platforms, new technology limits, etc.

INFO 627Lecture #220 Identify Solution Constraints System constraints, such as compatibility with existing systems or operating systems, installed size, or internationalization Environmental, such as legal, security, regulatory, emissions, or safety constraints

INFO 627Lecture #221 Identify Solution Constraints Schedule and resources; are there predefined limits on completion date, what resources are available for the project, can we get outsourced people (hire temps)?  Constraints can be added to the problem statement, with their rationale

INFO 627Lecture #222 Problem Analysis  Make sure customer agrees with problem analysis and its resulting statement  Now have a framework for defining the customer’s problem and needs, and started sketching the scope and constraints on the system we’ll create to meet those needs  This gives structure to begin defining requirements

INFO 627Lecture #223 Business Modeling  The system boundary outline gave us a start on understanding who and what will use our system  Now we want to expand on that and determine how they will use the system  What kind of activities will users and systems need to perform? That forms the heart of business modeling

INFO 627Lecture #224 When to do Business Modeling  Basic business modeling can help identify types of activities to be performed using the system  Detailed business modeling is good for very complex systems, especially with many types of users and/or many interfaces

INFO 627Lecture #225 Business Modeling  Business modeling helps answer higher level questions like: Where should the system be located? What kind of activities are performed in different locations and facilities? Do we need to reorganize our organization? What processes need to be automated?

INFO 627Lecture #226 Modeling Techniques  Many techniques can be used for business modeling Process modeling can help understand each activity in detail Process modeling SAP uses “scenarios” to model activities SAP Some aspects of UML directly support it  Here we focus on “use cases”

INFO 627Lecture #227 Use Cases  Use cases are simply names for activities which users need to perform using your system  Each use case is a set of activities with a clear start and finish, which performs some significant function using your system ‘Ship Order’, ‘Analyze Customer Trends’, ‘Process Returned Shipment’, ‘Create Invoice’

INFO 627Lecture #228 Use Cases  There are also trivial use cases, which are complete activities which aren’t very important by themselves ‘Validate User’, ‘Print Mailing Labels’, etc.  Think of a new employee who will need to use your system – what kind of activities would you need to teach them? Those might be use cases…

INFO 627Lecture #229 Use Cases  To decide between significant and trivial use cases: Ask whether the user would brag to their boss how many times they performed that activity If they might brag about it, it’s a significant use case; otherwise it’s probably trivial  Also consider how to write a user’s job description or user’s manual; each task described may be a use case

INFO 627Lecture #230 Use Cases  To draw a use case diagram: Each actor is a stick figure Each use case is labeled in an oval Each external system is labeled in a box Lines connect actors to use cases, and actors to external systems, to show lines of communication

INFO 627Lecture #231 Sample Use Case Diagram Generally show only significant use cases.

INFO 627Lecture #232 Documenting Use Cases  Many formats may be used to describe use cases; see for Alistair Cockburn’s* templatehttp://  The use case description captures key aspects of the business process – what happens, who does it, what is used or created as a result, when does it occur, etc. * The ‘ck’ in his name is silent, BTW – “CO-burn”

INFO 627Lecture #233 Systems Engineering of Software  The systems engineering approach works well for software-based systems too  How do you solve a big problem? Break it into little problems!  Main emphasis is on breaking the system down into subsystems, and determining what each subsystem needs to do

INFO 627Lecture #234 Systems Engineering  For example, a car has subsystems like: Powertrain  Engine, Transmission  Axle, Differential Suspension  Wheels  Tires  Shocks or Struts  Springs

INFO 627Lecture #235 Systems Engineering  Often applied for embedded (built-in) software systems  See INCOSE for more info on this approachINCOSE Or WWISA for software architectureWWISA  Parts of a software system might be called configuration items, components, packages, modules, or units

INFO 627Lecture #236 Systems Engineering  Several layers of subsystems can be designed to organize specific functions User Interface  Shipping and Receiving Module Shipment Verification Screen  Each subsystem can then have specific functions to perform using a specific set of inputs

INFO 627Lecture #237 Systems Engineering  One person or small team can then design that subsystem in detail  This approach can help allocate (assign) requirements to different parts of the system  This leads to detailed requirements for each subsystem or interface between subsystems These detailed requirements are derived, as in derived from overall requirements

INFO 627Lecture #238 Systems Engineering  For examples, derived requirements can be used to guide selection of commercial components for your system Servers Database vendor Networking hardware And so on…

INFO 627Lecture #239 Systems Engineering  Many industries have recently started incorporating software into things which didn’t have any 20 years ago Hence they have to care about allocated software requirements Software is now the dominant cost in many systems, and controls whether it will succeed

INFO 627Lecture #240 Systems Engineering  Another influence of the systems engineering approach has been greater emphasis on the entire life cycle cost for a system – including maintenance and disposal costs Many had focused only on development costs Cost of upgrades and product evolution are harder to predict for software

INFO 627Lecture #241 Systems Engineering  How can this help us define requirements? Consider how use cases might interact with subsystems Hide information that isn’t needed to perform the task Isolate interfaces to external systems Plan for more features and capabilities than needed this minute