1. Requirements Engineering

2. Simple Waterfall Model
Requirements
Analysis
and Specification
Design and
Specification
Coding and
Unit Testing
Integration and
System Testing
Delivery and
Maintenance

3. Notable Quotes:
"The hardest single part of building a software system is deciding precisely what to build"
(F. Brooks)

4. What is Requirements Engineering?
Requirements Engineering (RE) is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time [Zave, 1997]. 4

5. Requirements
The effects that the client wishes to be brought about in the problem domain
Definition of what the product should do
Potential customer needs
Specify what your user’s problem is
Not how to solve it
How a software system meets those needs
How it will be used
How it will fit into the work environment 5

6. Why Requirements Engineering?
Essential factor for ensuring project success
Resolve conflicting views of different stakeholders early
Start quality control & assurance activities earlier
Significant cost of fixing errors [Boehm]
A coding error not found until delivery costs 10 times as much to fix than if it is found during programming.
A requirement error not found until delivery costs 100 times more to fix. 6

7. Benefits of Requirements Processes
Fewer requirements defects
Reduced development rework
Fewer unnecessary features
Reduced project cost and delay
Improved system quality and customer satisfaction

8. Where Can Things Go Wrong?
Insufficient user involvement
Customers – fail to understand importance of RE
Developers – think they know what users want
Ambiguous requirements
Can interpret them in several ways
Minimal specifications
Gold plating
Developers add functionality not in the req. spec.
Overlooked classes of users
Inaccurate planning

9. Characteristics of Good Requirements
Complete
No missing requirements
Consistent
No conflicting requirements
Verifiable
Be able to verify that requirements are met
Traceable
Can be linked to design and code components

10. The Requirements Engineering Task
Identify problem and scope
Develop understanding of customer needs
Who will use the solution?
Why is the current situation a problem?
Define terminology
Characterize a good solution to the problem
Functions to be provided
Constraints to be met 10

11. Requirements Engineering Activities
Requirements Development
Requirements Management
Elicitation
Analysis
Specification
Validation

12. Requirements Engineering Activities
Requirements elicitation
Requirements discovered through consultation with stakeholders
Requirements analysis
Requirements are analyzed and conflicts resolved through negotiation
Requirements specification
A requirements document is produced
Requirements validation
The requirements document is checked for consistency and completeness
Requirements management
To cope with requirements changes

13. Requirements Engineering Activities
Requirements Development
Requirements Management
Elicitation
Analysis
Specification
Validation

14. Requirements Elicitation
The most difficult, most critical, most error-prone, and most communication-intensive aspect of software development
Success key: a collaborative partnership between customers and development team

15. Challenges for Requirements Elicitation
Problems of scope
The boundary of the system is ill-defined
Unnecessary design information may be given
Customers request features that are too expensive or that lie outside the intended product scope

16. Challenges for Requirements Elicitation
Problems of understanding
Users have incomplete understanding of needs
Users have poor understanding of computer capabilities and limitations
Analysts have poor knowledge of problem domain
User and analyst speak different languages
Conflicting views of different users
Problems of volatility
Requirements evolve over time

17. Elicitation Activities
Application domain understanding
Application domain knowledge is knowledge of the general area where the system is applied.
E.g., system for food pantry, supermarket, banking system, telecommunication system, etc.
Problem understanding
The details of the specific customer problem where the system will be applied must be understood.

18. Elicitation Activities
Understanding the needs and constraints of system stakeholders
You must understand, in detail, the specific needs of people who require system support in their work.
Consult them to discover their specific goals and needs
E.g., a new food pantry system needs to be integrated with an old database system

19. Elicitation Techniques
Background reading
Interviews
Survey/questionnaires
Brainstorming
Meetings
Task observation
Ethnography
Use case approach 19

20. Background Reading Sources of information Advantages Disadvantages
Company documents, organization charts, docs on existing systems, technical papers, etc.
Advantages
Understanding of the organization before meeting people who work there
May find detailed requirements for current system
Disadvantages
Written documents often do not match reality

21. Interviews
The requirements engineer or analyst discusses the system with different stakeholders and builds up an understanding of their requirements.
This is the predominant elicitation technique
Types:
Structured: The requirements engineer looks for answers to a pre-defined set of questions
Open-ended: There is no predefined agenda and the engineer discusses, in an open-ended way, what stakeholders want

22. Interview Advantages/Disadvantages
Rich collection of information
Can probe in depth
Disadvantages
Hard to analyze large amounts of qualitative data
Hard to compare different respondents

23. Interview Tips Be prepared Take notes
Don’t make interviewees think you’re thinking:
“My time is more valuable than yours”
“I don’t know what I’m doing”
“You don’t know what you’re talking about”
Be intelligible
Be receptive

24. Questions to Ask The problems to be addressed
The process of developing a solution
Who is paying for the development?
What are the underlying reasons for wanting a system?
What is the trade-off between delivery date and cost?
The elicitation itself
Do my questions seem relevant?
Are your answers official?
Is there anything else I should be asking?
Is there anything you would like to ask me?

25. Surveys/Questionnaires
Construct and administer a survey
Advantages
Can quickly collect info from large numbers of people
Can be administered remotely
Disadvantages
Simplistic questions can provide very little context
Things to be careful of:
Sample size
Sample selection method (random, voluntarily)
Ambiguous questions
A pilot run of a questionnaire can help eliminate bugs

26. Brainstorming
More natural interaction between people than formal interviews
Can increase the number of ideas
Relative short and intensive sessions seem to be most productive
Selection of personnel is critical
Do not allow criticism or debate
Idea reduction
Prune ideas that are not worthy of further discussion
Group similar ideas into super topics
Prioritize the remaining ideas

27. Meetings Used for summarization and feedback
To discuss the results of the information gathering stage
To conclude on a set of requirements
Meetings are an important managerial tool

28. Task Observation Advantages: Disadvantages:
Provides a way of addressing the “documented vs actual system” problem
Reveals details that other techniques cannot
Disadvantages:
Very time consuming
Subjective

29. Ethnography Particular variation of observation (over extended period)
People often find it hard to describe what they do because it is so natural to them. Sometimes, the best way to understand it is to observe them at work
Ethnography is a technique from social sciences, proven valuable in understanding actual work processes
Actual work processes often differ from formal, prescribed processes
An ethnographer spends some time observing people at work and building up a picture of how work is done
Expensive, so this may be cost effective only for complex and critical systems

30. Use Case Approach
In depth, later….

31. Elicitation Techniques: Which to use in your Class Project?
Background reading
Interviews
Survey/questionnaires
Brainstorming
Meetings
Task observation
Ethnography
Use case approach 31