unit 6: system quality...

Unit 6: System Quality Requirements

Software Quality

Calidad del Software

• Best products, from users point of view,

are those which have been developed

considering organizational needs, and how

product is going to help users in their work.

• Hence, to be successful, we must to study

in a very special way product

requirements.

System Requirements


• Product requirements must be understood by

clients and developers before design phase

and product development. This is the only

way to be sure that product will fulfill user

needs.

• According to USA Standard and Technology

Institute, imprecise and controversial

requirements produce the 70% of system

defects.

System Requirements


• Searching requirement process can be

viewed like a very detailed product

exploration to discover its behavior and its

functionality. This process produces a

written technical product description,

which finally will origin product design.

• Requirements are a statement about

business needs, without any predisposition

about implementation.

System Requirements


Requirement: It is a condition or characteristic that

must be satisfied by a system or by a component of

the system in order to fulfill a contract, standard,

specification or any other document formally imposed

(Spanish Association for Quality - AECC).

Functional Requirement: Requirement specifying the

function that a system must be able to perform

(AECC).

Operational Requirement: Requirement specifying a

running characteristic that the system must have

(AECC).

Definitions


• Functional Requirements: They describe “what” product does from the business point of view.

• Non Functional Requirements: They describe “qualities” the product must have to be attractive, useful, fast, reliable and secure.

• Restrictions specify product developing boundaries on time, costs, human resources, etc.

Requirement Classification


• Non functional requirements are as

important as functional requirements.

• Non functional properties, like usability,

can be the difference between an

accepted and liked product or a non useful

product to the customer.

System Requirements


• Look and Feel, product appearance.

• Usability.

• Operativity.

• Execution, aspects like availability,

fastness, efficiency, …

• Security.

• Maintainability.

Non Functional

Requirements


To identify requirements, they are used:

Prototypes: they are a draft of a system or a

part.

•High fidelity prototypes, using special tools.

•Low fidelity prototypes, using pencil and

paper.

•Scenarios: they are a step by step description of

the functionality of a case of use.

Requirements evolution


Requirements evolution

Case

of Use

Technical

Specification

Scenarios

Functional

Requirements

Non functional

RequirementsRestrictions

To understand

work

To understand

product

Technical

Requirements


• Requirement definition is a very difficult

task, but it is crucial for product final

quality. Hence take your time to do it.

• Requirement from successful system can be

reused.

• Once specification is finished, they are

revised with stakeholders.

Requirement Management


The requirements elicitation process must

also be reviewed in joining meetings of all

actors :

•What did we well?

•What did we wrong?

•If we will have to do it again, what will

we do different?

Requirement Management


Due to a good requirement specification

importance, it is needed to include

requirement verification as a stage in the

product quality life cycle.

To achieve this goal, every requirement

must pass through “quality door” before

enter in the specification.

Requirement Verification


• Quality doors are established in such a way

that only a small set of people validate the

characteristic of each one of the

requirements -relevance, coherence,

traceability, testability- before

incorporating them into the specification.



Target to achieve:

• To validate that requirements are correct

and complete.

• To associate requirements to business

functions.

• To remove ambiguities.

• To validate that every requirement can be

tested.



• Once requirement specification has been

completed, it must be reviewed.

• The whole specification gives us a

precise view of the product extension or

importance, and functionality.

• This specification must permit project

cost and risk reviews.

Specification Review


• During this phase, it is known

requirement associated to project risks.

For example: do we develop the product

with a new technology or with a

technology never used before?

• To review risk calculus at this point could

be useful to reach the success.

Specification Review


• A risk can be defined as a variation of the

expected results. This variation can be many

times of a random character, and it is out of

control from decision taken. Hence, it generates

an uncertainty problem.

• Every project implies risks. In general, risks are

damaging if they are ignored, and they can

generate problems.

Risks


They can be composed by:

• Random unexpected: which is the value or

behavior that the random variable could

take to which the project faces.

• Vulnerability: which is how vulnerable is the

project with respect to one of the random

unexpected behaviors.

Risks


• Reactive manner: only when problems

occur reaction is produced.

• Proactive manner: risks are

prevented, contingency plans have

been implemented. Prevention and

anticipation are wanted.

Face up to Risks


Every project has to estimate the possibility of risk becomes as a real fact. Negative consequences have to be also considered when you think on the risk level associated to a project.

To calculate business risk it has be determined and valuated negative consequences due to a fault, and also the probability of fault occurrence.

Risks Estimation


Risk assessment is done in two phases:

•To estimate for every business function its

impact in case of fault. In this context,

impact represents damage caused to the

business.

•To calculate the probability of fault per

every business function.

Risk Calculation


Business Impact

CriteriaResults

High Impact Medium Impact Low Impact

Processes TypeCalculus

ValidationData change Visualization

Business

implicationsLegal

Incorrect

InformationNone

Frequency of use Very frequent Often Rare

# affected

customersVery important Group some


CriteriaResults

Slightly Probable Probable Very Probable

Change rate Without changesChanging

functionNew function

Software

maturity

Mature

(>10 years)

In progress

(5-10 years)

Immature

(<5 years)

Defect rate Low Medium High

Fault Probability


Categories Calculation

CriteriaResults

Slightly Probable Probable Very Probable

Alto impacto Medium risk High risk High risk

Impacto medio Low risk Medium risk Medium risk

Bajo impacto Low risk Low risk Medium risk


PROJECT RISKS

Unforeseen or events which provoke delays in the completion of activities generating a possible delay at the ending of the project.

They are caused by:

• Budget.

• Staff.

• Planning.

• Resources.

• Clients and requirements.

Risks’ Types


Risks’ Types

PRODUCT RISKS

Possibility that the system or software could fail and does not satisfy customer’s needs, or expectations from people related to the project.

Not satisfactory software generally can omit some key functions which have been specified by the client, or that are needed by users or that have been promised by business agents.


Risks’ Types

TECHNICAL RISKS

It threatens quality and planning of the

developed software making difficult or

impossible any implementation.

Influential factors are:

• Problems of design and implementation.

• Of Cross-check and Maintenance.

• Technical uncertainty…


Risks’ Types

BUSINESS RISKS

• To develop a product that nobody wants or needs

(market risk).

• To develop a product that does not fit into the

strategic plan of the company (strategic risk).

• To develop products that we don’t know how to sell

them (strategic risk).

• Loss of support for changes of targets or staff (risk

of direction).

• To lose the budget or assigned personnel (risk of

budget).

Risk identification is a systematical attempt

to specify the threats to the project plan

(estimations, temporary planning, load of

resources, etc.). Identifying the well-known

and predictable risks, the project manager

can to avoid them when it is possible and to

control them when it is necessary.


Risks’ Types


Risks management carries out an evaluation of the most common project’s risks, defining an action plan.Among undesirable risks we can find out:• Bad management.• Metric inaccurate.• Pressure in delivery dates.• Inadequate measures.• Incorrect cost estimation.

Risk Management

unit 6: system quality...

Documents