modelling class t03 requirements engineering references: –conceptual modeling of information...

Modelling

Class T03Requirements Engineering

References:– Conceptual Modeling of Information Systems (Section 1.4)

– Nuseibeh, B. and Easterbrook, S. 2000. Requirements engineering: a roadmap. In Proceedings of the Conference on the Future of Software Engineering (Limerick, Ireland, June 04 - 11, 2000). ICSE '00. ACM, New York, NY, 35-46. DOI= http://doi.acm.org/10.1145/336512.336523

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

José Borbinha

Modelação 2

ProgramT01-T02 – Module 1

– Introduction to Systems Modelling

T03-T06 – Module 2

– Requirements Engineering– Conceptual Modelling – Domain


– Conceptual Modelling – BehaviourT12-T15 – Module 4

– Ontology


– Conceptual Modelling – ArchitectureT20-T21 – Module 6

– Conceptual Modelling – MetodologiesT22-T23 – Module 7

– Ontology: Advanced

T24-T25

– Conceptual Modelling – Revisions; Exercices, …

"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte".

(Pascal - 16ª Provinciale)

...Escrevi esta carta longa porque não tive tempo de a escrever mais curta...

Modelação 3

Requirements Engineering

1. The Requirements Engineering Process

2. Requirements Elicitation

3. Requirements Analysis

4. Requirements Negotiation

5. Requirements Documenting and Validation

Requirements and Stakeholders

• Requirements– A requirement is a condition or capability to which a system must

conform.– A requirement can have an origin from:

• A decision or request from a stakeholder• An imposition of a standard, a regulation, etc.

• Stakeholders– Anybody involved in the system’s lifecycle (analysis, design,

development, maintenance, …)– Anybody else who, directly or indirectly, may impose

requirements for the system (business owner, user, …)

Modelação 4

Systems and Systems of Systems

Modelação 5

Needs…

System’s Objectives

System’s Modelling

System’s Behaviour Modelling System’s Structure Modelling

Sub-System’s Modelling

Sub-System’s Behaviour Modelling Sub-System’s Structure Modelling





Systems and Requirements

Modelação 6

Generic Requirements

Specific Requirements

Needs…

System’s Objectives

System’s Modelling

System’s Behaviour Modelling System’s Structure Modelling








• Requirements engineering is a systematic approach to documenting the requirements of the system.

• From “Conceptual Modeling of Information Systems”:– “Requirements engineering is the branch of

software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families”

Modelação 7

Modelação 8

Requirements Elicitation

Requirements Analysis and Negotiation

Requirements Documenting

Requirements Validation

Requirements Document

System’s Specification…

• Business objectives• User’s needs• Information about the domain• Information about existing systems• Laws, regulations, standards, …• …

A General Process for Requirements Engineering

Modelação 9









Conceptual Modelling

Modelação 10

Why are requirements important?

Discussion…

Types of requirements

Modelação 11

• Functional Requirements (FR)– The specification of a function of the system or its components.

– It must refer a behaviour of the system!

• Non-Functional Requirements (NFR)– It must refer how the system must behave.

– Examples of non-functional requirements: Performance; Scalability; Availability; Reliability; Maintainability; Serviceability; Security; Regulatory; Manageability; Usability; Interoperability

Types of requirements

• Functional Requirements (FR)– The specification of a function of the system or its components.

– It must refer a behaviour of the system!

• Non-Functional Requirements (NFR)– It must refer how the system must behave.

– Examples of non-functional requirements: Performance; Scalability; Availability; Reliability; Maintainability; Serviceability; Security; Regulatory; Manageability; Usability; Interoperability

Modelação 12

In a project, a specific NFR typology depends of the specificities of the nature of the system or sub-

system…

Examples of requirements

• Functional Requirements (FR)– It must be possible to list all the costumers by alphabetic

order

– Every time a new user is created, a notification by email must be sent to the marketing department

