esof-engenharia de requisitos
Post on 06-Apr-2018
223 Views
Preview:
TRANSCRIPT
-
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=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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
22/29
Requirements management (1)
Walking on water and developing software from aspecification are easy . -Edward V. Berardif both are frozen
43
Requirements management (2)
(Software Requirements, K.E.Wiegers)
(the currently agreed-upon
body of requirements)
44
-
8/2/2019 ESOF-Engenharia de Requisitos
23/29
Requirements management (3)
(Software Requirements, K.E.Wiegers)
(*) proposed, approved, implemented, verified, rejected,
(*)
45
Requirements engineering in the
Rational Unified Process46
-
8/2/2019 ESOF-Engenharia de Requisitos
24/29
Requirements Engineering (RE) in RUP
Platform independent
model (PIM)
Platform specific
model (PSM)
47
RE in RUP: Activities48
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
-
8/2/2019 ESOF-Engenharia de Requisitos
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
top related