A9R58F4.Tmp

7/26/2019 A9R58F4.Tmp

1/22

SoftwareRequirementsAnalysisandSpecification

Chapter3

Topicsincludes

REQUIREMENTSDEFINED

REQUIREMENTCATEGORIES

GATHERINGREQUIREMENTS

REFININGREQUIREMENTS

RECORDINGREQUIREMENTS

VALIDATIONANDVERIFICATION

CHANGINGREQUIREMENTS

REQUIREMENTSDEFINED

Requirements are the features that your application must provide. Atthe beginning of the project, you gather requirements from the customers to

figure out what you need to build. Throughout development, you use the

requirements to guide development and ensure that youre heading in the

right direction. At the end of the project, you use the requirements to verify

that the finished application actually does what its supposed to do.

Depending on the projects scope and complexity, you might need only a few

requirements, or you might need hundreds of pages of requirements. The

number and type of requirements can also depend on the level of formality

the customers want.

REQUIREMENTSDEFINEDcont

Properties of Requirement

Clear

Unambiguous

Consistent

Prioritized

Verifiable

Words to Avoid

ComparativesWords like faster, better, more, and shinier. How

much faster? Define better. How much more?

Imprecise adjectivesWords like fast, robust, userfriendly, efficient,

flexible, and glorious. Vague commandsWords like minimize, maximize, improve, and

optimize.

7/26/2019 A9R58F4.Tmp

2/22

REQUIREMENTCATEGORIES

In general, requirements tell what an application is

supposed to do. Good requirements share certaincharacteristics (theyre clear, unambiguous, consistent,

prioritized, and verifiable), but there are several kinds

of requirements that are aimed at different audiences

or that focus on different aspects of the application. For

example, business requirements focus on a projects

highlevel objectives and functional requirements give

the developers more detailed lists of goals toaccomplish.

REQUIREMENTCATEGORIEScont

AudienceOriented Requirements. These categories focus on

different audiences and the different points of view that each audience has.They use a somewhat businessoriented perspective to classify requirements

according to the people who care the most about them.

Types:

Business Requirements. Business requirements lay out the projects highlevel

goals. They explain what the customer hopes to achieve with the project.

User Requirements. User requirements (which are also called stakeholder

requirements by managers who like to use the word stakeholder), describe how

the project will be used by the eventual end users. Functional Requirements. Functional requirements are detailed statements of the

projects desired capabilities. Theyre similar to the user requirements but they

may also include things that the users wont see directly.


Types cont

Nonfunctional Requirements. Nonfunctional requirements are statements about

the quality of the applications behavior or constraints on how it produces a

desired result. They specify things such as the applications performance,reliability, and security characteristics.

Implementation Requirements. Implementation requirements are temporary

features that are needed to transition to using the new system but that will be

later discarded. For example, suppose youre designing an invoicetracking system

to replace an existing system. After you finish testing the system and are ready to

use it full time, you need a method to copy any pending invoices from the old

database into the new one. That method is an implementation requirement.


FURPS. FURPS is an acronym for this systems requirement categories:functionality, usability, reliability, performance, and scalability. It was

developed by HewlettPackard.

Categories:

FunctionalityWhat the application should do.

UsabilityWhat the program should look like.

ReliabilityHow reliable the system should be.

PerformanceHow efficient the system should be.

SupportabilityHow easy it is to support the application.

7/26/2019 A9R58F4.Tmp

3/22


FURPS+. FURPS was extended into FURPS+ to add a few requirements

categories that software engineers thought were missing.

Categories:

Design constraintsThese are constraints on the design that are driven

by other factors such as the hardware platform, software platform,

network characteristics, or database.

Implementation requirementsThese are constraints on the way the

software is built.

Interface requirementsThese are constraints on the systems interfaceswith other systems.

Physical requirementsThese are constraints on the hardware and

physical devices that the system will use.

GATHERINGREQUIREMENTS

Listen to Customers (and Users). Learn as much as you can about

the problem they are trying to address and any ideas they may have abouthow the application might solve that problem. Initially, focus as much as

possible on the problem, not on the customers suggested solutions, so you

can keep the requirements flexible.

Use the Five Ws (and One H). Sometimes customers have troublearticulating their needs. You can help by using the five Ws (who, what, when,

where, and why) and one H (how).

Study Users. Interviewing customers (and users) can get you a lot ofinformation, but often customers (and users) wont tell you everything they

do or need to do. They often take for granted details that they consider trivial

but that maybe important to the development team

GATHERINGREQUIREMENTScont

Who? Ask who will be using the software and get to know as much asyou can about those people. Find out if the users and the customers are

the same and learn as much about the users as you can.

