Software Quality. Unit 6: System Quality Requirements

Transcription

1 Software Quality Unit 6: System Quality Requirements

2 System Requirements 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.

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

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

5 Definitions 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).

6 Requirement Classification 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.

7 System Requirements 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.

8 Look and Feel, product appearance. Usability. Operativity. Execution, aspects like availability, fastness, efficiency, Security. Maintainability. Non Functional Requirements

9 Requirements evolution 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.

10 Requirements evolution Case of Use Scenarios To understand work Functional Requirements Non functional Requirements Restrictions To understand product Technical Specification Technical Requirements

11 Requirement Management 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.

12 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?

13 Requirement Verification 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.

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

15 Requirement Verification 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.

16 Specification Review 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.

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

18 Risks 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.

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

20 Face up to 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.

21 Risks Estimation 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.

22 Risk Calculation 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.

23 Business Impact Criteria Processes Type Results High Impact Medium Impact Low Impact Calculus Validation Data change Visualization Business implications Legal Incorrect Information None Frequency of use Very frequent Often Rare # affected customers Very important Group some

24 Fault Probability Criteria Results Slightly Probable Probable Very Probable Change rate Without changes Changing function New function Software maturity Mature (>10 years) In progress (5-10 years) Immature (<5 years) Defect rate Low Medium High

25 Categories Calculation Criteria Results 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

26 Risks Types 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.

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

28 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

29 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).

30 Risks Types 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.

31 Risk Management 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.