1. Requirements
Engineering
Mohamed Shaaban| Systems Analyst
February 2011| mohamed.shaaban@mail.link.net
w w w. l i n kd e v. c o m
w w w. l i n kd e v. c o m

2. Requirements Engineering
I. Requirements Management
II. Requirements Elicitation
III. Requirements Analysis
IV. Requirements Communication
w w w. l i n kd e v. c o m

3. I. Requirements Management
• Stakeholders Analysis
• Managing Requirements Scope
• Managing Requirements Risks
• Requirements Traceability
• Managing Requirements Change
w w w. l i n kd e v. c o m

4. Stakeholders Analysis (1/4)
• Focus Areas Outside World
– The Immediate Business Area you
are Affecting e.g Accounting dept. Enterprise
– Rest of the Enterprise Dept.
– Outside World – e.g. government,
clients, suppliers…etc
• Levels of Stakeholders
– Primary Stakeholders: have direct influence on your
product e.g. end user and sponsor
– Secondary Stakeholders: are indirectly affected or can
influence the decision of primary Stakeholders
w w w. l i n kd e v. c o m

5. Stakeholders Analysis (2/4)
• Essential Categories
– The Boss
• Signoff, payment “70% of software purchased isn’t
used. 90% of those used are used by
• Less knowledge, less time small groups although they are
– The Users implemented for large organizations”
– Donald Gause and Gerald
• Task owners Weinberg
• Involvement is vital
• Give them what they want, not what you think is right
– Subject Matter Experts
• Have the Know-how
• Vendor/Customer side
w w w. l i n kd e v. c o m

6. Stakeholders Analysis (3/4)
• Planning the Team of Stakeholders
– Have a profile for each category
• Who they are? Their background, goals, concerns?
• How busy are they?
“Sampling is selecting representative
– Decide who participates in the team elements of a population with the
goal to reveal useful information
and who presents a key stakeholder about the population as a whole”
• Sampling – Kendall and Kendall
– Convenient, Purposive, Simple, Complex
– Decide on the participation plan of the stakeholders
• Top down approach – supervisor first
• Two people/level – info validation
• Keep the channel open for others
w w w. l i n kd e v. c o m

7. Stakeholders Analysis (4/4)
• Tools to Figure out Stakeholders
– Watch the work environment
– Check the enterprise organization chart
– Any info about the organization e.g. its website
– Investigate hard data: who provided it and who received it?
• Communication Strategies
– Executives: presentations, demos, summaries
– Developers: system requirements, usecases
– End users: prototypes
• RACI
– Responsible: does the work
– Accountable: is the decision maker (only one)
– Consulted: must be consulted prior to the work and gives input
– Informed: is on a need to know after the work is done
w w w. l i n kd e v. c o m

8. Managing Requirements Scope
• Identifying Scope
– User groups and number of users
– Modules and functions of the system
– Integration requirements
– Deployment locations
– Security requirements, platforms, browsers
– Data migration
– Administration requirements
– Specific technology requirements
– Others: workflows, reports
• Scope Creeps
– Source
– Mitigation
w w w. l i n kd e v. c o m

9. Managing Requirements Risks
• Common Risks
– Lack of key stakeholders involvement
– Requirements instability
– Ambiguous requirements
– Insufficient time assigned to requirements elicitation and
analysis
– Scope creeps
• Risk Management Process
– Planning: likelihood, impact, intervention difficulty, mitigation
strategy (avoidance, transference, mitigation, acceptance)
– Monitoring: perform periodic checks
– Controlling: effectiveness of action plans and lessons learned
w w w. l i n kd e v. c o m

10. Requirements Traceability
• Types of Traceability
– Requirements are traced back to:
• Source: who requested the requirement
• Rationale: the business goal that the requirement is to satisfy
– Requirements are traced forward to:
• Design module(s)
• Program code
• Test case(s)
• Preparing for Traceability
– Numbering system
– Build a Traceability Matrix
Requirements/Test Cases Req 1 Req 2 Req 3
Test Case 1 X
Test Case 2 X X
Test Case 3 X
w w w. l i n kd e v. c o m

11. Managing Requirements Change
• Your role, as an analyst, is to help the PM by:
– Validate change with respect to initial scope
– Assess impact of change on other requirements
– Document the change
• Description, source, reason, priority, date
• Update relevant documents e.g. Traceability Matrix.
Use revision history
– Communicate change to all affected stakeholders
– Obtain approval on either delivering the change or
scoping it out
w w w. l i n kd e v. c o m

12. II. Requirements Elicitation
• Elicitation Techniques
• Conflicts Management
• Challenges of Requirements Elicitation
• Qualities of Good Requirements
w w w. l i n kd e v. c o m

13. Elicitation Techniques (1/8)
• Elicitation Cycle
Elicit Organize Analyze Confirm
• Observing and Investigating
– Hard data could be documents, websites, invoices, pay
slips, forms
– Hard data explain only the past
– Role of the document: who wrote it to who and why it
was created/kept
– Hard data are useful to figure out data elements
– Data can guide you to stakeholders – who has this
data
w w w. l i n kd e v. c o m

14. Elicitation Techniques (2/8)
• Interviews
– Must be directed with a specific goal in mind,
otherwise you’ll loose track and waste time
– Interview many people – complete picture
– Listen carefully – every project is different
– Find out the interviewee goals
– Understand yourself – biases, background, mood
– Seek opinions and feelings, not only facts
– Revisit issues more than once
w w w. l i n kd e v. c o m