What? Figure out what the customers need the application to do. Focuson the goals as much as possible rather than the customers ideas about

how the solution should work.

When?Find out when the application is needed. If the application willbe rolled out in phases, find out which features are needed when.

Where? Find out where the application will be used.

Why? Ask why the customers need the application

How? Consider customer ideas.

REFININGREQUIREMENTS

Copy Existing Systems. If youre building a system to replace anexisting system or a manual process, you can often use many of the behaviors

of the existing system as requirements for the new one. If the old system

sends customers emails on their birthdays, you can require that the new

system does that too.

Clairvoyance. This technique is particularly effective if the project leadhas previously built a similar system. In that case, the lead already knows

more or less what the application needs to do, which things will be easy and

which will be hard, how much time everything requires, and which kinds of

donuts motivate the programmers the best.

7/26/2019 A9R58F4.Tmp

4/22

7/26/2019 A9R58F4.Tmp

5/22

RECORDINGREQUIREMENTScont

Prototypes. A prototype is a mockup of some or all of the application.

The idea is to give the customers a more intuitive hands

on feel for what thefinished application will look like and how it will behave than you can get

from text descriptions such as user stories and use cases.

Requirements Specification. These typically list major categoriesof requirements such as user documentation, user interface design, and

interfaces with other systems.

VALIDATIONANDVERIFICATION

Requirement validation is the process of making sure that the

requirements say the right things. Someone, often the customers or users,need to work through all the requirements and make sure that they: (1)

Describe things the application should do. (2) Describe everything the

application should do.

Requirement verification is the process of checking that thefinished application actually satisfies the requirements.

Validation Are we doing the right things?

VerificationAre we doing the things right?

CHANGINGREQUIREMENTS

In many projects, requirements evolve over time. As work

proceeds, you may discover that something you thought would

be easy is hard. Or you may stumble across a technique that lets

you add a highvalue feature with little extra work. Often

changes are driven by the customers. After they start to see

working pieces of the application, they may think of other items

that they hadnt thought of before.

You can help control the number of changes by creating a

change control board. Customers (and others) can submit

change requests to this board (which might actually be a single

person) for approval. The board decides whether a changeshould be implemented or deferred to a later release.

EndofChapter3

7/26/2019 A9R58F4.Tmp

6/22

SoftwareProjectPlanning

Chapter4

Topicsincludes

ProcessPlanning

EffortEstimation

ProjectSchedulingandStaffing

SoftwareConfigurationManagementPlan

ProcessPlanning

After the finalization of SRS, we would like to estimate size,

cost and development time of the project. Also, in many

cases, customer may like to know the cost and development

time even prior to finalization of the SRS

In order to conduct a successful software project, we must

understand:

1. Scope of work to be done

2. Software Project Planning

3. The risk to be incurred

4. The resources required

5. The task to be accomplished6. The cost to be expended

7. The schedule to be followed

ProcessPlanningcont

Goodprojectmanagementandgoodengineeringare

essential.

Projectmanagement

activities

can

be

viewed

as

havingthreemajorphases:1. Projectplanning,

2. Projectmonitoringandcontrol,and

3. Projecttermination

7/26/2019 A9R58F4.Tmp

7/22

ProcessPlanningcont

Importance of Planning

Without a proper plan, no real monitoring or controlling of the project ispossible.

1. Often projects are rushed toward implementation with not enough timeand effort spent on planning.

2. No amount of technical effort later can compensate for lack of carefulplanning.

3. Lack of proper planning is a sure ticket to failure for a large softwareproject.

The basic goal of planning is to look into the future, identify the activities thatneed to be done to complete the project successfully, and plan the schedulingand resources.

The inputs to the planning activity are the requirements specification andthe architecture description.

ProcessPlanningcont

Majorissuesprojectplanningaddress

Processplanning

Effortestimation

ScheduleandResourceEstimation

Qualityplans

Configurationmanagementplans

Riskmanagement

Projectmonitoringplans

ProcessPlanningcont

Process Planning A key activity is to plan and specify the process that should be used

in the project.

specifying the various stages in the process,

the entry criteria for each stage,

the exit criteria,

and the verification activities that will be done at the end of the stage.

The process planning activity mostly entails selecting a standardprocess and tailoring it for the project. The common tailoringactions are modify a step, omit a step, add a step, or change theformality with which a step is done.

ProcessPlanningcont

Process specification for the project

This process guides rest of the planning, particularly

detailed scheduling where detailed tasks to be donein the project are defined and assigned to people to

execute them.

Goback

7/26/2019 A9R58F4.Tmp

8/22

EffortEstimation

For a given set of requirements it is desirable to

know how much it will cost to develop the software,and how much time the development will take.

