CS 5150
Software Engineering
Lecture 7
Requirements 1
Administrivia
•
•
CS 5150
Quiz this evening
•
•
Rarely one “right” answer
Closed book
Feasibility study/plan due in a little over a
week
2
•
Causes of failed software projects (Standish Group study,
Why are Requirements Important?
1994)
•
•
•
•
•
•
•
•
CS 5150
Incomplete requirements
13.1%
Lack of user involvement
12.4%
Lack of resources
10.6%
Unrealistic expectations
9.9%
Lack of executive support
9.3%
Changing requirements & specifications
8.8%
Lack of planning
8.1%
System no longer needed
7.5%
3
Requirements in the Waterfall
Process
CS 5150
4
Requirements in Iterative Refinement
CS 5150
5
Requirements in Incremental
Development
CS 5150
6
Requirements Goals
•
•
•
•
CS 5150
Understand client/user requirements in detail
Requirements “text” must be understandable to
clients/users
•
•
•
Actual text
Diagrams
Prototypes/mock-ups
Requirements much be understandable to
designers, developers, testers, maintainers
Part of requirements gathering is ensuring that all
the relevant players understand them
7
Functional Requirements
•
Functional requirements describe the highlevel functions the system should perform, little
to no reference to underlying technology
issues
•
•
•
CS 5150
Major workflows
Data collected/managed
User interface idioms
8
•
Implementable and Verifiable
Developers should be able to imagine a realistic
implementation of any requirement
•
•
•
Bad example: The system must identify errors in
user input with 100% accuracy
There must be a way to unambiguously verify whether
a requirement has been met
•
•
CS 5150
Bad example: The system must process stock
trades between London and Chicago with
nanosecond latency
Bad example: The system should be easy to use
Better example: Typical internet users should be
able to use the system after completing a short
tutorial
9
Stages in Requirements Gathering
•
•
•
CS 5150
Analysis: Translate vague ideas about what
the system should do into a detailed and
concrete set of functions, services, goals and
constraints
Modeling: Organize the requirements into an
easier to digest and understand framework
(next two lectures)
Define, record and communicate: Make sure
requirements are recorded in a convenient
format and that all the players (developers,
client, etc) understand them
10
Requirements Analysis
•
•
•
•
CS 5150
Specifies external system behavior
Comprehensible by managers, customers,
users, etc
Covers:
•
•
Functions and services the system will
provide
Constraints under which it will operate
Often described in its own document:
•
“Our understanding of the requirements for
system X are ...”
11
Interviews with Clients and Users
•
Interviews with clients and users are at the
heart of requirements analysis
•
•
•
•
•
•
CS 5150
Allow plenty of time; perhaps multiple
meetings
Prepare questions before meeting
Keep notes; index cards often work well
If you don’t understand, don’t let it slide
Small meetings are often most effective
Repeat what you hear
12
Understand the Requirements
•
•
Domain understanding
•
Try to understand the fundamental
requirements of all stakeholders
•
•
CS 5150
May need to spend extra time learning the
client/user’s lingo
May need to interview several different
people
Stakeholders often don’t have a clear vision
of what the proposed system could do for
them
13
New and Old Systems
•
•
It is important to distinguish
•
•
Proposed new features
Clients often confuse their current way of
doing things with requirements for the new
system
•
•
•
CS 5150
Features of existing systems
New systems
Replacement systems
Legacy systems
14
Unspoken Requirements
•
•
CS 5150
Examples:
•
•
•
Resistance to change
Social friction
Organizational strengths and weaknesses
Unspoken requirements are one of the biggest
risks in requirements gathering
15
Stakeholders
•
A stakeholder is anyone affected by the system
•
•
•
•
•
•
Senior management
Deployment staff
Users
People whose information is collected
Example:
•
•
CS 5150
Client
Web shopping site
Customers, accounting dept, warehouse
managers
16
Viewpoint Analysis
•
•
•
•
CS 5150
Critique the requirements from the point of
view of a particular stakeholder
Get a real person, if that is feasible
Otherwise, do your best to role-play
Write a short separate document for each
viewpoint
17
Special Studies
•
•
•
CS 5150
If the team does not have the necessary
information or experience to be confident
about the requirement ...
Market research
•
Focus groups, surveys, competitive
analysis, etc
Technical research
•
Prototypes, experiments, literature survey,
etc
18
Conflicts
•
•
•
CS 5150
Some requirements may conflict with each
other
Information gathering vs. privacy
System performance vs. development cost
19
Negotiation
•
Sometimes client are unrealistic about what
they want
•
•
•
CS 5150
•
Extended discussion of relevant
requirements. Are there cheaper
alternatives?
Explain the specific reasoning behind
developer’s concerns
Be open to creative solutions
Leaving these issues unresolved is a big risk
20
Requirements Role-Playing Exercise
•
•
Get in groups of 2
•
Take turns gathering requirements from each
other
•
•
CS 5150
Different projects
One person plays the role of being their own
team’s client
Make up details if you have to
21