Requirements Elicitation

REQENG

Subtopics Background Material Requirements Elicitation Process Requirements Sources Elicitation Techniques

Requirement Types (1 of 4) System requirement

• Condition or capability that must be met or possessed by a system (IEEE STD 729)

• Externally visible function or attribute of a system (IEEE STD 830)

• Defines service the system must provide and associated constraints

Software requirement• Condition or capability that must be met or possessed by a

software component

Requirement Types (2 of 4) Functional requirement

• Condition or capability needed by end user to solve a problem or achieve an objective (IEEE STD 729)

• User requirement

• Behavioral requirement

Requirement Types (3 of 4) Non-functional requirement

• Requirement not specifically concerned with functionality• System quality or attribute

• Reliability• Availability• Maintainability• Portability• Usability• Security• Capacity• Performance• Safety

• Design constraint• Restriction on system/software to be built• Restriction on developmental process

Requirement Types (4 of 4) Information requirement

• Entities, attributes, and relationships that must be stored and processed by the system/software

• Data requirement

External interface requirement• Information that must be exchanged with an external system or

component

• Information exchange requirement

Systems Engineering Process Model

System Requirements Engineering

Architectural Design

Requirements Allocation

Software Requirements Engineering

Sub-system Development

System Integration

System Validation

Needs statement

Validated System

System Requirements Specification

Software Requirements Specification

Deriving Software Requirements from System Requirements

System Requirements Specification• Identifies requirements of total system

• Requirements are partitioned/allocated during architecture phase• Hardware requirements

• Software requirements

• May necessitate Hardware/Software tradeoff analysis

Software Requirements Specification• Identifies software specific requirements

• Mostly derived from system documents (requirements and architecture)

• Typically less interaction with user• Except for user interface definition

• Software requirements trace to system requirements

Requirements Engineering Activity Model

Requirements Elicitation

Requirements Analysis

Requirements Specification

Requirements Validation

Validated Requirements Specification

Existing System Information

Stakeholder Needs

Organizational Standards

Technical Standards

Regulations

Domain Information

Goals

Requirements Management

Subtopics Background Material Requirements Elicitation Process Requirements Sources Elicitation Techniques

Requirements Elicitation Knowledge transfer from users to developers First stage in building an understanding of the

problem that the software is required to solve Fundamentally a human activity Not a passive activity Also referred to as requirements capture,

requirements discovery, or requirements acquisition

Requirements Elicitation Concerns

Identifying stakeholders• Source of requirements

Identifying stakeholder needs (requirements) Identifying constraints Understanding problem context

• Application domain (e.g., education)

• Specific problem to be solved

• Business context

Components of Requirements Elicitation

Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998

Knowledge of general area

where system is applied

Understanding of specific

customer problem

to be solved

Understanding of how

systems interact and contribute

to overall business goals

Detailed understanding of

specific stakeholder needs

and constraints

Requirements Elicitation Process

Businessgoals

Systemconstraints

Problem to besolved

Establish objectives Understand background

Organisationalstructure

Applicationdomain

Existingsystems

Stakeholderidentification

Goalprioritisation

Domainknowledge

filtering

Organise knowledge

Stakeholderrequirements

Collect requirements

Domainrequirements

Organisationalrequirements

Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998

Requirements Elicitation Stages Establish objectives

• Establish organizational objectives and business goals • Describe problem to be solved and why system is necessary• Describe constraints on system (budget, schedule, interoperability)

Understand background • Obtain organizational information • Obtain application domain knowledge • Obtain existing system information

Organize knowledge• Organize and collate knowledge• Identify stakeholders

Collect requirements• Identify requirements

Elicitation Problems (1 of 2) Inadequate time allotted Inadequate preparation Inadequate user representation Different vocabularies

• Developers and users speak different language

Political factors Ambiguity of natural language Requirements change during the process

Elicitation Problems (2 of 2) Inability of stakeholder to articulate requirements Lack of cooperation

• Lack of stakeholder commitment or buy-in