The primary reason for cost and schedule estimationis costbenefit analysis, and project monitoring andcontrol.

A more practical use of these estimates is in biddingfor software projects, where cost estimates must be

given to a potential client for the developmentcontract.

EffortEstimationcont

The bulk of the cost of software development is due

to the human resources needed, and therefore mostcost estimation procedures focus on estimating

effort in terms of personmonths (PM).

By properly including the "overheads" (i.e., the cost

of hardware, software, office space, etc.) in the cost

of a personmonth, effort estimates can be

converted into cost.


1. Uncertainties in Effort Estimation

As the effort of the project depends on the nature and

characteristics of the project, at any point, the accuracy

of the estimate will depend on the amount of reliable

information we have about the final product.

Specifications with uncertainty represent a range of

possible final products, not one precisely defined

product.

Hence, the effort estimation based on this type of

information cannot be accurate.

Estimates at this phase of the project can be off by asmuch as a factor of four from the actual final effort


Accuracy of effort estimation

7/26/2019 A9R58F4.Tmp

9/22


2. Building Effort Estimation Models

An estimation model can be viewed as a "function" that

outputs the effort estimate, clearly this estimation

function will need inputs about the project, from which it

can produce the estimate.

The basic idea of having a model or procedure for

estimation is that it reduces the problem of estimation to

estimating or determining the value of the "key

parameters" that characterize the project, based on

which the effort can be estimated.


2. Building Effort Estimation Models cont

One common approach therefore for estimating effort is

to make it a function ofproject size, and the equation of

effort is considered as EFFORT = a*SIZEb, where a and b

are constants, and project size is generally in KLOC or

function points. Values for these constants for a

particular process are determined through regression

analysis, which is applied to data about the projects that

has been performed in the past.


Static,SingleVariableModels


Static,MultivariableModels

7/26/2019 A9R58F4.Tmp

10/22


Example 1

Compare the Walston

Felix model with the SEL model on asoftware development expected to involve 8 personyears

of effort.

1. Calculate the number of lines of source code that can be

produced.

2. Calculate the duration of the development.

3. Calculate the productivity in LOC/PY4. Calculate the average manning


EffortEstimationcont EffortEstimationcont

7/26/2019 A9R58F4.Tmp

11/22


Topdown approach

Often, however, simple productivity may be used todetermine the overall estimate from the size. That is, ifproductivity is P KLOC/PM, then effort estimate for theproject may be SIZE/P personmonths. This approach willwork if the size and type of the project are similar to theset of projects from which the productivity P wasobtained.

This approach of determining total effort from the totalsize is what we refer to as the topdown approach, as

overall effort is first determined and then from this theeffort for different parts are obtained.


Bottomup approach

A somewhat different approach for effort estimation is

thebottomup approach.In this approach, the project is

first divided into tasks and then estimates for thedifferent tasks of the project are first obtained. This typeof approach is also called activitybased estimation.

The bottomup approach lends itself to direct estimationof effort; once the project is partitioned into smallertasks, it is possible to directly estimate the effortrequired for them, specially if tasks are relatively small. Arisk of bottomup methods is that one may omit some

important activities in the list of tasks.


3. A BottomUp Estimation Approach The procedure for estimation can be summarized as the following

sequence of steps:1. Identify modules in the system and classify them as simple, medium,

or complex.2. Determine the average coding effort for simple/medium/complex

modules.

3. Get the total coding effort using the coding effort of different types ofmodules and the counts for them.

4. Using the effort distribution for similar projects, estimate the effort forother tasks and the total effort.

Refine the estimates based on projectspecific factors.

Note that this method of classifying programs into a fewcategories and using an average coding effort for eachcategory is used only for effort estimation.


4. COCOMO Model Constructive COst MOdel (COCOMO) developed by Boehm,

This model also estimates the total effort in terms of personmonths.

The basic steps in this model are:

1. Obtain an initial estimate of the development effort from theestimate of thousands of delivered lines of source code (KLOC).

2. Determine a set of 15 multiplying factors from differentattributes of the project.

3. Adjust the effort estimate by multiplying the initial estimate withall the multiplying factors.

7/26/2019 A9R58F4.Tmp

12/22



7/26/2019 A9R58F4.Tmp

13/22


Example2


7/26/2019 A9R58F4.Tmp

14/22


Example3



5.IntermediateModel

7/26/2019 A9R58F4.Tmp

15/22


5.IntermediateModelcont



7/26/2019 A9R58F4.Tmp

16/22



7/26/2019 A9R58F4.Tmp

17/22



Example 4

A new project with estimated 400 KLOC embedded system has to

be developed. Project manager has a choice of hiring from twopools of developers: Very highly capable with very little

