CSE 4312 Software Engineering Requirements - PowerPoint PPT Presentation

Loading...

PPT – CSE 4312 Software Engineering Requirements PowerPoint presentation | free to view - id: 81dd2a-N2UyM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

CSE 4312 Software Engineering Requirements

Description:

Title: ITEC 4040 Requirements Management Last modified by: atkinson Document presentation format: On-screen Show Other titles: Times New Roman Comic Sans MS Arial ... – PowerPoint PPT presentation

Number of Views:135
Avg rating:3.0/5.0
Slides: 68
Provided by: yor135
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: CSE 4312 Software Engineering Requirements


1
CSE 4312 Software 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 Design by
    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 4312 Software 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
About PowerShow.com