• Non-Functional Requirements (NFR)– The presentation of the list of all the costumers by

alphabetic order can not take more than 5 seconds

– The database management system must be always the most recent approved version of MySQL

– All the user interfaces must be bilingual, in Portuguese and English

Modelação 13

Modelação 14

More examples of Functional Requirements

(example from “Systems analysis and design with UML” – ISBN: 978-0471348061)

Modelação 15

More examples of Non-Functional Requirements

(example from “Systems analysis and design with UML” – ISBN: 978-0471348061)

Modelação 16

IEEE/ANSI 830-1993 proposes a structure for a requirements document (for software requirements specification - SRS)

Modelação 17

• Initial: No process, or chaotic, ad hoc (heroic).

• Repeatable: a process exists and is used repeatedly

and disciplined (project management)

• Defined: the process is defined according to a standard

business domain (process institutionalized)

• Managed: the process is defined and measurement

takes place (quantified)

• Optimizing: process management includes deliberate

process optimization (process improvement)

About Requirements Maturity Levels in Organizations or Methodologies

Modelação 18







Modelação 19










• Requirements elicitation is the process of discovering the requirements for a system by communication with the stakeholders.

• This process can employ several techniques:– Questionnaires– Analysis of documents– Interviewing– Joint Application Design workshops– Ethnography– Prototyping– Use Cases– …

Modelação 20

Questionnaires

• Relevant for– High number of stakeholders of the same kind, with

and already established sense of the needs– Main focus on functional requirements

• Process– Select participants– Define questions– Define strategies to assure a high number of quality

responses– Follow-up of the results to the stakeholders (for

information, validation, engagement…)

Modelação 21

Analysis of Documents

• Relevant in scenarios where systems or processes are already in place (scenario “as-is”) and there is a perceived need to change (scenario “to-be”, for the envisaged system)

• Typical documents– Forms– Reports– User manuals– …

Modelação 22

Interviews

• Relevant for– Low number and well identified of stakeholders,

especially if with the power to decide, highly specialized and with differentiated perspectives

– Main focus on functional requirements

• Process– Prepare yourself carefully– Define clear objectives for the interviews– Select stakeholders and provide them details in

advance, so they can prepare themselves– Define the questions carefully

Modelação 23

JAD – Joint Application Design• Relevant for

– It is intended a new system where the requirements depend from a heterogeneous group of stakeholders representing different classes of users of decision makers.

– Requires a relaxed organizational environment

• Process– Prepare several (2, 3, …) workshops in a functional place, with plenty of

time (1 full day). Do it only if everyone can be present!!! 8 to 12 participants is the ideal size…

– One of the participants must play a role of scribe.

– One of the participants must play the role of moderator (special communication skills are required)

– 1 or 2 members of the design team must be present but playing a passive role (just listening)

– One high level executive must sponsor the workshop, for credibility.

• Discuss advantages and risks…

Modelação 24

Modelação 25

Ethnography• Ethnography it is the practice of

observing all aspects of a culture from within the culture. The challenge is to do that as an internal observer but without directing the outcome.

• It is a relevant observational technique to elicited social and organizational requirements, especially those derived from the way in which people actually work rather than the way in which documents, assumptions of process definitions say they ought to work.

Modelação26

Prototyping• Prototypes can be built early, to provide insight into the general look

and feel of the system.

• Prototypes can be:– Throw-away artefacts (especially in the case of physical systems) or– Evaluative, as early versions of the final systems themselves (especially

in the case of software systems, developed with agile methodologies)

• Prototypes can be relevant because:– Requirements can be tested

– Design alternatives can be explored

– (Potential) Users can be involved

– Problems can be identified early, saving money an time...

Use Cases• Use cases describes an interaction between the system and other

external entity (an actor).

• The description must be provided from the point of view of the actor!

Therefore it describes "who" can do or is affected by "what" with or

from the system.

• The use case technique is used to elicit functional requirements by

relating them with usage/behavioral scenarios.