experience in the programming language being used

Or

Developers of low quality but a lot of experience with the

programming language. What is the impact of hiring all

developers from one or the other pool ?


7/26/2019 A9R58F4.Tmp

18/22


Example5


7/26/2019 A9R58F4.Tmp

19/22


Goback

ProjectSchedulingandStaffing

1. Overall Scheduling

One method to determine the normal (or nominal)

overall schedule is to determine it as a function ofeffort. Any such function has to be determinedfrom data from completed projects using statisticaltechniques like fitting a regression curve throughthe scatter plot obtained by plotting the effort andschedule of past projects. This curve is generallynonlinear because the schedule does not growlinearly with effort.

ProjectSchedulingandStaffingcont

Manpower rampup in a

typical project. The percentage of the schedule

consumed in the design and testingphases exceeds their effortpercentages.

The exact schedule depends on theplanned manpower rampup, and howmany resources can be used effectivelyin a phase on that project.

Generally speaking, design requiresabout a quarter of the schedule, buildconsumes about half, and integrationand system testing consume the

remaining quarter. COCOMO gives 19% for design, 62% for

programming, and 18% for integration.

7/26/2019 A9R58F4.Tmp

20/22


2. Detailed Scheduling

The major tasks fixed while planning the milestonesare broken into small schedulable activities in a

hierarchical manner.

The detailed design phase can be broken into tasks for

developing the detailed design for each module, review of

each detailed design, fixing of defects found, and so on.

For each detailed task, the project manager estimates the

time required to complete it and assigns a suitable resource

so that the overall schedule is met.


2. Detailed Scheduling cont The project manager determines the effort for the overall

task from the detailed schedule and checks it against theeffort estimates.

Activities related to tasks such as project management,coordination, database management, and configurationmanagement may also be listed in the schedule, eventhough these activities have less direct effect ondetermining the schedule because they are ongoing tasksrather than schedulable activities.

A detailed project schedule is never static. Changes may be

needed because the actual progress in the project may bedifferent from what was planned, because newer tasks areadded in response to change requests, or because of otherunforeseen situations.


3a. An Example.Highlevel schedule for the project


3b. An Example.Portion of the detailed schedule

7/26/2019 A9R58F4.Tmp

21/22

ProjectSchedulingandStaffingcont4. Team Structure Detailed scheduling is done only after actual assignment of

people has been done, as task assignment needsinformation about the capabilities of the team members.

In this hierarchical organization, the project manager isresponsible for all major technical decisions of the project.He does most of the design and assigns coding of thedifferent parts of the design to the programmers.

The team typically consists of programmers, testers, aconfiguration controller, and possibly a librarian fordocumentation.

There may be other roles like database manager, networkmanager, backup project manager, or a backupconfiguration controller.

It should be noted that these are all logical roles and oneperson may do multiple such roles.


Egoless teamsTeam Structure.

A different team organization is the egoless team :Egoless teams consist of ten or fewer programmers.

The goals of the group are set by consensus, and

input from every member is taken for major

decisions.

Group leadership rotates among the group

members. Due to their nature, egoless teams aresometimes calleddemocratic teams.


Software development Management related,

Development related, and Testing related.

Inthisstructure,consequently,thereisanoverallunitmanager,

under

whom

there

are

three

small

hierarchicorganizationsforprogrammanagement,fordevelopment,andfortesting. Theprimaryjobofdevelopersistowritecodeandtheywork

underadevelopmentmanager.

Theresponsibilityofthetestersistotestthecodeandtheyworkunderatestmanager.

Theprogrammanagersprovidesthespecificationsforwhatisbeingbuilt,andensurethatdevelopmentandtestingare

properlycoordinated.

Goback

SoftwareConfigurationManagement

Plan

The SCM plan, like other plans, has to

identify the activities that must be

performed, give guidelines for performingthe activities, and allocate resources for

them.

Planning for configuration management

involves identifying the configuration items

and specifying the procedures to be used for

controlling and implementing changes to

them.

7/26/2019 A9R58F4.Tmp

22/22

SoftwareConfigurationManagement

Plancont

Configuration Management

To summarize, the configuration controller does the CM planning whenthe project has been initiated and the operating environment andrequirements specifications are known. The activities in this stageinclude the following: Identify configuration items, including customersupplied and purchased items.

Define a naming scheme for configuration items.

Define the directory structure needed for CM.

Define version management procedures, and methods for tracking changes toconfiguration items.

Define access restrictions.

Define change control procedures.

Identify and define the responsibility of the CC.

Identify points at which baselines will be created.

Define a backup procedure and a reconciliation procedure, if needed.

Define a release procedure.

EndofChapter4

Documents

A9R58F4.Tmp