CS 179

1
CS 179 A Brief Review of Requirements
Engineering Dr Eamonn Keogh Computer Science
Engineering DepartmentUniversity of California -
RiversideRiverside,CA 92521eamonn_at_cs.ucr.edu
2

• Requirements Engineering
• Definition Establishing what the customer
  requires from a software system.

A process in which what is to be done is
elicited, modeled and communicated. This process
has to deal with different viewpoints, and it
uses a combination of methods, tools and actors.
The product of this process is a model, from
which a document, usually a requirements
definition is produced 1. 1 Leite, J.C.S.P,
Freeman, P. A. Requirements Validation Through
Viewpoint Resolution IEEE Transactions on
Software Engineering Vol. 17, N. 1, pp 1253 --
1269, (1991). Extreme Requirements (XR) 13
3
Horror Stories I
Adapted from Dr Michael Blacks Course Notes, used
with permission

• The Standish Group describes 3 categories of
  projects.
• Success (16.2)
• Delivered fully functional and on time
• Challenged (52.7)
• Deliver less than full functionality,
  over-budget, late
• Impaired (31.1)
• Canceled during development

4
Horror Stories II
Adapted from Dr Michael Blacks Course Notes, used
with permission
28 of projects exhibit cost overruns of 150 or
more The same 28 pf projects exhibit time
reruns of 200 or more Many projects start
with the wrong goals and need to restart (94 of
projects need to restart).
5
Horror Stories III
Where the money goes. Most money is spent on
testing and maintaining systems. 85 of the
errors are made at the requirements analysis
phase. Consider software costs by development
phase Requirements 3 Design 8 Programming
7 Testing 15 Maintenance 67 85 of the
errors are in the requirements phase, yet only 3
of the time/money is spent there!!
6

• Why is Requirements Engineering Important?
• It helps earlier detection of mistakes, which
  will be much more costly to correct if discovered
  later.
• It forces clients to articulate and review
  requirements and supports agreement among
  developers and customers.
• It records and refines requirements, helps
  understanding of design rationales, enhances
  communications.
• It serves as a standard against which to test
  design and implementation for correctness and
  completeness.
• It supports project management, e.g. resource
  estimation (cost, personnel, skill, equipment,
  ..).
• It boosts confidence among developers.

7

• Requirements Engineering consists of
• (These parts can be named or structured
  differently by different approaches)
• Requirements definition (This should be a more
  complete version of the proposal you handed in)
• A statement in natural language plus (optionally)
  diagrams of the services the system provides and
  its operational constraints.
• Requirements elicitation
• The process by which you find out what the
  customer really wants.
• Requirements specification
• A structured document setting out detailed
  descriptions of the system services. Written as a
  contract between client and contractor. (You are
  required to have me sign this before doing any
  coding or design).

8

• Requirements definition (This should be a more
  complete version of the proposal you handed in)
• A statement in natural language plus diagrams of
  the services the system provides and its
  operational constraints.
• This document should be as implementation
  independent as possible.
• A useful idea is to have some user scenarios.
  These are examples of how people interact with
  the system.
• Tom, a 22 year old computer whiz, wants to find
  out using a slow connection
• Sue, a 85 year old., from a local library with
  a fast

9

• Requirements elicitation
• The process by which you find out what the
  customer really wants. (Stakeholder analysis,
  Interviewing, Study similar companies,
  Observation, Task demonstration, Document
  studies, Questionnaires, Brainstorming, Focus
  groups, Domain workshops, Design workshops,
  Pilot experiments, Ask suppliers, Negotiation,
  Risk analysis, Cost/benefit analysis, Goal-domain
  analysis, Domain-requirements analysis).
• You need to come up with a plan to do the
  Requirements elicitation, and then document every
  step of the plan. At an absolute minimum...
• We decided to do Interviewing and Study
  similar we did a practice interview run with
  one member of our group posing as the client
  we researched the domain bywe came up with a
  list of questions to ask the client we came up
  with 10 scenarios to discuss with the client
  after the interview we recorded the following
  notes we summarized the notes here we sent a
  copy of the notes to the client on this date and
  invited him to comment on themwe..
• The above should be in a neat, organized document
  (I suspect that it will require at least 6
  pages.)

10

• Requirements specification I
• A structured document setting out detailed
  descriptions of the system services. Written as a
  contract between client and contractor. You are
  required to have me sign this before doing any
  coding or design.
• A requirements specification must be
• Correct
• Complete
• Unambiguous
• Verifiable
• Traceable
• Design Independent
• Comprehensible
• Modifiable
• Consistent, Concise, Organized.
• I can imagine this being well done in anything
  less than 8 pages.

It is NOT a design document!! As far as possible,
it should set out WHAT the system should do
rather than HOW it should do it.
11

• Requirements specification II

• Specify external system behavior.
• Specify implementation constraints.
• Serve as reference tool for maintenance.
• Record forethought about the life cycle of the
  system i.e. predict changes.
• Characterize responses to unexpected events.

12

• Requirements specification III
• One possible model
• Introduction
• Describe need for the system and how it fits
  with business objectives
• Glossary
• Define technical terms used
• System models
• Define models showing system components and
  relationships
• Functional requirements definition
• Describe the services to be provided
• Non-functional requirements definition
• Define constraints on the system and the
  development process
• System evolution
• Define fundamental assumptions on which the
  system is based and anticipated changes
• Requirements specification
• Detailed specification of functional
  requirements
• Appendices

13
What to do now!!

• If you have not done so, hand in your proposal
  within 24 hours
• Make an appointment for your group to meet me or
  the TA and do some requirements elicitation (in
  the next seven days). (plan your requirements
  elicitation before seeing me).
• Begin requirements specification, have a high
  quality draft in the next two weeks.

14
Links and references http//www.cs.toronto.edu/
sme/CSC2106S/03-ElicitationI.pdf http//www.cs.to
ronto.edu/sme/CSC444F/slides/L14-RequirementsAnal
ysis.pdf http//www.cs.toronto.edu/sme/CSC2106S/
index.html Goguen, J., Linde, C. (1993).
Techniques for Requirements Elicitation.
Proceedings, First IEEE International Symposium
on Requirements Engineering (RE'93) San Diego,
California, USA, pp. 152-164. IEEE Computer
Society Press.