Requirements

Analysis

1
 Overview
• Why gather requirements?
• Skills
• Project initiation
• Concurrent activities
• Current state analysis
• Desired state analysis
• How requirements are used

2
 Project Methodology
• Project initiation
• Customer problem
• Sales contact
• Project proposal
• Negotiations
• Project approval
• Project team
• Kickoff meeting
• Requirements gathering
3
 Concurrent Activities
• Finalize project resource needs
• Develop baseline project plan
• Conduct customer kick-off meeting(s)
• Status reporting and continual project
communication
• Establish risk management plan
• Create baseline schedule for development
phase
• Establish issue/change control procedures
4
 Why Change Control?
• Because scope creep is lethal
• Because only fools believe you can “freeze”
requirements & then build to them
• Because even though you all agree in April
doesn’t mean you’ll be speaking in June
• Because all of the parameters of a systems
project can change overnight

5
 Why Gather Requirements?
• Satisfies customer needs
• Promotes communication
• Basis for development activity
• Helps meet deadlines
• Maintains a practical project scope
• Testing and QA - traceability
• Customer satisfaction
• Reduce defects and lowers costs
6
Where do defects come from?
Other
Design 10% Code
27% 7%

Requirements
56%

Source - James Martin

7
Most likely cause of error
Factor How often cited

Lack of user input 13%

Incomplete requirements 12%

and specifications
Changing requirements 12%
and specifications
7%
Inadequate technology
skills
Inadequate staffing or 6%
resources
Unrealistic schedule or 4%
time frame

Source: Leffingwell and Widrig

8
 Errors in Requirements

Imprecise
Logical error Undocum ented
terminology assum ptions
3%
16% 30%

Traceability
and
inconsistency
24%
Inadequate
requirements
27%

According to Easterbrook, et al. Experiences using Formal Methods for Requirements Modeling.

9
 The Cost of Ambiguity
Software Development
Lifecycle Phase
1 Requirements
5 Design
10 Coding
20 Unit Test
50 Acceptance test
200 Maintenance
Relative Cost to Repair
10
 Risks from inadequate
requirements processes
• Insufficient user involvement leads to
unacceptable products
• Creeping user requirements contribute
to overruns and degrade product
quality
• Ambiguous requirements lead to ill-
spent time and rework
• Gold-plating by developers and users
add unnecessary features 11
 Risks from inadequate
requirements processes
• Minimal specifications lead to missing
key requirements
• Overlooking the needs of certain user
classes leads to dissatisfied customers
• Incompletely defined requirements
make accurate project planning and
tracking impossible
12
 Skills

• Organizing
• Listening
• Interviewing/Communicating
• Documenting

13
 Organizing

• Physical repository
• Electronic repository
• Calendar
• E-mail
• Hand-written notes repository
• Segmenting the task

14
 Tools
• Physical repository
• Word processing (Word)
• Spreadsheet (Excel)
• Project plan (MS Project)
• Flowcharting (Visio)
• 4GL tools (MS Access)
• Data modeling tools
• Presentation tools (PowerPoint)
15
 Listening
• Passive vs active
• Focus on understanding
• Repetition
• Investigating avenues

16
 Interviewing/Communicating

• Identifying candidates
• Interview plans
• Conducting Interviews
• Setting expectations

17
 Identifying Candidates

• Meet with the right people

• Meet with ALL the right people - do
not overlook line staff
• Get approval to interview
• Work out from the core, in
concentric circles

18
 Interview plans

• How many people should attend an

interview?
• Where to hold the interview?
• Know your objectives
• Prepare for the interview

19
 Conducting Interviews

• Opening lines
• Take notes
• Listen carefully
• Restate what you’ve heard
• Make one more phone call

20
 Setting Expectations

• Be careful of promising the moon

• Systems can do most anything, but
what does the budget/schedule
allow?
• Open the users minds to alternatives
• More on interviewing later...

21
 Documenting

• Quick review and re-statement

