chapter learning goals - enterprise labzajud/swe_1/07=cspec.pdf · chapter learning goals •...
TRANSCRIPT
Martin Jud NDS-I SWE I 1
Chapter Learning Goals
• Distinguish
– C- (Customer) requirements
– 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.
Requirements
Martin Jud NDS-I SWE I 2
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
Requirements
Martin Jud NDS-I SWE I 3
Lastenheft vs. Pflichtenheft
Aus der Vorlesung Informationstechnik von Berend Denkena u. Kirsten Tracht am ifw der Uni Hannover
Requirements
Martin Jud NDS-I SWE I 4
Das Lastenheft
Aus der Vorlesung Informationstechnik von Berend Denkena u. Kirsten Tracht am ifw der Uni Hannover
Requirements
Martin Jud NDS-I SWE I 5
Das Pflichtenheft
Aus der Vorlesung Informationstechnik von Berend Denkena u. Kirsten Tracht am ifw der Uni Hannover
Requirements
Martin Jud NDS-I SWE I 6
C- vs. D-Requirements
• Customer-oriented requirements (C-requirements), arepredominantly concerned with thequestion: What character istics, from a customer ’s or user ’s point of view, must a productexhibit to meet those needs? -> base to write D-requierements
• Developer-oriented software requirements (D-requirements), arepredominantlyconcerned with thequestion: What character istics, from a software developer ’s point of view, must a productexhibit to meet those needs?-> base for design and implementation.
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
Requirements
Martin Jud NDS-I SWE I 7
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
Requirements
Martin Jud NDS-I SWE I 8
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. Supporting information
Customer-Requirements
DetailedRequirements
Requirements
Martin Jud NDS-I SWE I 9
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.
Requirements
Martin Jud NDS-I SWE I 10
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
C-Requirements
Martin Jud NDS-I SWE I 11
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. Supporting information-- see chapter four --
Adapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
C-Requirements
Martin Jud NDS-I SWE I 12
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
C-Requirements
Martin Jud NDS-I SWE I 13
Requirements with Story Cards (XP)
Card # ���
� � ������ ��������������������������������� �������������������������
�� ����������������������� �������������������������������������
Priority � ��� Risk ��� Estimate � ��
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
C-Requirements
Martin Jud NDS-I SWE I 14
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
C-Requirements
Martin Jud NDS-I SWE I 15
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
• User’s psychological characteristics – Attitude towards job – Motivation – Cognitive style
( verbal vs. spatial; analytic vs. intuitive; concrete vs. abstract)
• User’s physical characteristicsAge– GenderAdapted from Software Engineering: An Object-Oriented Perspectiveby Eric J. Braude (Wiley 2001), with permission.
C-Requirements
Martin Jud NDS-I SWE I 16
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.
C-Requirements
Martin Jud NDS-I SWE I 17
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
C-Requirements
Martin Jud NDS-I SWE I 18
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
C-Requirements
Martin Jud NDS-I SWE I 19
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
C-Requirements
Martin Jud NDS-I SWE I 20
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
C-Requirements: UseCases
Martin Jud NDS-I SWE I 21
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
C-Requirements: Modelle
Martin Jud NDS-I SWE I 22
Why do we model visually ?
• Graphics reveal data
Edward TufteThe Visual Display of Quantitative Information, 1983
• Ein Bild sagt mehr als tausend Worte
Volksmund
C-Requirements: Modelle
Martin Jud NDS-I SWE I 23
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)
C-Requirements: Modelle
Martin Jud NDS-I SWE I 24
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
C-Requirements: Modelle
Martin Jud NDS-I SWE I 25
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
C-Requirements: Modelle
Martin Jud NDS-I SWE I 26
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
C-Requirements: Modelle
Martin Jud NDS-I SWE I 27
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
C-Requirements: Modelle
Martin Jud NDS-I SWE I 28
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
C-Requirements: Modelle
Martin Jud NDS-I SWE I 29
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.
C-Requirements
Martin Jud NDS-I SWE I 30
(… 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.
C-Requirements
Martin Jud NDS-I SWE I 31
Prototype
An early production of a runable modelof the future product.
a) An application that illustrates or demonstratessome aspetc(s) of an applicationthat 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 incrementallyto a full product.
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
C-Requirements: Prototypes
Martin Jud NDS-I SWE I 32
Horizontal vs. Vertical Prototype
User Interface
Application
LAN Database
System software
Vertical Prototype
HorizontalPrototype
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
C-Requirements: Prototypes
Martin Jud NDS-I SWE I 33
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.
C-Requirements: Prototypes
Martin Jud NDS-I SWE I 34
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
C-Requirements: Prototypes
Martin Jud NDS-I SWE I 35
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.
Requirements:
Martin Jud NDS-I SWE I 36
17-May 31-May 13-Jun 27-Jun 11-Jul 25-Jul 11-Aug 25-Aug 8-SepMilestones Complete release 0.1 X
Complete release 0.2 X
Develop release 0.1
C-requirementsD-requirements
ArchitectureDetailed designImplementation
Test
Develop release 0.2
C-requirementsD-requirements
ArchitectureDetailed designImplementation
Unit testIntegration
System test
Typical Schedule After C-requirements
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern