CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233:...

CSEB233: Fundamentals

of Software Engineering

Software Requirements

Part 1

Understanding Requirements Engineering

Objectives

• Discuss the concept of requirements and the types ofrequirements

• Explain what Requirements Engineering is, its process,and its importance to product development projects

• Explain and relate requirements elicitation,requirements analysis and negotiation, requirementsspecification, requirements verification and validation,and requirements management activities

• Describe various methods, approaches, and techniquesfor performing and supporting the RequirementsEngineering process

Understanding

Requirements Engineering

Concept and Types of

Requirements

What are ‘Requirements’?

• IEEE Standard Glossary of Software EngineeringTerminology (IEEE, 1990):

A condition or capability needed by a user to solve aproblem or achieve an objective

A condition or capability that shall be met or possessedby a system, system component, product or service tosatisfy a contract, an agreement, standard, specificationor other formally imposed documents

A documented representation of a condition or capabilityas in (1) and (2).

Types of Requirements

• Three types of requirement

Functional Requirements (FR)

Non-functional Requirements (NFR) – also known as

Quality Requirements

Constraints

Functional Requirements

• IEEE Standard Glossary of Software Engineering

Terminology (1990) define FR as:

“a requirement that specifies a function that a system or

system component must be able to perform”

• Function is defined as:

“a defined objective or characteristic action of a system

or component”

For example, a system may have inventory control as its

primary function


• Functional requirements relate to the actions (such

as calculate, retrieve, display) that the system or

system component must carry out in order to satisfy

the reason for its existence

(Robertson & Robertson, 1999)


• Describe the services a system or component of asystem should perform

• Tell you and your users how the system should react tocertain inputs

• Describe how the system should and/or should notbehave in particular situations

• Must not include quality statement such as 'fast',‘efficient’, ‘usable’, ’reliable’, and etc.

• Are important for the developers to use them to developthe system as expected by the customers

Non-functional Requirements

• A requirement that specifies quality property of the entiresystem, a system component, service or function.

• Quality property is usually associated with the system as awhole and not to individual function.

• It will affect degree of user satisfaction. Product - specify that the delivered product must behave in a

particular way e.g. execution speed, reliability, etc.

Organizational - a consequence of organizational policies andprocedures, e.g. process standards used, implementationrequirements, etc.

External - arise from factors which are external to the system andits development process e.g. interoperability requirements,legislative requirements, etc.

Non-functional Requirements

Examples

Constraints

• A constraint is an organizational or technological

requirement that restricts the way in which the

system shall be developed.

• Constraints are non-negotiable and are off-limits

during design trade-offs.

Constraints

• Example constraints:

Cultural constraints• User interfaces shall not contain abusive symbols or graphics for

any culture

Legal constraints• Creation of invoices shall consider the goods and services tax of 6%

Physical constraints• Engine control units in the vehicle interior shall work at

temperatures from -10 to +50 degree celcius

Project constraints• The overall development effort must not exceed RM 1,000,000.

Exercises

• Which of the following are FR, NFR and constraints? The house information system shall generate monthly statements of

allowed and denied accesses.

The release of the locking mechanism shall take 0.8 seconds at most.

If a sensor detects a damage of the window, the system shall inform thesecurity company.

If a correct PIN is entered at the keyboard of the access system, thesystem shall remove the door lock and shall record access date, timeand the PIN entered.

The effort for system development shall not exceed 480 person months.

The user password stored in the system shall be protected againstunauthorized access.

The system shall be developed using Rational Unified Process

Understanding


What is Requirements

Engineering?

What is Requirements Engineering

(RE)?

• “… a relatively new term which has been invented to cover all ofthe activities involved in discovering, documenting, andmaintaining a set of requirements for a computer-based system.

• The use of the term ‘engineering’ implies that systematic andrepeatable techniques should be used to ensure that systems arecomplete, consistent, relevant, etc”.

Sommerville & Sawyer (1997)

• “the process of developing a requirements specification”Pohl (1996)

• “the broad spectrum of tasks and techniques that lead to anunderstanding of requirements”

Pressman (2009)

Why is RE important?

• RE process can influence the development cost, time,effort, and quality of the product

• RE process is an essential contributor to the overallquality of the software product

• “Incomplete requirements”, “changing requirements”are major causes of project failures

• Good RE practices contribute more than 42% towardsthe overall success of a project, while improper REpractices account for more than 43% of the reasonswhy projects are late or over budget

(CHAOS, 1995)

How Far Have We Got?

Importance of RE

(http:/

/ww

w.p

roje

ctc

art

oon.c

om

)

How the customer explain it

How the project leader understood it

How the analyst design it

How the programmer wrote it

How the business

consultant described it

How the project was documented

What operations installed

How the customer was billed How it was supported

What the customer really needed

RE Framework

Framework Motivation

• Structuring requirements engineering by defining a set ofcore common concepts for each requirements engineeringprocess and their relationships

• Reference structure for industry

Training of managers, requirements engineers and developers.

Analysis of strength and weaknesses of RE processes.

• Reference structure for teaching requirements engineering

• Successfully introduced in a number of organizations,companies and universities!

Context

• The requirements engineering context consists of1. The system context is the part of the context in which the

system to be developed is operating/embedded.• Subject facet comprises system context objects about which information is

represented in the system or which influence or constrain therepresentation of information represented in the system.

• Usage facet comprises all system context objects (people and/or systems)which directly or indirectly interact with the system or which influence orbenefit from the usage of the system.

• IT system facet comprises all system context objects of the technical andoperational environment in which the system is going to be deployed in orwhich influence or constraint the deployment of the system and/or the useof technology by the system such as sensors, actuators or other systems.

2. The development context is the part of the context in which thesystem is being developed.

Core Activities

• Elicitation

• Negotiation

• Documentation

Elicitation

• The goal of the elicitation activity is to:1. Identify relevant requirements sources

2. Elicit existing requirements from the identified sources

3. Develop new and innovative requirement

• Requirements sources are not always known at the beginningof the process!

• Relevant requirements sources include: Stakeholders involved in the process,

existing documents

existing systems

Negotiation

• The goal of the negotiation activity is to:

1. Identify conflicts

2. Analyse the cause of each conflict.

3. Resolve the conflicts by means of appropriate strategies.

4. Document conflict resolution and their rationale.

• Wishes and needs of the stakeholders typically varyand can be in conflict

• Conflicts shall be identified and should be resolved

Documentation

• The goal of the documentation activity is to:1. Document relevant requirements information according to the defined

documentation guidelines.

2. Specify requirements according to the defined specification guidelines.

3. Choose documentation formats and notations which fit the stakeholderneeds, and are defined for the project.

4. Ensure consistency between different documentation formats used.

• In addition to the requirements, information about elicitation andnegotiation should be documented.

• Early in requirements engineering, information is oftendocumented informally/unstructured and thus not compliant withthe documentation and specification rules.

Artefacts

• A goal describes a high level objective of one or morestakeholders about a property of the system to be developed orthe development project

• A scenario describes a concrete example of satisfying or failing tosatisfy a goal (or set of goals).

• Three Types of Solution-oriented Requirements Data perspective considers the static data structures. It defines data

types, attributes and relationships between data types.

Functional perspective considers the manipulation of data by systemfunctions. It defines the transformation of inputs by functions intooutputs.

Behavioural perspective considers the system behaviour. It defines thereactions to external stimuli in form of permitted states, transitions andoutputs.

Three types of Solution-oriented

Requirements

Cross-sectional activities

• Validation

• Management

Validation

Three Validation Goals

• Validation of requirement artifacts Aims at detecting defects in requirements.

• Validating the artefacts with regard to the content, the documentation and the agreementdimensions.

• Checking the fulfilment of validation criteria.

• Validation of the core activities Checking the compliance of the activities performed and the process and/or activity

specifications.• Have all required steps been performed?

• Have the required stakeholders been involved in the activities?

• Validation of the context consideration Checking whether the context has been considered adequately in the activities.

• Have all relevant requirements sources been considered?

• Have the required stakeholders been involved?