• Pictures
• Follow-up
• Highlighting important items

22
Why stakeholders shouldn’t write
their own Requirements
• They often can’t articulate what they
want from the system.
• They often express requirements in
general terms.
• They often omit specific business
knowledge.
• They use their own terminology, rather
than objective terminology.
23
 Current State Analysis

You can’t build something new

without understanding what’s
currently being used.

24
 Purpose
• To open the lines of communication
• To understand how the customer is
currently solving business problems
• To understand where this project falls
among all active and planned projects
• NOT to focus on current state, but to
prepare the team for desired state
analysis
• NOT to duplicate the current situation
25
 Tasks
• Conduct and document stakeholder
interviews
• Review existing documentation
• Review existing application system
• Review database schemas
• Review manual tasks
• Discover related concurrent development
projects
• Discover current standards
• Create documentation repository 26
 Interviews

• Apply your interviewing skills

• Managers, users, and line staff
• Developers
• IS support staff
• External stakeholders

27
 Review Existing
Documentation
• Org charts
• Current process flows
• Manuals and procedures
• Current system architecture
• Data models / file layouts
• Glossary of terms
• Reports
• Regulations and/or interface
requirements
28
 Review Existing Application
System
• Builds on review of documentation
• Walk-through by source system
experts
• End-user perspective
• Access to test account
• Review source code, if applicable
29
 Existing Data Model(s)

• Application system database(s)

• Volumetrics
• External system interface data
• Non-electronic data
• Data Warehousing or extraction
issues

30
 Review manual tasks

• How do users augment the system?

• How do users work around the
system?
• Which manual process are practical
to automate?

31
 Discover related concurrent
development projects

• What else is being developed now?

• What is being planned?
• How do these projects interact with
or effect your project?

32
 Discover Current Standards

• Legal or organizational requirements

• Documentation/development
standards
• Programming standards
• Required interfaces with external
entities
• Architectural standards
33
 Documentation Repository
• Policies and procedures
• Organization charts
• Data
• Current application architecture
• Screen snaps
• Textual descriptions
• System glossary
34
 Desired State Analysis

The key is discovering

what’s needed,
not just what users say they want.

35
 Purpose
• To understand the goals of both
management and users
• To understand fully the business
problems
• To understand and document the
business rules that drive the organization
• To prepare the team for creation of
functional/technical specifications
• To view the problems in a new way, and
NOT duplicate the current state
36
 Tasks
• Review source documentation
• Conduct and document stakeholder
interviews
• Hold JAD/Plan and Brainstorming
sessions
• Document the desired state requirements
• Gain user consensus on the desired state
requirements
• Walk-through and validation
37
Review Source Documentation

• Builds on information gathered in

current state analysis
• Strategic Initiatives
• Pre-existing project analysis
documentation
• External entity documentation

38
 Requirements Elicitation
• Individual and group interviews
• Upper management
• Users, managers and line staff
• Developers
• IS support staff
• JAD/Plan Sessions
• Brainstorming

39
 Identifying Candidates
• Start with the person who has
authorized or is sponsoring the project
• Use the organization chart to help
identify other relevant people
• Ask for other candidates during each
interview
• Also consider people who may not be
actual users of the system to be built,
but who interact with the users
40
 Identifying Candidates -
Rules of Thumb
• Individual users disagree
• Defer to the product champion to resolve

• Different user classes disagree on requirements or

priorities
• Use the business objectives to decide which is most important

• Manager requirements conflict with user

requirements
• Use the business objectives to decide which is most important

• Developers concept conflicts with customer

requirements
• Normally should defer to the customer unless customer
requirements are infusible or cause cost overruns
41
Thus -- NO SINGLE RIGHT ANSWER
 General Interview Guidelines
• Explore answers to improve your
understanding
• Confirm your understanding by
• Writing it down
• Summarizing
• Rephrasing
• Showing implications of what you hear
• Use pictures where possible

42
 General Interview Guidelines
