FEUP, MIEIC, SOFTWARE ENGINEERING

SOFTWARE REQUIREMENTS ENGINEERING

Joo Pascoal Faria, 10/11/2011

Index
2

Scope and importance of requirements engineering Software requirements Requirements engineering process Requirements engineering in the Rational Unified Process

Scope and importance of requirements engineering

What is requirements engineering?

4

What is requirements engineering?

5

The process of studying user needs to arrive at a definition of system, hardware, or software requirements.
(Adpated from IEEE Standard Glossary of Software Engineering Terminology IEEE Std 610.12-1990)

Set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used.
(Steve Easterbrook, FoRE, 2004)

Importance of RE: critical project success factors

1 2 3 4 5 6 7 8 9 10 11

User Involvement
Executive Management Support

Clear Statement of Requirements

Proper Planning

Realistic Expectations
Smaller Project Milestones Competent Staff Ownership

Clear Vision & objectives

Hard-working, Focused Staff Other

16 % 14 % 13 % 10 % 8% 8% 7% 5% 3% 2% 14 %

( source: Standish group CHAOS report)

Importance of RE: sources of bugs

7

Bugs are caused for numerous reasons, but the main cause can be traced to the (requirements) specification

(source: "Software Testing", Ron Patton)

Importance of RE: cost of bugs

8

((source: "Software Project Survival Guide", Steve McConnell)

When RE is not properly done

10

Software Requirements

What is a (software) requirement?

11

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

What versus How

12

Requirements should focus the what instead of the how.

What How

Sometimes the frontier is not clear. As a rule of thumb, requirements end where the freedom of the developer starts (and vice-versa)

Levels of requirements
13

Business requirements represent high-level objectives of the organization or customer who requests the system
Usually captured in vision and scope document influence

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

Types of requirements
14

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

Quality requirements and ISO/IEC 9126

15

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 when it 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.

ISO/IEC 9126: Quality model framework

16

ISO/IEC 9126: Quality characteristics (1)

17

characteristics

+availability

subcharacteristics

ISO/IEC 9126: Quality characteristics (2)

18

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.

19

Requirements engineering processes

Requirements engineering
20

(Software Requirements, Karl E. Wiegers, 2003)

Requirements development
21

Requirements Engineering Processes and Techniques, Gerald Kotonya, Ian Sommerville, 1998

Requirements elicitation (1)

22

Requirements elicitation (2)

23

Purpose
Interact with stakeholders to discover their requirements

Techniques
Interviews Facilitated meetings Questionnaires Goal analyses Social observation and analysis (ethnography)
observe and analyse how people actually work

Use cases and scenarios (next class)

real-life examples of how a system can be used

Prototypes
user-interface prototypes

*Requirements elicitation (3)

24

Process
Establish objectives Business goals Understand background Organisational structure Organise knowledge Stakeholder identification Goal prioritisation Domain knowledge filtering Collect requirements Stakeholder requirements Domain requirements

Problem to be solved System constraints

Application domain Existing systems

Organisational requirements

(Kotonya)

Stakeholders
25

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 sistema influencia 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

Elicitation by Prototyping
26

A prototype is an initial/primitive version of a system

Cheaper, easier and faster to develop than the real system Limited functionality
User Needs

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

Requirements

Throwaway & Evolutionary Prototyping

27

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 strong end user involvement, and little or no separation between analyst, designer and programmer De prottipo em prottipo at ao produto final

Paper Prototypes
28

Quick, easy and cheap to develop Low fidelity Usually the preferred approach for requirements elicitation
http://www.youtube.com/watch?v=5Ch3VsautWQ EXCELENTE!

Computer-Based Prototypes
29

More time, skills and cost to develop Higher fidelity Functional, evolutionary prototype Or nonfunctional, throwaway drawings and mockups

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

Social Observation and Analysis

30

Many systems are developed to support people work People often find it difficult to tell how they perform tasks and work with others When tasks become routine and people don't think much about them consciously, it is hard to verbalize how the work is done Example: Try to explain how to tie your shoelaces
http://www.videojug .com/film/how-totie-your-shoelaces

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

Goal analyses
31

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

Goal analyses example (elevator)

32

Requirements analysis (1)

33

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

Requirements analysis (2)

34

Kotonya, 1998

Characteristics of good requirements and requirements specifications (1)

35

Characteristics of good requirements and requirements specifications (2)

36

Most problems here!

Characteristic Complete Correct Consistent

What to consider Is anything missing or forgotten? Is it thorough? Does it include everything necessary to make it stand alone? Is it factual?

Is the description of the feature written so that it doesn't conflict with itself or other items in the specification? Is the description exact and not vague? Is there a single Unambiguous interpretation? Is the description clear? Is the feature within the system scope? Is the feature traceable to an Necessary original customer need? Is the statement necessary to specify the feature? Is there extra information that should be left out? Can the feature be implemented with the available personnel, tools, Feasible and resources within the specified budget and schedule? Does the specification stick with defining the product and not the Implementation underlying software design, architecture, and code? (What instead of -free how) Verifiable Can the feature be tested? Is enough information provided that a tester could create tests to verify its operation?

Exerccio identificar problemas()

37

Feasible Implementatio n-free

Unambiguous

Necessary

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 permitir a 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, sem erros, 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).

