0721499 - Lecture 7 - Requirements Engineering

8/12/2019 0721499 - Lecture 7 - Requirements Engineering

1/20

Lecture 7: Requirements Engineering


2/20

Waterfall Model


3/20

The Requirement Engineering

Process The process of establishing what services are required and the

constraints on the systems operation and development

Requirements engineering help software engineers to better

understand the problem they will work to solve. It encompassesthe set of tasks that lead to an understanding of what thebusiness impact of the software will be, what the customer wantsand how end-users will interact with the software.

Requirement Engineering Process Feasibility Study

Requirements elicitation and analysis

Requirements Specification

Requirements Validation


4/20

The Requirements Engineering

Process


5/20

Requirements Elicitation It is the practice of obtaining the requirements of a system from

users, customers and other stakeholders. The practice is alsosometimes referred to as Requirement gathering.

Requirements elicitation practice include the following: Interviews Questionnaires User observation Workshops

Brain storming Use cases Role playing And prototyping


6/20

Requirements Elicitation Problems of Requirement Elicitation

Problems of scope:The boundary of system is ill-defined. Or unnecessary details are provided.

Problems of understanding:The users are not sure ofwhat they need, and dont have full understanding of theproblem domain.

Problems of volatility:the requirements changeovertime.


7/20

Requirements Elicitation Guidelines of Requirements Elicitation

Assess the business and technical feasibility for the proposed system

Identify the people who will help specify requirements.

Define the technical environment (e.g. computing architecture, operating

system, telecommunication needs) into which the system or product willbe placed

Identify domain constraints (i.e. characteristics of the businessenvironment specific to the application domain) that limit thefunctionality or performance of the system or product to build

Define one or more requirements elicitation methods (e.g. interviews, team

meetings, ..etc) Solicit participation from many people so that requirements are defined

from different point of views.

Create usage scenarios of use cases to help customers/ users better identifykey requirements.


8/20

Requirements Analysis Requirements Analysis, determining whether the

stated requirements are clear, complete, consistentand unambiguous.


9/20

Requirements Analysis Stakeholder Identification

Stakeholders are people or organizations that have avalid interest in the system. They may be affected by itdirectly or indirectly.

Stake holders may include:

Anyone who operates the system

Anyone who benefits from the system

Anyone involved in purchasing or procuring the system

People opposed to the system (negative stakeholders)

Organizations responsible for the system


10/20

Requirements Analysis Stakeholder Interviews

Interviews are a common technique used in requirementanalysis.

This technique can serve as a means of obtaining thehighly focused knowledge from different stakeholdersperspectives


11/20

Requirements Analysis Types of Requirements:

Customer Requirements: Operational distribution or deployment: Where will the system be

used?

Mission profile or scenario: How will the system accomplish itsmission objective? Performance and related parameters: What are the critical system

parameters to accomplish the mission? Utilization environments: how are the various system components to

be used?

Effectiveness requirements: How effective or efficient must thesystem be in performing its mission? Operational life cycle: How long will the system be in use by the

user? Environment: what environments will the system be expected to

operate in an effective manner?


12/20


Architectural Requirements:

A formal description and representation of a system,organized in a way that support reasoning about the structureof the system which comprises system components, theexternally visible properties of those components, therelationships and the behavior between them, and provides aplan from which products can be procured and systems

developed, that will work together to implement the overallsystem.


13/20


Functional Requirements:

Defines functions of a software system or its components.They may be calculations, technical details, datamanipulation and processing and other specific functionalitythat define what a system is supposed to accomplish?

They describe particular results of a system.

Functional requirements are supported by Non-functionalrequirements.


14/20


Non-Functional Requirements:

They are requirements that specify criteria that can be used to judge

the operation of a system, rather than specific behavior. Functional requirements define what the system is supposed to do,

whereas non-functional requirements define how a system issupposed to be.

Non-functional requirements can be divided into two main

categories: Execution qualities, such as security and usability, which are

observable at runtime.

Evolution qualities, such as testability, maintainability and scalability.


15/20

Requirements Specifications Requirements Specification is the direct result of a

requirement analysis and can refer to:

Software Requirements Specification

Hardware Requirements Specification


16/20

Requirements SpecificationsA Software Requirements Specification (SRS) a

requirements specification for a software system is acomplete description of the behavior of a system to bedeveloped. It includes a set of use cases that describeall the interactions the users will have with thesoftware. In addition to use cases, the SRS alsocontains non-functional requirements (such as

performance requirements, quality standards, ordesign constraints)


17/20

Requirements Specifications A Software Requirements Specification (SRS)

The software requirement specification document enlists allnecessary requirements for project development. To derive therequirements we need to have clear and thorough understanding of

the products to be developed. A general organization of an SRS is as follows:

Introduction Purpose, Scope, Definitions, System Overview, References

Overall Description Product Perspective, Product functions, User characteristics,

constraints, assumptions and dependencies. Specific Requirements

External Interface requirements, functional requirements,performance requirements, design constraints, logical databaserequirement, software system attributes.


18/20

Requirements Validation and

VerificationValidation (& Verification), is the process of checking

whether the requirements, as identified, do notcontradict the expectations about the system ofvarious stakeholders and do not contradict each other.

It is Requirements Quality Control


19/20

Validation Vs. VerificationValidation: Am I building the right product?

checking a work product against higher-level workproducts or authorities that frame this particular

product. Requirements are validated by stakeholders

Verification: Am I building the product right?

checking a work product against some standards andconditions imposed on this type of product and theprocess of its development. Requirements are verified by the analysts mainly


20/20

More about validation Requirements validation makes sure that requirements

meet stakeholders goals and dont conflict with them.

0721499 - Lecture 7 - Requirements Engineering

Documents

Transcript of 0721499 - Lecture 7 - Requirements Engineering