• Have all parts of the requirements engineering context been sufficiently considered?

Management

Three Management Goals

• Management of the requirements artifacts throughout the system lifecycle: Prioritization of requirements.

Persistent recording.

Configuration management.

Change management.

Requirements traceability.

• Management of the core activities Ensure an efficient and effective overall RE process.

Plan and control the execution of the RE activities.

Alignment of the process to the current project situation.

• Management of the context Identifying changes in the context relevant for the system.

Changes typically require (re-)initiating or (re-)scheduling of one or more RE activities.

Understanding


Requirements Elicitation

Goal

• As mentioned earlier, the goal of the elicitation activityis threefold.1. To identify relevant requirements sources

2. To elicit existing requirements from the identified sources

3. To develop new and innovative requirement

• Three types of requirements sources Documents

Existing systems

Stakeholders

Sources

• Documents Existing documents contain relevant information to be considered when

defining the requirements for the desired system.

Documents can be general (e.g. standards), organization specific (e.g.development guidelines) or product-specific (e.g. code, user manual).

• Stakeholders Either a person or an organization with potential interest in the desired

system.

A person can represent the interest of different stakeholders.

• Existing systems Requirements realized by the existing system might still be relevant for

the new system.

Existing systems can be used to identify enhancements, knowndeficiencies and previous errors.

Elicitation Components

• Four components of requirements elicitation:

Understanding application domain• this is about knowledge of the general area where the system is applied.

Understanding problem to be solved• understand details of the problem where the software will be applied.

Understanding business processes in an organization• understand how systems interact and affect the different part of the

business and how they contribute to overall business goals.

Understanding the needs and constraints of the stakeholders• understand the work processes that the system is intended to support, the

ways in which the system is likely to be used, and restrictions on thedegree of freedom we have in providing a solution.

Main Elicitation Techniques

• Interview Elicitation of requirements and context information from a stakeholder or a group of

stakeholders

• Workshop A group of stakeholders develops requirements for a system

• Focus Group A group of stakeholders focus on a specific item to identify the requirements regarding

this item

• Observation An observer elicits requirements by observing stakeholders of existing systems

• Questionnaire A stakeholder writes down his requirements by answering predefined questions

• Perspective-based Reading A stakeholder reads a document from a previously defined perspective, e.g. from the

perspective of a user or from the perspective of a tester

Other Supporting Techniques

• Brainstorming

• Prototyping

• KJ method

• Mind mapping

• Elicitation checklists

Elicitation Work Products

• A statement of need and feasibility

• A bounded statement of scope for the system or product

• A list of customers, users, and other stakeholders whoparticipated in requirements elicitation

• A description of the system’s technical environment

• A list of requirements (preferably organized by function) andthe domain constraints that apply to each

• A set of usage scenarios that provide insight into the use ofthe system or product under different operating conditions

• Any prototypes developed to better define requirements

Why is it difficult to understand what

the customer wants?

• Problems of scope

System/software boundary is ill-defined

Customers/users specify unnecessary technical detail

that may confuse overall system/software objectives

• Problems of volatility

Requirements change over time

(Christel and Kang, 1992)

Why is it difficult to understand what

the customer wants?

• Problems of Understanding

Customers/users not sure what they want

Poor understanding of the capabilities and limitations of theirown computing environment

Don’t have full understanding of the domain problems

Have trouble communicating need

Omit information that is believed to be “obvious”

Specify ambiguous requirements• “I want a user friendly interface in the XYZ system”.

Specify conflicting requirements

Understanding


Requirements Negotiation

Goal

• A process of discussing the conflicts in therequirements and finding resolutions to theidentified conflicts

• The goal of the negotiation activity is to:

1. Identify conflicts

2. Analyse the cause of each conflict.

3. Resolve the conflicts by means of appropriatestrategies.

4. Document conflict resolution and their rationale.

Conflict

• A conflict in requirements engineering exists, if theneeds and wishes of different stakeholdersregarding the system contradict each other, or ifneeds and wishes cannot be considered.

• Unresolved conflicts have negative impact on theacceptance of the system by the stakeholder.

