Week 1

The goal of software developmentTo develop quality software – on time on

budget – that meets customers’ needHowever, our customer are quite different…

the customer is an external entityThe customer is a company that has hired us to

develop its software The customer is someone who waiting

anxiously for that new application

A look at the dataOf course some systems work well…Its also true that there is a wide spectrum of

possibilities between perfection and failureIn many cases, the results are far more

serious.

Study by Standish group.

In the USA, we spend > $250 billion/year on IT app dev of appox. 175,000 projectsLarge company $2322000Medium –$ 1331000Small – $434000

A staggering 31% of projects will be cancelled before they ever get completed

52.7% projects will cost 189% of their original estimates$81 billion for cancelled projects$59 billion s/w projects that will be completed but

will exceed their original time estimates

The root cause of project success and failureThe first step in resolving problem is to

understand the root causes.1994 Standish Group study

Lack of user input 13 % of all projects

Incomplete requirements and specification

12%

Changing requirements and specifications

12%

At least a third dev projects run into trouble for reasons that are directly related to requirements gathering

Standish group also found that9% of the projects in large companies

were delivered on time and on budget16% - in small companies also enjoyed

similar successWhat were the primary success factors?

Of all successful projectsUser involvement 16%

Executive management support 14%

Clear statement of requirements 12%)

Other results ESPITI 1995 – based on 3800 responses

The two largest problems

what is the conclusion based on those surveys?

The frequency of requirements errors

Defect origins

Defect potentials

Removal efficiency

Delivered defects

Requirements 1.00 77 0.23Design 1.25 85 0.19

Coding 1.75 95 0.09

Documentation

0.60 80 0.12

Bad fixes 0.40 70 0.12

Total 5.00 85 0.75

Both studies indicate that respondents feel that requirements problems appear to transcend other issues --- Delivered code

Study by Capers Jones -- the likely number of potential defects in a dev project and the typical efficiency in removing those defects

Requirements errors are the most common category of system development errors

The high cost of requirements errors (Davis, 1993)

.1-.2 requirements time

.5 design

1 coding

2 unit test

5 acceptance test

20 maintenance

Stages

If a unit cost of ONE is assigned to the effort required to detect and repair an error during the coding stageThe cost to detect ad repair an error during the

requirements stage is between 5- 10 times lessThe cost to detect and repair an error during

the maintenance stage is 20 times more

The relative costs of various categories of errors and the cost of fixing them at different stages in the software lifecycle

Requirements time Totally requirements errors

Design timeErrors occurred during developmentRequirements error somehow leaked into the design

phase More expensive

The design will probably have to be thrown away or reworked

The true nature of the error may be disguised… they have got the wrong requirements

Tracking the details of the requirements errorsThe person may not be readily availableMay have forgottenMay just had change of mindMay have moved

Leakage defect (Hughes Aircraft- study by Synder and Shumate)74% discovered during requirements analyst4% leak into the preliminary design7% detailed design4% maintenance

Depending on when and where a defect is discovered, 50-100 times cost Respecification Redesign Recoding Retesting Change orders Corrective action Scrap Recall of defective versions of shrink-wrapped software and

associated manual from users Warranty costs Product liability Service costs for a company rep to visit a customer’s field

location to reinstall the new s/w documentation

Data presented demonstratesRequirements errors are likely to be the most

common class of errorRequirements errors are likely to be the most

expensive errors to fix

Key pointsThe goal of software development is to develop

quality software – on time and on budget – that meets customers’ real needs

Project success depends on effective requirements management

Requirements errors are the most common type of systems development error and the most costly to fix

A few key skills can significantly reduce requirements errors and thus improve software quality

DefinitionsWhat is a software requirement

A software capability needed by the user to solve a problem to achieve an objective

A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation

What is requirements managementA systematic approach to eliciting,

organizing, and documenting the requirements of the system, and a process that establishes and maintains agreements between the customer and the project team on the changings of the system

Anyone who has ever been involved with complex systems – knows that a crucial skill is to elicit the requirements from users and stakeholders

Many requirements are likely to be associated with a system, it’s importance to organize

Documenting the requirements is necessary – effective communication among the various stakeholders

What do these elements have to do with managing requirementsSmall project vs big project

Two-person project10 requirements

1000 requirements300K requirements – a Boeing 777

QuestionsWhich project team members are responsible

for the wind speed requirements (#278), which ones are allowed to modify it or delete it?

If requirements #278 is modified, what other requirements will be affected?

How can be sure that someone has written the code in a software system to fulfill requirements #278, and which test cases in the overall test suite are intended to verify that the requirements have indeed been fulfilled?

Application of requirements management techniquesTypes of software applications

IS and other applications developed for use within a company

System developed and sold as commercial products

Software that runs on computers embedded in other devices, machines or complex systems

Systems applicationsRequirements management can also be applied

to systems development consisting many subsystems and its interrelated pieces and parts

The road mapEmbarking on a journey to develop quality

software - Many questions will ariseIs this a need or a requirement?Is this a nice-to-have or a must-have?Is this a statement of the problem or a statement

of the solution?Is this a goal of the system or a contractual

requirement?Do we have to program in Java, says who?Who doesn’t like the new system, and where was

that person when we visited here before?

We’ll need to understand where we are at any point in time

Whom we are meetingWhat language they are speakingAnd what information we need from them to

complete our journey successfully

The problem domain THE HOME OF REAL USERS AND OTHER STAKHOLDERS

Different technical and economic background

On rare occasion, they are just like us. Might be easier , might be difficult to handle

They have business and technical problems

Our problem to understand their problem in their culture, their language and to build systems that meet their needs

Stakeholder needsOur responsibility to understand the needs of users and other stakeholders whose lives will be affected by our solution

As we elicit those needs, we’ll stack them in a little pile called stakeholder needs

needs

Moving towards the solution domainProvide a solution to the problem at hand

Focus on defining a solution to the user’s problem Computers, programming, OS, networks,

processing nodes Apply all the skills we have learned

Features of the systemState what you have learned in the

problem domain and how we intend to resolve those issues via the solution

EgThe car will have power windowsDefect-trending charts will provide a

visual means of assessing progressSimple descriptions, in the user’s

languageFeature is a service provided by the

system that fulfills one or more stakeholder needs

features

Software requirementsOnce feature set have been established and

agreed with the customerDefine the more specific requirements to be

imposed on the solutionSpecific requirements is software

requirements

Subtle transition in our thinking in this process

Problem domain

Solution domain

Key pointsA requirement is a capability that is imposed on

the systemRequirements management is a process of

systematically eliciting, organizing and documenting requirements for a complex system

Our challenge is to understand users’ problem in their culture and their language and to build systems that meet their needs

A feature is a service that the system provides to fulfill one pr more stakeholder needs

A use case describes a sequence of actions, performed by a system, that yields a result of value to a user