2- Requirement Engineering

Advanced Software

Engineering

Content

 What is Requirement Engineering?

 Constraints

 Types of Requirements

 Problems with Requirement

Engineering Process

Software Requirement

Engineering

Introduction

 Requirements form the basis for all software products.

 Requirements engineering is the process, which enables us to

systematically determine the requirements for a software

product.

Requirements engineering

_{The process of establishing the services}

that the customer requires from a system

and the constraints under which it

operates and is developed.

_{The requirements themselves are the}

Requirement

 Something required, something wanted or

needed

 There is a huge difference between wanted and needed and it

Software Requirements

 A complete description of what the software system will do

without describing how it will do it is represented by the software requirements.

 _{Software requirements are complete specification of the}

desired external behavior of the software system to be built. • _{They also represent External behavior of the system.}

• _{Software requirements may be:}

I. Abstract statements of services and/or constraints. II. Detailed mathematical functions

III. Part of the bid of contract IV. The contract itself

IEEE Definition

 A condition or capability that must be met or possessed by a

system...to satisfy a contract, standard, specification, or

Sources of Requirements

• _{People affected in some way by the system}

 Documents

 Existing system

Levels of Software

Requirements

 Stakeholders describe requirements at different levels of

detail.

 “What versus How”

 “One person’s floor is another person’s

Importance of Software

Requirements

 The hardest single part of building a software system is

deciding what to build.

• _{The risk in undocumented requirements} • _{Without requirements, testers don’t}

know what to test

• _{Developers don’t know what is}

considered “Complete”

Examples of Requirements

i. The system shall maintain records of all payments made to

employees on accounts of salaries, bonuses, travel/daily allowances, medical allowances, etc.

ii. The system shall interface with the central computer to send

daily sales and inventory data from every retail store.

iii. The system shall maintain records of all library materials including books, serials, newspapers and magazines, video

Types of Software

Requirements

 Functional requirements

 Non-functional requirements

 Domain requirements

 Inverse requirements

Functional Requirements

 Statements describing what the system does or functionality

of the system.

 _{Statements of services the system should provide}  _{Reaction to particular inputs}

 _{Behavior in particular situations}

 _{Sequencing and parallelism are also captured by functional}

requirements.

 _{Abnormal behavior is also documented as functional}

requirements in the form of exception handling.

 _{Functional requirements should be complete and consistent}  Customers and developers usually focus all their attention

on

Functional Requirements Examples

i. The system shall solve a quadratic equation using the following formula

x = (-b+sqrt(b2 – 4*a*c))/2*a

ii. The user shall be able to search either the entire database of patients or select a subset from it (admitted patients, or

patients with asthma, etc.)

iii. The system shall provide appropriate viewers for the user to read documents in the document store.

iv. Every order shall be allocated a unique identifier

(ORDER_ID) which the user shall use to access that order.

Comments on Examples

 _{Notice the level of detail in different requirements}

described

above. Some are very detailed compared to others.

 _{Notice the ambiguity in the requirement, which uses the}

term ‘appropriate viewers’.

 _{This requirement does not mention the formats of}

documents and types of viewers, which can be used.

 Notice the ambiguity in the requirement for solving the

quadratic equation. The requirement does not speak about

the possibility when the value of ‘a’ is zero

Comments on Example

 Incomplete and ambiguous requirements

are open to

multiple interpretations and assumptions.  This can lead to the development of poor

Non-Functional Requirements

 Most non-functional requirements relate to the system

as a

whole. They include constraints on timing, performance, reliability, security, maintainability, accuracy, the

development process, standards, etc.

 They are often more critical than individual functional

requirements

 _{Must be built into the framework of the software product}  Failure to meet a non-functional system requirement

may

Non-Functional Requirements

 For example, if an aircraft system does not meet reliability

requirements, it will not be certified as ‘safe’.

 If a real-time control system fails to meet its performance

requirements, the control functions will not operate correctly.

 _{Non-functional requirements arise through user needs,}

Product Requirements

Examples

 The system shall allow one hundred

thousand hits per minute on the website.

 The system shall not have down time of more than one

Organizational Requirements

Examples

 The system development process and

deliverable documents

shall conform to the MIL-STD-2167A

 Any development work sub-contracted by

the development

organization shall be carried out in accordance with

External Requirements

Examples

 The system shall not disclose any personal information about

members of the library system to other members except

system administrators.

 The system shall comply with the local and national laws

Observations on Non-Functional

Requirements

 Non-functional requirements can be written to reflect

general goals for the system. Examples include:

• _{Ease of use}

• _{Recovery from failure} • _{Rapid user response}

Observations on Non-Functional

Requirements

 _{Non-functional requirements should be written in a}

quantitative manner as much as possible, which is not always

easy for customers.

 _{For some goals, there are no quantitative measures, e.g.,}

maintainability.

 _{Chances of conflicts within non-functional requirements}

are

fairly high, because information is coming from different Stakeholders. For example, different stakeholders can give

Observations on Non-Functional

Requirements

 Some negotiations must be done among

different

stakeholders, to achieve an agreement in these situations.

 Non-functional requirements should be highlighted in the

requirements document, so that they can be used to build the

Graded Class

NFRs as Goals

 Non-functional requirements are sometimes

written as

goals, which are difficult to verify.

 They should be expressed quantitatively using metrics

Domain Requirements

 Requirements that come from the

application domain and

reflect fundamental characteristics of that application domain

 These can be both the functional or non-functional