• When resolving conflicts, often new ideas andinnovative requirements are developed – thusconflicts should be positively seen as opportunities!

Conflict Examples

• A group of stakeholders demands the use of radarsensors for distance measurement. Another groupof stakeholders asks, instead, for ultrasoundsensors.

• A stakeholder demands to display safety-relevantinformation for the driver on a head-up display.Other stakeholders argue this would detract thedriver and hence reject this requirement.

Conflicts

• In any set of requirements, there will always be

conflicts, overlaps, and omissions

• Developer must anticipate these and plan requirements

negotiation with all stakeholders to discuss and resolve

the problems

• Requirements conflicts are inevitable because different

stakeholders have different requirements and priorities

• One technique to identify conflicts and overlaps is by

using Interaction Matrix

Types of Conflict

• Data conflict Wrong, incomplete information about requirements, different interpretation,

different views and different assessment

• Interest conflict Interests or goals with regard to the system contradict each other

• Value conflict Different ways of life, ideology or religion resulting in each stakeholder

considering the importance of a requirement differently.

• Relationship conflict Strong emotions, deficient communication and negative interpersonal behavior

between stakeholders

• Structural conflict Unequal balance of authority or power, destructive patterns of interaction,

unequal control, ownership or distribution of resources and time constraints

Conflicts Resolution

• Three basic strategies for resolving data, value and

interest conflicts.

Negotiation

• The conflict parties agree on a solution by means of negotiation

Creative solution

• The original viewpoints of the conflicting parties are discarded and a

new, creative unanimous solution is developed.

Decision

• A higher authority makes a decision in favour of one conflicting

party.

Prioritizing Requirements

• To decide which requirements have to be

implemented and deliver first, which ones could be

implemented in the subsequent deliveries, and

which ones could be dropped.

• Must collaborate with the customers. Why?

You may not know which requirements are most

important to customers, and

Customers may not be able to judge the cost and

technical difficulty associated with specific requirements.

Techniques of Requirements

Prioritization

• Prioritization scale - A common approach to prioritization is togroup requirements into several priority categories.

E.g.: MoSCoW method (Coley Consulting, 2008)• M - MUST have this.

• S - SHOULD have this if at all possible.

• C - COULD have this if it does not affect anything else.

• W - WON'T have this time but WOULD like in the future

• Quality Function Deployment

• Semi-quantitative Analytical Approach - the requirements’priority can be calculated once you have estimated thebenefit, penalty, cost and risk for the negotiable requirements

Understanding


Requirements Documentation

Why Documentation?

• Persistence – to preserve information that otherwise might beforgotten

• Common reference

• Promotes communication – by having common reference torefer to

• Promotes objectivity – to preserve information from unwantedalteration

• Support training of new employees

• Preserve expert knowledge

• Support problem reflection – by filling up gaps andinconsitencies

What to be Documented?

How to Document?

• Textual Natural language text

Structured text

Templates

• Model-based Data perspective

Behaviour perspective

Functional perspective

• Combined Models with annotations

Text with models

Textual (using template)

Model-based

Combined

Requirements Specification

• Also known as Software RequirementsSpecification (SRS)

• A specific kind of requirements document whichsupports later development activities and/or used ascontracts.

• It is an official document that consists of informationthat should guide the system developers such asdesigners, programmers, and engineers through thedevelopment work of the product

Requirements Specification

• Should involve technical writers

appropriate skills for gathering requirements, reviewing

historic reports, writing formal documents and reports,

and etc.

can better assess and plan documentation tasks

know how to determine the questions that are of

concern to the customers and users regarding non-

functional requirements like ease of use and usability

Software Requirements

Specification (SRS)

• Attributes of a well-written SRS (IEEE Standard 830-1998 ): Correct

Unambiguous

Complete

Consistent

Ranked for importance or stability

Verifiable

Testable

Traceable

• SRS template: http://www.processimpact.com/process_assets/srs_template.doc

http://www.processimpact.com/process_assets/srs_template.doc

Understanding


Cross Sectional: Requirements

Validation

Requirements Validation

• Validation denotes checking whether inputs (context

artefacts and consideration), execution and outputs