• Be courteous during the interview
• Avoid questions that might seem
threatening
• Be an active listener during the
interview
• Avoid the tendency to anticipate an
answer

43
 General Interview Guidelines
• Allow the interviewee the opportunity
to answer questions fully
• Remain in control of the interview
• Be aware of non-verbal
communications
• Send out a written agenda prior to the
interview

44
 Begin the Interview
• Introduce yourself
• Review the goals of the interview
• Why you are here
• What will be done with the information collected
• Kinds of issues that will be covered
• Time allocation
• Assess the extent to which the interviewee is
prepared
• Explain any mathematical or graphical
notations being used 45
 Keep the Process Visible
• Ask questions about the interview itself
• “Are we doing all right?”
• “Have we ignored anything?”
• “Did we spend enough time on this issue?”
• Put questions in context
• Make sure the interviewee understands the
rationale for your questions
• Be prepared to point out if the interview
goes off track
46
 Check for Errors
• Be sensitive to communication
errors
• Recognize when they occur, and
correct them.

47
 Check for Errors
• Common kinds of errors include:
• Observational errors
• Recall errors
• Interpretation errors:
• Focus errors
• Ambiguities
• Conflicts
• Facts that are simply not true

48
 End the Interview
• Interviews end when:
• All the questions have been asked
and answered
• The allotted time has been exhausted
• You sense that the interviewee is
becoming too fatigued or “drained”
to continue

49
 End the Interview
• Leave five to ten minutes for
summarizing and consolidating the
information
• Explain the follow-up actions
• Solicit and answer questions
• Thank the interviewee

50
 Follow-up activities
• Send the interviewee a thank-you
note
• Produce a written summary of the
interview
• Request the interviewee confirm it
accurately reflects the information
exchanged

51
 Follow-up activities
• Confirm any statistical or other factual
information that depended solely on
the memory of the interviewee
• Review the procedures you used to find
ways to improve the process in the
future
• Clearly identify Action Items agreed
on
52
 Hold JAD/Plan Sessions
• JAD/Plan Session techniques out of
scope of this class
• Basically, key managers and users
interactively identify new system
requirements and rules
• Facilitated by a neutral person
• A scribe fully documents all conclusions
• Minimize complexity by partitioning
the effort
53
 Requirements Elicitation by
Brainstorming
• Simple group technique for
generating ideas
• Often used as a JAD/Plan technique
• Allows people to suggest and explore
ideas in an atmosphere free of
criticism or judgment

54
 Requirements Elicitation by
Brainstorming
• Consists of two phases
• Generation phase - participants are
encouraged to offer as many ideas as possible,
without discussion of the merits of the ideas.
• Consolidation phase - ideas are discussed,
revised, and organized.
• Can help overcome some of the
underlying difficulties of requirements
elicitation
55
 Generating Ideas
• Prepare for a brainstorming session
• Open the session by expressing a
general statement of the problem
• Generate new ideas relevant to the
problem expression
• Use of the ‘Round Robin’ technique

56
 Generating Ideas
• Concludes when
• Not enough ideas are being generated -
- the group reconvenes and continues
at another time when people (and their
ideas) are fresh
• Enough ideas have been generated and
recorded -- the group can move to the
consolidation phase

57
 Brainstorming Rules
• Move quickly, and do not analyze ideas
• Criticism of ideas is absolutely
forbidden
• Wild, offbeat, or unconventional ideas
are encouraged

58
 Brainstorming Rules
• The number of ideas generated should
be very large
• In addition to suggesting totally new
ideas, participants should be
encouraged to combine or embellish
ideas of others

59
 Keep all ideas visible
Techniques that can be used include:
• Designate a scribe to record all ideas on a
white board or flip chart
• Participants step to the whiteboard or flip
chart to record their own idea
• Use smaller sheets of paper and they are
placed in the middle of the table where all
participants can reach them
• Use post-it notes

60
 Reaching Consensus