15. Elicitation Techniques (3/8)
• Interviews (cont.)
– Preparation
• Read related material
• Establish interview objectives
• Prepare the interviewee
– Avoid:
• Speaking computers – don’t intimidate the interviewee
• Helping the interviewee with answers
• Leading questions
• Double-barreled questions – what do you do and how!
• Walking in with a Design in mind
w w w. l i n kd e v. c o m

16. Elicitation Techniques (4/8)
• Interviews (cont.)
– Tips for maximum benefit
• Explain what you mean by major terms you use
• Order the questions by subject
• Assess the knowledge level of the interview and act
accordingly
• Watch out for signs from the users that show that they are
not convinced
• Don’t fake that you understand if you don’t
• Rephrase and summarize back
• Document!
w w w. l i n kd e v. c o m

17. Elicitation Techniques (5/8)
• Interviews (cont.)
– Closure
• Summarize and give the interviewee a feedback of your
impression
• Best last question: an invitation to the interviewee to
state if there is anything he would like you to know and
you didn’t touch on
• Tell them what will happen next
w w w. l i n kd e v. c o m

18. Elicitation Techniques (6/8)
• Questionnaires
– Avoid them!
• Not reliable: Q & A are subject to interpretation
• People don’t like filling questionnaires
• Take long time to plan, analyze, convince people to fill them
• Not for the To Be situation: people cannot envision the
future on their own
– Use them as a last resort when:
• Users are geographically dispersed and it’s hard to reach
them
• You are running a market survey for an off-shelf product
• You need to gather information about the existing situation
w w w. l i n kd e v. c o m

19. Elicitation Techniques (7/8)
• Meetings and Facilitation
– Typical complaints about meetings:
• Too long and boring
• Have no purpose and stray from the subject
• Painful
– Types of meetings
• Collect information
• Validate and confirm information
• Resolve issues
• Report findings
• Propose solutions
• Raise spirits
• Increase/decrease number of ideas
w w w. l i n kd e v. c o m

20. Elicitation Techniques (8/8)
• Meetings and Facilitation (cont.)
– To make meetings effective:
• Set an agenda and basic ground rules: interruptions, time
limit, personal attacks
• Provide necessary info for attendees beforehand
• Determine who should attend
• Record, validate, and publish immediately after the meeting
• If the project has too many meetings, it may mean that you
either have too many people involved or tasks are not well
divided so people cannot work without affecting each other
w w w. l i n kd e v. c o m

21. Conflicts Management (1/3)
• Possibilities or disasters
• Essential and inessential conflicts
– An essential conflict is a conflict that concerns this
particular project at this particular time and
involves only those people who are present at the
moment or who are the actors at this point
– Avoid and delay inessential conflicts
w w w. l i n kd e v. c o m

22. Conflicts Management (2/3)
• Types of conflicts
– Personality clashes – “you always”, “you never”
• Ask if it’s really a here-and-now issue
• Don’t take sides
– Personality differences
• Optimistic/pessimistic
• Micromanagement
• Looking for reward/avoid punishment
• Like to be in control/under control
w w w. l i n kd e v. c o m

23. Conflicts Management (3/3)
• Types of conflicts (cont.)
– Intergroup prejudice
– Levels prejudice
• Recommendations
– Be fully present
– Don’t pretend things are not happening
– Ask about anything puzzling
– Use negotiation skills
w w w. l i n kd e v. c o m

24. Challenges of Requirements Elicitation
• Assumptions
– The beginning of a project is when the most
assumptions are made. Revisit!
– The client also assumes you know things
– Ask for clarification and exact information
– Give complete, accurate information
– Everything is the same. And everything is different
– Write down assumptions and confirm them
– Ensure that nobody makes fun of someone who asks
questions to avoid assumptions
w w w. l i n kd e v. c o m

25. Challenges of Requirements Elicitation
– Writing about the implementation instead of the
requirements (the how, not the what)
– Missing the real “why” of the requirement
– Imposing Solutions on the customer. Remember
there’s no perfect solution or one right way
– The stakeholders' unwillingness to change or help
design a new product
w w w. l i n kd e v. c o m

26. Qualities of Good Requirements (1/2)
• Get Specific
– I need certain information to make decisions – let’s list
them one by one
– The system must not produce too many errors – how many
errors is an acceptable number?
• Prioritize – for resources and time shortages
– The value of the requirement to the customer business
– The customer satisfaction if the requirement is
implemented
– The cost and time needed to implement the requirement
– Any obligation that mandate the implementation of the
requirement, such as legal obligations
w w w. l i n kd e v. c o m

27. Qualities of Good Requirements (2/2)
– Weigh each requirement on a scale from 1 to 3
Requirement Business value Implementation Customer Obligations Total
cost/time satisfaction
Req 1 1 0 1 1 3
– Must: indispensable functions in the relevant phase of the
product
– Should Have: important, but the product will not be
useless without them
– Nice to have: frill functions that the user can do
without, but would like to have if they cost nothing
• Prioritize every time new requirements are added or
when a function is decomposed into sub-functions
w w w. l i n kd e v. c o m

28. Exercise
• Think about your own biases
• Think about how you see change
• Case study
– Stakeholders Analysis
– Risk Analysis
– Interview: one on one and observers
• Requirements Process
• RSD Walkthrough
w w w. l i n kd e v. c o m

29. Questions
w w w. l i n kd e v. c o m