Requirements Analysis (I)

(1)

Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 1

Requirements Analysis (

I

)

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Plan project

Integrate & test system

Analyze requirements Design Maintain Test units Implement Identify corporate practices

Obtain customer’s wants and needs (C-requirements) Express C-requirements prose use cases state diagrams data-flow diagrams Refine requirements (next chapter)

Chapter Learning Goals

• Distinguish

– C- (Customer) requirements from

– D- (Detailed) requirements

• Be equipped with ways to express C-requirements

– exploit use cases

– exploit state diagrams

– exploit data flow diagrams

– sketch user interfaces

• Be able to write first parts of a SRS

(Software Requirements Specification)

(2)

Martin Jud IntroductionSoftware-Engineering - Requirements Analysis I 3

Requirement Types

Needs Features System-Requirements Lastenheft Software Specification Pflichtenheft Problem Space Solution Space C-Requirements D-Requirements

Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern

Lastenheft vs. Pflichtenheft

(3)

Das Lastenheft

Aus der Vorlesung Informationstechnik von Berend Denkena u. Kirsten Tracht am ifw der Uni Hannover

Das Pflichtenheft

(4)

C- vs. D-Requirements

• Customer-oriented requirements (C-requirements),

are predominantly concerned with the question:

What characteristics, from a customer’s or user’s point of

view, must a product exhibit to meet those needs?

-> base to write D-requierements

• Developer-oriented software requirements (D-requirements),

are predominantly concerned with the question:

What characteristics, from a software developer’s point of

view, must a product exhibit to meet those needs?

-> base for design and implementation.

C- vs. D-Requirements - Beispiel

Zeit/Datum Art Aktion C-Requirement (Feature):

#1: Eine Lichtquelle kann zeitgesteuert ein-/ausgeschaltet werden.

D-Requirement (Software Specification):

Timer.

#T1: Ein Timer ist frei programmierbar. Für jedes Zeitereignis kann eine Aktion definiert werden.

#T2: Einmale Zeitereignisse: Datum/Uhrzeit - Auflösung Minuten. #T3: Zyklische Ereignisse: minütlich, stündlich, täglich, Wochentag. #T4: Mögliche Aktionen: Lichtquelle ein/aus.

#T5: Protokoll, welches Timer bei Ereignis-Eintritt aussendet:

(5)

C-Requirements vs. D-Requirements

SRS (IEEE)

1. Introduction

2. Overall

description

3. Specific

requirements

4. Supporting

information

Customer-Requirements

Detailed

Requirements

Each requirement must be …

• expressed properly,

• made easily accessible,

• numbered,

• accompanied by tests that verify it,

• provided for in the design,

• tested in isolation,

• tested in concert with others,

• validated

(6)

Road Map for C-Requirements

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 1. Identify “the customer” -- see section 2.2

2. Interview customer representatives

• identify wants and needs

• exploit tools for expression (section 3.1 - 3.4)

• sketch GUI’s (section 3.5)

• identify hardware

3. Write C-requirements

in standard document form (see case study)

4. Inspect C-requirements

5. Build D-requirements

(next chapter)

On customer approval ...

Review with customer

IEEE 830-1993 SRS Table of Contents

1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations 1.4. References 1.5. Overview 2. Overall description 2.1. Product perspective 2.1.1. System interfaces 2.1.2. User interfaces 2.1.3. Hardware interfaces 2.1.4. Software interfaces 2.1.5. Communications interfaces 2.1.6. Memory constraints 2.1.7. Operations 2.1.8. Site adaptation requirements 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5. Assumptions and dependencies 2.6. Apportioning of requirements 3. Specific requirements

see chapter four

--4. Supporting information

see chapter four

(7)

Zum Vergleich: Gliederung eines Lastenhefts

1 Zielbestimmung

zu erreichende Ziele durch den Produkteinsatz

2 Produkteinsatz

Anwendungsbereiche und Zielgruppen

3 Produktfunktionen

Hauptfunktionen aus Auftraggebersicht

4 Produktdaten

zu speichernder Daten, E/A Schnittstellen

5 Produktleistungen

Anforderungen, bez. Zeit, Daten, Genauigkeit

6 Qualitätsanforderungen

Zuverlässigkeit, Bedienbarkeit

7 Ergänzungen

z.B. Rahmenbedingungen

