PVK-05 1

Contents

IntroductionRequirements EngineeringProject ManagementSoftware DesignDetailed Design and CodingQuality AssuranceMaintenance

PVK-05 2

Requirements Engineering

What is a Requirement?

RE Activities

Requirements Documentation

RE Methods and Notations

Examples

PVK-05 3

What is a requirement?

A Requirement is something that the product must do or a quality that the product must have.Three kinds of requirements:o Functional Requirementso Non functional requirementso Constraints

PVK-05 4

1. System shall communicate with external system X.

2. The product shall run on the company’s existing Unix machines.

3. The system must have a file containing a complete list of students that is accessible only by the teacher.

4. The product should be user friendly.....

Functional

Constraint

Non Functional

Functional and non functional

.....new users should be able to add buttons within 30 minutes of their first attempt at using the product.

Examples

PVK-05 5

Acquire and identify requirementso Study the system / organisationo Study available documentso Ask users / domain experts

• Questionnaires• Interviews

Analyse and evaluate requirementso Domain analysiso Prototypingo JAD / JAW o Scenario modelling

Document requirementsReview and validate requirements

RE Activities

PVK-05 7

Describe external system behaviouro Functional requirementso User interfaceo Acceptable responses to undesired events

Describe system propertieso Non-functional requirementso Acceptance criteria

Implementation independent reference Specifies the WHAT and not the HOW Part of the contract between customer and

developer

Purpose of the Requirements Document

guide analysis

guide design

PVK-05 9

Quality factors for requirements documents

o Understandable by users and developers

o Correct

o Consistent

o Complete

Documenting Requirements is Important

oRealistic

oTestable

oTraceable

oPrioritised

PVK-05 10

Requirements Writing Style

Do not use vague terms or verbs like “some,” “obviously,” “usually,” “often,” “it follows that,” …

Make sure that uncompleted lists are understood completely (e.g. “etc.,” “and so on,”“…,” ...)

Make sure that ranges are clearly understood, e.g. what means “in the range of 1 to 100”

Ask for clear definitions of terms like “always,” “never,” “almost,” etc.

Use pictures and examples to aid in understanding

Explain all of your terminology Use “shall,” “must,” “should,” consistently

PVK-05 11

Requirements Engineering

What is a Requirement? RE ActivitiesRequirements DocumentationRE Methods and NotationsExamples

PVK-05 12

Classical Approaches to RE

Problems:o Coping with size

Structured approachStepwise refinementHierarchical organisation

o Coping with changeLogic modelMaintainable results

o Coping with documentation

Simple notationGraphical elements

Solutions:o SA (75/75)

Function-oriented

o ER (end 70s)Data-oriented

o SA/RT (85/87)Control-oriented

o Integrated approachesSA/ER/RT (end 80s)OO/RT (early/mid 90s)???

Systematic approaches to requirements analysis and definition

PVK-05 13

Structured Analysis (SA)Developed 1975/76o DeMarco/Yourdono Gane/Sarson

System = Process transforming input into outputHierarchical, logical system modelo Processeso Data flowso Data storeso Terminators

Notation:o Data flow diagrams (DFDs)o Data dictionary (DD)o Process specifications (PSpecs)

PVK-05 14

Data Flow Diagrams

Gane/Sarson DeMarco/Yourdon

Terminator:Source or destination of data/information.

Outside the system boundaries.

Data flow:Flow of data.

Process:Transforms input data flow(s)

into output data flow(s).

Data store:Data repository.

data item(s) data item(s)

PVK-05 15

DFD DevelopmentStart with a context diagramSuccessively refine processesDescribe all data in the data dictionaryDescribe all atomic processes by PspecsExample: Order processing

Customerprocessorders

order

invoice

refineCustomer

verifyif order is

valid

order

invoice

package data

customer data

credit status

available

packages

assembleand invoice

order

PVK-05 16

DFDs--Managing Complexity

structure

DFD hierarchy+ numbering/naming rules

+ balancing rules

Level n+1

Level n

Level n+2

PVK-05 17

DFDs--“Forbidden” Structures

The SA notation is not formally definedRules are defined by experiences and tool features

In-data only

Out-data only

Store-to-store flows

Terminator-to-terminator flows

Cycles

Unnamed dataflows(exception: from/to data stores)

PVK-05 18

DFD Naming and Balancing

System0