• In a document requirements the use cases can be presented before

the lists of requirements, as they can provide good glimpses…

• Use cases are also useful to make the bridge between the

requirements documenting and the modeling of the detailed

systems’ behavior

Modelação 27

Modelação 28






5. Tools for Requirements Engineering

Modelação 29









Good requirements must be (ISO Std 830):

• Correct

• Unambiguous

• Complete

• Consistent

• Ranked for importance and/or stability

• Verifiable

• Modifiable

• Traceable

Modelação 30

Requirements Analysis

• The purpose is to find problems, failures, inconsistencies, etc.

• The requirements analysis must be interlaced with the elicitation. Check lists must be maintained…

Modelação 31

Requirements checklist• Each requirement must be checked against:

– Early/Premature Design: information about too early design or implementation?

– Detail: is it a unique requirement, or should it be split in more than one?

– Need: is it really a requirement, or just a “cosmetic” wish?

– Non standard technology: detect as soon as possible if the requirement implies non standard hardware, software, or other technology

– Conformity with the business objectives: is the requirement consistent with the objectives exposed in the beginning?

– Ambiguities: is it only one possible interpretation, or is the requirement susceptible of multiple interpretations?

– Realism: it is a realistic requirement, especially concerning the technology, costs, and other assumptions ort constraints?

– Testability: can it be designed a test to assess if the system accomplishes the requirement?

Modelação 32

Requirements interaction matrix• A technique to show interactions between requirements,

stressing conflicts and overlaps:– 0 => Independent requirements– 1 => Conflicting requirements– 100=> Overlapping requirements (they state the same, totally or

partially)

Modelação 33

Requirement R1 R2 R3 R4 R5 R6R1 0 0 1000 0 1 1R2 0 0 0 0 0 0R3 1000 0 0 1000 0 1000R4 0 0 1000 0 1 1R5 1 0 0 1 0 0R6 1 0 1000 1 0 0

Traceability

Traceability Diagrams

Modelação 34

Relationship Matrix

A fundamental technique in modelling to relate decisions with their origin or implications

Traceability in the Enterprise Architect tool

Modelação 35







Modelação 36









Modelação 37

Requirements negotiation• The negotiation is a step to try to find

solutions for open issues. It can take time, as it might imply consensus…

• Process:– Inform: explain the issues to the relevant

stakeholders– Discussion: listen to the stakeholders;

use this step to give priorities to the requirements…

– Resolution: decide about the requirements (delete, change, refine, …)

Modelação 38







Modelação 39









Modelação 40

Requirements documenting and validation

• Requirements validation: to show that the requirements actually define the intended system.

• Techniques:– Requirements review: analyze requirements systematically by one or a

group of reviewers

– Prototyping: validate requirements with potential users

– Test-case generation: assure that requirements are testable

– Automated analysis: requirements are expressed in tools with functions to check consistency…

Inventories of tools

• http://easyweb.easynet.co.uk/~iany/other/vendors.htm

• http://www.volere.co.uk/tools.htm

• http://www.softdevtools.com/modules/weblinks/viewcat.php?cid=93

• http://software.forbes.com/requirements-management-software

• http://www.paper-review.com/tools/rms/read.php

• …

Modelação 41

http://easyweb.easynet.co.uk/~iany/other/vendors.htm

Modelação 42

Modelação 43

Tool to InGest and Elucidate Requirements PROfessional (TIGER PRO)

PETS - Prototype Educational Tools for Systems and Software

Engineering

Researching the properties of object-oriented

requirements

Modelação 44

http://www.seecforum.unisa.edu.au/SEECTools.html

Systems Engineering & Evaluation Centre Division of Information Technology Engineering and the Environment

Modelação 45

modelling class t03 requirements engineering references: –conceptual modeling of information...

Documents

software systems

systems of systemsmodelao

systems lifecycle analysis

branch of software engineering

software familiesmodelao

programt01t02 module

system business owner

ieee std