CHAPTER 2: REQUIREMENTS ENGINEERING &
COST ESTIMATIONSlides by: Ms. Shree Jaswal
Topics to be covered
◦ Requirement,
◦ Types of Requirements,
◦ Requirement gathering,
◦ Requirement Engineering Task,
◦ Identifying Stakeholders,
◦ Multiple viewpoints,
◦ SRS (Software Requirement Specification)
◦ Project Estimation: LOC based, FP based and Use case based estimation.
Chapter 2 Slides by: Ms. Shree Jaswal 2
Which Chapter? Which Book?
◦ Chapter 5: Understanding Requirements, Roger
Pressman, “ Software Engineering: A practitioner’s
Approach”, 7th Edition, Mc Graw Hill Publication
◦ Chapter 7: Requirements Engineering, Roger
Pressman, “ Software Engineering: A practitioner’s
Approach”, 6th Edition, Mc Graw Hill Publication
◦ Chapter 26: Estimation for software projects,
Roger Pressman, “ Software Engineering: A
practitioner’s Approach”, 7th Edition, Mc Graw Hill
Publication
◦Chapter 2 Slides by: Ms. Shree Jaswal 3
What is requirements engineering?
◦ It is the process of discovering, analyzing,
documenting and validating the
requirements of the system
◦Each software development process goes
through the phase of requirements
engineering
Chapter 2 Slides by: Ms. Shree Jaswal 4
RequirementsA requirement is
◦a function that a system must be able to do (A
Functional Requirement :Eg. The software shall
allow the user to Save Data
◦a constraint that a system must meet (A Non-
Functional Requirement)
◦A constraint may be qualitative : Eg. The system
must respond in 10 seconds (describes how well a
system performs)
◦a constraint imposed by the client (A Pseudo-
requirement) :Eg. The cabinet shall be painted
blue, The Operating System to be used is
WindowsChapter 2 Slides by: Ms. Shree Jaswal 5
Chapter 5
Slides by:Ms.Shree Jani
Requirements◦Definition [IEEE Std] : A condition or capability needed by a user to solve a problem or achieve an objective. The set of all requirements forms the basis for subsequent development of the system or system component.
Requirements may be◦Essential – must have◦Desirable – should have◦Optional – may be omittedRequirements may also be◦Derived – resulting from design analysis, e.g. file system, networking, database◦ Implicit – an expected property of the kind of software
Chapter 2 Slides by: Ms. Shree Jaswal 6
Ideal Properties of Requirements◦Correct
◦Consistent
◦Complete
◦Realistic
◦Required
◦Testable
◦Traceable
E.g. The system shall provide real time response to queries can be made testable by rewording it to read The system shall respond to user queries in 2 seconds
Chapter 2 Slides by: Ms. Shree Jaswal 7
Different levels of abstraction◦User requirements
◦Usually the first attempt for the description of the
requirements
◦Services and constraints of the system
◦ In natural language or diagrams
◦Readable by everybody
◦Serve business objectives
◦System requirements
◦Services and constraints of the system in detail
◦Useful for the design and development
◦Precise and cover all cases
◦Structured presentationChapter 2 Slides by: Ms. Shree Jaswal 8
Example
◦User requirement: The library system should provide a way to allow a patron to borrow a book from the library.
◦ System requirement: The library system should provide a withdraw interaction that allows a patron to withdraw a book given the isbnand copy number of the book to be withdrawn. The interaction fails if: the book is already withdrawn, the book is not in the library's collection, the patron has already withdrawn 5 books, the patron owes more than $5, the book is on hold by someone else. Otherwise…(To be completed)
Chapter 2 Slides by: Ms. Shree Jaswal 9
Types of requirements
◦Functional requirements
◦Services the system should provide
◦What the system should do or not in reaction to particular situations
◦They can be further categorized as:
◦What i/p the system should accept
◦What o/p the system should produce
◦What data the system should store
◦What computations the system should perform
◦The timing & synchronization of above
Chapter 2 Slides by: Ms. Shree Jaswal 10
◦Non-functional requirements◦Constraints on the services or functions offered by the system
◦Examples: Timing constraints, constraints on the development process (CASE, language, development method…), standards etc
◦One of the most imp things about non-functional requirements is to make them verifiable.
◦Verification is normally done by measuring various aspects of the system & seeing if measurements conform with the requirements.
Chapter 2 Slides by: Ms. Shree Jaswal 11
Non-functional requirements
◦ They are further grouped into different
categories:
1. Constrains on design
Response time - Eg. certain result must
be calculated in less than 3 secs
Throughput- Eg. Transactions per min
Resource usage - Eg. System will use no more than 30 MB of memory
Chapter 2 Slides by: Ms. Shree Jaswal 12
Non-functional requirements
Reliability- it is measured as the average amount of time between failures or the probability of a failure in a given period. Eg. Server running continuously must not suffer more than 1 failure per week.
Availability- it measures the amount of time that a server is running & available to respond to users. Eg. Server must be available over 99% of time & that no period of downtime may exceed 1 min.
Recovery from failure
Allowances for maintainability & enhancement
Allowances for reusabilityChapter 2 Slides by: Ms. Shree Jaswal 13
Non-functional requirements
2. Constrains on environment & technology
◦ Platform – such requirements specify the
least powerful platforms & declare that it
must work on anything more recent or
powerful.
◦ Technology to be used – such
requirements are normally stated to
ensure that all systems in an organization
use the same technology.
Chapter 2 Slides by: Ms. Shree Jaswal 14
Non-functional requirements
3. Constrains on project plan &
development methods
◦ Development process (methodology) to be used – Eg. Particular approaches
to testing
◦ Cost and delivery date
Chapter 2 Slides by: Ms. Shree Jaswal 15
Types of requirements
◦Domain requirements
◦From the application domain of the
system
◦May be functional or non-functional
◦Examples: Medicine, library, physics,
chemistry◦ Note: You can have user/system functional/non-functional
requirements.
Chapter 2 Slides by: Ms. Shree Jaswal 16
Requirement gathering essentials
1. Focus and Clarity
2. A Format for Specifying Requirements
3. Selecting Author of the Requirements
Document
4. The Language of Requirements
5. Accuracy is Critical
6. Minimize the Risk of Errant Interpretation
Chapter 2 Slides by: Ms. Shree Jaswal 17
Chapter 2 Slides by: Ms. Shree Jaswal 18
Requirements Engineering◦ Inception—ask a set of questions that establish …
◦ basic understanding of the problem
◦ the people who want a solution
◦ the nature of the solution that is desired, and
◦ the effectiveness of preliminary communication
and collaboration between the customer and the
developer
◦ Elicitation—elicit requirements from all stakeholders
◦ Elaboration—create an analysis model that identifies
data, function and behavioral requirements
◦ Negotiation—agree on a deliverable system that is
realistic for developers and customers
Chapter 2 Slides by: Ms. Shree Jaswal 20
Requirements Engineering◦ Specification—can be any one (or more) of the following:
◦ A written document
◦ A set of models
◦ A formal mathematical
◦ A collection of user scenarios (use-cases)
◦ A prototype
◦ Validation—a review mechanism that looks for
◦ errors in content or interpretation
◦ areas where clarification may be required
◦ missing information
◦ inconsistencies (a major problem when large products or systems are engineered)
◦ conflicting or unrealistic (unachievable) requirements.
◦ Requirements management
Chapter 2 Slides by: Ms. Shree Jaswal 21
Identifying Stakeholders◦ A stakeholder is anyone who has a direct interest in
or benefits from the system that is to be developed.
◦ Each stakeholder has a different view of the system,
achieves different benefits when the system is
successfully developed, and is open to different risks
if the development effort should fail.
◦ At inception, you should create a list of people who
will contribute input as requirements are elicited
◦ Usual stakeholders: business operations managers,
product managers, marketing people, internal and
external customers, end users, consultants, product
engineers, software engineers, support and
maintenance engineers, and others.Chapter 2 Slides by: Ms. Shree Jaswal 22
Recognizing Multiple Viewpoints◦ Because many different stakeholders exist, the
requirements of the system will be explored
from many different points of view.
◦As information from multiple viewpoints is
collected, emerging requirements may be
inconsistent or may conflict with one another.
◦ You should categorize all stakeholder
information (including inconsistent and
conflicting requirements) in a way that will
allow decision makers to choose an internally
consistent set of requirements for the system.
Chapter 2 Slides by: Ms. Shree Jaswal 23
Asking the First Questions
◦The first questions
◦Who is behind the request for this work?
◦Who will use the solution?
◦What will be the economic benefit of a successful solution
◦ Is there another source for the solution that you need?
Chapter 2 Slides by: Ms. Shree Jaswal 24
Eliciting Requirements◦ meetings are conducted and attended by both
software engineers and customers
◦ rules for preparation and participation are established
◦ an agenda is suggested
◦ a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting
◦ a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used
◦ the goal is ◦ to identify the problem◦ propose elements of the solution◦ negotiate different approaches, and◦ specify a preliminary set of solution requirements
Chapter 2 Slides by: Ms. Shree Jaswal 25
Determining Requirements
Some methods in determining requirements:
◦Consulting with the client
◦Facilitated Application Specification
Techniques (FAST)
◦Prototyping
◦Requirements Analysis
Details are as follows:
Chapter 2 Slides by: Ms. Shree Jaswal 27
Consulting with the client◦ Initially :
◦ Client and developer do not know each other.
◦ The developer will ask questions about the reasons the client wants the work done:
◦ Who is behind the request for this work?
◦ Who will use the solution?
◦ What is the economic benefit?
◦ Is there another source for the solution?
◦ Then questions about the problem, its environment and a solution:
◦ What problem(s) will the solution address?
◦ What are the characteristics of a ‘good” solution?
◦ Can you show or describe the environment?
◦ Are there special constraints involved (e.g. performance)?
◦ Then questions about the meeting:
◦ Are the questions relevant?
◦ Is there anyone else who can provide additional information?
◦ Is there anything else I should be asking you?
Chapter 2 Slides by: Ms. Shree Jaswal 28
Facilitated Application Specification Techniques (FAST)
◦ Also know as Joint Application Development (JAD)
◦ Team oriented – the team being members of the client business and developers.
◦ Typical guidelines:
◦ Meet at a neutral site and attended by customers and developers
◦ Rules for preparation and participation are established
◦ An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas
◦ A “facilitator” (a customer, developer or outsider) chairs the meeting
◦ The goal is : to identify the problem, propose elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements.
Chapter 2 Slides by: Ms. Shree Jaswal 29
Software Prototyping◦A prototype is a model of (part of) a software application to be built. It could be◦ a mock up giving an outside view – screens, mocked up data
files, mocked up activity◦ a working sub-system to study a question – to estimate
throughput, to explore how to do something
◦At one extreme, we throw away the prototype. At the other, we incorporate it into the system.
◦Purposes:◦ to demonstrate display screens to the client◦ to investigate user interaction◦ to develop algorithms interactively◦ to explore system properties
◦Prototypes are not meant to be complex.Chapter 2 Slides by: Ms. Shree Jaswal 30
Elicitation Work Products◦ a statement of need and feasibility.
◦ a bounded statement of scope for the system or product.
◦ a list of customers, users, and other stakeholders who participated in requirements elicitation
◦ a description of the system’s technical environment.
◦ a list of requirements (preferably organized by function) and the domain constraints that apply to each.
◦ a set of usage scenarios that provide insight into the use of the system or product under different operating conditions.
◦ any prototypes developed to better define requirements.
Chapter 2 Slides by: Ms. Shree Jaswal 31
Negotiating Requirements
◦ Identify the key stakeholders
◦ These are the people who will be
involved in the negotiation
◦Determine each of the stakeholders “win
conditions”
◦Win conditions are not always obvious
◦Negotiate
◦Work toward a set of requirements that
lead to “win-win”
Chapter 2 Slides by: Ms. Shree Jaswal 32
Requirement Validation◦ Its concerned with showing that the
requirements actually define the system
which customer wants.
◦ It is important because errors in requirement
document can lead to extensive rework
costs after the system is ready.
◦During this process, different checks which
should be carried out on the requirements in
requirements document include:
Chapter 2 Slides by: Ms. Shree Jaswal 33
Requirement Validation
1. Validity checks
2. Consistency checks
3. Completeness checks
4. Realism checks
5. Verifiability
Chapter 2 Slides by: Ms. Shree Jaswal 34
Requirement Validation
◦Different req. validation techniques are:
1. Requirement reviews
2. Prototyping
3. Test case generation
4. Automated consistency analysis
Chapter 2 Slides by: Ms. Shree Jaswal 35
Requirements Management
◦Management
◦ Identification and classification
◦Using a unique identifier for each
requirement
◦Hierarchies – sub-requirements
◦Change management
◦ Traceability
Chapter 2 Slides by: Ms. Shree Jaswal 36
Requirements change management
◦Should apply to all proposed changes to the
requirements. Principal stages are:
1. Problem analysis.
-Discuss requirements problem and propose
change.
2. Change analysis and costing.
-Assess effects of change on other requirements.
3. Change implementation.
-Modify requirements document and other
documents to reflect change.
Chapter 2 Slides by: Ms. Shree Jaswal 37
Requirements change management
Chapter 2 Slides by: Ms. Shree Jaswal 38
Requirement traceability
◦There are many relationships between
req. & req. and between req. & system
design.
◦Traceability is an overall property of a
requirements spec. which reflects the
ease of finding related requirements
◦ It is often represented using traceability
matrices which relate req. to
stakeholders, each other or design
modules.
Chapter 2 Slides by: Ms. Shree Jaswal 39
Requirement traceability
Chapter 2 Slides by: Ms. Shree Jaswal 40
Requirements
document
1.1 XXXX
……because
1.2 YYYY
Design document
…. Due to
Requirement 1.2
rationale
Chapter 2 Slides by: Ms. Shree Jaswal 41
What is a specification?
◦Purpose
◦ Representation before existence
◦ Simplification
◦ Capture essential exterior characteristics of a module
◦ Interaction with environment:
◦ Services
◦ Requests
◦ Internal matters are not considered
◦How specification works
◦ Aligned with problem solving strategy
◦ Identify, define → specification
◦ Captures purpose
◦ Gives the module designer a sense of direction
Chapter 2 Slides by: Ms. Shree Jaswal 42
Specification VS Description
◦Description
◦May be ambiguous
◦May be incomplete
◦May be dependent on unstated assumption.
◦Specification
◦To be unambiguous
◦To be complete
◦With assumption exposed
Chapter 2 Slides by: Ms. Shree Jaswal 43
Communicating Req. - SRS
◦Purpose
◦ Communicates an
understanding of the
requirements
◦ Contractual
◦ Baseline for evaluating
subsequent products
◦ testing, V&V
◦ Baseline for change
control
Chapter 2 Slides by: Ms. Shree Jaswal 44
◦Audience
◦ Users, Purchasers
◦ Requirements Analysts
◦ Developers,
Programmers
◦ Testers
◦ Project Managers
It is common practice to capture & communicate the requirements to others in an SRS
Characteristics of SRS1. Correct
2. Complete
3. Unambiguous
4. Verifiable
5. Consistent
6. Ranked for importance and/or stability
7. Modifiable
8. Traceable
Chapter 2 Slides by: Ms. Shree Jaswal 45
Components of SRS
◦ Functionality
◦Performance
◦Design constraints imposed on an
implementation
◦External interfaces
Chapter 2 Slides by: Ms. Shree Jaswal 46
Format of SRS (IEEE STD)◦1. Introduction
1.1. Purpose1.2. Scope1.3. Definitions, Acronyms and Abbreviations1.4. References1.5. Overview
2. General Description2.1. Product Perspective2.2. Product Functions2.3. User Characteristics2.4. General Constraints2.5. Assumptions and Dependencies
3. Specific Requirements
Chapter 2 Slides by: Ms. Shree Jaswal 47
Format of SRS (IEEE STD)
◦3. Specific requirements3.1. Functional Requirements3.2. External Interface Requirements3.3. Performance Requirements3.4 Design Constraints
3.4.1. Standards Compliance3.4.2. Hardware Limitations …
3.5. Attributes3.5.1. Security3.5.2. Maintainability …
3.6. Other Requirements3.6.1. Data Base …
Chapter 2 Slides by: Ms. Shree Jaswal 48
Requirement Specification Languages
◦ Commonly used languages are:
1. Structured English (natural language)
2. Regular Expressions
3. Decision tables
4. Finite state automata (FSA)
Chapter 2 Slides by: Ms. Shree Jaswal 49
Quality Function Deployment◦Quality function deployment (QFD) is a
quality management technique that
translates the needs of the customer into
technical requirements for software.
◦QFD defines requirements in a way that
maximizes customer satisfaction.
◦QFD emphasizes an understanding of what is
valuable to the customer and then deploys
these values throughout the engineering
process.
Chapter 2 Slides by: Ms. Shree Jaswal 51
Quality Function Deployment◦ QFD identifies three types of requirements:
◦ Normal requirements. The objectives and goals that are
stated for a product or system during meetings with the
customer. If these requirements are present, the customer
is satisfied.
◦ Examples: requested types of graphical displays, specific
system functions, and defined levels of performance.
◦ Expected requirements. These requirements are implicit to
the product or system and may be so fundamental that
the customer does not explicitly state them. Their absence
will be a cause for significant dissatisfaction.
◦ Examples: ease of human/machine interaction, overall
operational correctness and reliability, and ease of
software installation.
Chapter 2 Slides by: Ms. Shree Jaswal 52
Quality Function Deployment
◦ Exciting requirements. These features go beyond
the customer’s expectations and prove to be
very satisfying when present. Care has to be
taken to avoid requirements creep
◦ For example, software for a new mobile phone
comes with standard features, but is coupled
with a set of unexpected capabilities (e.g.,
multi-touch screen, visual voice mail) that
delight every user of the product.
Chapter 2 Slides by: Ms. Shree Jaswal 53
PROJECT ESTIMATION
Software Estimation
◦The first step in any estimation is
assessing the size of the software to be
built.
◦The estimated size becomes the basis
for further estimation-that is the effort
that will be required, the project
schedule & the project cost.
◦ It is thus an important step in the
process of estimation.
Chapter 2 Slides by: Ms. Shree Jaswal 55
Size estimation
◦ Ideally, size estimation or “sizing” is best done
when there is complete information about
the system
◦But this is not available till the system is
actually built,
◦ Sizing done at the end of the project will be
more accurate (since everything is known)
but also the most useless-as the size estimate
comes too late to be used for planning or
other decision making
Chapter 2 Slides by: Ms. Shree Jaswal 56
Size estimation◦The challenge for the estimator is
therefore to arrive at a reasonable
estimate of the size of the system with
partial information
◦A good estimate is one that has a high
probability of turning out correct, within
a range.
Chapter 2 Slides by: Ms. Shree Jaswal 57
Decomposition for Estimation
Chapter 2 Slides by: Ms. Shree Jaswal 58
• Break the problem up into the bits that must be solved individually.
- e.g. user interface, the file system, the database, the application.
• Break each piece up further until we reach a size that is small enough to which estimating methods can be applied.
• Estimate the lines of code (LOC) or Function Points (FP) required foreach component.
• If we take the most likely estimate of a quantity and add it together withthe most optimistic and the most pessimistic estimates, according to
we take into account the extremes.
• We can then combine the estimates into a total.
expected =(optimistic + 4 x most likely + pessimistic)
6
Decomposition for Estimation
Chapter 2 Slides by: Ms. Shree Jaswal 59
• An example of using the formula
We say the estimated LOC for the user interface is 2267
expected =(optimistic + 4 x most likely + pessimistic)
6
Expected LOC =(1900 + 4 x 2300 + 2500)
6 2267
Suppose we estimate the line of code (LOC) for a user interface as
follow:
most optimistic LOC = 1900
most pessimistic LOC = 2500
most likely LOC = 2300
then
Example of LOC based estimation
Chapter 2 Slides by: Ms. Shree Jaswal 60
Function Estimated Lines of Code
user interface and control facilities 2300
two-dimensional geometry analysis 5300
three-dimensional geometry analysis 6800
database management 3350
computer graphics display facilities 4950
peripheral controllers 2100
design analysis modules 8400
Estimated lines of code 33200
• Historical data (given) is 620 LOC/pm.
• Hence, the effort is 33200/620 = 54 person-months (pm)
• At $50 per hour and work 160 hours per month, we have an
estimate of $432,000 (= 54*160*50)
Function Point (FP) Estimation• Another method of estimating project
• consists of three steps
1. Calculate “count-total” from 5 measurement
parameters
2. Calculate “total of complexity adjustment
factors” from 14 complexity factors
3. Calculate the final Function Point (FP) by
combining results from step 1 and 2
Chapter 2 Slides by: Ms. Shree Jaswal 61
FP Estimation Step 1
Chapter 2 Slides by: Ms. Shree Jaswal 62
Measurement parameter Count Simple Average Complex Function Points
Number of User Inputs x 3 4 5 =
Number of User Outputs x 4 5 7 =
Number of User Inquiries x 3 4 6 =
Number of Files x 7 10 15 =
Number of External Interfaces x 5 7 10 =
Count-total
Number of User Input: the number of user inputs that provide distinct application
oriented data to the software. It is distinguished from user inquires
Number of User Output: e.g. reports, screens, error messages, etc.
Number of User Inquires: e.g. client info inquire, price inquire, etc.
Number of Files: each logical master file is counted
complex weighting factor (somewhat subject)
Number of External Interface: the number of all machine readable interfaces that
are used to transmit info to another system.
FP Estimation Step 1 (example)
Chapter 2 Slides by: Ms. Shree Jaswal 63
Measurement parameter Count Simple Average Complex Function Points
Number of User Inputs 10 x 3 4 5 = 30
Number of User Outputs 20 x 4 5 7 = 100
Number of User Inquiries 15 x 3 4 6 = 90
Number of Files 5 x 7 10 15 = 35
Number of External Interfaces 3 x 5 7 10 = 21
Count-total 276
Then we must consider 14 “complexity adjustment values”
rated on a scale of 0 – 5 (Step 2 of FP Estimation):
• No influence 0
• Incidental1
• Moderate2
• Average 3
• Significant 4
• Essential 5
FP Estimation Step 2 (example)
Chapter 2 Slides by: Ms. Shree Jaswal 64
Factor Rating1. Reliable backup and recovery2. Data communications
3. Distributed processing functions
4. Performance critical?5. Will the system run on existing heavily utilised operational
environment?6. On-line data entry?7. On-line data entry over multiple screens or operations8. Are the master files updated on-line?9. Are the inputs, outputs files or enquiries complex?10. Is the internal processing complex?11. Is the code designed to be reusable?12. Are conversion and installation included in the design?13. Is the system designed for multiple installations in different
organisations?14. Is the application designed to facilitate change and ease of use
by the user?
50
2
4
1
4353211
5
3
Total of complexity adjustment factors = 39
FP Estimation Step 3: FP Calculation
Chapter 2 Slides by: Ms. Shree Jaswal 65
FP is then calculated as follows:
where the count-total comes from step 1,
Fi is the total of complex adjust factors from step 2.
FP = count-total x [ 0.65 + 0.01 x F i]
FP = 276 x [ 0.65 + 0.01 x 39 ]
= 287.04
With the example values:
Process-Based Estimation
Chapter 2 Slides by: Ms. Shree Jaswal 66
Obtained from “process framework”
framework activities
Effort required to
accomplish
each framework
activity for each
application function
application
functions
Process Based Estimation◦ Here we consider how much effort each phase of design will take.
Chapter 2 Slides by: Ms. Shree Jaswal 67
Activity Customer
Com.Planning
Risk
AnalysisEngineering
Construction
Release
Customer
EvaluationTotals
Task Analysis Design Code Test
pm pm pm pm pm
Function
User Interface and Control Facilities 0.50 2.50 0.40 5.00 n/a 8.40
2D Geometric Analysis 0.75 4.00 0.60 2.00 n/a 7.35
3D Geometric Analysis 0.50 4.00 1.00 3.00 n/a 8.50
Database Management 0.50 3.00 1.00 1.50 n/a 6.00
Computer Graphics Display Facilities 0.50 3.00 0.75 1.50 n/a 5.75
Peripheral Control 0.25 2.00 0.50 1.50 n/a 4.25
Design Analysis Modules 0.50 2.00 0.50 2.00 n/a 5.00
Total 0.25 0.25 0.25 3.50 20.50 4.75 16.50 46.00
% effort 1% 1% 1% 8% 45% 10% 36% 100%
Building the Analysis Model◦ Elements of the analysis model
◦ Scenario-based elements
◦ Functional—processing narratives for software
functions
◦ Use-case—descriptions of the interaction between
an “actor” and the system
◦ Class-based elements
◦ Implied by scenarios
◦ Behavioral elements
◦ State diagram
◦ Flow-oriented elements
◦ Data flow diagram
Chapter 2 Slides by: Ms. Shree Jaswal 68
Use-Cases
◦ A collection of user scenarios that describe the thread of usage of a system
◦ Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way
Chapter 2 Slides by: Ms. Shree Jaswal 69
Use-Cases◦ Each scenario answers the following questions:
◦ Who is the primary actor, the secondary actor (s)?
◦ What are the actor’s goals?
◦ What preconditions should exist before the story begins?
◦ What main tasks or functions are performed by the actor?
◦ What extensions might be considered as the story is described?
◦ What variations in the actor’s interaction are possible?
◦ What system information will the actor acquire, produce, or change?
◦ Will the actor have to inform the system about changes in the external environment?
◦ What information does the actor desire from the system?
◦ Does the actor wish to be informed about unexpected changes?
Chapter 2 Slides by: Ms. Shree Jaswal 70
Chapter 2 Slides by: Ms. Shree Jaswal 71
Use-Case Diagram
Chapter 2 Slides by: Ms. Shree Jaswal 72
homeow ner
Arms/ disarms
syst em
Accesses syst em
via Int ernet
Reconf igures sensors
and relat ed
syst em f eat ures
Responds t o
alarm event
Encount ers an
error condit ion
syst em
administ rat or
sensors
Use case description
◦ Use case: InitiateMonitoring
◦ Primary actor: Homeowner.
◦ Goal in context: To set the system to monitor sensors when the
homeowner leaves the house or remains inside.
◦ Preconditions: System has been programmed for a password and to
recognize various sensors.
◦ Trigger: The homeowner decides to “set” the system, i.e., to turn on the
alarm functions.
◦ Scenario:
◦ 1. Homeowner: observes control panel
◦ 2. Homeowner: enters password
◦ 3. Homeowner: selects “stay” or “away”
◦ 4. Homeowner: observes read alarm light to indicate that SafeHome has
been armed
Chapter 2 Slides by: Ms. Shree Jaswal 73
Use case description
◦ Exceptions:
◦ 1. Control panel is not ready: homeowner checks all sensors to
determine which are open; closes them.
◦ 2. Password is incorrect (control panel beeps once): homeowner
reenters correct password.
◦ 3. Password not recognized: monitoring and response subsystem
must be contacted to reprogram password.
◦ 4. Stay is selected: control panel beeps twice and a stay light is
lit; perimeter sensors are activated.
◦ 5. Away is selected: control panel beeps three times and an away
light is lit; all sensors are activated.
◦ Priority: Essential, must be implemented
◦ When available: First increment
Chapter 2 Slides by: Ms. Shree Jaswal 74
Use case description◦ Frequency of use: Many times per day
◦ Channel to actor: Via control panel interface
◦ Secondary actors: Support technician, sensors
◦ Channels to secondary actors:
◦ Support technician: phone line
◦ Sensors: hardwired and radio frequency interfaces
◦ Open issues:
◦ 1. Should there be a way to activate the system without the use of a
password or with an abbreviated password?
◦ 2. Should the control panel display additional text messages?
◦ 3. How much time does the homeowner have to enter the password
from the time the first key is pressed?
◦ 4. Is there a way to deactivate the system before it actually activates?
Chapter 2 Slides by: Ms. Shree Jaswal 75
Estimation with Use-Cases◦ Use cases can be used for estimation, but only if they are
considered within the context of the “structural hierarchy”
that they are used to describe.
◦ Before use cases can be used for estimation, the level
within the structural hierarchy is established, the average
length (in pages) of each use case is determined, the
type of software (e.g., real-time, business,
engineering/scientific, WebApp, embedded) is defined,
and a rough architecture for the system is considered.
◦ Once these characteristics are established, empirical
data may be used to establish the estimated number of
LOC or FP per use case (for each level of the hierarchy).
Historical data are then used to compute the effort
required to develop the system.Chapter 2 Slides by: Ms. Shree Jaswal 76
Estimation with Use-Cases
◦ LOC estimate N x LOCavg + [(Sa/Sh – 1) + (Pa/Ph -1)] x
LOCadjust
◦ where
◦ N actual number of use cases
◦ LOCavg historical average LOC per use case for this type of
subsystem
◦ LOCadjust represents an adjustment based on n percent of
LOCavg where n is defined locally and represents the difference
between this project and “average” projects
◦ Sa actual scenarios per use case
◦ Sh average scenarios per use case for this type of subsystem
◦ Pa actual pages per use case
◦ Ph average pages per use case for this type of subsystem
Chapter 2 Slides by: Ms. Shree Jaswal 77
Estimation with Use-Cases
Chapter 2 Slides by: Ms. Shree Jaswal 78
Considering the first row of the table, historical
data indicate that UI software requires an average of
800 LOC per use case when the use case has no
more than 12 scenarios and is described in less than
five pages.
Estimation with Use-Cases
◦Using 620 LOC/pm as the average productivity
for systems of this type and a burdened labor
rate of $8000 per month, the cost per line of
code is approximately $13(i.e 8000/620).
Based on the use-case estimate and the
historical productivity data, the total
estimated project cost is $552,000(i.e.
42568x13) and the estimated effort is 68
(i.e. 42568/620) person-months.
Chapter 2 Slides by: Ms. Shree Jaswal 79
Empirical Estimation Models
• Estimation models use empirical formulae to predict effort based on size
and duration.
◦ The general model is E = A + B × (ev)C
◦ where E is the effort,
◦ A, B and C are empirically derived constants, and
◦ ev (estimation variable) is either LOC or FP
• Pressman lists seven different models, which all give different
answers for the same values of LOC or FP. This is because they are
empirical and calibrated to the local situation.
◦ One of the FP oriented models, is the linear model, in which effort is
proportional to size is: E = A + B × ev
◦ Example: E = -37 + 0.96 × FP (Kemerer regression model)
Chapter 2 Slides by: Ms. Shree Jaswal 81
COCOMO MODEL◦ Cost Constructive Model (COCOMO) was first
anticipated by Barry W. Boehm in his book in 1981.
◦ For Basic COCOMO: Effort=A × (Size) B
◦ Where, A =Constants based on different classes of
Software Projects
◦ B=Economy or Diseconomy of Scale based on
different classes of Software Projects
◦ Size= No. of Source Lines of Code (KSLOC)
◦ Basic COCOMO model is good in quick and early
estimation of software project costs.
Chapter 2 Slides by: Ms. Shree Jaswal 82
COCOMO MODEL
◦ Organic: In this mode, products are small and require less
innovation. Also products are similar to the previous
developed product in a well-known and secure
environment. For example: Any accounting system.
◦ Semidetached: The projects characteristics are in-between
organic and embedded modes. Here mixed teams
working with mix or less rigid set of requirements and
constraints.
◦ Embedded: An embedded mode project requires a great
amount of innovation. Here project is characterized by
tight, inflexible constraints and interface requirements.
Recent android apps development tools and which uses
customized hardware can be considered in this modeChapter 2 Slides by: Ms. Shree Jaswal 83
BASIC COCOMO MODEL
The basic COCOMO equations takeS the form
Effort Applied (E) = ab(KLOC)bb [ man-months ]
Development Time (D) = cb(Effort Applied)db
[months] People required (P) = Effort Applied /
Development Time [count]
where, KLOC is the estimated number of
delivered lines (expressed in thousands ) of code
for project. The coefficients ab, bb, cb and db are
given in the following table:
Chapter 2 Slides by: Ms. Shree Jaswal 84
BASIC COCOMO MODEL
Chapter 2 Slides by: Ms. Shree Jaswal 85
Advantages AND Disadvantages
Adv : Basic COCOMO model is good in quick
and early estimation of software project costs.
Disadv : The basic COCOMO Model is limited in
functionality because it doesn't consider certain
factors of cost estimation such as hardware
constraints, personnel quality and experience and
modern techniques and tools.
Chapter 2 Slides by: Ms. Shree Jaswal 86
Example
Consider a software project using semi-
detached mode with 30,000 lines of code.
Obtain the estimation for this project.
1. Effort Estimation :
2. Duration Estimation
3. Persons Estimation
Chapter 2 Slides by: Ms. Shree Jaswal 87
(1) Effort estimation
E= ab(KLOC)Exp(bb)person-months
E=3.0(30)1.12 where lines of code=30000=30 KLOC
E=135 person-month
(2) Duration estimation
D=cb(E)Exp(db)months
=2.5(135)0.35
D=14 months
(3)Person estimation
P=E/D
=135/14
P=10 persons approx
Chapter 2 Slides by: Ms. Shree Jaswal 88
COCOMO-II◦ COCOMO II is actually a hierarchy of estimation models
that address the following areas:
◦ Application composition model. Used during the early
stages of software engineering, when prototyping of
user interfaces, consideration of software and system
interaction, assessment of performance, and
evaluation of technology maturity are paramount.
◦ Early design stage model. Used once requirements
have been stabilized and basic software architecture
has been established.
◦ Post-architecture-stage model. Used during the
construction of the software.
Chapter 2 Slides by: Ms. Shree Jaswal 89
COCOMO-II
Chapter 2 Slides by: Ms. Shree Jaswal 90
Step 1: compute object points
object points = Σ (number of objects)*(weight factor)
Weight factors are listed below:
Step 2: estimate reuse percentage (%reuse), if applicable
Object typeComplexity weight
Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL component 10
COCOMO-II
Chapter 2 Slides by: Ms. Shree Jaswal 91
Application composition model:
Step 3: compute new object points (NOP)
NOP = (object points)* [(100-%reuse)/100]
Step 4: compute the estimated effort (in person-month)
Developer’s
experience/capabilityVery low Low Nominal High Very high
Environment
maturity/capabilityVery low Low Nominal High Very high
PROD 4 7 13 25 50
Estimated effort = NOP / PROD
PROD (productivity rate) is provided in the following table
THANK YOU!
Chapter 5
Slides by:Ms.Shree Jani
Top Related