Download - ESOF-Engenharia de Requisitos

8/2/2019 ESOF-Engenharia de Requisitos

1/29

FEUP, MIEIC, SOFTWARE ENGINEERING

SOFTWARE REQUIREMENTSENGINEERING

Joo Pascoal Faria, 10/11/2011

Index

Scope and importance of requirements engineering

Software requirements

Requirements engineering process

Requirements engineering in the Rational UnifiedProcess

2


2/29

Scope and importance of requirements

engineering3

What is requirements engineering?4


3/29

What is requirements engineering? The process of studying user needs to arrive at a

definition of system, hardware, or softwarerequirements.

(Adpated from IEEE Standard Glossary of Software EngineeringTerminology IEEE Std 610.12-1990)

Set of activities concerned with identifying andcommunicating the purpose of a software-intensivesystem, and the contexts in which it will be used.

(Steve Easterbrook, FoRE, 2004)

5

Importance of RE: critical project

success factors

( source: Standish group CHAOS report)

1 User Involvement 16 %

2 Executive Management Support 14 %

3 Clear Statement of Requirements 13 %

4 Proper Planning 10 %

5 Realistic Expectations 8 %6 Smaller Project Milestones 8 %

7 Competent Staff 7 %

8 Ownership 5 %

9 Clear Vision & objectives 3 %

10 Hard-working, Focused Staff 2 %

11 Other 14 %

6


4/29

Importance of RE: sources of bugs Bugs are caused for

numerous reasons,

but the main cause

can be traced to

the (requirements)

specification

7

(source: "Software Testing", Ron Patton)

Importance of RE: cost of bugs

