Analysis Phase: Requirements and Techniques
Analysis Phase Overview
Purpose: identify what the new system should do by determining detailed requirements from users and managers.
Inputs from planning: system request, feasibility analysis, project plan.
Core idea: break the system into parts to understand functions and interrelationships; translate high-level business requirements into detailed requirements.
Deliverables of the Analysis Phase
End product: System Proposal, comprising:
Requirements Definition Statement (RDS)
Use cases (to be covered next week)
Process and data models (in upcoming weeks)
Updated versions of planning phase deliverables (request feasibility analysis and project plan)
RDS is a concise list of functional and non-functional requirements, used to guide design and prevent scope creep.
What is a Requirement
Definition: something the system must do or have (functionalities and features).
Categories: business, user, functional, non-functional, and system requirements.
Requirement Categories (brief)
Business requirements: describe what the business needs; stated in the system request (high level).
Example: improve pay, patient safety, and quality of care.
User requirements: describe what users need to do; linked to use cases.
Functional requirements: what the software should do to fulfill user requirements; can be a process or information provided.
Examples: navigate to patient, input order, execute order; dynamic report; verify administration.
Non-functional requirements: system behaviors/qualities (performance, usability, etc.).
Examples: portability; web-based; performance and reliability.
System requirements: used in the design phase; primarily for developers.
Non-functional Requirement Aspects
Operational: operating environment (e.g., compatibility with iOS/Android).
Performance: speed and reliability (e.g., handle at least simultaneous connections).
Security: access controls and safeguards.
Cultural and political: compliance and regulatory concerns (e.g., HIPAA).
Requirements Definition Statement (RDS)
Purpose: a baseline document that captures functional and non-functional requirements.
Content: bullet-point list of requirements, grouped by tasks or similarity; order may imply priority.
Role: aligns customer and project team; helps manage expectations and prevent scope creep.
Requirements Discovery Techniques (the five classic methods)
Interviews
Purpose: face-to-face data collection from individuals or groups.
Preparation: informal interview schedule evolving to formal; include managers, users, and other stakeholders.
Question types: open-ended (for depth) and closed-ended (for quantification); use probing questions as needed.
Structure options: unstructured (broad, open-ended) vs structured (specific questions); top-down vs bottom-up approaches.
Planning and conduct: have a plan, set time, remain professional and unbiased, take thorough notes, summarize and verify, watch for body language.
Post-interview: prepare a report, share for feedback, and clarify as needed.
Joint Application Development (JAD)
Group sessions with up to users; sessions should not exceed people in one room.
Facilitator: skilled in JAD; neutral and guides the process.
Logistics: off-site preferred; can use electronic tools; ground rules and a defined agenda.
Deliverable goal: contribute to the first analysis deliverable and reduce scope creep through group consensus.
Advantages: captures diverse views quickly; reduces scope creep; visibility of requirements.
Questionnaires
Purpose: gather information from a larger group; efficient for many respondents.
Question types: fixed-format (e.g., multiple choice) and free-format (open-ended).
Pros/cons: fast distribution and easy tabulation for fixed-format; lower response rates and less depth for open-ended.
Analyzing existing documents
Purpose: understand current system through its documentation (often used in healthcare for transitioning from paper to electronic records).
Caution: documents describe intended work, not always actual practice; supplement with other techniques.
Observation
Purpose: watch actual processes to validate gathered information.
Strength: reveals real work practices and checks accuracy of other sources.
Limitation: people may alter behavior when observed; best done discreetly.
Technique Comparison (depth, range, integration, effort, cost)
Depth: Interviews/JAD generally yield richer detail; observation/document analysis tend to be shallower.
Range: JAD offers broad input in one setting; documents provide wide scope when available.
Integration: JAD excels at converging information in one session; other techniques may require synthesis.
Effort and cost: Interviews and JAD are higher effort/cost; questionnaires, documents, and observation are lower.
Overall: successful requirements gathering uses a blend of techniques tailored to the project.
Requirements Analysis Strategies (by scope)
Small improvements (incremental):
Problem analysis: identify existing limitations and opportunities for quick wins.
Root cause analysis: dig into underlying causes of problems.
Outcome: typically small to medium incremental improvements.
Moderate improvements:
Duration analysis (time study): measure time for each step; compare to total process time to identify bottlenecks.
Activity-based costing: focus on costly steps to reduce expenses.
Benchmarking: study how other organizations perform similar processes; common in healthcare quality and outcomes comparisons.
Redesign / major improvements (complete process redesign):
Outcome analysis: understand fundamental outcomes that deliver value to customers.
Technology analysis: evaluate new technologies and their application to the business, including big data analytics.
Activity elimination: identify and remove non-value-adding activities; brainstorm to ensure the process still meets goals.
Strategy selection: no single strategy is inherently best; choose based on the project context and what needs to be achieved.
Quick recall
Five common requirement discovery techniques: techniques (Interviews, JAD, Questionnaires, Document Analysis, Observation).
JAD session size limits: up to users in a session; no more than people in the same room.
Key deliverable after requirements gathering: Requirements Definition Statement (RDS) to guide subsequent use cases and models.
Main non-functional categories: Operational, Performance, Security, Cultural/Political.
Primary goal of analysis phase: translate high-level business requirements into a concrete, actionable list of what the system must do and how well it must perform.