(requirements artefacts and additional information)

of the RE core activities fulfill defined quality criteria.

• Validation is performed by involving relevant

stakeholders, other requirement sources as well as

external reviewers if necessary.

Validation Goals

Validation versus Verification

Validation Techniques

• Reviews the requirements specification

Desk-check

Walkthrough

Inspection

Checklist

• Prototyping

• Acceptance Tests

Understanding


Cross Sectional: Requirements

Management

Requirements Management

• ‘Ripple Effect’ – one thing causes a series of other things tohappen (e.g., Tsunami)

• Changes in requirements specified in a requirementsdocument are inevitable and must be allowed

• However, even seemingly a minor change may unexpectedlyrequire lot of work

• Main activities in managing requirements artefacts: Managing changes to requirements

Managing configuration of requirements and requirementsdocument – version control

Maintaining requirements traceability

Tracking requirements status

Ripple Effect

Why Requirements Change?

Internal Factors External Factors

1. Failure to elicit the real requirements of the

stakeholders

2. Iterating from requirements to design

creates new requirements

3. The implementation team might encounter

technical, schedule and/or cost problems

in implementing a requirement

4. RE process is iterative and must create a

practical process to help manage changing

requirements. Failure to create a practical

requirements change management

process will only cause rework and stress

1. The problem we are trying to solve

somehow change as a result of a changing

economy, government regulations,

consumer preferences etc.

2. Customers and users understand better

what they really require from a system or

simply change their minds

3. The customers’ organization may change

its structure, procedures and processes

4. The external environment change, which

create new constraints and opportunities

Managing Requirements Changes

• Formal change management is crucial to ensure

that the requirements changes maintain the

proposed system’s support to the fundamental

business goals

• To ensure a consistent approach to change

management, organizations should define a set of

change management policies and procedures

Managing Requirements Changes

• Basic policies:

The change management process – includes change

management principles and guidelines, and activities of

the change management process.

The change impact analysis – needed to avoid changes

from causing overruns in project schedule and budget,

or resulting negative impact on the product’s quality.

Requirements Configuration

Management

• Means detail recording and updating that have been appliedto the requirements document, and providing version control,release management, and issue tracking.

• Benefits (Leffingwell and Widrig, 2003): Prevents any unauthorised and potentially destructive changes to

the requirements.

Preserves the revisions to requirements document.

Facilitates the retrieval and/or recreation of requirementsdocument archives.

Prevents simultaneous updates of requirements documents.

Prevents conflicting and uncoordinated updates to differentdocument at the same time.

Managing Requirements

Traceability

• “The ability to describe and follow the life of arequirement, in both a forward and backward direction,i.e. from its origins, through its development andspecification, to its subsequent deployment and use,and through periods of ongoing refinement and iterationin any of these phases”

(Gotel and Finkelstein, 1994)

• Technique: traceability matrix

to show the dependencies between requirements or linksbetween requirements and other system documents

Traceability Matrix

Use

case

Functional

Requirements

Design

Element

Code Test Case

UC-28 catalog.query.sort Class catalog catalog.sort() search.7

search.8

UC-29 catalog.query.import Class catalog catalog.import()

catalog.validate()

search.8

search.13

search.14

Tracking Requirements Status

• Monitoring implementation status of each requirement to ensure existing requirements are addressed and traceable

throughout the development life cycle

• Tracking requirements status supports overall project statustracking. e.g. proposed, approved, implemented, verified, deleted, rejected

• “If a project manager knows that 55% of the requirementsallocated to the next release have been implemented andverified, 28% are implemented but not verified, and 17% arenot yet fully implemented, then he or she has good insightinto the project status”

(Wiegers, 1999a)

Summary

• The concept of requirements and types of requirements

• What Requirements Engineering is, its process, and theimportance of them to product development projects ingeneral

• What requirements elicitation, requirements analysisand negotiation, requirements specification,requirements verification and validation, andrequirements management tasks are

• Various methods, approaches, and techniques forperforming and supporting the RE process

CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233:...

Documents

Transcript of CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/re.pdfCSEB233:...