requirements

 These requirements, sometimes, are not

explicitly

mentioned

 Domain experts find it difficult to convey domain

requirements

Domain Requirements

 Domain requirements can impose strict

constraints on

solutions. This is particularly true for scientific and

engineering domains

 Domain-specific terminology can also cause confusion

Example:

 In a commission-based sales businesses, there is no concept of

negative commission. However, if care is not taken novice

developers can be lured into developing systems, which

Inverse Requirements

 They explain what the system shall not do. Many people find it convenient to describe their

needs in this manner

 These requirements indicate the uncertain nature

of customers about certain aspects of a new

software product.

Example:

 The system shall not use red color in the user interface,

Design and Implementation

Constraints

 _{They are development guidelines within which the}

designer

must work.

 These requirements can seriously limit design and

implementation options

 _{Can also have impact on human resources}

Example:

 _{The system shall be developed using the Microsoft .Net}

platform.

 _{The system shall be developed using open source}

tools and

Requirements Problem

 The requirements don’t reflect the real needs of the

customer for the system

 Requirements are inconsistent and/or incomplete

 It is expensive to make changes to requirements after they

have been agreed upon.

 There are misunderstandings between

customers, those

developing the system requirements, and software engineers

Problem with Natural

Language

Requirement specification in natural language pose some problems which include

 Lack of clarity

 Requirements confusion

 _{Requirements amalgamation(merge)}

 Natural language understanding relies on the

specification

readers and writers using the same words for same concept

 A natural language requirements specification is over

flexible.

Impact of Wrong

Requirements

 When requirements are wrong, systems are

late, unreliable

and don’t meet customers needs

 This results in enormous loss of time, revenue, market share,

Requirements engineering

processes

 _{The processes used for RE vary widely depending}

on the application domain, the people involved

and the organisation developing the

requirements.

 _{However, there are a number of generic activities}

common to all processes

_{Requirements elicitation;}

_{Requirements analysis;}

_{Requirements validation;}

_{Requirements management.}

 _{In practice, RE is an iterative activity in which}

Requirements elicitation and

analysis

 software engineers work with customers and

system end-users to find out about the

application domain, what services the system should provide, the required

performance of the system, and hardware

constraints.

Requirements Elicitation and

Analysis Process activities

 Requirements discovery

 Interacting with stakeholders to discover their

requirements. Domain requirements are also discovered at this stage.

 Requirements classification and organisation

 Groups related requirements and organises them into

coherent clusters.

 Prioritisation and negotiation

 Prioritising requirements and resolving requirements

conflicts.

 Requirements specification

 Requirements are documented and input into the next

Problems of requirements

analysis

 _{Stakeholders don’t know what they really want.}

 _{Stakeholders express requirements in their own terms.}

Requirements engineers, without experience in the

customer’s domain, may not understand these requirements.

 _{Different stakeholders may have conflicting} requirements. Requirements engineers have to discover all potential sources of requirements and

discover commonalities and conflict.

 _{Organisational and political factors may influence the}

system requirements. Managers may demand specific system requirements because these will allow them to increase their influence in the organization.

 The requirements change during the analysis process.

Requirement discovery



The process of

gathering information

about the required and existing systems

and extracting the user and system

requirements from this information.



Sources of information during the

requirements discovery phase include

documentation

,

system

stakeholders

, and

specifications of

similar systems

.



Systems normally have a range of

Requirements validation

 Requirements validation is the process of checking that requirements actually define the system that the customer really wants.  Requirements error costs are high so

validation is very important

 Fixing a requirements error after delivery

Requirements validation

checking

 _Validity

 _{Does the system provide the functions which best support the}

customer’s needs?

 _{A user may think that a system is needed to perform certain}

functions. However, further analysis may identify additional or different functions that are required

 _Consistency

 _{Requirements in the document should not conflict.}

 _{That is, there should not be contradictory constraints or}

different descriptions of the same system function.

 _Completeness

 _{The requirements document should include requirements that}

Changing requirements

 Large systems usually have a diverse user community, with many users having

different requirements and priorities that may be conflicting.

 _{The final system requirements are inevitably}

Requirements validity

checking

 _Realism

 Using knowledge of existing technology, the

requirements should be checked to ensure that they can actually be implemented. These checks should also take account of the budget and schedule for the system development.

 _{Verifiability}

 To reduce the potential for dispute between customer

and contractor, system requirements should always be written so that they are verifiable.

 _{This means that you should be able to write a set of}

Requirements validation

techniques

 Requirements reviews

 The requirements are analyzed systematically by a

team of reviewers who check for errors and inconsistencies.

 _{Both client and contractor staff should be involved in}

reviews.

 Prototyping

 Using an executable model of the system to check

requirements.

 Client can experiment with this model to see if it

meets their real needs.

 Test-case generation

 Developing tests for requirements to check testability.  _{If a test is difficult or impossible to design, this usually}

Requirements management

 Requirements management is the process of

managing changing requirements during the requirements engineering process and system development.

 New requirements emerge as a system is being

developed and after it has gone into use.

 _{You need to keep track of individual}

requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes.

 You need to establish a formal process for

Changing requirements

 _{The business and technical environment of the system}

always changes after installation.

 New hardware may be introduced, it may be

necessary to interface the system with other

systems, business priorities may change, and new legislation and regulations may be introduced that the system must necessarily abide by.

 _{The people who pay for a system and the users of that}

system are rarely the same people.

 System customers impose requirements because of