http://www.yorku.ca/cysneiro/courses.htm
ITEC 4040
Requirements Management
Luiz Marcio Cysneiros
http://www.yorku.ca/cysneiro/courses.htm
1
http://www.yorku.ca/cysneiro/courses.htm
Textbook
Requirements engineering : processes and
techniques
Gerald Kotonya and Ian Sommerville.
Publication info: Chichester ; New York : J.
Wiley & Sons, c1998. ISBN: 0471972088
2
http://www.yorku.ca/cysneiro/courses.htm
Scoring
Mid-term exam
40 points
Final exam
55 points
Assignment (Optional)
5 points
If you get less than 35% in the Final Exam
you Fail the course.
3
http://www.yorku.ca/cysneiro/courses.htm
Final and Round up
• Final = Everything goes on it
• No Round up
• Ex: 49.8 = E
4
http://www.yorku.ca/cysneiro/courses.htm
Directions
email
office
cysneiro@yorku.ca
TEL Building 3051
Office Hours – Tuesday: 3:00 PM to 4:30 PM and
Wednesday 5:00 PM to 6:30 PM
5
6
7
8
9
http://www.yorku.ca/cysneiro/courses.htm
The Course at a Glance
•
•
•
•
•
Introduction
Elicitation
Modelling
Analysis
Management
10
http://www.yorku.ca/cysneiro/courses.htm
Nowadays World
• Software-Intensive Systems
• Software vs Systems ?
– Software Alone is useless
– Hardware Alone is useless
– Both only exist when used to support any
human activity
– Software+Hardware+People+activities
• Systems
• Intensive use of software systems
11
http://www.yorku.ca/cysneiro/courses.htm
Nowadays World
• Software systems present opportunities for change
– It may be complex but should also be adaptable
– Changes very quickly and some times very frequently
– A New System may change human activities in many
significant ways
•
•
•
•
•
Paperless Hospitals
Virtual Doctors
Virtual Surgeries
Phone Chat
facebook
12
http://www.yorku.ca/cysneiro/courses.htm
Nowadays World
• Software Systems became Ubiquitous
– Even Refrigerators have software systems
today
– However, we are frequently disappointed with
them
– If it doesn’t work chances are :
• Who designed didn’t understood what was needed
• It is been used for different purposes than the
original intended
13
http://www.yorku.ca/cysneiro/courses.htm
Requirement:
(Macmillan English Dictionary)
something that is needed in order for something
to happen:
1.
–
Check the car’s fuel requirements.
–
Good insulation can cut the energy requirements of a
house by more than half.
2.
something that a rule, law, contract, etc. states
that you must do:
–
Do these goods comply with our safety requirements?
–
requirement of: It is usually a requirement of banks
and investors that a new company is formed to effect
the management buy-out.
–
requirement for: Applicants must satisfy the
requirements for admission to the university.
14
http://www.yorku.ca/cysneiro/courses.htm
System: (Macmillan English Dictionary)
1.
[count] a set of connected things that work together for a particular
purpose:
–
a central heating system
–
I decided to install a security system to prevent any break-ins.
–
the city’s inadequate public transportation system
System: some part of a reality that can be observed to interact with
its environment
a set of interrelated components, or sub-systems, with a particular
purpose.
1) there are 2 components at least,
2) each of which is related (directly or indirectly) to every other
component and,
3) no sub set of which is unrelated to any other subset.
Ackoff, Russell L., (1971). Towards a System of Systems Concepts. Management
science, 17(11), 661-71.
15
http://www.yorku.ca/cysneiro/courses.htm
Req. Engineering Job ?
Denys Lasdun
– “Our job is to give the client, on time and on cost,
not what he wants, but what he never dreamed
he wanted; and when he gets it, he recognizes it
as something he wanted all the time”
16
http://www.yorku.ca/cysneiro/courses.htm
Context
• Software crises continues
– Denver Airport
• More than 50 million US $ due to errors in the
baggage control system
– London Ambulance Service
• The system was deactivated one day after its
deployment due to many errors. Most of them
related to non-functional requirements such as:
Safety, Reliability and Usability
17
http://www.yorku.ca/cysneiro/courses.htm
Software Crises
• Flaws in the Production Process
Unhappy Clients
High costs
18
http://www.yorku.ca/cysneiro/courses.htm
Europe
• Questionnaire sent to 3.805 companies
showed:
• For the Analysts, Major problems are:
–
–
–
–
Requirements specification (53%)
Requirements Management (43%)
Documentation (36%)
Test (35%)
19
Good News …
“26% of the Software projects were considered a
success.”
Standish Group, CHAOS Report, 2000
20
Bad News…
Meaning that 74% have FAILED!
Standish Group, CHAOS Report, 2000
21
http://www.yorku.ca/cysneiro/courses.htm
Tom De Marco
“56% of the errors in a software can be
traced back to the requirements phase”
• The later an error is detected the more
expensive is to fix it.
• Many errors are done during Requirements
elicitation and analysis
22
• Many errors in requirements can (and
should) be detected early in the software
development life cycle.
• Typical errors include: Use of incorrect
facts, omission, inconsistency and
ambiguity.
• Errors in requirements specification are one
of the major concerns for software industry.
23
200 x
Cost to
Repair
Analysis
Design
Code
Unit Test
Integration Maintenance
Test
Stage when the Error is found
24
http://www.yorku.ca/cysneiro/courses.htm
Definition of RE
“ Requirements engineering is a sub-area of
Software Engineering that studies the process of
defining the requirements for a software-to-be. It
is a new area started in 1993 when the 1st
International Symposium on RE was organized.
The process for defining requirements is an
interface between the desires and the needs of the
clients and a future implementation of these
requirements as a software.”
25
http://www.yorku.ca/cysneiro/courses.htm
Another Definition
• RE is:
“The development and use of technology
effective to elicit, specify and analyse
requirements from stakeholders
(clients/users) that shall be performed by a
software system.”
26
http://www.yorku.ca/cysneiro/courses.htm
Goals
• Understand the needs and support the client’s
desires.
• Provide the Software Engineer with methods,
techniques and tools to help on the process of
understanding and registering what a software
must do.
27
http://www.yorku.ca/cysneiro/courses.htm
Fred Brook’s
• Brook adds:
“The most difficult part of building a software
system is to decide, precisely, what must be
built. No other part of the work can
undermine so badly the resulting software if
not done correctly. No other part is so
difficult to fix later.”
28
http://www.yorku.ca/cysneiro/courses.htm
Factors influencing requirements
• Personality and status of stakeholders
• The personal goals of individuals within an
organization
• The degree of political influence of
stakeholders within an organization
29
http://www.yorku.ca/cysneiro/courses.htm
RE process problems
•
•
•
•
•
•
Lack of stakeholder involvement
Business needs not considered
Lack of requirements management
Lack of defined responsibilities
Stakeholder communication problems
Over-long schedules and poor quality requirements
documents
• Many confuse it with Design
• Pressure from the Market
– “It has to be ready next week”
• Clients keep adding and changing things
30
http://www.yorku.ca/cysneiro/courses.htm
Process improvement
• Process improvement is concerned with
modifying processes in order to meet some
improvement objectives
• Improvement objectives
– Quality improvement
– Schedule reduction
– Resource reduction
31
http://www.yorku.ca/cysneiro/courses.htm
Planning process improvement
• What are the problems with current
processes?
• What are the improvement goals?
• How can process improvement be
introduced to achieve these goals?
• How should process improvements be
controlled and managed?
32
http://www.yorku.ca/cysneiro/courses.htm
Process maturity
• Process maturity can be thought of as the
extent that an organization has defined its
processes, actively controls these processes
and provides systematic human and
computer-based support for them.
• The SEI’s Capability Maturity Model is a
framework for assessing software process
maturity in development organizations
33
http://www.yorku.ca/cysneiro/courses.htm
Capability maturity model
Level 5
Optimizing
Le vel 4
Managed
Level 3
Defined
Le vel 2
Repeatable
Level 1
Initial
34
http://www.yorku.ca/cysneiro/courses.htm
RE process maturity levels
• Initial level
– No defined RE process. Suffer from requirements
problems such as requirements volatility, unsatisfied
stakeholders and high rework costs. Dependent on
individual skills and experience.
• Repeatable level
– Defined standards for requirements documents and
policies and procedures for requirements
management.
• Defined level
– Defined RE process based on good practices and
techniques. Active process improvement process in
place.
35
http://www.yorku.ca/cysneiro/courses.htm
Maturity levels
• Managed level
– Detailed measurements of both process and
product quality are collected and used to
control the process.
• Optimizing level
– The organization has a continuous process
improvement strategy, based on objective
measurements in place.
36
http://www.yorku.ca/cysneiro/courses.htm
Good practice for RE process improvement
• RE processes can be improved by the
systematic introduction of good
requirements engineering practice
• Each improvement cycle identifies good
practice guidelines and works to introduce
them in an organization
37
http://www.yorku.ca/cysneiro/courses.htm
Software Development System
Establish goals
MANAGEMENT
give
feedback
Manage the SDS/SDLC
Build a team
Produce software
Create systems
PEOPLE
Support creative work
Implement policies
METHODS
Keep the state of the art
support
methods
INFORMATION
reuse
information
Guarantee policies are followed
organize
systems
process
information
TOOLS
Measure the process
record software
38
http://www.yorku.ca/cysneiro/courses.htm
Most Common Scenario
•
•
•
•
•
•
•
Structured Analisys
Structured Project
Entity-Relationship Model
Essential Analysis
Objects
CASE
Automatic Genaration of Applications
39
http://www.yorku.ca/cysneiro/courses.htm
Abstraction X Formalism
Abstract
Very
High
Level
Ideal
Concrete/Abstract
Conventional
High
Level
Low
Level
Goal
Talk
Informal
Specification
Linguistic Level
Code
Machine
Level
Concrete
Formal
40
http://www.yorku.ca/cysneiro/courses.htm
Why Requirements Engineering?
Von Neumann:
“There is no sense in being precise when you
don’t even know what you are talking
about”
41
http://www.yorku.ca/cysneiro/courses.htm
Context
• The Blank Page Fallacy
• The Completeness Fallacy
• Social Aspects Involved
42
So, What are Requirements?
Clients
Users
Needs
Limitations
Impossibilities
Technological Infra-Structure
43
http://www.yorku.ca/cysneiro/courses.htm
Definition
• Software Requirements
– Sentences that express clients’ needs and establish the desired
quality
44
http://www.yorku.ca/cysneiro/courses.htm
Types of Requirements
• Functional Requirements
– FR are the requirements that are directly related to the software functionality.
– What the system must do !
• Non-Functional Requirements
– NFRs express constraints that a software must comply with.
– Can be seen as specific qualities that a software must have
– “How” the software must do the “What”
• Ex: Safety, accuracy, usability,security
• Requirements-1 (Inverse Requirements)
– IR establish conditions that must never happen
– Frequently associated to an NFR
45
After all, What are Requirement?
Clients
FR
Users
Needs
Limitations
Impossibilities
NFR
NFR
IR
Technological Infra-Structure
46
http://www.yorku.ca/cysneiro/courses.htm
Definitions
• Requirement
– Necessary condition to achieve a certain goal, or the
fulfillment of a certain goal
• Specification
– Detailed description of the characteristic that a material,
work, or service must present
47
http://www.yorku.ca/cysneiro/courses.htm
Examples
• The system should provide a form to enter results for
clinical tests performed for a client (FR)
• Depending on the result of the test, only the Supervisor can
entry the result for this patient. E.g. Glucose over 8.0 (NFR
Safety)
• The system should give the client a receipt. This should
take no longer than 8 sec (FR “.” NFR Performance)
• The system can not erase any client information (IN)
48
http://www.yorku.ca/cysneiro/courses.htm
Definitions
• Universe of Discourse
– Is the context in which the software should be developed and
operated. UofD includes all sources of information and all
people related to the software. These people are also known as
the actors of this universe. UofD is a reality circumstantiated
by the set of goals defined by those who demand the software
49
http://www.yorku.ca/cysneiro/courses.htm
Information Systems
Universe of Discourse
Macrosystem
Software
System
50
organization
hardware
software
Information
System
51
http://www.yorku.ca/cysneiro/courses.htm
Where We Are
52
http://www.yorku.ca/cysneiro/courses.htm
The “Requirements Lifecycle”
• Not Waterfall
• Not Spiral
• Not Iterative
53
An SADT Model for the Definition of Requirements
UofD
Select
Personel
Soft. Eng. Viewpoints
clients
method
UofD
Elicit
facts
requirements
Model
model
UofD
Analyse
Select
Method
tools
Management
54
http://www.yorku.ca/cysneiro/courses.htm
55
http://www.yorku.ca/cysneiro/courses.htm
Books
•
Requirements Engineering: Processes and Techniques by Ian
Sommerville, Gerald Kotonya (September 1998)
John Wiley & Son Ltd; ISBN: 0471972088 Amazon.com Sales Rank:
188,502
•
System Requirements Engineering by Pericles Loucopoulos, Vassilios
Karakostas (June 1995)
McGraw Hill Text; ISBN: 0077078438 Amazon.com Sales Rank:
1,067,908
•
Software Requirements & Specifications : A Lexicon of Practice,
Principles and Prejudices by Michael Jackson (July 1995)
Addison-Wesley Pub Co; ISBN: 0201877120 Amazon.com Sales Rank:
38,607
56
http://www.yorku.ca/cysneiro/courses.htm
More Books
•
Exploring Requirements : Quality Before Design
by Donald C. Gause and Gerald M. Weinberg (September 1989) Dorset
House; ISBN: 0932633137 Amazon.com Sales Rank: 13,641
•
Mastering the Requirements Process by Suzanne Robertson, James
Robertson (May 4, 2000) Addison-Wesley Pub Co; ISBN: 0201360462 ;
Dimensions (in inches): 0.93 x 9.50 x 7.66 Amazon.com Sales Rank: 7,392
•
Managing Software Requirements: A Unified Approach (The AddisonWesley Object Technology Series)by Dean Leffingwell, Don Widrig
(November 1999),Addison-Wesley Pub Co; ISBN: 0201615932 Dimensions
(in Inches): 1.13 x 9.46 x 7.76 Amazon.com Sales Rank: 14,447
57
http://www.yorku.ca/cysneiro/courses.htm
Reading for next Class
• Requirements Engineering - a roadmap - Nuseibeh,
Easterbrook
• [Goguen94] - Goguen, J.A. and Linde, C. - Techiques for
Requirements Elicitation, In Proceedings of the First
IEEE International Symposium on Requirements
Engineering, San Diego, Ca, IEEE Computer Society Press
- 1994, pp 152-164.
• [Goguen94a] - Goguen, Joseph - Requirements
Engineering as the reconciliation of social and technical
issues - in Requirements Engineering: Social and
Technical Issues edited by Joseph Goguen and Marina
Jirotka - Academic Press 1994.
• Download from course page
58