CHAPTER 2: REQUIREMENTS ENGINEERING & COST...

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


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


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


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)


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


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


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



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


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.



3. Constrains on project plan &

development methods

◦ Development process (methodology) to be used – Eg. Particular approaches

to testing

◦ Cost and delivery date


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.


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


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


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


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.


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?


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


Determining Requirements

Some methods in determining requirements:

◦Consulting with the client

◦Facilitated Application Specification

Techniques (FAST)

◦Prototyping

◦Requirements Analysis

Details are as follows:


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?


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.


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.


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”


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:


Requirement Validation

1. Validity checks

2. Consistency checks

3. Completeness checks

4. Realism checks

5. Verifiability


Requirement Validation

◦Different req. validation techniques are:

1. Requirement reviews

2. Prototyping

3. Test case generation

4. Automated consistency analysis


Requirements Management

◦Management

◦ Identification and classification

◦Using a unique identifier for each

requirement

◦Hierarchies – sub-requirements

◦Change management

◦ Traceability


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.


Requirements change management


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.


Requirement traceability


Requirements

document

1.1 XXXX

……because

1.2 YYYY

Design document

…. Due to

Requirement 1.2

rationale

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


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


Communicating Req. - SRS

◦Purpose

◦ Communicates an

understanding of the

requirements

◦ Contractual

◦ Baseline for evaluating

subsequent products

◦ testing, V&V

◦ Baseline for change

control


◦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


Components of SRS

◦ Functionality

◦Performance

◦Design constraints imposed on an

implementation

◦External interfaces


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


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 …


Requirement Specification Languages

◦ Commonly used languages are:

1. Structured English (natural language)

2. Regular Expressions

3. Decision tables

4. Finite state automata (FSA)


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.


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.


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.


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.


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


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.


Decomposition for Estimation


• 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


• 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


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


FP Estimation Step 1


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)


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)


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


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


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.


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


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


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?


Use-Case Diagram


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


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


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?


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




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.


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


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)


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.


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:


http://en.wikipedia.org/wiki/Man-month

BASIC COCOMO MODEL


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.


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


(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


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.


COCOMO-II


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


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

CHAPTER 2: REQUIREMENTS ENGINEERING & COST...

Documents

Transcript of CHAPTER 2: REQUIREMENTS ENGINEERING & COST...