Embed Size (px)
Citation preview
1
TopicsTopics
• Requirements
• Business Process Modeling
• Business Concept Modeling
• System Envisioning
• Use Case Modeling
• Module Summary
• Appendix: Project Estimation
• Hands-on: Requirements Definition
2
Factors on Challenged Software ProjectFactors on Challenged Software Project
• 37% of factors related to problems with requirements, making requirements issues the largest single contributor to problems.
• Jim Johnson, “Chaos: Charging the Seas of Information Technology”, Published Report. The Standish Group, 1994]
Other50%
Poor user inputPoor user input13%13%
Incomplete requirementsIncomplete requirements12%12%
Changing requirementsChanging requirements12%12%
Poor technical skills7%
Poor staffing6%
3
RequirementsRequirements
• A requirement is a property that must be exhibited by a system developed or adapted to solve a particular problem.
• Requirements on a system are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the system must operate.
• Requirement engineering• The systematic handling of requirements.
• Software requirements are one of the products of the requirement engineering process.
4
Main Objectives of Requirements EngineeringMain Objectives of Requirements Engineering
• To discover how to partition the system• to identify which requirements should be allocated to which components.
• Good communication between system users and system developers.
5
Breakdown of Topics for Software RequirementBreakdown of Topics for Software Requirement
[“SWEBOK: Guide to the Software Engineering Body of Knowledge”, IEEE, 2001]
6
Business Process ModelingBusiness Process Modeling
• Purpose• Understand the business needs in terms of strategy, organization, process
and information.• Provide a good starting point before define user requirements.Provide a good starting point before define user requirements.
• Representation• Activity Diagram
• Input• Domain Knowledge• Business Strategy
• Output• Business Process Model (or Domain Model)
• Modeling Techniques• An important point at this stage is how you worked together with users,
business analysts, and domain experts.• Business process description is in no way a statement of the requirements an
IT system.
7
Example: Business Process ModelExample: Business Process Model
• Business Process for hotel reservation• The reservation process is initiated by an enquiry from a potential customer.
• Room availability is checked.
• If a suitable room is available, the customer makes a reservation.
• Details of the reservation are confirmed to the customer by e-mail.
• Then one of four things can happena. The customer take up his reservation.b. He might cancel.c. He might amend some details of it.
• This will require another confirmation.
d. He might no-show.• But He is going to get a bill anyway.
8
Example: Business Process Model – Cont’dExample: Business Process Model – Cont’d
• Business Process for hotel reservation
Check
availability
Make
reservation
Confirm
reservation
Wait for
event
Amend
reservation
Take up
reservation
Cancel
reservation
Process
no-show
Notify billing
system
enquiry/
[suitable
room]
[else]
amendment
request/
customer arrives/
cancel request/
no-show/
9
Requirements Definition StageRequirements Definition Stage
• Purpose• Agree on some Basic Concepts• Define the Scope of Project• Capture User Requirements
• Input• Domain(Business Process) Model• User Requirements
• Output• Business Concept Model• High level System Envisioning Statement• Use Case Model
• Activities• Business Concept Modeling• System Envisioning• Use case Modeling
Provisioning
Specification
Requirements
Assembly
RequirementDefinition
Deployment
ComponentIdentification
ComponentInteraction
ComponentSpecification
BusinessProcesses
10
Activities in Requirement DefinitionActivities in Requirement Definition
Provisioning
Specification
Requirements
Assembly
RequirementDefinition
Deployment
ComponentIdentification
ComponentInteraction
ComponentSpecification
BusinessProcesses
RequirementDefinition
Business Process Model
Business ConceptModel
Use Case Model
Business ConceptModel
Use Case Model
System Envisioning
11
Business Concept ModelingBusiness Concept Modeling
• Purpose• Introduce principal Concepts within the project scope.
• Representation• Represented by Class Diagram, But informal.
• Input• Domain Knowledge
• Business Process Model
• Output• Business Concept Model
• Modeling Techniques• Identify Business Concept.
• Define each Business Concept.
• Identify association between Business Concepts.
• Identify any obvious attributes of the Business Concepts.
12
Finding Business ConceptFinding Business Concept
• Find objects in problem statement, domain vocabulary, scenarios• Any noun (or noun-phrase)
• If you can count, see, or touch it, it is a candidate
• The memory of an event – e.g., Order
• Any object that directly participates in an action
• Consider different varieties of objects• Physical – e.g., Vehicle, Person, Equipment, Book, Location
• Process or activity – e.g., Meeting, Order, Accident
• Abstract – e.g., Organization Unit, Rule, Project
• Not too generic or specificNot too generic or specific• Select level appropriate to business.Select level appropriate to business.
Person Namkyu ChoCustomer
13
Defining Business ConceptDefining Business Concept
• Dictionary-style definition• One or two sentences
• Avoid using the concept name in its definition
• Applicable to the domain
• Add any obvious attributes
• More can be added later as they are discovered.
• Precise, but not detailed.Precise, but not detailed.
• Examples• Customer – a person or organization that rent a car from HVH company.
• Order – a set of goods that a customer wants to buy.
• Payment – a financial transaction where the customer pays for ordered goods.
14
Finding AttributesFinding Attributes
• Optional task • Ensuring that information is not forgotten.
• Only document known attributes Only document known attributes • Do not spend time searching for attributes.Do not spend time searching for attributes.
• Just name attributes • Do not define them
• Examples
Customer
number
name
deliverlyAddress
Payment
date
method
amount
15
Basic Concepts of Class DiagramBasic Concepts of Class Diagram
• TypeType is a set of objects that have some (but not necessarily all) behavior in common.
• A type is a partial description.
• Different from a class which specifies how an object does what it does.
• Corresponds to a real-world description.
Fruit
16
Basic Concepts of Class Diagram – Cont’dBasic Concepts of Class Diagram – Cont’d
• AttributeAttribute is a specific characteristic of a type which is itself of a type.
• A type typically has a set of attributes of interest.
• An instance of that type will have a set of values corresponding to the attributes.
name: Text
taste: Taste
avgNumSeeds: Number
Fruit
apple
sweet
25
17
Basic Concepts of Class Diagram – Cont’dBasic Concepts of Class Diagram – Cont’d
• AssociationAssociation is a pair of attributes that are inverses of each other, usually drawn as a line connecting two types.
• Defines type of relationship between instances of types.
name: Text
taste: Taste
avgNumSeeds: Number
Fruit
apple
sweet
25
price: Money
stock: Units
Fruit Juice
1.99
5500
18
Example: Business Concept ModelExample: Business Concept Model
• Business Concept Model for hotel reservation
Hotel Chain
Customer
Address
Payment
Hotel
Reservation
Bill
Room
Room Type
Clerk
contactAddress
contactedHotel
allocation
1
1..*
*
*
11..*
1
0..1
1 *1
0..11
*1*
1..*
1
1
1..*
19
Package Structure: Business Concept ModelPackage Structure: Business Concept Model
Requirements
Business Concept Model
Use Case Model
Specification
Business Type Model
Interface Specifications
Component Specifications
Component Architecture
Interactions
Create a business concept model under the Business Concept Model package
20
System EnvisioningSystem Envisioning
• Purpose• Describe the system’s functionalities from the point of view of its users to
identify the software boundary.
• Modeling Technique• Storyboarding.
• Example: High-level system envisioning statement for hotel reservation
호텔 체인 내의 어느 호텔이든 예약 시스템을 통해 예약 업무를 수행 할 수 있다 . 현재 각 호텔은 서로 호환되지 않는 각자의 시스템을 가지고 있으며 , 예약은 중앙의 예약 센터나 각 호텔로 전화를 통해서 하거나 인터넷을 통해서도 할 수 있다 . 새로운 시스템의 주요한 장점이라면 원하는 호텔에 객실이 없을 경우 인접한 다른 호텔의 객실을 제공할 수 있다는 점이다 . 예약을 위하여 호텔내의 접수 데스크 , 사무실 , 접객원 데스크 등의 시설이 이용된다 . 각 호텔에는 예약을 통제할 수 있는 담당자가 있지만 허가를 받았다면 누구라도 예약을 접수할 수 있다 . 전화나 사람을 통한 예약 접수는 3 분 이내에 가능해야 한다 . 이상의 업무 진행 시간을 단축시키기 위해서 이미 고객으로 등록된 정보는 저장되고 언제든지 사용 가능한 상태로 관리되어야 한다 .
21
Use Cases ModelingUse Cases Modeling
• Purpose• Identify and scope the business context of the software behavior.
• Representation• Use Case Diagram• Use Case Description
• Input• Domain Knowledge• Business Process Model
• Output• Use Case Model
• Modeling Techniques• Identify business needs.• Discover use cases and actors.• Storyboard the use cases.• Factoring out <<include>> and <<extend>> use cases.• Describe each use case.
22
Actors and RolesActors and Roles
• A coherent set of roles that users of use cases play when interacting with these use cases.
• An actor has one role for each use case with which it communicates.• “can play the role of”
• Always external to your system, not a part of your system.
• An actor defines a single role played by users in their interactions with the system:
• Multiple users can play a single role
• A single user may play multiple roles
23
Example: Actors and RolesExample: Actors and Roles
<<actor>>
BillingSystem
<<actor>>
ReservationMaker
<<actor>>
ReservationAdministrator
<<actor>>
Guest
<<actor>>
Customer
<<actor>>
Clerk
24
Identifying ActorsIdentifying Actors
• Look for things in the categories of people, other software, hardware devices, data stores, or networks…
• Who uses the system?
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• Who shuts down the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a present time?
25
Use CasesUse Cases
• The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.
• A use case should be a complete task from the actor’s perspective.
• The behavior of a single use case is often complete in a relatively short period of time.
• A use case is always started by an actor.
26
Use Case IdentificationUse Case Identification
• Look for things that actors want the system to do• What functions will the actor want from the system?
• Does the system store information? What actors will create, read, update, or delete that information?
• Does the system need to notify an actor about changes in its internal state?
• Are there any external events the system must know about? What actor informs the system about those events?
27
Use Case GranularityUse Case Granularity
• Use Cases can be big or small.
• Consider spectrum of granularity.
Stock Control Find SupplierMonitor Stock
HIGH LOW
Manage
Reservation
Make a
reservation
Cancel a
reservation
Take up a
reservation
28
Use Case Granularity – Cont’dUse Case Granularity – Cont’d
• There can be various level of granularity on use cases.
• However, in the same model, you must keep the granularity consistent • That is, it is not allowed that “(Big) Purchasing” and “(Small) Find Supplier” are
in the same use-case model.
• Then, what is the appropriate level of granularity?• In [CF98], Martin Folwer says “They used around 170 use-cases, while
another authority would have expected 25.”
• This disagreement comes from the different purposes• Some wants to manage a project with use cases.
• While others just want to draw an agreement of his customers.
• In this presentation, we will follow the view of the latter• Then, we will the notion of “system operation” in the analysis phase for the
view of the former.
29
Documenting CRUDDocumenting CRUD
• You will often need the use case which has functionality known as CRUD when your application includes maintaining data.
• There are two approaches• One is to create a separate use case for each kind of access to the data.
• The other is to create one use case for a data type that embeds all of the CRUD functions.
• In this class, we uses the first approach.• Because different actors use separate CRUD functions, so it makes more
sense to make them separate use cases.
• On the other hand, in some applications combining them may be sensible. for example, if the application is for a database administrator to update tables in a database.
30
Identify Use cases from Business ProcessIdentify Use cases from Business Process
Check
availability
Make
reservation
Confirm
reservation
Wait for
event
Amend
reservation
Take up
reservation
Cancel
reservation
Process
no-show
Notify billing
system
enquiry/
[suitable
room]
[else]
amendment
request/
customer arrives/
cancel request/
no-show/
System
Reservation
Maker
Guest
A use case describes the interaction that follows from a single business event. Where an event triggers a number of process steps, all the steps form a single use case.
Take Up
Reservation
Cancel
Reservation
Amend
Reservation
Process
No-Show
Make
Reservation
31
Handling TimeHandling Time
• In some systems, there are activities that take place at certain times or conditions. For examples,
• Process No-ShowProcess No-Show• {A reservation not claimed by 8 a.m. on the day after scheduled arrival will be treated as a no-{A reservation not claimed by 8 a.m. on the day after scheduled arrival will be treated as a no-
show.}show.}
• There are essentially two ways to handle times (or conditions) in use cases• Treat time as an actor
• Treat handling time as part of the system
• Combine above methods
Print a
System Report
Every day at midnight
Print a
System Report
System administrator
Print a
System Report
Every day at midnight System administrator
32
Check Use CasesCheck Use Cases
• Pore over the business concept model, asking following questions.
• Business concept model create/destroy check• Do the things these boxes represent get created and destroyed?
• Does the software need to know about this?
• If so, how does it find out?
• Does this thing have attributes that might change?
• Business concept model association update check• Do the relationships between these things, as indicated by the associations,
change over time?
• If so, does the software need to know and how does it find out?
33
Concept Model Create/Destroy CheckConcept Model Create/Destroy Check
HotelChain 요구사항은 단일 체인점만을 위한 예약 시스템이므로 체인을 새로 생성하거나 삭제할 필요가 없음 .
Hotel 아주 드물기는 하겠지만 호텔은 새로 추가되거나 삭제될 수 있으므로 , 이 이벤트를 위한 유스케이스가 필요하다 .
Room 객실은 추가되거나 삭제될 수 있으며 , 이 이벤트를 위한 유스케이스가 필요하다 .
RoomType 객실 유형은 추가되거나 삭제될 수 있으며 , 이 이벤트를 위한 유스케이스가 필요하다 .
Clerk 직원은 입사하거나 퇴사할 것이다 . 따라서 이 이벤트를 위한 유스케이스가 필요하다 .
Customer 고객은 예약을 하는 과정의 일부로써 시스템에 등록된다 . 일정기간 동안 이용실적이 없는 고객을 삭제하기 위한 기능이 필요하다 .
Address 고객과 동일 .
Reservation 예약은 비지니스 프로세스 수행 중에 생성된다 . 우리는 1 년간 예약 정보를 보관해야 하며 , 만료된 예약을 삭제하기 위한 기능이 필요하다 .
Payment 예약 시스템 범위 밖이다 .
Bill 예약 시스템 범위 밖이다 .
34
Concept Model Association Update CheckConcept Model Association Update Check
HotelChain – Hotel 변경되지 않음 .
Hotel – Room 변경되지 않음 .
Hotel – Clerk 직원은 다른 호텔로 옮길 수 있지만 , 시스템은 이것을 지원하지 않는 것으로 한다 .
Hotel – Customer 소프트웨어가 관리하지 않는다 .
Hotel – Reservation 예약 변경을 하였을 때 변경이 가능하다 .
Customer – Address 변경되지 않음 .
Customer – Reservation 변경되지 않음 .
Reservation – RoomType 예약 변경을 하였을 때 변경이 가능하다 .
Reservation – Bill 시스템의 영역 밖이다 .
Reservation – Room 고객이 예약을 실제로 이행하기 위해서 도착할 때 이 연관관계가 발생하는 것으로 결정한다 . 객실의 사전 할당은 없을 것이다 .
Bill – Payment 시스템의 영역 밖이다 .
RoomType – Room 변경되지 않음 .
35
Basic Concepts of Use Case DiagramBasic Concepts of Use Case Diagram
• ActorActor is a role that a user plays with respect to the system.
• Not specific to a person or job title – a user can play more than one role.
• An actor can perform many use cases.
• A use case may be performed by more than one actor.
• Actor does not necessarily need to be a person – can be an external system.
• Often easier to list actors first and then identify the use cases for each actor.
• Some users gain value from the use case whereas some others may just participate.
Drinker
36
Basic Concepts of Use Case Diagram – Cont’dBasic Concepts of Use Case Diagram – Cont’d
• Use caseUse case is a typical interaction between a user and a computer system.
• A use case captures some user-visible function.
• A use case may be small or large.
• A use case achieves a discrete goal for the user.
• Yields an observable result of value to a particular actor.
Pick up
the fruit juice
Vending Machine
Drinker
37
Example: Use Case DiagramExample: Use Case Diagram
Reservation system
ReservationMaker
Guest
BillingSystem
ReservationAdministrator
Cancel a reservation
Make a reservation
Update a reservation
Take up a reservation
Process no shows
Add, amend, Add, amend, remove remove
hotel, room, hotel, room, customer, customer, ......
38
Use Case DescriptionsUse Case Descriptions
• Think about how the initiating actor will interact with the system.
• Guided by the business process description and the system envisioning statement.
• Begin with the basic path, then add alternatives.
• Contents of Use Case Description• Use case name
• List the participating actors
• Clearly define the goal
• Describe basic path• Write from user’s perspective, but consider who will be reading the use cases.• Clearly define responsibilities(actor versus system).• Use business language.
• Consider alternative paths separately
39
Use Case Descriptions – Cont’dUse Case Descriptions – Cont’d
• Details of use cases are expressed textually.
• But typically need graphical depiction of the interaction• Activity Diagrams
• Emphasize the steps in the process.
• Sequence Diagrams• Emphasize the message flow and sequencing.
• Collaboration Diagrams• Emphasize the context, message, and data flow.
• UI Prototype• Emphasize the user & system interactions.
• Not all information can be, or should be, shown on a use case diagram.Not all information can be, or should be, shown on a use case diagram.• You will often need a combination of diagrams to get a complete picture of You will often need a combination of diagrams to get a complete picture of
your system.your system.
40
Presentation StylesPresentation Styles
• Informal text form
• Numbered steps form
• Table form
request
display form
enter the information
transaction
respond
1. request
2. display form
3. enter the information
4. transaction
5. respond
actor system
1. request
2. display form
3. enter the information
4. transaction
5. respond
41
Example: Use Case DescriptionExample: Use Case Description
Name Take up reservation
Initiator Guest
Goal Claim a reservation and check in to the hotel
Main Success Scenario
1. Guest arrives at hotel and claim a reservation.
2.2. Guest provides reservation tag.Guest provides reservation tag.
3. Guest confirms details of stay duration, room type.
4. System allocates room.
5. System notifies billing system that a stay is starting.
42
Alternative PathsAlternative Paths
• An alternative path gives alternatives to the basic path.
• We also document errors as alternative paths.
• The alternative paths are good for showing things that can happen at any time
• something that interrupts the normal flow of events.
43
Finding Alternative PathsFinding Alternative Paths
• Go through the basic path line by line with following questions• Is there some other action that can be taken at this point?
• Is there something that can go wrong at this point?
• Is there some behavior that can happen at any time?
• Use categories• An actor exists the application
• An actor cancel a particular operation
• An actor requests help
• An actor provides bad data
• An actor incomplete data
• An actor chooses an alternative way of performing the use case
• The system crashes
• The system is unavailable
44
Documenting AlternativesDocumenting Alternatives
Documentation Technique
Style Pros Cons
Add directly easy to see all possible behavior
hard to read and understand
Add in paragraph
easier to read than the previous
No change to the original step numbering
Add in a different section
easy to read the basic path separately
too many pages of document
1.2.3. 3. IfIf4.
1.2.
3.
1.2.3.Alternative PathsAlternative Paths
more com
plex use cases
45
Advanced Concepts in Use Case DiagramAdvanced Concepts in Use Case Diagram
• IncludeInclude is a relationship from a base use case to an inclusion use case, specifying how the behavior for the base use case contains the behavior of the inclusion use case. The behavior is included at the location which is defined in the base use case. The base use case depends on performing the behavior of the inclusion use case, but not on its structure.
• You can abstract the common behavior with a include relationship.
• Including use case is no longer complete by itself.
• The use case being included does not know when or it is included.
• A use case can use any number of other use cases. You can have as many levels of include as you desire.
Drinker
Pick up
the fruit juice
Vending MachineCount the
coins<<include>>
46
Advanced Concepts in Use Case DiagramAdvanced Concepts in Use Case Diagram
• ExtendExtend is a relationship from an extension use case to a base use case, specifying how the behavior defined for the extension use case augments (subject to conditions specified in the extension) the behavior defined for the base use case. The behavior is inserted at the location defined by the extension point in the base use case. The base use case does not depend on performing the behavior of the extension use case.
• Extend is used to conditionally extend the behavior of an existing use case.
• The extension includes a conditional expression. When the extension point is reached, if the condition is true, the steps in the extension are executed.
Drinker
Pick up
the fruit juice
Vending MachineCount the
coins
No-Ice
<<include>>
<<extend>>
47
Example: Included Use CaseExample: Included Use Case
Reservation system
ReservationMaker
Guest
BillingSystem
ReservationAdministrator
Cancel a reservation
Make a reservation
Update a reservation
Take up a reservation
Process no shows
Add, amend, remove
hotel, room, customer, ...
IdentifyIdentifyreservationreservation
<<<<include>>include>>
<<<<include>>include>>
<<<<include>>include>>
48
Example: Use Case AbstractionExample: Use Case Abstraction
Name Identify reservation
Initiator Included only
Goal Identify an existing reservation
Main Success Scenario
1. Actor provides reservation tag.
2. System locates reservation.
ExtensionsExtensions
2. System cannot find a reservation with the given tag.
a. Actor provides name and post code.
b. System display active reservations for that customer.
c. Actor select the reservation.
d. Stop.
2. The reservation tag refers to a reservation at a different hotel.
a2. Fail.
2b. No active reservations at this hotel for this customer.
a. Fail.
49
Example: Use Case AbstractionExample: Use Case Abstraction
Name Take up reservation
Initiator Guest
Goal Claim a reservation and clerk in to the hotel
Main Success Scenario
1. Guest arrives at hotel and claim a reservation.
2.2. Include Identify Reservation.Include Identify Reservation.
3. Guest confirms details of stay duration, room type.
4. System allocates room.
5. System notifies billing system that a stay is starting.
Extensions
3. Reservation not identified.
a. Fail.
50
Package Structure: Use Case ModelPackage Structure: Use Case Model
Requirements
Business Concept Model
Use Case Model
Specification
Business Type Model
Interface Specifications
Component Specifications
Component Architecture
Interactions
Create a use case model under the Use Case Model package
Cancel a reservation
Make a reservation
Create sub-packages for each use case with the same name as the use case, and then write an use case descriptions under the Sub-Package
...
51
Quality of ServiceQuality of Service
• Other requirements that are not visible to the actors and are hard to express in use cases.
• Quality Attributes in ISO/IEC 9126• Functionality, Reliability, Usability, Efficiency, Maintainability, Portability.
• Timing and size requirements for real time systems
• Other requirements can be written with the related use case, in the Special RequirementsSpecial Requirements section, but some prefer to also consolidate all of them in the Supplementary SpecificationSupplementary Specification.
52
Example: Supplementary SpecificationExample: Supplementary Specification
• The System must support 200 simultaneous users.
• System response to any input must not exceed 2 seconds (95 percent) for direct connections and 5 seconds (90 percent) for Internet connections.
• The system must support (total number of rooms) * 10 active reservations, and assume 100 percent hotel occupancy.
Make a Reservation
53
System BoundariesSystem Boundaries
• What things are inside your system?• You have to worry about creating them.
• What are outside your system?• You don’t have to create them, but you have to worry about interfacing with
them.
• Scoping the project• Define what parts of the system you will create within a certain time period, on
a certain budget.
54
Potential Boundary ProblemsPotential Boundary Problems
• It is worth while to define a clear boundary for your system at upfront• Are these requirements necessary for this system?
• Are these requirements something this system would logically do?
• How do the new requirements affect our current risk analysis?
• Can these requirements be handled by one of the current actors to our system? In other words, is someone else responsible for there requirements?
• Are these requirements something our customers would expect our system to do?
• Would these requirements differentiate our product in the marketplace?
55
Scoping the ProjectScoping the Project
• Do you intend to build the whole system in the current project?
• If not, you need to clearly define the pieces of the system that will be included and those that will not.
• Prioritizing the requirements• Required or Must Have
• Important or Should Have
• Nice or Could Have
• Future or Would Like To Have
56
Prioritizing the RequirementsPrioritizing the Requirements
• Distributed Stakeholders need to prioritize• requirements, goals, win conditions, and risk items.
• Why?• Because time(schedule) and resources(budget) are limited.
• Stakeholders have their own viewpoint on requirements and these conflict with each other.
• Not resolving conflicts early on can cause problems to the quality and success of the project.
• Goal• Is to minimize overall risk by identifying classification and an ordering that
maximize satisfaction over all the stakeholders.
57
Distributed Collaboration and Prioritization ToolDistributed Collaboration and Prioritization Tool
• Display the result of the prioritization with respect to the bin model selected
• Display item vote summaries
• Display the relative priorities according to the bin models
(from USC/CSE)(from USC/CSE)
58
Module SummaryModule Summary
• The requirements workflow must deliver to the specification workflow a business concept model and a set of use cases.
• The business concept model lists the important concepts in the problem domain and shows the relationships between them.
• The use cases clarify the software boundary, identify the actors who interact with system, and describe those interactions.
59
Estimating Work with Use CaseEstimating Work with Use Case
• Karner’s method• A method for determining the amount of work for OO project.
• Formula• UUCP(Unadjusted Use Case Points) = Total actor weight + Total use case weight
• TFactor = Sum(TLevel * WeightingFactor)• TCF(Technical Complexity Factor) = 0.6 + (0.01 * TechnicalFactor)
• EFactor = Sum(ELevel * WeightingFactor)• EF(EnvironmentFactor) = 1.4 + (-0.03 * EFactor)• UCP(Use Case Point) = UUCP * TCF * EF
• Karner suggests using a factor of 20- man/hours per UCP for a project estimate.
60
Review – Use Case Model of Hotel ReservationReview – Use Case Model of Hotel Reservation
Reservation system
ReservationMaker
Guest
BillingSystem
ReservationAdministrator
Cancel a reservation
Make a reservation
Update a reservation
Take up a reservation
Process no shows
Add, amend, remove
hotel, room, customer, ...
61
Weighting ActorsWeighting Actors
• Actor Weighting Factors
Actor Type Description Factor
Simple Program interface 1
Average Interactive, or protocol-driven, interface 2
complex Graphical interface 3
62
Example: Weighting ActorsExample: Weighting Actors
ReservationMaker – Complex
Guest – Complex
BillingSystem – Simple
ReservationAdministrator - Average
1 simple * 1 = 1
1 average * 2 = 2
2 complex * 3 = 6
Total actor weight = 1 + 2 + 6 = 9
63
Weighting Use CasesWeighting Use Cases
• Transaction-based Weighting Factors
• Analysis Class-based Weighting Factors
Use Case Type Description Factor
Simple 3 or fewer transactions 5
Average 4 to 7 transactions 10
Complex More than 7 transactions 15
Use Case Type Description Factor
Simple Fewer than 5 analysis classes 5
Average 5 to 10 analysis classes 10
Complex More than 10 analysis classes 15
64
Example: Weighting Use CasesExample: Weighting Use Cases
Cancel a reservation – Simple
Make a reservation – Simple
Update a reservation – Simple
Take up a reservation – Average
Process no shows – Average
Add, amend, remove hotel, room, customer, ... – Simple
4 simple * 5 = 20
2 average * 10 = 20
0 complex * 15 = 0
Total use case weight = 20 + 20 + 0 = 40
Unadjusted Use Case Points(UUCP) =
total actor weight + total use case weight = 9 + 40 = 49
(We don’t need to consider included use cases or extending use cases)
65
Weighting Technical FactorWeighting Technical Factor
• Technical Factors for System and Weights
Factor number Factor Description Weight
T1 Distributed system 2
T2 Response or throughput performance objective 1
T3 End-user efficiency (online) 1
T4 Complex internal processing 1
T5 Code must be reusable 1
T6 Easy to install 0.5
T7 Easy to use 0.5
T8 Portable 2
T9 Easy to change 1
T10 Concurrent 1
T11 Includes special security features 1
T12 Provides direct access for third parties 1
T13 Special user training facilities required 1
66
Example: Weighting Technical FactorExample: Weighting Technical Factor
Factor # Weight Assigned Extended Reason
T1 2 0 0 Not planning on distributing first release
T2 1 3 3 Speed is likely limited by human input
T3 1 5 5 Needs to be efficient
T4 1 1 1 Easy processing
T5 1 0 0 Nice, but later
T6 0.5 5 2.5 Need to be easy for non-technical people
T7 0.5 5 2.5 Need to be easy for non-technical people
T8 2 0 0 Not at this time
T9 1 3 3 Sure
T10 1 5 5 Not exactly, but it is multiuser
T11 1 3 3 Simple security
T12 1 5 5 Customers
T13 1 0 0 So easy we don’t need training
TFactor = Sum(Tlevel * WeightingFactor) =
0 + 3 + 5 + 1 + 0 + 2.5 + 2.5 + 0 + 3 + 5 + 3 + 5 + 0 = 30
TCF(Technical Complexity Factor) =
0.6 + (0.01 * TFactor) = 0.6 + (0.01 * 30) = 0.9
67
Weighting Environment FactorWeighting Environment Factor
• Environment Factors for Team and Weights
Factor number Factor Description Weight
F1 Familiar with Rational Unified Process 1.5
F2 Application experience 0.5
F3F3 Object-oriented experienceObject-oriented experience 11
F4 Lead analyst capability 0.5
F5 Motivation 1
F6 Stable requirements 2
F7 Part-time workers -1
F8 Difficult programming language -1
68
Example: Weighting Environment FactorExample: Weighting Environment Factor
Factor # Weight Assigned Extended Reason
F1 1.5 1 1.5 Most of team unfamiliar
F2 0.5 1 0.5 Most of team not programmers
F3 1 1 1 Most of team not programmers
F4 0.5 5 2.5 Gus is really good
F5 1 5 5 Team is really eager
F6 2 5 10 We don’t expect change
F7 -1 0 0 No part-timers
F8 -1 2 -2 We’re looking at Visual Basic
EFactor = Sum(Elevel * WeightingFactor) =
1.5 + 0.5 + 1 + 2.5 + 5 + 10 + 0 + -2 = 18.5
EF(Environmental Factor) =
1.4 + (-0.03 * EFactor) = 1.4 + (-0.03 * 18.5) = 0.845
69
Project EstimateProject Estimate
• Karner suggests using a factor of 20 man-hour per UCP.
• Look at EF factors F1 through F8. Count how many of F1 through F6 are below 3 and how many in F7 and F8 are above 3.
• The total is 2 or less, use 20 man-hours per UCP.
• The total is 3 or 4, use 28.
• The total is 5 or more, try very hard to change your project so that the numbers can be adjusted.
UCP(Use Case Points) =
UUCP * TCF * EF = 49 * 0.9 * 0.845 = 37.2645
Total Man/Hour = 28 * 37.2645 = 1043.4061043.406
70
Lab 04: Requirements DefinitionLab 04: Requirements Definition
Business Type
Modeling
Interface Responsibility
Modeling
Component Architecture
Modeling
Business Concept
Modeling
Use Case
Modeling
Use Case Step
Modeling
Interface Interaction
Modeling
Interface Information
Modeling
Writing
Pre/Post-condition
Completing
Component Specification
RequirementRequirement
SpecificationSpecification
Object ModelingObject Modeling Behavior ModelingBehavior Modeling