Martin Jud Technical MethodsSoftware-Engineering - Requirements Analysis I 14

Requirements with Story Cards (XP)

Card #

Priority

Risk

Estimate

(8)

Sources of Requirements

unconstrained Relatively high Relatively low Type of application highly constrained Approximate % of requirements gathered from people missile guidance system

flight control system for airliner

enhancement to corporate accounting system manufacturing control system

corporate accounting system Encounter video game

decision support system for military tactics

Know Your Users

• Level of knowledge and

experience

– computer literacy – system experience – experience with similar

applications

– education / reading level • Characteristics of the

user’s tasks and jobs – Frequency of use

– Turnover rate for employees – Importance of task

– Repetitiveness of task – Training anticipated

• Psychological characteristics

of the user

– Attitude towards job – Motivation – Cognitive style ( verbal vs. spatial; analytic vs. intuitive; concrete vs. abstract) • Physical characteristics of the user – Age – Gender – Physical handicaps (color-blind; deaf; …)

(9)

Before interview:

1. List and prioritize “customer” interviewees – most likely to determine project’s success 2. Schedule interview with fixed start and end times

– at least two from development team should attend – prepare to tape?

At interview:

3. Concentrate on listening

Don’t be passive: probe and encourage

– persist in understanding wants and exploring needs – walk through use cases, also data flow? state diagrams? Take thorough notes

4. Schedule follow-up meeting After interview:

5. Draft SRS C-requirements using a standard 6. E-mail customer for comments

Handle Interviews

Requirements nach USDP

Der USDP versteht unter Requirements folgendes:

Zusätzlicher Input für SRS Nichtfunktionale Anforderungen aufnehmen UseCase-Modell Funktionale Anforderungen aufnehmen Geschäftsmodell

(Domain / Business Model) Systemkontext erfassen

Feature List Anforderungen aufzählen

Resultat Tätigkeit

(10)

USDP Domain Model

– Zweck

Die wichtigsten Klassen im Kontext der Aufgabenstellung verstehen und dokumentieren

– Nutzen

Die im DomainModel dokumentierten Klassen dienen • zum Beschreiben der UseCases

• zum Entwerfen der Benutzerschnittstelle • als Anstoss für die Analyse

– Hinweis

Bei einfachen Systemen genügt ein Glossary

USDP Business Model

• Zweck

Die wichtigsten Business-UseCases der Organisation im Kontext der Aufgabe verstehen und dokumentieren

• Nutzen

Die im BusinessModel dokumentierten UseCases dienen als Ausgangspunkt für die

„eigentlichen“ UseCases

(11)

UseCase Model:

Entwicklungsstufen

• Inception

Die meisten UseCases werden in der Einstiegsphase erfasst. Die wichtigsten 10% werden auch schon ausgearbeitet.

• Elaboration

Die restlichen UseCases werden in der Ausarbeitungsphase erfasst (und bis zum Ende der Phase auch weitestgehend ausgearbeitet).

• Construction

Während der Konstruktionsphase werden die noch verbliebenen UseCases ausgearbeitet.

Why do we model ?

“Modeling captures essential parts of the system”

James Rumbaugh

• Provide structure for problem solving

• Communication

• Experiment to explore multiple solutions

• Furnish abstractions to manage complexity

• Manage the risk of mistakes

• Decrease development costs

(12)

Why do we model visually ?

• Graphics reveal data Edward Tufte

The Visual Display of Quantitative Information, 1983

• Ein Bild sagt mehr als tausend Worte Volksmund

Analyse-Modell entwickeln

Anforderungsanalyse / Business Model

1. Geschäftsprozess

(sketch business process by enterprise scope use cases)

Problembereichsanalyse / Domain Model

2. Systemdiagramm

(describe the system boundaries & identify the actors)

3. Primäre Anwendungsfälle

(sequences of actions yielding a result to an actor)

Iteration der Problembereichsanalyse

4. Vervollständigtes Anwendungsfall-Modell

(13)

1) Business Process Modeling

What needs to be identified:

• The stakeholders in the organization’s behavior

• The external primary actors whose goals you propose that the organization satisfy

• The triggering events that the organization must respond to • The services the business offers, with success outcomes for

the stakeholders

This is also the bounding information for a use case

Adapted from A. Cockburn, 2001

2) Finding actors and use cases

• Purpose

