Embed Size (px)
Citation preview
Analyzing the Problem : Concepts and Techniques
3
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.
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.
Team Skill #1. Analyzing The Problem
The Five Steps in Problem Analysis.
Business Modeling.
Systems Engineering of Software Intensive Systems.
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.
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
Step 1: Gain Agreement on the Problem Definition.
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 simply write the problem down and see whether everyone agreesproblem down and see whether everyone agrees.
It is helpful to write down in a standardized format which we call “The Problem Statement”.
The Problem Statement
Element Description
The problem of
affects
The result of which
Benefits of
The Problem Statement
Element Description
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
The Problem Statement - advantages
What are the advantages of the Problem Statement?
When you write down the “The Problem Statement”, you will be able to classify the requirements into need-to-haveneed-to-have requirements and nice-to-havenice-to-have requirements.
The primary goal of the new system is to provide electronic electronic funds transfer that would improve the cash flow of thefunds transfer that would improve the cash flow of the companycompany.
After a raucous discussion, it became clear in the application of electronic funds transfer:
need-to-have: security
nice-to-have : emails, voice transmission
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.
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.
The Problem Behind the Problem – fishbone diagram
Improper sales orders
Finished-goods obsolescence
Manufacturin
g defects
Damaged in shipment
Customer
return
s
other
Scrap
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:
Element Description
The problem of Improper and inaccurate sales order.
affects Sales order personnel, customers, manufacturing, shipping, and customer service.
The result of which Is increased in 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
Online sales transaction
Improved reporting of sales data to management
higher profitability
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.
Step 3: Identify the Stakeholders and the Users
A stakeholderstakeholder 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?
Users and stakeholders of our new sales order entry system
Users stakeholdersSales order entry clerks MIS director and development
team
Sales order supervisor Chief financial officer
Production control Production manager
Billing clerk
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.
Step 4: Define the Solution System Boundary
We divide the world into two classes:
• Our system
• Things that interact with our system
I/O I/O
Our system
System boundary
users Other systems
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?
An actoractor is someone or something, outside the system, that interacts with the system.
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
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.
Step 5: Identify the Constraints to Be Imposed on the Solution
A constraintconstraint is a restriction on the degree of freedom we have in providing a solution.
What are the potential system constraints?
Source Sample 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?
Source Sample 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?
Our new sales order entry system
Source Constraints Rationale
System An 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.
System The applications footprint on the server must be less than 20 MBs.
We have limited server memory available.
Technical The system must be developed on existing server and host; new client hardware for users may be provided.
Cost control and maintenance of existing systems.
Economical Fixed staffing resource; no outsourcing.
Fixed operating costs as per the current budget.
Technical New OO methodology to be used. We believe that this technology will increase productivity and increase reliability of the software.
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
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.
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?
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.
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.
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
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.
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
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
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.
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
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
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.
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.
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.
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
BA-1 A-2
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.1. Subsystem requirementsSubsystem requirements are those that must be imposed on the subsystems themselves but do not necessarily provide a direct benefit to the end user.
2.2. InterfaceInterface requirementsrequirements 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 A Subsystem B
A to B interface
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
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.
1.Analyzing the problem1.Analyzing the problem
3.Managing the system
3.Managing the system
2.Understanding user needs
2.Understanding user needs
4.Defining the System
Defining.4the System
6.Building the right system
6.Building the right system
5.Refining the system definition
5.Refining the system definition
Business ModelingBusiness Modeling System
Engineering of soft. Intensive sys
System Engineering of
soft. Intensive sys
Five steps in problem
statement
Five steps in problem
statement
1.Gaine Agreement
on the Problem
Definition
1.Gaine Agreement
on the Problem
Definition
5.Identifiy the constraints to be Imposed on solution
Identifiy the.5 constraints to be Imposedon solution
4.Define the solution System
boundary
4.Define the solution System
boundary
3.Identify the
Stakeholders and the
users
3.Identify the
Stakeholders and the
users
2.Understand the Root
CausesProblem Behind
Problem
2.Understand the Root
CausesProblem Behind
Problem
Effective Requirements Management
Effective RequirementsManagement
Summery
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
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
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
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
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)
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)
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
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
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
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 ShippingClerk
Supplier Shipping Company
InventorySystem
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
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
PlaceOrder
Cancel Order
SendCatalog
CalculatePostage
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
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.
Define Use Cases (Flow of Events)
Place Order Use Case
Pre-conditions: A valid user has logged into the systemPrimary 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 paidAlternate Flow of Events 1: In step 7, the system prompts the user to correct any incorrect informationAlternate Flow of Events 2: In step 8, if the transaction is refused by the bank, the order is marked as pendingPost-conditions: The order has been saved in the database
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.
Order-Processing Use Case Diagram
Customer
ShippingClerk
Supplier
Shipping Company
CustomerRepresentative
PlaceOrder
Cancel Order
SendCatalog
CalculatePostage
Get orderstatus
Return Product
DeliverProduct
Send UsProduct
