requirements analysis (i - skybeam · martin jud 06.04.2004 software-engineering i-requirements...

Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 1

��

Requirements Analysis (I )

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

Plan project

Integrate & test system

Analyze requirements

Design

Maintain

Test unitsImplement

Identify corporate practices

Obtain customer ’s wants and needs (C-requirements)

Express C-requirementsproseuse casesstate diagramsdata-flow diagrams

Refinerequirements

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


Martin Jud IntroductionSoftware-Engineering - Requirements Analysis I 3

��

Requirement Types

Needs

FeaturesSystem-RequirementsLastenheft

Software SpecificationPflichtenheft

Problem Space

Solution Space

C-Requirements

D-Requirements

Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern


��

Lastenheft vs. Pflichtenheft

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


��

Das Lastenheft



��

Das Pflichtenheft



��

C- vs. D-Requirements• Customer-oriented requirements (C-requirements),

arepredominantly concerned with thequestion: What character istics, from a customer ’sor user ’s point of view, must a product exhibit to meet thoseneeds? -> base to write D-requierements

• Developer-oriented software requirements (D-requirements), arepredominantly concerned with thequestion: What character istics, from a software developer ’spoint of view, must a product exhibit to meet thoseneeds?-> 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:



��

C-Requirements vs. D-Requirements


SRS (IEEE)

1. Introduction

2. Overall descr iption

3. Specific requirements

4. Suppor ting information

Customer-Requirements

DetailedRequirements


��

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



��

Road Map for C-Requirements


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. Wr ite C-requirementsin 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 Contents1. Introduction

1.1. Purpose1.2. Scope 1.3. Definitions, acronyms

& abbreviations1.4. References1.5. Overview

2. Overall descr iption2.1. Product perspective

2.1.1. System interfaces2.1.2. User interfaces2.1.3. Hardware interfaces2.1.4. Software interfaces2.1.5. Communications

interfaces

2.1.6. Memory constraints2.1.7. Operations2.1.8. Site adaptation

requirements2.2. Product functions2.3. User characteristics2.4. Constraints2.5. Assumptions and

dependencies2.6. Apportioning of

requirements3. Specific requirements -- see chapter four --4. Suppor ting information-- see chapter four --



��

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 � ��



��

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; …)



��

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 notes4. Schedule follow-up meeting

After interview:5. Draft SRS C-requirements using a standard6. E-mail customer for comments

Handle Interviews



��

Requirements nach USDP

Der USDP versteht unter Requirements folgendes:

Zusätzlicher Input für SRSNichtfunktionale Anforderungen aufnehmen

UseCase-ModellFunktionale Anforderungen aufnehmen

Geschäftsmodell(Domain / Business Model)

Systemkontext erfassen

Feature ListAnforderungen aufzählen

ResultatTätigkeit

© 1999 by Addison Wesley USDP Jacobson Booch, Rumbaugh


��

USDP Domain Model

– ZweckDie wichtigsten Klassen im Kontext der Aufgabenstellung verstehen und dokumentieren

– NutzenDie im DomainModel dokumentierten Klassen dienen

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

– HinweisBei einfachen Systemen genügt ein Glossary



��

USDP Business Model

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

• NutzenDie im BusinessModel dokumentierten UseCasesdienen als Ausgangspunkt für die „eigentlichen“ UseCases



��

UseCase Model: Entwicklungsstufen

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

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

• ConstructionWä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

© 2001 by SWEED, Martin Kropp


��

Why do we model visually ?

• Graphics reveal data

Edward TufteThe Visual Display of Quantitative Information, 1983

• Ein Bild sagt mehr als tausend Worte

Volksmund


��

Analyse-Modell entwickeln

Anforderungsanalyse / Business Model1. Geschäftsprozess

(sketch business process by enterprise scope use cases)Problembereichsanalyse / Domain Model2. Systemdiagramm

(describe the system boundaries & identify the actors)3. Primäre Anwendungsfälle

(sequences of actions yielding a result to an actor)Iteration der Problembereichsanalyse4. Vervollständigtes Anwendungsfall-Modell

(use case variations: generalisations and extensions)


��

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)

© 2002 by Scott Hawker, University of Alabama


��

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



��

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 case2. 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==>



��

(… 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

��

PrototypeAn early production of a runable modelof the future product.

a) An application that illustrates or demonstratessome aspetc(s) of an application that is underconstruction.

b) An application that is part of the product definition(usually GUI).

c) A first increment of an application, that will bedeveloped incrementally to a full product.


Martin Jud PrototypingSoftware-Engineering - Requirements Analysis I 33

��

Horizontal vs. Vertical Prototype

User Interface

Application

LAN Database

System software

Vertical Prototype

HorizontalPrototype



��

Payoff from buildingprototype ($’s saved per $ spent)

optimalexpenditureon prototype

full project

expenditure

% expenditureon prototype0% 100%

Prototype Payoff



��

Example: Estimates for E-commerce Clothing Application


Esti- Gross Benefit Percentage Net Payoffmated excluding of prototypecost code re-use code reused in

min max application min max averagePrototype 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

security3. Complete $80,000 $10,000 $400,000 50% -$30,000 $200,000 $85,000

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

draftResult of updating SPMP after

obtaining C-requirements

Milestones Initial More milestones; more specific

RisksIdentify initial risks

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

Schedule Very rough Preliminary project schedule

PersonnelDesignate C-requirements engineers

Designated engineers for D-requirements analysis

Cost Estimation

Very rough First estimates based on job content


requirements analysis (i - skybeam · martin jud 06.04.2004 software-engineering i-requirements...

Documents