• The goal is consensus, not
compromise
• Permits the group to organize the
ideas in ways that they can best be
used

61
 Reaching Consensus
• Steps include
• Review the ideas for the purpose of
clarification
• Nominal Group technique
• Discard the ideas that are too wild to be
usable
• Discuss and prioritize the remaining ideas
• Produce a record of all the remaining ideas,
along with their priorities or other relevant
comments from the consolidation phase
62
 Document the Desired State
Requirements
• Objectify requirements in one document
• Requirements scrubbing
• General requirements and business objectives
• Critical performance areas
• User interface requirements
• Business functions
• System interface requirements
• Hardware and system throughput
requirements
• Security requirements
63
 Three Levels of User
Requirements

• Business Requirements
• User Requirements
• Functional Requirements

64
 Business Requirements

High-level objectives of the

organization or customer requesting
the system

•Users will be able to correct spelling in a

document efficiently.

65
 User Requirements

Tasks the user must be able to

accomplish with the product

•Find spelling errors in the document and

decide whether to replace each misspelled
word with one chosen from a list of
suggested replacements.

66
 Functional Requirements
Software functionality the developers
must build into the product to
accomplish their tasks

•The spell checker has many functional

requirements that deal with operations such as
finding and highlighting a misspelled word,
displaying a dialog box with suggested
replacements, and making global replacements.
67
 Three levels of Non-Functional
requirements

• System Requirements
• Constraints and Assumptions
• Quality Attributes

68
 System Requirements

Standards, regulations, and contracts

which the product must conform;
descriptions of interfaces

•The spell check program must conform to

Acme Corporation User Interface Standards.

69
 Constraints and Assumptions
Restrictions placed on the choices
available for design and construction
of the software product, and facts the
project assumes are true

•The spell checker must work with word

processing systems running on Win98,
NT4.0 and Win2000 operating systems.

70
 Quality Attributes
Describes the product’s characteristics in
various dimensions that are either
important to the users or developers

•The spell check program must be able to

perform search and global replacements
operations in 20 seconds or less for small and
medium documents (those under 50 pages) and 2
minutes or less for large documents (those over
250 pages).
71
 Software Requirements
Specification
• The SRS is ...
• the first definitive representation of the capability
that the provider is to deliver
• precisely states the functions and capabilities must
be provided and the constraints that that must be
respected
• the basis for all a project's subsequent management,
engineering, and assurance activities.
• The ultimate source for all product requirements
• All participants must work from the same set
of approved requirements

72
 SRS Audiences
• Customers and the • Software maintenance
marketing department and support staff
• Project managers • Publications group
• Software development • Training personnel
team • More …..
• QA and Testing group

All participants must work from the same set

of approved requirements to avoid
unnecessary rework and miscommunication.
73
 Writing the SRS
• General Guidelines
• Number sections, subsections, and
individual requirements consistently.
• Leave text ragged on the right
margin
• Make liberal use of white space.

74
 Writing the SRS
• General Guidelines (continued)
• Use visual emphasis (such as bold,
underline, italics, and different fonts)
consistently and judiciously.
• Create a table of contents and an
index
• Number and label all figures and
refer to them by number.

75
 Writing the SRS
• General Guidelines (continued)
• Use your word processor’s cross-
reference facility, rather than hard-
coded page or section numbers, to refer
to other items or locations within the
document.
• Use the notation TBD (to be determined)
to highlight areas where you know you
lack a piece of information.

76
 Writing the SRS
• General Guidelines (continued)
• Label each TBD, record them on a list,
and track each to closure.
• Resolve all TBDs before you proceed
with design and construction. If you
must proceed while TBDs remain, defer
those requirements or design those
portions of the product to be easily
modifiable when the open issues are
resolved.
77
 Guidelines for Writing SRS
• The SRS must be understandable. It
does not have to be interesting.
Aspire to be a good engineer, not a
literary artist

78
 Guidelines for Writing SRS
