CSE 4312 Software Engineering Requirements

1
CSE 4312Software Engineering Requirements

• Instructor Antonio Oliveira
• oliveira_at_cs.yorku.ca
• Classes Tuesdays and Thursdays
• Time 400 530 PM
• Room CB 129

2
Textbook

• Requirements Engineering - Processes and
  Techniques
• Gerald Kotonya and Ian Sommerville
• Publication info Chichester New York J.
  Wiley Sons, c1998. ISBN 0471972088

3

• Classes Tuesdays and Thursdays
• Time 400 530 PM
• Room CB 129
• Mid-term Exam November 3rd
• Final Exam To be determined

4
Scoring

• Assignments 10 points each (2)
• Mid-term exam 35 points
• Final exam 45 points

5
Assignments Policy

• Due dates To be specified
• Late Assignments Late assignments will face a 15
  penalty for each day after due day. Hence, one
  day later means 85 is your maximum, 2 days means
  70 is your maximum and so on. Saturday and
  Sunday count also.
• Assignments later than 3 days will not be
  accepted and they will receive a mark of zero.
• Missed assignments No reason graded with 0
• With reason transferred to
• final exam value

6
Directions

• email oliveira_at_cs.yorku.ca
• office TEL Building 3053
• Office Hours Wednesdays and Thursdays
• 1100 A.M. Noon

7
The Course at a Glance

• Introduction
• Elicitation
• Modelling
• Analysis
• Management

8
Requirement (Macmillan English Dictionary)

• something that is needed in order for something
  to happen
• Check the cars fuel requirements.
• Good insulation can cut the energy requirements
  of a house by more than half.
• 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.

9
System 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.
System (Macmillan English Dictionary)

• 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 capitals inadequate public transportation
  system

10
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

11
Software Crises

• Flaws in the Production Process

12
Europe

• Questionnaire sent to 3.805 companies showed
• For the Analysts Major problems are
• Requirements specification (53)
• Requirements Management (43)
• Documentation (36)
• Test (35)

13
USA

• Requirements Management is seen as one of the
  most important problems to be overcome in order
  for companies to achieve level 2 in the SEIs CMM
  (Capability Maturity Model)
• SEI has recently released a package aiming to
  transfer technology in RE to facilitate
  companies certification

14
Good News
15
Bad News
16
Schachs Summary
17
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

18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
Definition

• 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. This
  Year will have the 11th edition of this congress.
  
• 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.

26
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.

27
Goals

• Understand the needs and support the clients
  desires.
• Provide the Software Engineer with methods,
  techniques and tools to help on the process of
  understanding and registering what a software
  must do.

28
Fred Brooks

• 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.

29
Brief History

• Requriements Engineering as a discipline 1993
• RE (93, 95, 97, 99. 01)
• ICRE (94, 96, 98, 00)
• WER (98, 99, 00, 01)
• Requirements Engineering Journal
• Past System Analysis
• Today A network of processes
• Pressure from the market for quality(CMM e ISO)
• Books (Sommerville, Jackson, Loucopoulos, )
• Tools (Doors, Requisite-Pro, Caliber-RM)

30
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

31
More Books

• Exploring Requirements Quality Before Designby
  Donald C. Gause and Gerald M. Weinberg (September
  1989) Dorset House ISBN 0932633137 Amazon.com
  Sales Rank 13,641 (disponível em Português)
• 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 Addison-Wesley 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

32
Links for Information on RE

• http//www.er.les.inf.puc-rio.br
• http//www.scielo.br/scielo.php?scriptsci_abstrac
  tpidS0104-65001999000200003lngennrmiso
• http//www.telelogic.com/products/doorsers
• http//www.starbase.com/
• http//www.rational.com/products/reqpro/index.jtmp
  l
• http//www.cs.ucl.ac.uk/research/renoir/
• http//www.shu.ac.uk/tfre/
• http//www.re01.org http//www.re02.org
• http//link.springer.de/link/service/journals/0076
  6/index.htm

33
Market

