Requirements Inception & Elicitation

• Week 3's agenda includes requirements inception and requirement elicitation
• The RE Lifecycle stages are elicitation, clarification, analysis, evaluation, re-evaluation, specification and documentation

Requirements Inception

• Establishes a common product vision and project scope
• It includes analysis of use cases, critical non-functional requirements, business cases, and development environment preparation
• Most projects start with a brief exploration period, addressing the vision, feasibility, build-vs-buy decisions, rough cost estimates, and stakeholder alignment
• It involves some requirements exploration to define the vision
• It does not aim to finalize all requirements or create comprehensive estimates or project plans
• This phase should be relatively short
• The goal is to determine if serious investigation during the elaboration phase is worthwhile

Activities and Artifacts in the Inception Phase

• Activities and artifacts include a short requirements workshop, naming actors, goals, and use cases
• Most use cases are in brief format
• A percentage of 10-20% of use cases have fully detailed descriptions to clarify scope and complexity
• Key quality and risk requirements have identification
• Creates initial vision and supplementary specification document
• Develops a risk list, technical proof-of-concept prototypes, user interface prototypes for functional vision, and component recommendations

How Long is Inception

• Inception is usually short: one or a few weeks
• It's intended to assess project investigation rather than conduct the investigation itself
• It may encompass the first workshop and iteration planning before moving to elaboration

Sample Inception Artifacts

• The vision and business case describe goals, limitations, business rationale, with an executive summary
• The use-case model outlines functional needs, names most use cases, analyzes detail
• Supplementary specification covers non-functional needs, key design elements
• Describes risks, their response
• The glossary defines terminology
• Prototypes and proof of concepts clarify the vision and validate ideas
• The iteration plan outlines tasks for initial iterations
• Rough estimate made for phase costs
• The development case customizes project process

Preliminary Investigation

• Investigates business opportunity or problem
• It involves understanding the opportunity, setting scope, fact-finding, SWOT analysis, and a feasibility study

Fact Finding Techniques

• Strategies for fact-finding include system observations, questionnaires, online research, industry research etc.

Questionnaire

• A pre-designed form asks questions
• It is useful when many people are interviewees or in distance
• It can be distributed without an interview
• Has multiple designs for different audiences
• Wording on the form is important as there chance for clarification
• Advantage is low cost, but it must suite the target audience

Different Types of Questions

• Close-ended questions require brief answers
• Open-ended questions necessitate detailed responses
• Compound questions include multiple inquiries in one
• Leading questions influence the interviewee's response
• Probing questions seek examples

Interviews

• An interview allows asking questions to elicit input
• Suited to open-ended questions
• Happens on a one-to-one or group basis
• A benefit includes direct, face-to-face interaction
• Interview guide can either follow a pyramid, funnel, or diamond form

Different Types of Interviews

• Structured interviews ask the exact same questions to each participant
• Unstructured interviews are like conversations without questions
• Semi-structured interviews use a guide, but are conversational

Prepare for Interview

• Review context beforehand
• Schedule and inform interviewees
• Identify interviewees and questions to ask
• Know different interviewee perspectives
• Watch bias issues
• Keep interview short
• Also discuss exceptions to normal operations

Interview Procedure

• Open the interview
• Conduct the interview
• Document the interview
• Close the interview

Feasibility

• Analysts must assess viability
• Evaluates prospects, based on research
• Organizations adapt feasibility review
• Reviews operations, technical aspects, economic impact, organizational factors, and scheduling

Operational Feasibility

• Assesses alignment
• Asks if the problem is workable
• Asks if the system is useable
• Asks if the system is effective
• Asks if the system places demands on users

Technical Feasibility

• Is focused on gaining understanding of present technical resources
• Includes an evaluation of the hardware and software to see how it fits the proposed system
• It answers build idea

Economic Feasibility

• The goal is to measure economic benefits to the organization from the proposed solution
• It includes analysis of the costs and benefits of the new system
• It answers "Should we build it"

The basic formula to convert a future cash flow to its present value is:

• PV = (Cash flow amount) / (1 + rate of return)^n

Benefit-Cost Analysis (BCR)

• Determines which solution provides the most financial value
• It is calculated with by Discounted value of incremental benefits ÷ Discounted value of Incremental costs

Net Present Value

The Formula for NPV

• NPV = (Cash flow/ (1 + i)t) - initial investment
• i = Required return or discount rate
• t = Number of time periods

Return on Investment (ROI).

• Measure a calculation that measures the return earned on the money invested in the project.
• ROI = (Total Benefits - Total Costs) / Total Costs

Organizational Feasibility

• How stakeholders embrace the new system
• Answers "If we build it, will they come?”

Schedule Feasibility:

• Is a timetable assessment
• The project will fail to complete if too long
• Deadlines from users or developers

SWOT Definition and Analysis

• Stands for Strengths, Weaknesses, Opportunities & Threats
• Evaluates viable projects by assessing internal and external elements
• Strengths are internal, weaknesses are internal
• Opportunities are external
• Threats are external

Requirements Elicitation

• Understand application domain
• Identify the source of needs
• Know stakeholders
• Choose the techniques, tools
• Elicit needs

Requirments Elicitation Objectives

• Understand the processes, people, and resources
• Determine coverage and boundary if too wrong
• Separates needs by priority

Requirement's Elicitation Dimensions

• 1. Understanding the business
• 2. Understanding the application domain
• 3. Understanding the specific problem.
• 4. Understanding the needs and constraints of system stakeholders.
• 5. Understanding acquisition and project management.
• 6. Understanding requirements engineering and systems engineering
• 7. Understanding the technologies and engineering involved.

Source of requirements.

• Discussions with all classes of stakeholders to based on their perspectives
• Analysis of any competing systems
• manuals for system interactions
• The marketing and customer care departments should not be overlooked

Rationale for Stakeholder Analysis

• What are the resources
• Know stakeholders affected
• Know needs of those who work with project
• Know needs of users

Steps in Stakeholder Analysis

• Who is primary, secondary, and has interest in the issue (stakeholder rings)
• 4 RS (Rights, Responsibilities, Returns, and Relationship)
• Stakeholder power and interests, Venn-Diagram
• Graph of stakeholders importance and influence

Identifying Stakeholders

• Users
• Clients
• Technical staff

Rings of Stakeholders

• Primary stakeholders invest capital
• Secondary stakeholders can influence
• Stakeholder Register: includes roles, contact info, and interest in project
• People that is internal to organization
• People that is external to organization

Prioritize Your Stakeholder's Engagement Levels

• Unaware: Unaware of the project
• Resistant: Aware of the project yet unwilling to change
• Neutral: Aware of the project yet supportive nor resistant
• Supportive: Aware of the project and supportive of change
• Leading: Aware of the project

Different Techniques for Requirement Elicitation

• Observation on users
• Interview to prepare
• Ask skills and exceptions
• Scenarios to document
• Use cases to analyze
• Brainstorm to trigger reaction

Elicitations Problems

• Time, preparation
• User issues
• Political issues
• Conflicting stakeholder