• Follow effective technical-writing
guidelines
• Use complete sentences that have
proper grammar, spelling, and
punctuation
• Keep sentence and paragraphs short
• Use simple sentence structures
• Use the active voice
79
 Guidelines for Writing SRS
• Select the right words and phrases
• Use terms consistently and as defined
in the glossary
• Avoid the use of jargon, abbreviations,
and acronyms
• Avoid vague, subjective terms
• Avoid comparative words

80
 Guidelines for Writing SRS
• State requirements consistently
• Write statements in a consistent
fashion
• Use “shall,” “should,” “will,” and
“must” in a consistent way

81
 Labeling Requirements
• Every requirement must be uniquely identified
• The numbers or other identification label
should not be reused -- deleted requirement is
simply flagged
• Labeling schemes
• Hierarchical numbering – 4.3.2.2
• Sequence Number - SRS1, SRS2, …
• Hierarchical Textual Tags -
PRINT.COPIES.CONFIRM

82
 Characteristics of good
requirements statement

• Complete • Verifiable
• Correct • Atomic
• Feasible • Consistent
• Necessary • Modifiable
• Prioritized • Traceable
• Unambiguous • Clear
83
 Ambiguity Reducing
Techniques
• Questions that refine generalized
requirements
• Think of requirements as business
rules - “It is a requirement that…”

84
 Supplementing Natural
Language
• Some requirements are best described using
specialized notations.
• Use decision tables where actions have to be
taken depending on a complex set of conditions.
• Use programming languages or program design
languages to describe a number of actions which
must take place in sequence and where some of
these actions are conditional or may be repeated.
• Use lists and tables wherever possible to present
information sequences. 85
 Requirements Validation
Includes the activities intended to
ensure:
• The SRS correctly describes the intended
system behaviors and characteristics
• The software requirements were
correctly derived from the system
requirements or other origins

86
 Requirements Validation
Includes the activities intended to
ensure:
• The requirements are complete and of
high quality
• All views of the requirements are
adequate based to proceed with product
design, construction and testing

87
 Why Validate
• Fixing requirements problems can avoid a lot
of expensive rework of the system design and
implementation.
• Typical problems
• Lack of conformance to quality standards
• Poorly worded requirements which are
ambiguous
• Requirements conflicts which were not detected
during the analysis process
• Missing requirements
88
 When to validate
• Not a single discrete phase
• Some validation activities are threaded
throughout
• Informal reviews, walkthroughs, etc
• Other are useful as a final quality filter prior
to base lining
• Formal inspections
• For project planning
• Incorporate validation activities as discrete tasks
• Include time for the subsequent rework

89
 Informal and Formal Reviews
• Excellent technique for identifying
• Ambiguous or unverifiable requirements
• Requirements that are not clearly enough
defined
• Requirements that are in fact design
specifications
• They provide a way for stakeholders to
agree on the seriousness of specific
issues.

90
 Informal and Formal Reviews
• Inspection of requirements is arguable
the highest leverage software quality
technique.
• Possible savings of ten hours of work for
every hour investing in requirements
inspections

91
Walk Through and Validation
Summary
• Iterative review of Requirements
Document
• Put document under change control
• Conclude with requirements walk-
through and project owner sign-off
• Expect changes - they WILL happen

92
 How Requirements are used
• Defines agreed upon scope, outside
of which change control must be
applied
• Basis for determining what to test
• Foundation for creation of
functional/technical specifications
• The project resources triangle
93
Project Resources Triangle

Scope Resources

Time

94
 Conclusion

• Develop and apply fundamental skills

• Requirements form the base of the
pyramid
• Basis for managing scope creep
• Basis for effective testing
• Significantly increase the likelihood of
project success

95
 Suggested Reading
• Software Requirements - Karl Weigers
• Rapid Development - Steve McConnell
• Exploring Requirements - Donald C. Gause &
Gerald M Weinberg
• The Mythical Man-Month - Frederick P.
Brooks
• IS at Your Service - L. Paul Ouellette
96