((source: "SoftwareProject Survival Guide",Steve McConnell)

8


5/29

When RE is not properly done

Software Requirements10


6/29

What is a (software) requirement? A software requirement is a property which must be

exhibited by software developed or adapted to solve a

particular problem. [Guide to the Software Engineering Body of Knowledge]

Requirement. [IEEE Standard Glossary of Software Engineering Terminology (1990) ]

1. A condition or capability needed by a user to solve a

problem or achieve an objective.

2. A condition or capability that must be met or possessed by

a system or system component to satisfy a contract,standard, specification, or other formally imposed

documents.

3. A documented representation of a condition or capability

as in (1) or (2).

11

What versus How

Requirements should focus the whatinstead of the how.

Sometimes the frontier is not clear. As a rule of thumb,

requirements end where the freedom of the developer

starts (and vice-versa)

12

What How


7/29

Levels of requirements Business requirements represent high-level objectives of the organization

or customer who requests the system

Usually captured in vision and scope document

User requirements describe user goals or tasks that the user must be able

to perform with the product

May be captured in use case models

System requirements are the requirements for the system as a whole

(which frequently include hardware & software components)

Usually captured in a system requirements specification document

Software requirements are derived from system requirements (by

allocating system req.s to software components and detailing them)

Usually captured in a software requirements specification (SRS) document

influence

13

Types of requirements

Functional requirements describe the functions that the

software is to execute

Also known as capabilities

Example: The system shall send an e-mail notification to the customer when

the items he/she ordered are dispatched Nonfunctional requirements are the ones that act to constrain

the solution

Also known as constraints or quality requirements

Can be further classified according to the quality attributes (see next)

Can also include (development) process requirements

Example: The maximum system down-time should be 8 hours per year

14


8/29

Quality requirements and ISO/IEC 9126

Defines quality characteristics and sub-characteristics as well

as quality metrics

Distinguishes three views of software product quality:

Internal Quality: totality of characteristics of the software product from

an internal view during its development or maintenance

External Quality: totality of characteristics of the software product from

an external view during its execution

Quality in Use: users view of the quality of the software product whenit is used in a specific environment and a specific context of use. It

measures the extent to which users can achieve their goals in a

particular environment, rather than measuring the properties of the

software itself.

15

ISO/IEC 9126: Quality model framework

16


9/29

ISO/IEC 9126: Quality characteristics (1)

subcharacteristics

characteristics

17

+availability

ISO/IEC 9126: Quality characteristics (2)

Functionality - The capability of the sw product to provide functions which

meet stated and implied needs when the sw is used under specified conditions.

Reliability - The capability of the sw product to maintain a specified level of

performance when used under specified conditions.

Usability- The capability of the sw product to be understood, learned, used& attractive to the user, when used under specified conditions.

Efficiency - The capability of the sw product to provide appropriate

performance, relative to the amount of resources used, under stated conditions.

Maintainability - The capability of the sw product to be modified.

Modifications may include corrections, improvements or adaptation of the sw

to changes in environment, & in requirements and functional specifications.

Portability - The capability of the sw product to be transferred from one

environment to another.

18


10/29

Requirements engineering processes19

Requirements engineering

(Software Requirements, Karl E. Wiegers, 2003)

20


11/29

Requirements development

Requirements Engineering Processesand Techniques, Gerald Kotonya, IanSommerville, 1998

21

Requirements elicitation (1)22


12/29


13/29

Stakeholders Interessados no sistema"

Pessoas que sero afectadas pelo sistema e que tm uma influncia directa

ou indirecta na elaborao dos requisitos:

Cliente

Utilizadores finais

Gestores e outros envolvidos nos processos organizacionais que o sistemainfluencia

Responsveis pelo desenvolvimento e manuteno do sistema

Clientes da organizao que possam vir a usar o sistema

Organismos de regulao e certificao, etc.

Exemplo num sistema automtico de sinalizao ferroviria:

operadores do sistema, condutores dos comboios, gestores, passageiros,

engenheiros de instalao e manuteno, autoridades de certificao e

segurana

25

Elicitation by Prototyping

A prototype is an initial/primitive version of a

system

Cheaper, easier and faster to develop than the real

system

Limited functionality User interface prototypes give an early preview

of what the final system will look and work like

Better comprehension and validation of requirements

Reduced requirements uncertainty

Can be developed in several technologies

UI Prototype

User Needs

Requirements

26


14/29

Throwaway & Evolutionary Prototyping

Throwaway prototyping

Support for requirements elicitation (and initial UI design) only

Allows focusing on requirements rather than implementation constraints

Appropriate for clarifying requirements that are more difficult to

understand

Evolutionary prototyping

The objective is to produce a running system as soon as possible to the

customer

Appropriate for rapid, iterative, application development, with strongend user involvement, and little or no separation between analyst,

designer and programmer

De prottipo em prottipo at ao produto final

27

Paper Prototypes

Quick, easy and

cheap to develop

Low fidelity

Usually the

preferred

approach for

requirements

elicitation

http://www.youtube.com/watch?v=5Ch3VsautWQ

EXCELENTE!

28


15/29

Computer-Based Prototypes More time, skills

and cost to

develop

Higher fidelity

Functional,

evolutionary

prototype

Or non-functional,

throwaway

drawings and

mockups http://www.mockupscreens.com/index.php?page=Screen-Prototypeshttp://www.youtube.com/watch?v=B8zNyEkCiGo&feature=related

29

Social Observation and Analysis

Many systems are developed to support people work

People often find it difficult to tell how they perform tasks andwork with others

When tasks become routine and people don't think much aboutthem consciously, it is hard to verbalize how the work is done

Example: Try to explainhow to tie your shoelaces

Requirements can be derived from the external observationof the routine way and tactics of work

http://www.videojug.com/film/how-to-tie-your-shoelaces

30


16/29

Goal analyses Hierarchical decomposition of stakeholder goals to derive

system and software requirements

Goal versus Requirement

Goal - a desired state (e.g., increase web sales by 10% in 2 years)

Requirement - a desired or needed property of a system (for reaching

a goal)

Benefits of focusing on the notion of goals in RE:

Helping identifying requirements (ask why, how)

Helping justifying the presence of requirements

Helping detecting and resolving requirements conflicts

31

Goal analyses example (elevator)32


17/29

Requirements analysis (1) Goals:

Detect and resolve conflicts between requirements

Discover the bounds of the software and how it must

interact with its environment

Elaborate system requirements to derive software

requirements

Techniques Requirements classification and prioritization

Modeling

33

Requirements analysis (2)

Kotonya, 1998

34


18/29

Characteristics of good requirements and

requirements specifications (1)35

Characteristics of good requirements and

requirements specifications (2)

Characteristic What to consider

CompleteIs anything missing or forgotten? Is it thorough? Does it include

everything necessary to make it stand alone?

Correct Is it factual?

ConsistentIs the description of the feature written so that it doesn't conflict

with itself or other items in the specification?

UnambiguousIs the description exact and not vague? Is there a singleinterpretation? Is the description clear?

NecessaryIs the feature within the system scope? Is the feature traceable to an

original customer need? Is the statement necessary to specify the

feature? Is there extra information that should be left out?

FeasibleCan the feature be implemented with the available personnel, tools,and resources within the specified budget and schedule?

Implementation-free

Does the specification stick with defining the product and not the

underlying software design, architecture, and code? (What instead of

how)

VerifiableCan the feature be tested? Is enough information provided that atester could create tests to verify its operation?

Mostproblemshere!

36


19/29

Exerccio identificar problemas()

Requisitos de Sistema de Voto Electrnico Presencial

Complete

Correct

Consistent

Unambiguous

Necessary

Feasible

Implementatio

n-

free

Verifiable

R1. O sistema deve garantir o anonimato do voto.

R2. O sistema deve garantir a unicidade do voto.

R3. O sistema deve garantir a no coercibilidade do voto.

R4. O sistema deve contar os votos correctamente e deve permitira recontagem por no especialistas informticos.

R4. O sistema deve permitir a mobilidade, isto , deve permitir

que um cidado vote em qualquer local de voto.

R5. O sistema deve ser fcil de usar por qualquer cidado, semerros, nem necessidade de aprendizagem.

R6. O sistema deve ser acessvel a pessoas com deficincias.

R7. O sistema deve ter 100% fivel e 100% disponvel.

R8. O sistema deve ser seguro (protegido contra fraudes).

37

System models are usefull to

Document requirements (better synthesis and formalization)

Organize requirements

Analyze requirements (detect ambiguities, conflicts and omissions)

Help eliciting new requirements (make questions)

Examples of useful UML models

Use case models clarify system context, users and services

Domain models clarify relationships among concepts in the domain;capture information requirements

Business process models useful when we are developing an informationsystem to support the business/organizational processes

Role of models in requirements eng.38


20/29

Requirements specification Produce a Software Requirements Specification (SRS) document and

accompanying artifacts

Documents SRS document

Preliminary user manual

Glossary (business and technical terms)

Tables and matrices Requirements attributes tables

Traceability matrices

Prototypes User-interface prototypes

Models Use case models + Domain models

Data-flow diagrams (DFDs) + Entity-relationship diagrams (ERDs)

Formal models

39

SRS Template (1)

IEEE Std 830-1998 - Recommended Practice for Software Requirements Specifications

40


21/29

SRS Template (2)

. . .

May be use cases

Template of SRS Section 3 organized by feature

41

Requirements validation

Goals Demonstrate that the requirements define the system that the

customer really wants

Motivation Requirements error costs are high so validation is very important

Fixing a requirements error after delivery may cost up to 100times the cost of fixing an implementation error

Techniques Requirements reviews

Prototyping

Model validation

Acceptance test case generation

42


22/29

Requirements management (1)

Walking on water and developing software from aspecification are easy . -Edward V. Berardif both are frozen

43


(Software Requirements, K.E.Wiegers)

(the currently agreed-upon

body of requirements)

44


23/29


(Software Requirements, K.E.Wiegers)

(*) proposed, approved, implemented, verified, rejected,

(*)

45

Requirements engineering in the

Rational Unified Process46


24/29

Requirements Engineering (RE) in RUP

Platform independent

model (PIM)

Platform specific

model (PSM)

47

RE in RUP: Activities48


25/29

RE in RUP: Artifacts49

References and further reading

Software Engineering, Ian Sommerville, 9th Edition, chapter 4 Requirements Engineering

Software Requirements, 2nd Ed, Karl E. Wiegers, Microsoft Press, 2003

Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004edition, IEEE Computer Society

IEEE Std 830-1998 - Recommended Practice for Software RequirementsSpecifications

IEEE Std 610.12: 1990 - Standard Glossary of Software EngineeringTerminology

ISO/IEC 12207 - Information technology - Software life cycle processes

ISO/IEC Std 9126 - Software Engineering - Product Quality

50


26/29

Appendix A Additional definitions51

Functionality

Functionality - The capability of the software product to providefunctions which meet stated and implied needs when the software isused under specified conditions. Suitability - The capability of the software product to provide an

appropriate set of functions for specified tasks and user objectives.

Accuracy - The capability of the software product to provide the rightor agreed results or effects with the needed degree of precision.

Interoperability - The capability of the software product to interact withone or more specified systems.

Security - The capability of the software product to protect informationand data so that unauthorised persons or systems cannot read or modifythem and authorised persons or systems are not denied access to them.

Functional Compliance - The capability of the software product toadhere to standards, conventions or regulations in laws and similarprescriptions relating to functionality.

52


27/29

Reliability Reliability - The capability of the software product to

maintain a specified level of performance when used underspecified conditions. Maturity - The capability of the software product to avoid failure

as a result of faults in the software. Frequency of failure

Fault tolerance - The capability of the software product tomaintain a specified level of performance in cases of softwarefaults or of infringement of its specified interface.

Recoverability - The capability of the software product to re-establish a specified level of performance and recover the datadirectly affected in the case of a failure.

Reliability compliance - The capability of the software productto adhere to standards, conventions or regulations relating toreliability.

Note: Availability is considered a combination of maturity, fault tolerance and recoverability

53

Usability

Usability - The capability of the software product to beunderstood, learned, used and attractive to the user, whenused under specified conditions. Understandability - The capability of the software product to

enable the user to understand whether the software is suitable,

and how it can be used for particular tasks and conditions of use. Learnability - The capability of the software product to enable

the user to learn its application.

Operability - The capability of the software product to enablethe user to operate and control it.

Attractiveness - The capability of the software to be attractiveto the user

Usability compliance - The capability of the software product toadhere to standards, conventions, style guides or regulationsrelating to usability.

Note: Usually combined with accessibility, particularly in the web

54


28/29

Efficiency Efficiency - The capability of the software product to

provide appropriate performance, relative to the amount ofresources used, under stated conditions.

Time behavior - The capability of the software product toprovide appropriate response and processing times andthroughput rates when performing its function, under statedconditions.

Resource utilization - The capability of the software product touse appropriate amounts and types of resources when the

software performs its function under stated conditions. Efficiency compliance - The capability of the software product

to adhere to standards or conventions relating to efficiency.

55

Maintainability

Maintainability - The capability of the software product to bemodified. Modifications may include corrections, improvements oradaptation of the software to changes in environment, and inrequirements and functional specifications. Analyzability - The capability of the software product to be diagnosed

for deficiencies or causes of failures in the software, or for the parts tobe modified to be identified.

Changeability - The capability of the software product to enable aspecified modification to be implemented.

Stability - The capability of the software product to avoid unexpectedeffects from modifications of the software.

Testability - The capability of the software product to enable modifiedsoftware to be validated.

Maintainability Compliance - The capability of the software product toadhere to standards or conventions relating to maintainability.

56


29/29

Portability Portability - The capability of the software product to be

transferred from one environment to another. Adaptability - The capability of the software product to be

adapted for different specified environments without applyingactions or means other than those provided for this purpose forthe software considered.

Installability - The capability of the software product to beinstalled in a specified environment.

Co-existence - The capability of the software product to co-existwith other independent software in a common environment sharing

common resources. Replaceability - The capability of the software product to be

used in place of another specified software product for the samepurpose in the same environment.

Portability Compliance - The capability of the software productto adhere to standards or conventions relating to portability.

57

Quality in use

Effectiveness The capability of the software product to enable users to

achieve specified goals with accuracy and completeness ina specified context of use.

Productivity The capability of the software product to enable users to

expend appropriate amounts of resources in relation to theeffectiveness achieved in a specified context of use. Safety The capability of the software product to achieve

acceptable levels of risk of harm to people, business,software, property or the environment in a specified contextof use.

Satisfaction The capability of the software product to satisfy users in a

specified context of use.

58