Context diagram Level 0

Terminput

output

Do X1

System Level 1

input outputDo Y

2

Do Z3

some data

other data

data

Do A.1

Do Z Level 2

data d5Do B

.2

Do C.3

d3

d2

d1a store d6

In data dictionary: some data = d5 + d6(alternatively: some data = d5 | d6)

All names must beunambiguous.

Numbering schemehelps to find processesin the hierarchy Do C: 3.3

PVK-05 19

PSpecs and DDThe format of PSpecs is not restrictedo Free texto Pseudocode

PSpecs must be defined for all atomic processes

The format of the DD is semi-formalExample:

telephone number = [ local extension | outside number ]local extension = 2 + { number }3

outside number = 0 + [ local number | long distance number ]local number = prefix + access numberlong distance number = (1) + area code + local numberprefix = [ 123 | 124 | 125 ]access number = { number }4

number = * any number between 0 and 9 *

selection (or)

optional

repetitiona comment

composition (and)

PVK-05 20

SA--SummaryAdvantageso Simple notationo Supports hierarchical decompositiono Easy to understando Good communication mediumo Supports consistency checks

Disadvantageso Not well definedo No common guidelineso Many dialectso Incomplete

• Very poor data descriptions• No description of control flows

PVK-05 21

Data Modelling

The entity-relationship (ER) model was developed by Chen (late 70s) to support data(base) modellingFocuses only on the static structure of dataNotationo Entity-relationship diagrams (ERDs)o Attribute dictionary

PVK-05 22

ERD NotationAccording to Chen + common extensions

Set of real or abstract things about which data is stored

Set relations between entities with cardinalities m and n.

Information that is stored along with entities and relationships.Composition of entities.

Classification between entity- and relationship types.

Entitytype

Attribute

Relation-ship type

m n

PVK-05 23

ERD--An ExampleTeam

MemberName Responsi-bility

n 1..3

ExternalEmployee

SWProject

DocumentsEquipment

Address

Rank h/week

Responsi-bility

m n

Attribute Dictionary

Attribute structuresTeamMember = Name, Address, Rank;Employee = ...;...

Attribute typesName = STRING;Address = STRING;...

PVK-05 24

SA/ER Integration

ProjectTeam

Data Dictionary

ProjectTeam = { TeamMember }n

TeamMember = Name + Address + Rank...

Process

DFDsTeam

MemberName Responsi-bility

n 1..3

ExternalEmployee

SWProject

Address

Rank

ERDs

PVK-05 25

ERM--SummaryAdvantageso Simple notationo Supports hierarchical and

structural decompositiono Easy to understando Good communication mediumo Well understoodo Widely usedo Good tool support

Well-suited for DB design

Disadvantageso No behaviour

descriptionso No control

descriptions

Almost useless for non-DB applications

Extensions of ERM lead to OO approaches

PVK-05 26

Use Case Diagram

Sign on for exams

Take exam Student

Secretary

Dean

Student

Administer marks

Schedule lectures Prof

PVK-05 27

Popularity of (Classical) Methods

23%

8%13%

5%

36%

15%

SA [DeMarco/ Yourdon]

SA [Gane/ Sarson]

DSSD [Warnier/ Orr]

Other "structured"methods (JSD, SADT, ...)VHLL [Martin] (no RElanguage)Inhouse method

Study from 1990, see [Yourdon 92].

PVK-05 28

ReferencesYourdon, E. (1989). Modern structured analysis. Englewood

Cliffs, N.J. : Yourdon Press.Page-Jones, M. (1988). The Practical Guide to Structured

Systems Design. Englewood Cliffs, N.J. : Yourdon Press.Kaufmann, A. (2000). Transcript for Systems Analysis Lecture.

University of Applied Sciences Giessen-FriedbergSimons, A. (2000). Use Cases Considered Harmful Dept. of

Computer Science, University of Sheffieldhttp://

www.smartdraw.com/resources/centers/software/ssadm.htmhttp://www.canberra.edu.au/~sam/whp/datadict.htmlhttp://www.software-magazin.de/Programmierung/Methoden/SA/body_sa.htmlhttp://www.sims.berkeley.edu/courses/is208/s01/Lectures/208-dataflowdgm.ppthttp://www.cis.ohio-state.edu/~bbair/516http://www.bus.iastate.edu/hndrcksn/MIS538