1. Requirements Elicitation
REQENG

2. Subtopics Background Material Requirements Elicitation Process
Requirements Sources
Elicitation Techniques

3. 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

4. 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

5. 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

6. 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

7. Systems Engineering Process Model
Needs statement
Validated System
System Requirements Engineering
System Validation
System Requirements Specification
Architectural Design
System Integration
Requirements Allocation
Sub-system Development
Software Requirements Specification
Software Requirements Engineering

8. 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

9. Requirements Engineering Activity Model
Requirements Management
Requirements Elicitation
Requirements Analysis
Requirements Specification
Requirements Validation
Validated Requirements Specification
Existing System Information
Stakeholder Needs
Organizational Standards
Technical Standards
Regulations
Domain Information
Goals

10. Subtopics Background Material Requirements Elicitation Process
Requirements Sources
Elicitation Techniques

11. 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

12. 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

13. Components of Requirements Elicitation
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
Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998

14. Requirements Elicitation Process
Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998

15. 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

16. 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

17. 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

18. Subtopics Background Material Requirements Elicitation Process
Requirements Sources
Elicitation Techniques

19. Requirements Sources Goals Domain knowledge Operational environment
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

20. Requirements Sources Organizational environment System stakeholders
Structure, culture, and internal politics
System stakeholders
Customers
End users
Domain experts
System maintainers
Regulatory authorities
System developers

21. Subtopics Background Material Requirements Elicitation Process
Requirements Sources
Elicitation Techniques

22. 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

23. 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

24. 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

25. Interviews (2 of 2) Advantages Limitations
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

26. 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

27. 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

28. 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

29. 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

30. Scenarios (2 of 2) Advantages Limitations
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

31. Example Scenario -- ATM
Source: Ian Sommerville, Software Engineering, 6th edition, 2000

32. 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

33. 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

34. Prototypes (2 of 2) Advantages Limitations 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

35. 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

36. 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.

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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