Role of models in requirements eng.

38

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 information system to support the business/organizational processes

Correct

Requisitos de Sistema de Voto Electrnico Presencial

Verifiable

Consistent

Complete

Requirements specification
39

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

SRS Template (1)

40

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

SRS Template (2)

41

May be use cases

...

Template of SRS Section 3 organized by feature

Requirements validation
42

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 100 times the cost of fixing an implementation error

Techniques
Requirements reviews Prototyping Model validation Acceptance test case generation

Requirements management (1)

43

Walking on water and developing software from a specification are easy if both are frozen . - Edward V. Berard

Requirements management (2)

44

(the currently agreed-upon body of requirements)

(Software Requirements, K.E.Wiegers)

Requirements management (3)

45

(*)

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

(Software Requirements, K.E.Wiegers)

46

Requirements engineering in the Rational Unified Process

Requirements Engineering (RE) in RUP

47

Platform independent model (PIM) Platform specific model (PSM)

RE in RUP: Activities
48

RE in RUP: Artifacts
49

References and further reading

50

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), 2004 edition, IEEE Computer Society IEEE Std 830-1998 - Recommended Practice for Software Requirements Specifications IEEE Std 610.12: 1990 - Standard Glossary of Software Engineering Terminology ISO/IEC 12207 - Information technology - Software life cycle processes ISO/IEC Std 9126 - Software Engineering - Product Quality

51

Appendix A Additional definitions

Functionality
52

Functionality - The capability of the software product to provide functions which meet stated and implied needs when the software is used 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 right or agreed results or effects with the needed degree of precision. Interoperability - The capability of the software product to interact with one or more specified systems. Security - The capability of the software product to protect information and data so that unauthorised persons or systems cannot read or modify them and authorised persons or systems are not denied access to them. Functional Compliance - The capability of the software product to adhere to standards, conventions or regulations in laws and similar prescriptions relating to functionality.

Reliability
53

Reliability - The capability of the software product to maintain a specified level of performance when used under specified 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 to maintain a specified level of performance in cases of software faults or of infringement of its specified interface. Recoverability - The capability of the software product to reestablish a specified level of performance and recover the data directly affected in the case of a failure. Reliability compliance - The capability of the software product to adhere to standards, conventions or regulations relating to reliability.
Note: Availability is considered a combination of maturity, fault tolerance and recoverability

Usability
54

Usability - The capability of the software product to be understood, learned, used and attractive to the user, when used 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 enable the user to operate and control it. Attractiveness - The capability of the software to be attractive to the user Usability compliance - The capability of the software product to adhere to standards, conventions, style guides or regulations relating to usability. Note: Usually combined with accessibility, particularly in the web

Efficiency
55

Efficiency - The capability of the software product to provide appropriate performance, relative to the amount of resources used, under stated conditions.
Time behavior - The capability of the software product to provide appropriate response and processing times and throughput rates when performing its function, under stated conditions. Resource utilization - The capability of the software product to use 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.

Maintainability
56

Maintainability - The capability of the software product to be modified. Modifications may include corrections, improvements or adaptation of the software to changes in environment, and in requirements 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 to be modified to be identified. Changeability - The capability of the software product to enable a specified modification to be implemented. Stability - The capability of the software product to avoid unexpected effects from modifications of the software. Testability - The capability of the software product to enable modified software to be validated. Maintainability Compliance - The capability of the software product to adhere to standards or conventions relating to maintainability.

Portability
57

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 applying actions or means other than those provided for this purpose for the software considered. Installability - The capability of the software product to be installed in a specified environment. Co-existence - The capability of the software product to co-exist with 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 same purpose in the same environment. Portability Compliance - The capability of the software product to adhere to standards or conventions relating to portability.

Quality in use
58

Effectiveness
The capability of the software product to enable users to achieve specified goals with accuracy and completeness in a specified context of use.

Productivity
The capability of the software product to enable users to expend appropriate amounts of resources in relation to the effectiveness 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 context of use.

Satisfaction
The capability of the software product to satisfy users in a specified context of use.