Conflicting stakeholder requirements Requirements creep Unrealistic requirements

Subtopics Background Material Requirements Elicitation Process Requirements Sources Elicitation Techniques

Requirements Sources Goals

• Overall high-level objectives of system• Motivation for the system• Needs to be assessed for feasibility

Domain knowledge• Knowledge about the application domain

• Current system documentation• Similar problems and systems

Journals, product literature Requirements reuse

Operational environment• Constraints imposed by operational environment

• Timing• Interoperability

Requirements Sources Organizational environment

• Structure, culture, and internal politics

System stakeholders• Customers

• End users

• Domain experts

• System maintainers

• Regulatory authorities

• System developers

Subtopics Background Material Requirements Elicitation Process Requirements Sources Elicitation Techniques

Elicitation Techniques Techniques for getting human stakeholders to

articulate their requirements Elicitation Challenges

• Users may have difficulty describing their tasks

• Users may leave unimportant information unstated

• Users may be unwilling to cooperate

Elicitation Techniques Interviews Questionnaires Scenarios Use cases

• Also a requirements analysis method Prototypes

• Also a requirements validation method Facilitated workshops (e.g., JAD session) Observation

• Job protocol analysis• Social analysis

Interviews (1 of 2) Requirements engineer discusses system with different

stakeholders and builds up understanding of requirements• Closed interviews

• Predefined set of questions

• Open interviews• No predefined agenda• Open ended questions

Keys to successful interviews• Interviewers must be open-minded with no pre-conceived notions

about what is required• Stakeholders must be given starting point for discussion• Interviewers must be aware of organizational politics

• Many real requirements may not be discussed because of their political implications

Interviews (2 of 2) Advantages

• Good for developing understanding of problem

• Good for eliciting very general system requirements

Limitations• Less effective for eliciting application domain knowledge

• Domain terminology

• Some domain knowledge is difficult to explain

• Some domain knowledge is so familiar to users that it is overlooked

• Less effective for understanding organizational issues• Political and social factors

Interview Process Model (1 of 2) Prepare for interview

• Develop understanding of project scope and objectives• Become familiar with organizational structure

Plan and schedule interview• Prepare list of topics and questions• Determine who to interview• Request and schedule interview

Open interview• Introductions• State purpose of interview• Set tone for rest of interview

Interview Process Model (2 of 2) Conduct interview

• Ask open ended questions (to get interviewee to open up)• Use domain words and phrases

Close interview• Summarize topics covered and important results

• Impacts success of any follow up

Follow up with user(s) • Clarify information not completely understood

• Helps to resolve conflicting information

• Ask closed questions• Schedule follow up interviews/meetings

Questionnaires Set of questions sent to user(s) Often sent to users prior to conducting interviews Contact users in remote locations Used to gather input from large number of users

Scenarios (1 of 2) Description of how a system might be used Includes following information:

• Initial system state

• Normal flow of events

• Exceptions to normal flow

• Information about concurrent activities

• Final system state

Concerned with a single type of interaction between a user and the system

Scenarios (2 of 2) Advantages

• Easier for people to relate to than abstract statements• Helps with requirements understanding• Exposes possible system interactions • Reveals system facilities which may be required• Provides context to elicitation of requirements• Useful for adding details to requirements descriptions• Provides a framework for asking questions

• What if?• How is this done?

Limitations• Large number of scenarios is usually required• Time consuming

Example Scenario -- ATM

Source: Ian Sommerville, Software Engineering, 6th edition, 2000

Validate user

Request PIN

Selectservice

Timeout

Return card

Invalid card

Return card

Stolen card

Retain card

Incorrect PIN

Re-enter PIN

Incorrect PIN

Return card

Card

PIN

Card present

Accountnumber

PIN

Accountnumber

Valid card

User OK

Use cases Scenario showing sequence of actions between one or

more actors and system Captures functional requirements of a system Actor (user of the system) initiates a use case Communication associations connect actors with use

