Slide 1
RequirementsRajiv RamnathDirectorCERCS for Enterprise
Transformation and Innovation (CETI)CSE 757 Software
EngineeringNarrated by:
0Learning Outcomes10/18/2011Requirements1
To begin with, here are the learning outcomes from this lecture.
We want you to be:Be familiar with the concept of requirementsBe
familiar with techniques for requirements identification.Be
familiar with requirements work-products and their use in capturing
requirements.1Definition of RequirementsThe needs or conditionsthat
a new or altered software systemmust meet, taking into accountthe
possibly conflicting perspectivesof the various
stakeholders.10/18/2011Requirements2
The needs or conditions that a new or altered software system
must meet, taking into account the possibly conflicting
perspectives of the various stakeholders.
Note that requirements come from a variety of stakeholders end
users, business sponsors, technical groups, regulatory bodies etc.
Requirements from a stakeholder might be in conflict. For example,
the business sponsor may require low cost while the end user may
require high performance. Thus, trade-offs have to be made, based
on how important a stakeholder and his requirements are.
2How do you find and capture requirements?Domain and Problem
AnalysisAnalyze a piece of the businessExamine value chain
activitiesDevelop Balanced ScorecardsExamine existing business
processes and transactionsUser and domain expert
interviewsEthnographic studies:Field observations, studies and
interviews (Intuit: follow-me-homes:
http://blog.intuit.com/trends/what-is-a-follow-me-home/)Could be
longitudinalRequirements are then captured - in work-products, or
as tacit knowledge10/18/2011Requirements3
Domain and Problem AnalysisAnalyze a piece of the
businessExamine value chain activitiesDevelop Balanced
ScorecardsExamine business processes and transactionsNote: You did
some of this before earlier probably without knowing that what you
were doing is analysis.User interviewsEthnographic
studies:Observations (Intuit: follow-me-homes)
http://blog.intuit.com/trends/what-is-a-follow-me-home/Embedded
field studiesLongitudinal research studies that look at progression
over time.In-depth interviewsRequirements are then captured - in
work-products, or as tacit knowledge
3Requirements Work Products10/18/2011Requirements4
Let us now look at requirements work-products.
4Requirements Work Products Problem StatementContent:Business
domain, goals, objectives, stakeholdersWhat are we trying to
accomplish, for whom, and whyNot focused on solutionHow:Written
with customer, before the project begins Shared, incomplete,
consensus achievedFormat:Free format text with sections such as:
Objectives, Success Criteria, Itemized requirements, Stakeholders
etc.10/18/2011Requirements5
The first requirements work product we will look at is the
Problem Statement. The focus is on the problem, or need, not the
solution. A text description of business goals, objectives, problem
to be solved. Capture what RESULTS the solution is supposed to
deliver as opposed to the solution itself.
Most of the time a problem statement is captured in free-form
text with perhaps a few sections.
5Problem Statement ExcerptTheFirm is a firm consisting of 3
business - a law firm, a title company and a processing company,
doing high-volume legal work, charging fixed fees and with a larger
ratio to staff vs. attorneys. A high-volume foreclosure law firm is
different from a regular law firm; it cannot rely upon the attorney
to get the work done. The high-volume law firm is dependent on its
case management system to keep track of the cases and to identify
what must be done in those cases and when. We are a high-volume law
firm. As a result, we need an automated workflow system, one that
tells the user what needs to be done and when. We need a system
that allows us to handle the volume of cases with consistency, high
quality and efficiency, and integrated with the systems and
processes of our customers.10/18/2011Requirements6
Part of a problem statement from a project done with a law firm.
Non-traditional law firm. Did not do litigations in court or
prepare legal briefs. It was a high-volume law firm. Few lawyers,
most work done not even by paralegals but by employees trained in
the administrative tasks needed to process foreclosures.
Organization measured based on throughput and efficiency. Hence
a good candidate for a software system that could guide employees
without legal training in properly following the process, creating
the necessary documents and so on.
6Requirements Work Products Business CaseJustification of
expense - effort or monetaryViewpoint from multiple
stakeholdersItemized cost estimates, including opportunity costFree
formatCould include soft benefits: social, environmental, ethical
and politicalStructure as: COST vs. BENEFIT
10/18/2011Requirements7
The business case is a justification of the expense and effort
of doing the project. It should be structured in two parts cost vs.
benefit (value). Unlikely at start of project of the cost or
benefit. So this should be refined as the project proceeds. Cost
might be in $$ or hours of work, benefit might be intangible. Make
the extra effort of converting benefits to $$ if possible.
7Example Business CaseEstimated cost:$1M, based on staffing size
and estimated duration of 1 yearEstimated Benefit (over 1
year):Reduction in training costs: 1 person month per employee *
turnover rate = $100,000Reduction in penalties due to errors:
$250,000Increased revenue due to increased capacity from 200 cases
to 250 casesCompetitive advantage due to a demonstrable
assetEtc.10/18/2011Requirements8
Example business case from the law firm example.
A. Estimated cost as $1M. Well look at better ways to estimate
the cost in a more refined in a later module.
Here we estimated the cost based on the resources applied
software developers, architects, DBA, users, equipment costs.
Rough, but gave the owner an idea that this is likely to be an
expensive project, and should expect at least a $1M worth of
return.
B. Estimated Benefit:
Reduce training costs because training doesnt have to be
one-on-one in person. Dont have to train on process, only on
system. Saved 1 month per year, multiplied
Delays in process caused penalties. System could save these
costs. About $250K per year.
Made each person more productive because he didnt have to do
manual things, about 25%. So more cases 50 more per year.
Total of $750K per year in cost savings.
But also, gave the law firm a tangible asset that gave it
demonstrable competitive advantage with respect to winning new
business.
8Requirements Work Products StoryboardNarrativeOf how the
organization would work using the system, OROf how the organization
currently works
10/18/2011Requirements9
A storyboard is a very useful work product to collect
requirements. Speaker comes and tells a story that illustrates how
an organization typically works, how users may interact with the
system (the system vision). Natural work product to capture
requirements. This is an informal narrative, from which the other
structured or more systematic work products can be derived.
9Requirements Work Products Use Case ModelCaptures functional
requirementsConsists of:Actors (humans, external systems)
hierarchyUse CasesExtends vs. Uses (SEE NOTES PAGE)Use Case Diagram
context modelUML NotationDrives all activity - starting with
analysisDrives acceptance tests
10/18/2011Requirements10
Very popular work products is a Use Case Model, and consists of
3 components: (a) the actors that use the system human as well as
system actors (b) Use Cases visible interactions of the system with
the actors captured and packaged in an intelligent manner (c) Use
Case Diagram shows the context of the system that is, its place in
its environment.
Use Cases typically drive the rest of the process. That is,
other work products are often derived from Use Cases, such as the
Acceptance Plan which we will see later that closes the loop with
respect to requirements.
10Example: Actors HierarchyActor:TheFirm EmployeeTheFirm
UserIntake ProcessorTitle AdminTitle
ProcessorAttorneyConsultantTitle Examiner
10/18/2011Requirements11
Example of the actor inheritance hierarchy from the law firm
example.TheFirm EmployeeTheFirm User not all employees use the
system. Now different rolesIntake ProcessorTitle AdminTitle
ProcessorAttorneyConsultant users outside the firmTitle
Examiner
Defines the prototypical users of the system. Structured in a
hierarchy, and could be internal as well as external to the
organization.
11Example Use CasesDepartment: IntakeActors: Intake
ProcessorNormal Use CasesIntake Processor Claims Case from Client
SystemIntake Processor Assigns AttorneyIntake Processor Assigns
Title ExaminerExceptional Use CasesChange or Correct Attorney
AssignmentChange or Correct Examiner AssignmentAttorney leaves
TheFirmExaminer leaves TheFirm
10/18/2011Requirements12
Example use cases from the system we developed. Actor is Intake
Processor, assigned to a department called Intake. Three use cases
capture how the actor normally interacted with the system (hence we
have termed these Normal use cases.
There were also 4 exceptional use cases that capture how the
actor interacted with the system in rare situations.
Useful to create two categories of use cases to help in
prioritization.
Also, while a use case may be rarely used, it may be an
important use case say one against which the design of the system
must be validated.
12Use Case DiagramShows context of systemSystem
boundaryActorsUse case namesRelationships
10/18/2011Requirements13
A Use Case Diagram shows the boundary of the system to be
designed, the use cases of the system, and which actors interact
with which use cases.
What is inside the system boundary is what is to be
implemented.
13Example Use Case Diagram10/18/2011Requirements14
Intake ProcessorClient System
On this example use case diagram you can see two actors a human
actor and a system actor (the system from which foreclosure cases
are to be pulled).
The use case diagram shows the context of the system. You see
which use cases interact with which actor. It also shows a larger
use case being refined to smaller use cases.
14Requirements Work Products - ScenariosAlso known as FlowsUsed
to refine a Use CaseOne path through a Use CaseHappy PathUnhappy
pathsAssumptionsOutcomes10/18/2011Requirements15
From the Storyboard, you could derive Use Cases. But Use Cases
are still high level. Have to breakdown use cases further. For
example, User Withdraws Money From ATM can be broken down into
several scenarios, namely: User Withdraws More Than Limit from ATM,
User Enters Incorrect Password.
These scenarios are typically broken down into happy scenarios,
such as User Withdraws Less Than Balance From ATM or unhappy
scenarios, such User Enters Incorrect Password.
Note two other components of scenarios, namely, Assumptions and
Outcomes. What has happened before the scenario are the
assumptions. What happens once the scenario executes are the
outcomes. For example, the assumption could be that the user has
entered his card and typed in his password. This the scenario would
start from that point onwards.
Outcomes are what has happened after the scenario has executed.
Thus, in the happy path scenario, the user would have successfully
withdrawn his money. In the unhappy path scenario, the outcome
would be an error message saying Incorrect Password or Withdrawal
Not Authorized.
15Example ScenariosUse Case: Intake Processor Claims Case from
Client SystemPrimary scenario (or Happy Path)Case is successfully
claimedAlternate scenarios:Client system has invalid
requestDuplicate case is launchedCase is incorrectly launched
10/18/2011Requirements16
Example scenario from the Foreclosure system drawn from the Use
Case Intake Processor Claims Case from Client System
Primary scenario (or Happy Path) occurs when the case is
successfully claimed.
Unhappy paths (alternate scenarios) are things like the case
having invalid data, being a duplicate case, or the case doesnt
have sufficient data to be launched.
There could be several happy paths: E.g. take the use case User
Makes A Deposit. This could have the following several happy
scenarios: User Deposits Check, User Deposits Cash, and so on.
Granularity of use cases and scenarios is up to you. You could
capture every scenario as a use case, but then you would lose the
big picture, and make mistakes like implementing the UI of each
scenario, which should be similar in terms of look and feel being
from the same use case, slightly differently.
16Requirements Work Products User StoriesUsed to capture
functional AND non-functional requirementsFormat: As an I want to
to achieve 10/18/2011Requirements17
A User Story is a work-product equivalent to a scenario. The
format of a story is: As an I want to to achieve A User Story may
also be used to capture non-functional requirements, as we will see
in the later slides.
17Example Story Functional RequirementAs an Intake Processor I
Evaluate a Case as follows:I am notified of a new case in the
client systemI look through the case to see if it is a valid and
new foreclosure caseIf it is a new foreclosure case, I can accept
the case, thus preventing another company or another intake
processor from claiming itIf not, I release it.so that I may Accept
it for Processing or Reject it10/18/2011Requirements18
As an Intake Processor I Evaluate a Case as follows:I am
notified of a new case in the client systemI look through the case
to see if it is a valid and new foreclosure caseIf it is a new
foreclosure case, I can accept the case, thus preventing another
company or another intake processor from claiming itIf not, I
release it.so that I may Accept it for Processing or Reject it
Hope you see how a user story may be written.
Later you will see a slide where a story captures a
NON-functional requirement.
18Requirements Work Products Non-Functional RequirementsAlso
known as architectural, assurance, or design requirementsVERY
important - can break a projectBut cannot make it Example
categories: Performance, Availability, Compatibility, Usability,
Security, CostDrives DESIGN not analysisWho does this:Customer,
project manager, team leaderProcess:Make it real for the system
under considerationVerify coverage against use casesMust be
testable10/18/2011Requirements19
Just as the use case model captures the functional requirements
of the system which is what the system is supposed to do, the WHAT
of the system non-functional requirements capture the HOW of the
system.
Once again, take the situation of an ATM machine; the use case
is user withdraws cash from the ATM. The non-functional requirement
is a typical user is able to withdraw cash from an ATM within 15
seconds of inserting a card. This is not a functionality
requirement, because the functionality requirement is simply a user
withdraw cash, it is what is known as a non-functional, or design,
requirement which puts a specification on how the functionality
must be implemented. That is, it must be implemented in a way such
that a user can withdraw with 15 seconds.
Both functional and non-functional requirements translate into
behavior of the system, because if the FR is user withdraws cash,
then there has to be behavior in the system that allows the user to
withdraw the cash, and a NFR that says a user must be able to
withdraw cash within 15 seconds, it makes the system work fast
enough so that it can deliver the cash within 15 seconds. So keep
in mind that both kinds of requirements ultimately result in
behavior of the system.
The distinction is that NFRs drive the design of the system, not
the analysis of the system. So when you are thinking about what the
system is supposed to do, you can do that by looking only at the
FR; its when you try to design the system so that you can build it
that you start to look at the NFRs.
The reason to separate the two is to allow the software
engineering team to separate analysis and design so they dont too
quickly paint themselves into a corner with a particular solution,
when there are better ones around. Now, NFRs can be categorized in
various ways, typically speed, performance, scalability,
modifiability, usability, etc.19Example Non-Functional
RequirementsPerformance:Based on studies of user attention span
synchronous tasks must respond within 5s in system steady
stateUsability:Prototypical LawFirm users must be able to learn to
use the system within 10 daysScalability:User growth rate: +20
users per year3000 new cases per year2 new company acquisitions per
year10/18/2011Requirements20
On this slide are some example NFRs in three categories:
performance, usability, and scalability. Keep in mind that an
attempt has been made to quantify these requirements in the context
of the system being built. That is, we are not saying things like
the system must be high performing, usable, and scalable, we are
quantifying exactly what performance, usability, and scalability
mean.
This is very important. Its very important that the
quantification of these NFRs be in the context of the system, in
other words, its the quantification thats different from system to
system. For example, lets take usability. We say that user must be
able to use the system within 10 days. Why have we said within ten
days? Remember the original rationale for building the system: we
would be able to save about a month in training time for each user.
Ten days has been decided as the appropriate time to train each
user. If it took more than ten days, then maybe we wouldnt save as
much money as we anticipated. Thats where the requirement came
from: a business requirement!
Secondly, you can see its probably feasible to train a user on
this system, even without seeing or designing it, you can see that
it is a reasonable requirement that people learn how to use it
within 10 days. On the other hand, imagine a system that performs
robotic surgery. It certainly wouldnt be a reasonable requirement
that a surgeon learn to operate the machine within ten days because
there is a sense that robotic surgery is dangerous, so the surgeon
would require weeks of training. Just keep this in mind: NFRs have
to be quantified. The quantification has to be done within the
context of the system.
There are not many standard quantifications. By the way, here is
an example of a standard quantification: the first one, that says
the system must respond within five seconds. That one came from a
study that says users lose interest in ANY system that doesnt
respond within five seconds. So that requirement did not come from
this particular system, but the others did. Both came from the
business case of what the system was supposed to address.20Example
Non-Functional Requirements Captured as StoriesAs a TheFirm User, I
want to be able to run your product on all versions of Windows from
Windows 95 on.As the TheFirm Systems Administrator, I want the
system to use our existing orders database rather than create a new
one sot that we dont have one more database to maintain.As a
TheFirm User, I want the program to be available from 8 am to 6 pm
Mondays through Fridays.As TheFirm Partner, we might want to sell
this product internationally.10/18/2011Requirements21Reference:
User Stories Applied: For Agile Software Development, Mike Cohn,
Safari http://is.gd/eyzsl5
Here are examples of non-functional requirements captured as
stories.
The first one is a portability requirement.
The second is a compatibility or integratability
requirement.
The third is an availability requirement.
And the fourth is a business requirement, all captured as
stories.21Requirements Work Products Prioritized
RequirementsPrioritized requirementsHow to prioritize:Customer
valueRiskPriority is a combination of:Importance or Business
ValueVital, important, would be niceand UrgencyOther functions
depend on it etcCould be coarse granularity, partitioned by
use-case, or fine granularity, partitioned by scenarioDrives
prioritization of Acceptance Plan and Project Management
work-products10/18/2011Requirements22
The next work product is a work product known as prioritized
requirements. You might think that this belongs as a project
management work product and you might be right. The basic idea here
is to take all the requirements, both functional and
non-functional, and prioritize them.
The prioritization is generally done on two axes: business value
and urgency. Business value, or importance, speaks to how much
revenue you could generate from this product. Urgency comes from
whether other pieces of functionality depend on it. For example, a
login use case has no business value because it generates no
revenue, but it has high urgency because other functions depend on
it.
Now when you prioritize requirements, you can prioritize them at
a coarse granularity by use case or non-functional requirement or
you can prioritize it at a fine granularity, such as by scenario
within a use case. Even the non-functional requirements can be
prioritized in a granular manner, for example, you can have NFRs
attached that serve as use cases that have to be implement first,
and so on.
So once again, the whole reason for prioritizing the
requirements is to give an order to the development process and
this in turn will drive two things: an acceptance plan, which we
will talk about next, and the project management work products
because the prioritization will determine the order of which things
need done.22Requirements Work Products Acceptance PlanAcceptance
planCommits customer to a deterministic way of determining
acceptanceParticipants: decision makers, stakeholdersShould include
time to fix clausesLess important for internal
projects10/18/2011Requirements23
Now we come to the last work product in this list of work
products. This work product is known as the acceptance plan and it
essentially closes the loop with respect to requirements. Just as
the storyboards, use cases, and storyboards capture what the system
is supposed to do, the acceptance plan outlines the process for
validating that the system performs as it was required to do. So if
everything else was a requirement, this one is a verification and
validation step as to whether the requirements were implemented
correctly and were the right things to implement.
An acceptance plan is also a contract closure document because
it commits the customer to a deterministic way of figuring out
acceptance. In other words, the idea is not to give the customer
too much wiggle room with respect to requirements. It makes the
customer agree to saying that, when the system is finished, I will
validate that the requirements are met in this manner. With respect
to the acceptance plan, it is made jointly with the customer,
because when customers are asked how they will test the system,
they will be more precise in giving the requirements in the first
place and this is meant to be a collective effort, not an
adversarial effort. Typically in these acceptance plans, there is a
time-to-fix clause, so there is some wiggle room in the sense that
the customer might say you think you passed this test and I agree
that from your perspective, you did, but I really meant this
slightly differently and it doesnt seem much different from what
you thought it was, so could you fix it? Or it could be a test that
you genuinely missed because you missed some situation where your
software would fail. So typically an acceptance plan will include a
time-to-fix clause, for example, we will fix any bugs that are
reported within thirty days.
An acceptance plan is less important for an internal project
because, after all, its within the same company, so you might know
someone who can fix it.
One quick thing, I dont know how many of you have ever bought a
house or built a new house especially, there is usually a
walkthrough at the end, just before you close, where you walk
around with a checklist. The idea is that if you find anything
wrong, the builder will fix it for you. Thats essentially what an
acceptance plan is.23Example Acceptance PlanAll functional
requirements in the released system must pass acceptance
testingPerformance:Based on studies of user attention span
synchronous tasks must respond within 5s in system steady stateTest
with:5 concurrent users10000 cases in
databaseUsability:Prototypical LawFirm users must be able to learn
to use the system within 10 daysTest with Joe, Sarah, Barack and
JohnScalability:User growth rate: +20 users per year3000 new cases
per year2 new company acquisitions per yearQuestion: How will we
test these elements? Are these requirements
under-specified?10/18/2011Requirements24
Heres an example acceptance plan. I hope that, when reading
through this, that you notice one key thing. All the items here are
connected to your non-functional requirements. Typically, there is
less discussion about whether a functional requirement has been
met. So if you have a functional requirement that says a user
withdraws money from an ATM, you test the system, you put your PIN
in and the system gives you money, and it means the functional
requirement requirements pass.
So in a typical acceptance plan, the acceptance criteria are
typically not spelled out in detail, theres typically just a line
that says all functional requirements must pass acceptance testing,
or something like that. Of course, if there is a very critical
functional requirement, you might spell that out in detail, but
typically all that is said in an acceptance plan is all that was
said that it was supposed to do, it does.
But when it comes to the non-functional requirements, things
arent so simple. For example, lets say there was a performance
requirement that says the system must respond in 5 seconds. The
customer is supposed to test it; does that mean he tests it with
nobody else on the system? Does that mean he tests it with 1000
concurrent users on the system? With no cases in the database? With
a million?
This quantification that I talked about that needs to take place
on the non-functional requirements, a further quantification has to
take place for the acceptance plan because a deterministic test
must result from this process that a customer can explicitly do.
The passing or the failing of that test should be clear, which
constitutes a failure of the acceptance test.
You will see that in each of these cases, performance,
usability, and scalability, we have taken the NFR and further
refined it to make it deterministic and make sure that it is clear
how to perform the test. So take a look at this. With respect to
performance, we say five concurrent users and ten thousand cases in
the database. With usability, we say to test with these four
people. Now my question for you is to think about how, for
scalability, you could take the NFR and create deterministic tests
tests that you can actually do to pass or fail the acceptance
test.24Agile Processes and RequirementsLive users (serve as tacit
holders of requirements)User storiesSystem testsAny work-product
from a structured process, but developed in an agile wayE.g.
Whiteboard sketches10/18/2011Requirements25Reference: Beck, K.
Extreme Programming eXplained: Embrace Change. Safari.
When it comes to agile requirements capture, here are the work
products. The first work product is the customer himself. The
customers in agile requirements gathering is a first-class work
product because the thinking is that the customers are the true
repositories of the requirements. However, there are some documents
that are created to capture requirements work products. The first
such work product is a user story. Youll see examples of user
stories in the subsequent slide. The user story is used to capture
both functional and non-functional requirements. I hope you still
remember what non-functional requirements are! The accepted format
for capturing a user story is show here: As I want so that . Youll
see an example of that in the next slide.
The third work product with respect to requirements capture in
agile processes is the system test itself. This is a very novel and
unique concept in agile processes. That is, the system test is both
a validation of the system but its also a specification for the
system. The thinking is that, if you can write a test for a piece
of functionality correctly, then you probably have a very good
understanding of what the functionality is supposed to be.
Therefore, the test can serve as a requirement.
Finally, agile processes are very welcoming, in terms of
accepting work products, so if you feel that there is a work
product that you feel does make sense in an agile process, the
agile advocates say go ahead and use it. So pretty much any work
product from a structured process can be an agile work product, but
the intent is to develop it in an agile way, so you dont spend time
documenting and using a tool and printing pretty documents, you
might just draw it on the whiteboard and photograph it.
When it comes to capturing requirements using agile processes,
the tradeoff is between less documentation for more shared, tacit
knowledge, whereas with structured processes, youre putting more
into documentation and trusting less on the shared knowledge of the
people on the team. So the basic principle behind agile processes
is to capture just enough requirements and document them and trust
in the shared knowledge of the people working on the team to know
what the complete requirement is.25Partnership for PerformanceUse
Case Sketch
Here is an example of a Use Case Diagram drawn informally on a
whiteboard and then photographed.26What have we
learned?10/18/2011Requirements27
Finally, we revisit the learning outcomes to go over how we
covered them.Be familiar with the concept of requirements. We
covered this by explaining what requirements are, and that
requirements represent the perspectives of multiple stakeholders.Be
familiar with the techniques for requirements identification and
capture. For this learning outcome we briefly described several
requirements identification techniques.Be familiar with
requirements work-products. Finally, we described and gave examples
of work-products in which to capture requirements. Here we noted
that, in agile processes, certain concerns of requirements may be
tacitly captured, or by using informal work-products, such as
sketches.
27ReferencesDeveloping Object-Oriented Software An
Experience-Based Approach (online):Chapters 9 on Requirements
REQUIRED
10/18/2011Requirements28
Here are the reading assignment for this lecture:Developing
Object-Oriented Software An Experience-Based Approach: Chapters 9
on Requirements. This reading is REQUIREDEthnographic study of IT
use in a home. This needs to be read for the project.
28Thank you!10/18/2011Requirements29nullBlues5929.811