Requirements EngineeringLecture 03

National University – FASTSeptember 05, 2015, 18:00 – 21:00

2

Requirements Engineering

Analyze, Document,

Review, Negotiate

Requirements Change Process

Baseline Requirements

RequirementsDevelopment

RequirementsManagement Current

BaselineRevisedBaseline

Marketing,Customers,

Management

ProjectEnvironmentRequirements

ChangesProject

Changes

Marketing, Customers, Management

Requirements

3

Requirements EngineeringThe deliverable from requirements

development is a baseline that constitutes an agreement among key project stakeholders as to the new product’s capabilities

During requirements management, the project controls changes in the requirements baseline and monitors requirements implementation

4

Subcomponents of Requirements Development

Elicitation Analysis

Specification Validation

5

ElicitationUnderstand our usersDiscover their needsDefine the product’s business requirementsGet extensive user involvementFocus on user tasksDefine quality attributes

6

AnalysisDerive more detailed requirements from

higher level requirementsCreate multiple views of the requirementsNegotiate prioritiesSearch for missing requirementsEvaluating technical feasibility, risk, and

failure modesAnalysis provides a feedback loop that refines

the understanding that the analyst developed during an elicitation activity

7

SpecificationRecord the various types of requirements

information in forms that will facilitate communication among the project stakeholdersDocuments containing natural language textGraphical analysis modelsTablesMathematical expressions

Store requirements in a management toolDOORS – Quality Systems and Software, Inc.RequisitePro – Rational Software Corporation

8

ValidationInspect requirements specificationsEnsure correct requirements , that will

Satisfy customer needsHave all the characteristics of high quality

requirementsValidation might lead the analyst to

Rewrite some requirements specificationsReassess the initial analysisCorrect and refine the set of documented

requirements

9

What Requirements Are NotRequirements specifications do not include

design or implementation details (other than known constraints), project planning information, or testing information

Separate such items from the requirements so that the requirements activities can focus on understanding what the team intends to build

10

What Requirements Are NotProjects typically have other kinds of

requirements, includingDevelopment environment requirementsSchedule or budget limitationsThe need for a tutorial to help new users get

up to speedRequirements for releasing a product and

moving it into the support environment

11

Levels of RequirementsA project needs to address three levels of

requirements, which come from different sources at different project stagesBusiness Requirements

Describe why the product is being built and identify the benefits both customers and the business will reap

User Requirements Captured in the form of use cases, describe the

tasks or business processes a user will be able to perform with the product

12

Levels of RequirementsFunctional Requirements

Describe the specific system behaviors that must be implemented

The functional requirements are the traditional “shall” statements found in a software requirements specification (SRS)

System Requirements The term system requirements describes the top level

requirements for a product that contains multiple subsystems

A system can be all software or it can include both software and hardware subsystems

People are a part of a system, too, so certain system functions might be allocated to human beings

13

Types of RequirementsBusiness

Requirements

Vision and Scope Document

User Requirements

System Requirements

Functional Requirements

Business Rules

Quality Attributes

External Interfaces

Constraints

Use Case Document

Software Requirements Specification

Functional Non Functional

14

Non Functional RequirementsBusiness Rules

Business rules include corporate policies, government regulations, industry standards (such as accounting practices), and computational algorithms

Quality AttributesQuality attributes describe the product’s

characteristics in various dimensions that are important either to users or to developers and maintainers. These characteristics include availability, performance, usability, portability, integrity, efficiency, robustness, and many others

Sometimes these characteristics are called quality factors or quality of service requirements

15

Non Functional RequirementsExternal Interfaces

External interfaces between the system and the outside world constitute another class of nonfunctional requirements

ConstraintsThese are restrictions imposed on the choices

available to the developer for some legitimate reason

Some people consider all requirements to be constraints, but this broad generalization isn’t very helpful