cases Defines system behavior without revealing internal

structure UML notation for use case diagram

• See Gomaa Figure 2.1 Covered in detail later in semester

Prototypes (1 of 2) Partial physical representation of a proposed

system used to elicit user requirements• Used to clarify unclear requirements

• Typically used to elicit user interface requirements• Screens and reports

• Provides context

• Bridges communication gap between developer and user• With no physical representation of system, there will be at least

two mental models of the proposed product (developers and users) Mental models may not map, resulting in

miscommunication

Prototypes (2 of 2) Advantages

• Provides quick feedback• Easy for customers and users to understand and react to • Displays unanticipated aspects of systems behavior• Produces answers to questions and generates new questions• May shorten development time and cost• Increases user satisfaction• Improves productivity• Allows users to experiment with initial system • Establishes feasibility and usefulness before development

Limitations• May unexpectedly evolve into final system May be difficult to manage user

expectations• Prototypes are imperfect (incomplete functionality)• Need to explain what a prototype is and is not

Prototyping Techniques (1 of 2) Throwaway prototypes

• Intended to help elicit and develop system requirements • Prototype requirements which cause most difficulties to customers and

which are hardest to understand• No need to prototype well understood requirements

• Static prototypes• Visual representation or paper mock-up of user interface• Static screens in graphics tool (e.g., PowerPoint)• Quick and inexpensive, but lacks interactivity

• Dynamic prototypes• Executable screens in CASE tool (e.g., Power Builder)• Supports navigation between screens, but has limited functionality

• Discarded when user evaluation is complete

Prototyping Techniques (2 of 2) Evolutionary prototypes

• Intended to deliver a workable system quickly to the customer • Well understood requirements that can provide useful functionality are

prototyped first

• Prototype evolves into production system

• Must have quality built in

• Process Model• Develop

• Demonstrate

• Gather user feedback

• Modify

• Redemonstrate

• Etc.

Facilitated Workshops Meeting of group of stakeholders facilitated by

requirements engineer Objectives

• Improve understanding of requirements

• Promote user and customer participation

• Give users feeling of ownership of system

• Surface and resolve conflicting requirements

Advantages• Group can bring more insight to requirements than individuals

• Can result in richer and fuller set of requirements

• Can accelerate requirements elicitation process

Keys to Successful Facilitated Workshop

Commitment from upper management Competent users with authority to make decisions Competent and impartial facilitator One or more scribes to document Limited to maximum of 8-12 users Preparation

• Understand context of problem

• Define process and ground rules

• Specify deliverables

• Obtain hardware and software support

Observation Requirements engineer observes user performing tasks

• Shows context within organizational environment• Shows how users interact with their systems and each other

Advantages• Good for manual or clerical tasks• Useful for tasks that are too subtle and complex to describe easily• Actual work processes often differ from documented processes• People do not have to explain or articulate their work• Social and organizational factors of importance may be observed

Limitations• Difficult for cognitive tasks• Observed (existing) practices may no longer be relevant

Requirements Elicitation Process Support

Standards• Only very general guidance is available that sets goals, but has little to

say on techniques Measurement

• Very little work on relevant metrics Tools

• Elicitation is poorly supported• Scenario and use case modeling tools available

• Rational Rose

• Prototyping tools available• Power Builder

• Limited support for viewpoint analysis

Key Points (1 of 2) Requirements elicitation involves:

• Understanding application domain• Understanding specific problem to be solved• Understanding organizational needs and constraints• Understanding needs of system stakeholders

There are various requirements elicitation techniques • Interviewing• Questionnaires• Scenarios and use cases• Prototypes• Facilitated workshops • Observation

Key Points (2 of 2) Prototypes are effective for requirements elicitation

• Gives stakeholders something to experiment with to find real requirements

Quality of requirements elicitation has direct effect on product quality

Critical to identify all relevant requirements sources• Stakeholders• Domain information• Potential sources for requirements reuse

Strive to avoid missing important requirements Strive to accurately report the requirements