ITEC 4040 Requirements Management

advertisement

ITEC 6120

System Requirements

Management

Luiz Marcio Cysneiros

Fall 2015 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

1

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.mathstat.yorku.ca/~cysneiro/courses.htm

Scoring

Oral Presentation +

Leading discussion 45%

Final exam 55% http://www.mathstat.yorku.ca/~cysneiro/courses.htm

3

email office

Directions

cysneiro@yorku.ca

TEL Building 3053

Office Hours – Tuesday: 2:30 PM to 3:45 PM

Wednesday 5:00 PM to 6:30 PM

4 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

http://www.mathstat.yorku.ca/~cysneiro/courses.htm

5

http://www.mathstat.yorku.ca/~cysneiro/courses.htm

6

http://www.mathstat.yorku.ca/~cysneiro/courses.htm

7

http://www.mathstat.yorku.ca/~cysneiro/courses.htm

8

Course Objectives

RE State-of-the-art for research and Practice

What does a RE do ?

Techniques

Methods

Process

Understanding RE

Research in RE

Existing Methods

Where it will lead us ?

Alternatives ?

9

The Course at a Glance

• Introduction

• Elicitation

• Modelling

• Analysis

• Management http://www.mathstat.yorku.ca/~cysneiro/courses.htm

10

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 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

11

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.mathstat.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.mathstat.yorku.ca/~cysneiro/courses.htm

http://www.mathstat.yorku.ca/~cysneiro/courses.htm

14

Requirement:

(Macmillan English Dictionary)

1. something that is needed in order for something to happen:

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

15 http://www.mathstat.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.

16 http://www.mathstat.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 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

17

Software Crises

• Flaws in the Production Process

Unhappy Clients High costs http://www.mathstat.yorku.ca/~cysneiro/courses.htm

18

Europe

• Questionnaire sent to 3.805 companies showed:

• For the Analysts, Major problems are:

– Requirements specification (53%)

– Requirements Management (43%)

– Documentation (36%)

– Test (35%) http://www.mathstat.yorku.ca/~cysneiro/courses.htm

19

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 SEI’s (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

20 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

Good News …

26% of the Software projects were considered a success.”

Standish Group, CHAOS Report, 2000

21 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

Bad News…

Meaning that 74% have FAILED !

Standish Group, CHAOS Report, 2000 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

22

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

23 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

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

24 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

200 x

Cost to

Repair

Analysis Design Code Unit Test Integration

Test

Maintenance

Stage when the Error is found

25 http://www.mathstat.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 1 st

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

26 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

http://www.mathstat.yorku.ca/~cysneiro/courses.htm

27

Goals

• Understand the needs and support the client’s desires.

• Provide the Requirements Engineer with methods, techniques and tools to help on the process of understanding and registering what a software must do.

28 http://www.mathstat.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.”

29 http://www.mathstat.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

30 http://www.mathstat.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

31 http://www.mathstat.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

32 http://www.mathstat.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?

33 http://www.mathstat.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

34 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

Level 1

Initial

Capability maturity model

Level 5

Optimizing

Le vel 4

Managed

Level 3

Defined

Le vel 2

Repeatable http://www.mathstat.yorku.ca/~cysneiro/courses.htm

35

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.

36 http://www.mathstat.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.

37 http://www.mathstat.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

38 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

Most Common Scenario

• Structured Analisys

• Structured Project

• Essential Analysis

• Entity-Relationship Model

• Objects

• CASE

• Automatic Genaration of Applications http://www.mathstat.yorku.ca/~cysneiro/courses.htm

39

Abstraction X Formalism

Ideal

Very

High

Level

Abstract

Conventional

Goal

Talk Specification Code

High

Level

Low

Level

Machine

Level

Concrete

Informal Linguistic Level Formal http://www.mathstat.yorku.ca/~cysneiro/courses.htm

40

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.mathstat.yorku.ca/~cysneiro/courses.htm

The Context of RE

• Information System

• Engineering Systems

• Organizations Producing Software

• Models http://www.mathstat.yorku.ca/~cysneiro/courses.htm

42

Context

The Blank Page Fallacy

The Completeness Fallacy

Social Aspects Involved http://www.mathstat.yorku.ca/~cysneiro/courses.htm

43

So, What are Requirements?

Clients

Users

Needs

Limitations

Impossibilities

Technological Infra-Structure http://www.mathstat.yorku.ca/~cysneiro/courses.htm

44

Definition

• Software Requirements

– Sentences that express clients’ needs and establish the desired quality http://www.mathstat.yorku.ca/~cysneiro/courses.htm

45

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

46 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

After all, What are Requirement?

Clients

FR

Users

Needs

Impossibilities

IR

Limitations

NFR

NFR

Technological Infra-Structure

47 http://www.mathstat.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.mathstat.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.mathstat.yorku.ca/~cysneiro/courses.htm

Information Systems

Universe of Discourse

Macrosystem

Software

System http://www.mathstat.yorku.ca/~cysneiro/courses.htm

50

organization software hardware

Information

System

51 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

http://www.mathstat.yorku.ca/~cysneiro/courses.htm

52

An SADT Model for the Definition of Requirements

UofD

UofD

Select

Personel

UofD

Select

Method

Soft. Eng. Viewpoints clients method

Elicit facts

Model requirements model

Analyse tools

53 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

The “Requirements Lifecycle”

• Not Waterfall

• Not Spiral

• Not Iterative http://www.mathstat.yorku.ca/~cysneiro/courses.htm

54

http://www.mathstat.yorku.ca/~cysneiro/courses.htm

55

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

57 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

Reading for next Class

• Requirements Engineering - a roadmap - Nuseibeh,

Easterbrook – First Presentation

[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 http://www.mathstat.yorku.ca/~cysneiro/courses.htm

Download