Requirements Engineering

MBIT - Lecture 1Introduction to Requirements Engineering

Contents Course Outline and Evaluation Criteria Introduction to Requirements Engineering What are Requirements Stakeholders in Requirements Engineering Characteristics of Requirements Types of Requirements Importance of Requirements Engineering

Introduction to 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 entire system development process begins with requirements engineering.

What vs. How Software Engineering Process

VisionWhy

DefinitionWhat

DevelopmentHow

MaintenanceChange

What are Requirements - IEEE1. A condition or capability needed by 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 document.

3. A documented representation of a condition or capability as in 1 or 2.

What are Requirements – Jones & Sommerville1. The statement of needs by a user that triggers the

development of a program or system - Jones 19942. Requirements are ... A specification of what should be

implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system. - Sommerville 1997

Stakeholders in Requirements Engineering1. Customer2. User

1. Operator2. Manager3. Executive4. General public

3. Architect4. Developer5. QA Engineer6. Maintenance Engineer

Characteristics of Requirements1. Clarity2. Precision3. Completeness4. Verifiability5. Realistic6. Traceability

Clarity and Precision Unambiguous Same meaning for all stakeholders Appropriate representation for different stakeholders

Wireframes, Storyboards for users DFDs, data flows, ER diagram for developers Component, system diagrams for architects

Completeness Description of all complexities Cohesive Consistent

No conflicts or contradictions In practice, it is very difficult to produce a complete,

consistent, and cohesive requirement

Realistic and Verifiable Requirement should be realistic

Computationally Practically

Verifiability Mention success scenarios as well as failure scenarios Test cases covering all logical flows Verifiable through different states of system

Traceability Forward tracing

Requirement - UI - Design - Test case Backward tracing

Test case – Design – UI – Requirement

Types of Requirements1. Functional requirements

Domain requirements Customer requirements User requirements Business requirements System requirements

2. Non-functional requirements Product requirements Organizational requirements External requirements

3. Direct and Derived requirements

Functional Requirements Services that system should provide Detailed system requirements Details of the functionality or services Different types include

Domain requirements Customer requirements User requirements Business requirements System requirements

Non-Functional Requirements Constraints on the system or services Constraints on development process or standards Constraints from users or external sources Product requirements

Efficiency – Performance and Memory Reliability Portability Usability Design and architecture Maintainability

Non-Functional Requirements Organizational requirements

Processes followed in the organization Delivery Implementation Standards

External requirements Interoperability Ethical Legislative Safety Privacy

Goals & Non-Functional Requirements Some non-functional requirements are derived from goals and

vision behind building the system System Goal – Users should be able to learn and adapt to new

system within no time – Usability, User friendliness System Goal – To provide 24/7 service to our customers to

maintain their accounts – Stability, Sustainability, Maintainability Distinction between functional and non-functional is not always

very clear Non-functional requirements should be written in quantitative

manner For some goals, quantitative measure is not possible i.e.

maintainability

Non-Functional Requirement MeasuresProperty MeasuresSpeed Transactions / second

Requests /secondUser response timeScreen refresh time

Size Memory / RAM consumptionSize of page in browser

Ease of use Training timeSteps to perform actions

Reliability Mean time to failureProbability of unavailabilityRate of failures

Robustness Fail-over mechanismBackupRestart time

Portability Platform independenceNo. of targeted systems

Conflicts in Non-Functional Requirements Conflicts in different non-functional requirements are

common in complex systems Space vs efficiency Spacecraft system

Minimize weight: use less independent chips Minimize power consumption: use low power chips Using low power chips means more independent chips Minimizing weight is more important or minimizing power

consumption?

Domain requirements Derived from the domain of the system May be functional, non-functional, or constraints Understandability

Expressed in terms of language of the domain Can be difficult to understand by software engineers Domain experts take these as implicit requirements but

development team doesn’t

Problems with natural language Lack of clarity Confusion Amalgamation of requirements Difficult to express complex requirements in terms of

natural language Difficult to express mathematical requirements Lack of readability

Guidelines for writing requirements Use standard format Use of diagrams / tables as much as possible Use language in a consistent way Avoid using computer jargons

Importance of requirements engineering Boehm (1981) – correcting the error after

development costs 68 times more than correcting it before

Other studies shows it can be as high as 200 times Identifying and defining requirements in proper way is

the key to reduce errors Prevention vs Removal of errors

Assignment # 11. Choose a software system of your own liking2. Give two examples of each type of requirement that

we have studied in context of selected system3. Submission Date: Monday, 8th April, 20144. Zero tolerance for Plagiarism