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