The document provides guidance on writing functional requirements and conducting effective user interviews. It discusses the purpose of functional requirements, outlines 11 rules for writing requirements, and reasons why software projects fail such as changing requirements. Effective user interviews involve open-ended questions, paraphrasing responses, and making interviewees comfortable to obtain honest feedback.

1. Writing Great
Functional
Requirements
& Effective
User Interviewss
September 2017
John Guber
HR and Finance Systems
1
Best when viewed as slide show.

2. Overview
2 John Guber
1. Purpose of the Functional Requirements.
2. Writing the Requirements.
3. Why Software Projects Fail?
4. Minimizing Requirements changes.
5. Effective User Interviews.

3. Writing Great Requirements
3 John Guber

4. Purpose of the Functional
Requirements
4
The purpose of a functional requirements document is to clearly
describe what must be accomplished from a business perspective.
A good functional requirements document brings clarity to the
process and allows the team, including management, vendors, IT,
QA, IOC and other resources, to achieve the desired outcome and
then measure the results against the requirements.
At any point in the process, anyone should be able to read the
functional requirements document and understand what’s going to
be accomplished.
John Guber

5. Writing the Requirements
5
11 Rules
John Guber

6. Writing the Requirements
6
• 1) Make requirements verifiable and measurable.
• One important purpose of a business requirements document is to
measure results. Take for example, a requirement that says, “the
system must be easy to use.” General statements must be made
specific so that it can be tested throughout the development process.
• For example :
• All content to be viewable on screen without scrolling.
• Process buttons to have same shape, text font and color.
• All links to be colored in bold blue text.
• What if user wants too many features?
John Guber

7. Writing the Requirements
7
• 2) Do not include the solution design.
• The requirements focus on what needs to be done, not how to
do it. The “how to do it” will be determined by the Design
Team.
John Guber

8. Writing the Requirements
8
• 3) Format requirements as separate paragraphs.
• It’s important to do this so that each requirement can be linked to
details in the subsequent design document. Specifically, each
requirement should express a single concept, for example:
John Guber

9. Writing the Requirements
9
• 4) Use details wisely.
• Two common mistakes with details:
• Including more details than are relevant to the
reader. Ask yourself, does the reader really need
to know this detail? If not, take it out.
• Not including enough important details. To avoid
missing critical details, take a wide view of the
business.
John Guber

10. Writing the Requirements
10
• 5) Use uncomplicated sentences and chunk information
so it’s easy to understand.
• Simple sentences are more understandable and they lend
themselves to more precise evaluation. Break out details into
bulleted chunks so they’re easier to grasp.
• Assessments of functional quality must be derived through an online survey of multiple
business line managers, senior executives, sales and marketing managers, production
managers, and customers and then maintained in a database and available as monthly
reports or through ad hoc queries.
•
Original
Revised
John Guber

11. Writing the Requirements
11
• 6) Avoid unnecessary words.
• If the words do not add meaning to a sentence, leave them
out. For example:
• Original -There must be three following results from this
process:
• Revised - The three results must be :
John Guber

12. Writing the Requirements
12
• 7) Use simple words rather than “complicated”
words.
• If the words do not add meaning to a sentence,
leave them out. For example:
John Guber

13. Writing the Requirements
13
• 8) Avoid using “it” and “this” without a clear
antecedent.
• This helps in two ways:
• The repeated antecedent adds clarity to the sentence.
• If the sentence is “lifted” from the text, for traceability
purposes the meaning will remain understandable. For
example:
John Guber

14. Writing the Requirements
14
• 9) Use terminology consistently.
• Avoid using different terms for the same thing. For
example:
• This is important when modifying existing
requirements for new enhancements. Use the same
terms as used originally.
John Guber

15. Writing the Requirements
15
• 10) Use business process flowcharts, screen mock-ups,
diagrams and computational examples.
• This enables developers to :
• Understand the objectives.
• Visualize what is required.
John Guber

16. Writing the Requirements
16
• 11) Review the document and then spell check and
proofread.
• Read through the entire document to be sure the
document makes sense and flows logically. Spell
check.
• Then, proofread the document, checking for missing
words and incorrect numbering or cross-references.
• Then check that the table of contents refers to the
correct page numbers.
• In a final pass, read the document aloud to catch
anything you might have missed previously.
John Guber

17. Software Project Failure Reasons
17
• Are poorly written requirements one of the reasons?
• IBM Cites:
1. Poor Project Planning and Direction.
2. Insufficient Communication.
3. Ineffective Management.
4. Failure to Align With Constituents and Stakeholders.
5. Ineffective Involvement of Executive Management.
6. Lack of Soft Skills or the Ability to Adapt.
7. Poor or Missing Methodology and Tools.
John Guber

