ESOF-Engenharia de Requisitos

download ESOF-Engenharia de Requisitos

of 29

  • date post

    06-Apr-2018
  • Category

    Documents

  • view

    217
  • download

    0

Embed Size (px)

Transcript of 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

  • 8/2/2019 ESOF-Engenharia de Requisitos

    2/29

    Scope and importance of requirements

    engineering3

    What is requirements engineering?4

  • 8/2/2019 ESOF-Engenharia de Requisitos

    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

  • 8/2/2019 ESOF-Engenharia de Requisitos

    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

  • 8/2/2019 ESOF-Engenharia de Requisitos

    5/29

    When RE is not properly done

    Software Requirements10

  • 8/2/2019 ESOF-Engenharia de Requisitos

    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

  • 8/2/2019 ESOF-Engenharia de Requisitos

    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/2/2019 ESOF-Engenharia de Requisitos

    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

  • 8/2/2019 ESOF-Engenharia de Requisitos

    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

  • 8/2/2019 ESOF-Engenharia de Requisitos

    10/29

    Requirements engineering processes19

    Requirements engineering

    (Software Requirements, Karl E. Wiegers, 2003)

    20

  • 8/2/2019 ESOF-Engenharia de Requisitos

    11/29

    Requirements development

    Requirements Engineering Processesand Techniques, Gerald Kotonya, IanSommerville, 1998

    21

    Requirements elicitation (1)22

  • 8/2/2019 ESOF-Engenharia de Requisitos

    12/29

  • 8/2/2019 ESOF-Engenharia de Requisitos

    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

  • 8/2/2019 ESOF-Engenharia de Requisitos

    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

  • 8/2/2019 ESOF-Engenharia de Requisitos

    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=