– System boundary: delimit system from environment – Outline actors and their use cases

– Capture and define common terms (glossary) • Inputs

– Stakeholders (especially customers, users, other analysts)

– Business/domain model, vision document, customer requirements specification

• Activity steps (detailed on next slides)

– Find actors – Find use cases

– Describe each use case

– Describe use case model as a whole (incl. glossary)

(14)

3a) Finding the actors

• Example actors or actor categories

– Business workers, business actors

– The person/system asking the question, making the decision – External systems

– System maintenance and operational support • Criteria

– Must be at least one real user who can enact the candidate actor – Minimum overlap between roles

• Capture

– Actor name

– What the actor uses the system for; actor needs and system responsibilities

– What the system uses the actor for; role and actor responsibilities and system needs

3b) Finding the use cases

• Examples: deliver an observable result of value to a particular actor

– Use case(s) for every role of every worker

– Use case to support user’s need to create, change, track, remove or study business objects

– Use case to allow user to tell system of event or for system to tell user of event

– Use cases for system startup, termination or maintenance

• Use case name: verb phrase describing result of interaction

• Use case scope and boundaries are hard to find

– Decouple them in time and data sharing – Iterate with architecture tasks

(15)

4) Refine the Use-Case Model

• General and shared functionality: “uses”

– Like inheritance: specific (real) uses general (abstract) – The generalization captures overlap between use cases

• Additional or optional functionality: “extends”

• Be careful in structuring use-case model

– Reflect real use cases

– Keep things understandable and manageable – Remember to make only little use of relations

between use cases

Express Customer Requirements

• If the requirement is simple, and stands alone, express it in clear sentences within an appropriate section of the SRS

• If the requirement is an interaction between the user and the application, express via a use case.

1. Name the use case

2. Identify the “actor” (the external user role-- usually a person) 3. Write the sequence of user - application actions

• If the requirement involves process elements, each taking inputs, and producing outputs, use data flow.

1. Identify the processing elements (usually high level); show as circles or rectangles

==>

(16)

(… continued)

2. Identify the data sources & destinations; show as names between two horizontal lines

3. Show the data paths among processing elements. Indicate types of data flowing on each

• If the requirement involves states that the application can be in (or parts can be in)

1. Identify the states (each a passive verb, e.g., “waiting”) show as rounded rectangles

2. Show initial state with special arrow

3. Identify the events (happenings external to the unit) that cause transitions among the states; show as labeled arrows 4. Identify sub-states; show as rectangles within rectangles

Martin Jud PrototypingSoftware-Engineering - Requirements Analysis I 32

Prototype

An early production of a runable model

of the future product.

a) An application that illustrates or demonstrates

some aspetc(s) of an application that is under

construction.

b) An application that is part of the product definition

(usually GUI).

c) A first increment of an application, that will be

developed incrementally to a full product.

(17)

Martin Jud PrototypingSoftware-Engineering - Requirements Analysis I 33

Horizontal vs. Vertical Prototype

User Interface

Application

LAN

Database

System software

Vertical Prototype

Horizontal

Prototype

Payoff from building prototype

($’s saved per $ spent)

optimal expenditure on prototype full project expenditure % expenditure on prototype 0% 100%

Prototype Payoff

(18)

Example: Estimates for E-commerce Clothing Application

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Esti- Gross Benefit Percentage Net Payoff

mated excluding of prototype cost code re-use code reused in

min max application min max average

Prototype feature B D E C D-(1-C)B E-(1-C)B

1. GUI screenshots $10,000 $10,000 $80,000 50% $5,000 $75,000 $40,000 2. Transaction $50,000 $10,000 $300,000 80% $0 $290,000 $145,000 security 3. Complete $80,000 $10,000 $400,000 50% -$30,000 $200,000 $85,000 transaction 4. Customer $120,000 $20,000 $140,000 30% -$64,000 $56,000 -$4,000 tries on clothing

Update PMP After Obtaining C-requirements

Status after initial draft

Result of updating SPMP after obtaining C-requirements

Milestones Initial More milestones; more specific

Risks Identify initial risks

Retire risks identified previously; identify more risks now that more is known about the project

Schedule Very rough Preliminary project schedule

Personnel

Designate C-requirements engineers

Designated engineers for D-requirements analysis

Cost

Estimation Very rough First estimates based on job content