CS 4312 Software Engineering Requirements

1
CS 4312 Software Engineering Requirements

• Luiz Marcio Cysneiros
• Fall 2006

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 Tuesday/Thursday
• Time 400 PM 530 PM
• Room CSB 129
• Mid-term Exam TBA
• Final Exam TBA

4
Scoring

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

5
Assignments Policy

• Due dates To be specified
• Since Assignments are in groups of no less than 3
  and no more than 4, late assignments wont be
  accepted

6
Final and Round up

• Final Everything goes on it
• No Round up
• Ex 49.8 E

7
Directions

• email cysneiro_at_yorku.ca
• office TEL Building 3051
• Office Hours Tuesday and Wednesdays and
  1100 A.M. - Noon

8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
The Course at a Glance

• Introduction
• Elicitation
• Modelling
• Analysis
• Management

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

14
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

15
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

16
Software Crises

• Flaws in the Production Process

17
Europe

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

18
USA

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

19
Good News
20
Bad News
21
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
Schachs Summary
23
(No Transcript)
24
200 x
Cost to Repair
Analysis
Design
Code
Unit Test
Integration Test
Maintenance
Stage when the Error is found
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 we had the 13th 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
• 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.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.re05.org
• http//link.springer.de/link/service/journals/0076
  6/index.htm

33
Factors influencing requirements

• Personality and status of stakeholders
• The personal goals of individuals within an
  organisation
• The degree of political influence of stakeholders
  within an organisation

34
Process improvement

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

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

36
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

37
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

38
Capability maturity model
39
RE process maturity model
40
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.

41
Maturity levels

• Managed level
• Detailed measurements of both process and product
  quality are collected and used to control the
  process.
• Optimizing level
• The organisation has a continuous process
  improvement strategy, based on objective
  measurements in place.

42
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
  organisation

43
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
44
Most Common Scenario

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

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

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

47
Problems

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

48
The Context of RE

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

49
So, What are Requirements?
Clients
Users
Needs
Limitations
Impossibilities
Technological Infra-Structure
50
Types of Requirements

• Customized Systems
• Built inside the organization (in house)
• Built by third parties
• General Products
• Production and selection
• Specific Products
• Production and selection

51
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 !

52
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

53
After all, What are Requirements?
Clients
FR
Users
Needs
Limitations
Impossibilities
NFR
NFR
IR
Technological Infra-Structure
54
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

55
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)

56
Ecologic Aspects
57
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

58
Information Systems
Universe of Information
Macrosystem
Software System
59
organization
hardware
Information System
software
60
Where We Are
61
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

62
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
63
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