• Starbase
• http//www.tbi.com/caliberrm30/index.cfm
• Telelogic
• http//www.er.les.inf.puc-rio.br/doors.htm
• Rational
• http//www.rational.com/products/reqpro/index.jsp
• EDS
• http//www.eds.com/products/plm/teamcenter/slate/
• Igatech systems
• http//www.igatech.com/rdt/index.html

34
CSE 4312Software Engineering Requirements

• Antonio de Padua Albuquerque Oliveira
• Luiz Marcio Cysneiros
• Fall 2005

35
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

36
Process improvement

• Process improvement is concerned with modifying
  processes in order to meet some improvement
  objectives
• Improvement objectives
• Quality improvement
• Schedule reduction
• Resource reduction

37
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?

38
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

39
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 SEIs Capability Maturity Model is a
  framework for assessing software process maturity
  in development organizations

40
Capability maturity model
41
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.

42
RE process maturity model
43
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.

44
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

45
Software Development System
Establish goals
Manage the SDS
MANAGEMENT
Produce software
Build a team
Create systems
PEOPLE
give feedback
Support creative work
METHODS
Implement policies
Keep the state of the art
organize systems
INFORMATION
support methods
process information
TOOLS
Guarantee policies are followed
reuse information
Measure the process
record software
46
Most Common Scenario

• Structured Analisys
• Essential Analysis
• Entity-Relationship Model
• Structured Project
• Objects
• CASE
• Automatic Genaration of Applications

47
Abstraction X Formalism
Abstract
Very High Level
Ideal
Conventional
Concrete/Abstract
High Level
Low Level
MachineLevel
Concrete
Talk Specification
Code
Informal Linguistic Level Formal
48
Why Requirements Engineering?

• Von Neumann
• There is no sense in being precise when you
  dont even know what you are talking about

49
Problems

• Management Support
• Availability of Processes
• Integration of Platforms
• Education vs Ignorance
• Cost

50
The Context of RE

• Information System
• Engineering Systems
• Organizations Producing Software
• Models

51
Context

• The Blank Page Illusion
• The Completeness Illusion
• Social Aspects Involved

52
So, What is a Requirements?
Clients
Users
Needs
Limitations
Impossibilities
Technological Infra-Structure
53
Definitions

• Software Requirements
• Sentences that express clients needs and
  establish the desired quality
• Functional Requirements
• FR are the requirements that are directly related
  to the software functionality.
• What the system must do !

54
Definitions

• 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
• Requirements-1 (Inverse Requirements)
• IR establish conditions that must never happen
• Frequently associated to an NFR

55
Requirements Sentences
formula The system must verb object agent
complement conditions.

• example
• The system must prepare the customers invoices,
  10 days before the expiration.

56
Requirements Sentences
verb express functionality, non-functionality,
reverse
formula The system must verb object agent
complement conditions.
contextualize

• example
• The system must prepare the customers invoices,
  10 days before the expiration.

57
After all, What is a Requirement?
Clients
FR
Users
Needs
Limitations
Impossibilities
NFR
NFR
IR
Technological Infra-Structure
58
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

59
Examples

• The system should provide a form to enter results
  for clinical tests performed for a client (RF)
• 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)

60
Ecologic Aspects
61
Definitions

• Universe of Discourse
• Is the context in which the software should be
  developed and operated. UofD includes all the
  sources of information and all the 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

62
Information Systems
Universe of Information
Macrosystem
Software System
63
organization
hardware
Information System
software
64
Where We Are
65
Definitions

• Requirements Engineering establish the process
  of requirements definition as a process during
  which what has to be done has to be elicited
  modelled and analyzed. This process must deal
  with different viewpoints and use a combination
  of methods, tools and personnel. The product of
  this process is a model from which a document
  called requirements is produced. This process is
  continual and happens in a context previously
  defined to which we call Universe of Discourse

66
An SADT Model for the Definition of Requirements
UofD
Soft. Eng. Viewpoints
Select Personel
clients
method
UofD
Elicit
facts
requirements
Model
model
UofD
Analyse
Select Method
tools
67
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