Upload
dinhmien
View
223
Download
0
Embed Size (px)
Citation preview
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)
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 2
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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)
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 4
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
Lastenheft vs. Pflichtenheft
Aus der Vorlesung Informationstechnik von Berend Denkenau. Kirsten Tracht am ifw der Uni Hannover
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 5
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
Das Lastenheft
Aus der Vorlesung Informationstechnik von Berend Denkenau. Kirsten Tracht am ifw der Uni Hannover
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 6
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
Das Pflichtenheft
Aus der Vorlesung Informationstechnik von Berend Denkenau. Kirsten Tracht am ifw der Uni Hannover
Martin Jud IntroductionSoftware-Engineering - Requirements Analysis I 7
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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.
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
Martin Jud IntroductionSoftware-Engineering - Requirements Analysis I 8
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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:
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 9
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
C-Requirements vs. D-Requirements
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
SRS (IEEE)
1. Introduction
2. Overall descr iption
3. Specific requirements
4. Suppor ting information
Customer-Requirements
DetailedRequirements
Martin Jud IntroductionSoftware-Engineering - Requirements Analysis I 10
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 11
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
Road Map for C-Requirements
Adapted from Software Engineering: An Object-Oriented Perspectiveby 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. 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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 12
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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 --
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 13
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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 � ��
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 15
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
Sources of Requirements
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 16
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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; …)
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 17
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 18
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 19
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
© 1999 by Addison Wesley USDP Jacobson Booch, Rumbaugh
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 20
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
© 1999 by Addison Wesley USDP Jacobson Booch, Rumbaugh
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 21
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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.
© 1999 by Addison Wesley USDP Jacobson Booch, Rumbaugh
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 22
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 23
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
Why do we model visually ?
• Graphics reveal data
Edward TufteThe Visual Display of Quantitative Information, 1983
• Ein Bild sagt mehr als tausend Worte
Volksmund
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 24
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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)
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 25
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 26
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 27
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
3a) Finding the actors
© 2002 by Scott Hawker, University of Alabama
• 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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 28
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
© 2002 by Scott Hawker, University of Alabama
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 29
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
4) Refine the Use-Case Model
© 2002 by Scott Hawker, University of Alabama
• 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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 30
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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==>
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 31
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
(… 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
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
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.
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
Martin Jud PrototypingSoftware-Engineering - Requirements Analysis I 33
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
Horizontal vs. Vertical Prototype
User Interface
Application
LAN Database
System software
Vertical Prototype
HorizontalPrototype
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 34
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
Payoff from buildingprototype ($’s saved per $ spent)
optimalexpenditureon prototype
full project
expenditure
% expenditureon prototype0% 100%
Prototype Payoff
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 35
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
Example: Estimates for E-commerce Clothing Application
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
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
Martin Jud 06.04.2004 Software-Engineering - Requirements Analysis I 36
���������������������������������� ���� ���� ���� ���� ���� ���� ���� ����������
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
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.