18. Software Project Failure Reasons
18
• Are poorly written requirements one of the reasons?
• Computerworld Cites:
1. Unrealistic Schedules.
2. Inappropriate Staffing.
3. Poor-Quality Work.
4. Changing Requirements During Development. .
John Guber

19. Software Project Failure Reasons
19
• Are poorly written requirements one of the reasons?
• Harvard University Cites:
1. No specific methodology ~ coding is all that is important.
2. Create the project plan by working backwards from due date.
3. Don’t bother with a data model. Just build whatever tables you need.
4. Use a Technical Lead that has never built a similar system.
5. Hire forty developers to make the coding go faster.
6. Build the system in Java, even though most of the development team
still thinks that Java is coffee and you have no intention of ever
deploying to the Web.
7. Three months before the system goes live, assign one junior developer
to handle the data migration.
8. Skip the testing phase because the project is way behind schedule.
9. Buy a commercial, off-the-shelf package and customize it … a lot.
10. Change the system to support new or missed requirements discovered
during final development.
John Guber

20. Minimizing Requirements
Changes
20
• Poorly written requirements are not one of the top reasons for
unsuccessful projects BUT changing requirements is frequently
cited.
• We can not control changes in systems resulting from bona fide
business process change, legislation, competition, sales
compensation changes, etc.
• However, one great way to minimize changes is to nail down
requirements as accurately as possible through effective user!
John Guber

21. Effective User Interviews
21
• Recruit more participants than you need.
• Higher priorities come up. People need to cancel. Have more than 1
SKE for each area of interest.
• Factor in breaks.
• Give yourself an hour between sessions — to digest what you heard.
You don’t want to still be thinking about what the last person said when
you’re listening to the next person, or you might miss something.
• Interviews can be exhausting. Just because you can speak to seven
people in a day doesn’t mean you should.
• Record the sessions.
• You’ll be able to take lighter notes and concentrate on what’s being
said.
John Guber

22. Effective User Interviews
22
• Be casual and conversational.
• Prepared questions should only be used as conversation starters ~ a
checklist of topics to cover.
• Don’t number your questions. This implies a predetermined order in
which you need to ask them. It is most effective to ask the question at
the appropriate time in the conversation — when the participant
naturally brings up the topic.
• Ask open-ended questions.
• Always start your questions with Who, What, Where, When, Why, and
How. Open-ended questions can’t be answered with a Yes or No.
• Never start a question with, “Do you…” and expect to get more than a
three-word answer. A better way to phrase it would be, “To what
extent do you…” or “Tell me more about…” This forces people to really
think about their response.
John Guber

23. Effective User Interviews
23
• Ask the question, then pause.
• Ask your question, and then shhh. Let them answer, even if it takes a
moment. Stop yourself from offering up answers for them to choose
from.
• Play dumb.
• It is not your goal to demonstrate how much you know, but instead to
find out what they know, how they think about it, what they call it, and
how they think it all works.
• “Help me understand…” and “I’ve never done…” puts the participant
into the teacher role and you into the learner role.
• Don’t judge answers.
• If shocked by what you hear, do not show it. You are there to learn
about real people and real situations, not to form opinions or evaluate
their answers.
John Guber

24. Effective User Interviews
24
• Paraphrase what you heard.
• Summarize key learning points and repeat them back to the
participant. This gives them the chance to confirm or clarify, and will
keep you from going down the wrong path later on.
• If you’re wondering, ask.
• Often you get one shot to spend some time picking this person’s brain.
the participant uses a term you’ve never heard before, ask them to
explain it. If you think you misheard something, ask them to repeat it.
If one of their responses makes you think of something that isn’t on
your list of questions, ask it anyway. Let the conversation go where the
participant is taking it, and don’t allow shyness or preconceived notions
to stand in the way of true discovery.
John Guber

25. Effective User Interviews
25
• Be grateful.
• Say please, and thank you. Make the interviewee feel like a partner in
the process rather than just a subject of study, and that will lead to
more honest feedback, deeper answers, and just general good rapport.
John Guber

26. John Guber

27. John Guber

28. Sources
• ComputerWorld – Watts S. Humphrey
• IBM Systems Magazine - Joseph Gulla
• Harvard University – Dr. Paul Dorsey
• TechWrite Inc.
• Articles Base – Alexander O. McGee
• Bright Hub PM- Marlene Gundlach
• Vicarious Partners – Whitney Hess
• Dilbert – Scott Adams
John Guber

29. Writing Great User Requirements &
Effective User Interviews (Special
Feature Outakes!)
29 John Guber

30. Writing Great User Requirements &
Effective User Interviews (Special
Feature Outakes!)
30 John Guber

31. Writing Great User Requirements &
Effective User Interviews
(Special Feature Outakes!)
31 John Guber

32. Writing Great User Requirements &
Effective User Interviews
(Special Feature Outakes!)
32 John Guber