Project Scope VS System Boundary
Business Analysis
I/O of Business Analysis
Activities in Business Analysis
● Requirements Discovery
● Business Modeling
Requirements Discovery
Requirements
● System Requirement (a.k.a. Business Requirement) - something that the IS must do or a property that it must have.
● Functional Requirement - something that IS must do.
● Nonfunctional Requirement - a property or quality that system must have.
Examples include security, ease-of-use, performance, etc.
System Requirements Criteria
● Consistent - the reqs are not conflicting or ambiguous
● Complete - the reqs describe all possible system inputs and responses
● Feasible - the reqs can be satisfied based on the available resources and constraints
● Required - the reqs are truly needed and fulfill the purpose of the system
● Accurate - the reqs are stated correctly
● Traceable可追蹤 - the reqs directly map to the functions and features of the system
● Verifiable - the reqs are defined so that they can be demonstrated during testing
Fact Finding Techniques 實況調查技術
● Sampling of existing documentation, forms and databases
● Research and site visits
○ Market Research
○ Competitor Research
● Observation of the work environment
● Questionnaires
● Interviews
● Discovery prototyping
● Joint requirements planning (JRP)
Describe Requirements
Product Requirement Document
Key Points
○ Business problem to solve
○ Stakeholders
○ Objectives
○ Non-Objectives
○ Requirements / User Scenarios
○ Assumptions
Examples
○ [WIP] PRD- Device Graph
○ Live DAI - Master PRD
○ Hulu Ad Exchange_ Reporting Spec
User Story
User Stories
● User stories articulate清楚說出 the experience of what the user will be able to do once this feature exists.
● User stories are a place to start a conversation, they are not standalone 獨立documentation.
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
Put another way, a user story is an outcome, who it’s for, and why they care about it.
User Stories typically follow a simple template:
● As a < type of user >, I can < some goal > so that < a thing the user cares about is true >.
● User Clause - As a ; this is who the outcome is for
● Outcome Clause - I can ; a concise statement of that outcome
● Value Clause - so that <a thing the user cares about is true; why the user cares about it
Acceptance Criteria
Be outcome oriented以結果爲導向, think about the final experience and value for the user that this story will deliver.
● Example: Monsters University course registration platform rejects the course retaking requests because of the randomize selection strategy.
○ As a student who needs to retake a course
○ I want my retaking requests to be always approved by the course registration platform
○ So that my graduation will not be blocked by missing retaking courses
Student Information System
During the Business Analysis, You will
● Request some documents like
○ Rules of course application and seats assignment
○ Rules of grading of different types of courses
○ Classrooms information
○ Course information
○ ……
● Site visits
● Questionnaires
○ User process
○ Experience
○ Suggestions
○ …
● Interview
○ Investigate 調查 the organization chart, select your interviewee and schedule the time
○ Prepare your interview
■ Agenda 議事日程
■ Question list
■ Keep impartial 不偏不倚
○ Interview
■ Communication skills
○ Post-interview
■ Share the summary
● Organize joint requirements planning (JRP)
○ Attendees
■ Owner, host, users, recorder, tech
○ Plan a JRP
■ Location
■ Attendees
■ Agenda
○ Pros
■ Involve users (managers) to the project proactively
■ A joint meeting instead of scattered interviews
■ Prototype discussion in the meeting
Context Diagram
Business Analysis Output
● User stories
○ As a student / lecture, …
● Data / Entity spec
○ Key properties of Course, Classroom…
● Detail Requirements
○ Logic of core function
■ Process of course registration
○ Reporting example
■ Grading report example of a course
Feasibility Analysis / Study 可行性研究
Feasibility Analysis / Study
● Feasibility - the measure of how beneficial or practical an IS will be to an organization
● Feasibility Analysis - the process by which feasibility is measured
● The goal is to determine whether the project should go ahead, be redesigned, or else abandoned altogether完全放棄.
A Creeping Commitment Approach
● When to run feasibility analysis?
○ Feasibility should be measured throughout the life cycle
○ Checkpoints
■ By the end of scope definition
■ By the end of problem analysis
■ By the end of decision analysis
● Why to run many times of feasibility analysis?
Feasibility Analysis Includes
● Operational Feasibility
● Cultural (Political 政治) Feasibility
● Technical Feasibility
● Schedule Feasibility
● Economic Feasibility
● Legal Feasibility
Operational Feasibility
● How well proposed system solves the problems and takes advantage of opportunities identified during the scope definition and problem analysis phases
● How well proposed system satisfies system requirements identified in the requirements analysis phase
● Is the problem still worth solving?
Cultural (Political) Feasibility
● Does management support the system?
● How do end users feel about their role in the system?
● What end users may resist or not use the system? How can this be overcome?
● How will the working environment change? Can users and management adapt to the change?
Technical Feasibility
● Is the proposed technology or solution practical?
● Do we currently possess the necessary technology?
● Do we possess the necessary technical expertise?
Schedule Feasibility
● Are specified deadlines mandatory or desirable? 規定的期限是強制性的或可取的
● Are mandatory deadlines realistic for proposed solution?
Economic Feasibility
● During Scope Definition
○ Do the problems or opportunities warrant the cost of a detailed study and analysis of the current system? 問題或機會是否值得對當前系統進行詳細研究和分析？
● During Problem Analysis
○ After a detailed study of the current system
○ Better estimates of development costs and benefits 更好地估計發展成本和效益
● During Decision Analysis
○ Requirements now defined 現已確定的需求
○ Development costs can be better estimated
Legal Feasibility
● Copyrights
● Union contracts 工會合同
● Legal requirements for financial reporting 財務報告的法律要求
● Antitrust laws 反托拉斯法即反壟斷法
● National data and work laws 國家數據和工作法
Economic Feasibility
Cost
● Development costs
○ Personnel 全體員工
○ Computer usage
○ Training
○ Supply, duplication and equipment
○ Computer equipment and software
● Operating costs
○ Fixed costs
○ Variable costs 可變成本
Benefits
Tangible benefits 顯著收益
○ Fewer processing errors
○ Increased throughput 提高生產力
○ Decreased response time
○ Elimination of job steps 減少工作步驟
○ Increased sales
○ Reduced credit losses 減少信貸損失
○ Reduces expenses
Intangible benefits
Cost-effectiveness Techniques 成本-效益技術
Payback Analysis 投資回報分析
○ A technique for determine if and when an investment will pay for itself 一種確定一項投資是否和何時會自行支付的技術
○ Payback period: the period of time that will lapse before accrued benefits overtake accrued and continuing costs 償還期：應計利潤超過應計和持續費用之前的一段時間
Return On Investment (ROI)投資收益率
○ A technique that compares the lifetime profitability of alternative solutions 一種比較替代方案的終生盈利能力的技術
Net Present Value 淨現值
○ Analysis techniques that compares annual discounted costs and benefits of alternative solutions 比較替代解決方案年度折扣成本和效益的分析技術
Time Value of Money 貨幣時間價值
● Used with all three cost-effectiveness techniques
Payback Analysis
ROI
● Lifetime ROI
= (Net Present Value) / Lifetime Costs * 100%
= (Lifetime Benefits - Lifetime Costs) / Lifetime Costs * 100%
● Annual ROI
= (Lifetime ROI) / Lifetime
● Minimum Acceptable ROI
Candidate Solutions
Candidate Systems Matrix
Feasibility Analysis Matrix
Readings
System Analysis and Design Methods 7th- Whitten & Bentley
○ Chapter 5 The requirements analysis phase
○ Chapter 6
○ Chapter 11
Extracurricular readings
○ https://www.freecodecamp.org/news/how-and-why-to-write-great-user-stories-f5a110668246/
○ https://www.mountaingoatsoftware.com/agile/user-stories