2. “The hardest single part of building a software system is deciding
what to build. No part of the work so cripples the resulting system
if done wrong. No other part is more difficult to rectify later.”—
Fred Brooks
“You start coding. I’ll go find out what they want.” —Computer
analyst to programmer
3. How will you find the answers of the
following questions?
What does the customer want?
How will the end-users interact with the software?
What will be the business impact?
4. Customer statement of requirements
starting point of requirements engineering
informal description of what the customers think they need from a software
system to do for them
problem could be identified by management personnel, through market
research, by ingenious observation, or some other means
opinion-based
evolves over time with changing market conditions or better understanding of
the problem
5. Goal of requirements engineering
fact-finding: how the problem can be solved in the current practice
envisioning: how the planned system might work
6. Final outcome of requirements
engineering
Software Requirements Specification (SRS) document
7. Stakeholder
an individual, team, or organization with interests in, or concerns related to, the
system-to-be
types:
customers
end users
business analysts
systems architects
developers
testing and quality assurance engineers
project managers
future maintenance organization
owners of other systems that will interact with the system-to-be
9. Requirements gathering
what is to be accomplished
how the system will fit into the needs of the business
how the system will be used on a day-to-day basis
10. Requirements analysis
refining of and reasoning about the requirements
creation and elaboration of user scenarios that describe how the
end-user will interact with the system
negotiation with the customer to determine the priorities, what is
essential, and what is realistic
11. Requirements specification
problem statement in a semiformal or formal manner to ensure
clarity, consistency, and completeness
function and quality of the software-to-be
constraints that will govern its development
can be a written document, a set of graphical models, a formal
mathematical model, a collection of usage scenarios (or, “use
cases”), a prototype, or any combination of these
13. “The best performance improvement is the transition from the
nonworking state to the working state.”
—John Ousterhout
14. Customer statement of requirements
I want to create a job posting site. It can do following things:
1. A user can search for a job.
2. A company can post job openings.
It should have all features that all existing job posting sites have as well as
some exciting features so that people are attracted to our site
15. “A user can search for jobs.”- Where Are
the Details?
o What values can users search on? State? City? Job title? Keywords?
o Does the user have to be a member of the site?
o Can search parameters be saved?
o What information is displayed for matching jobs?
16. “A user can search for jobs.”- Where Are
the Details?
o A user can search for jobs by attributes like location, salary range,
job title, company name, and the date the job was posted
o A user can view information about each job that is matched by a
search
o A user can view detailed information about a company that has
posted a job
17. Not recommended
“A user can view information about each job that is matched by a
search”
A user can view a job description
A user can view a job’s salary range
A user can view the location of a job
18. How Long Does It Have to Be?
understand the expectations of a project’s users
acceptance test
Try it with an empty job description.
Try it with a really long job description.
Try it with a missing salary.
Try it with a six-digit salary.
19. Bad Example
The software will be written in C++.
The program will connect to the database through a connection
pool.
20. Customer Team
includes those who ensure that the software will meet the needs
of its intended users
team may include testers, a product manager, real users, and
interaction designers
21. Why does the customer team write the
stories?
The customer team, rather than the developers, writes the user
stories for two primary reasons
each story must be written in the language of the business, not in technical
jargon, so that the customer team can prioritize the stories for inclusion into
iterations and releases
as the primary product visionaries, the customer team is in the best position
to describe the behavior of the product
23. Which of the following are not good
stories? Why?
a) The user can run the system on Windows XP and Linux.
b) All graphing and charting will be done using a third-party library.
c) The user can undo up to fifty commands.
d) The software will be released by June 30.
e) The software will be written in Java.
f) The user can select her country from a drop-down list.
g) The system will use Log4J to log all error messages to a file.
h) The user will be prompted to save her work if she hasn’t saved it for 15 minutes.
i) The user can select an “Export to XML” feature.
j) The user can export data to XML.