Requirements Analysis-Software Requirement-Lecture Slides, Slides of Software Project Management

This course includes types of requirements, modeling of non functional, static and dynamic modelling, requirement elicitation and use case modeling. This lecture includes: Context, Organization, environment, project, constraints, Imposed, People, Discussed, Interviews

Typology: Slides

2011/2012

Uploaded on 08/07/2012

angana
angana 🇮🇳

4.4

(52)

158 documents

1 / 29

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Requirements Analysis
Lecture # 12
docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d

Partial preview of the text

Download Requirements Analysis-Software Requirement-Lecture Slides and more Slides Software Project Management in PDF only on Docsity!

1

Requirements Analysis

Lecture # 12

2

Recap of Requirements

Elicitation - 1

  • Requirements elicitation deals with

discovering requirements for a softwareproduct

  • It is an iterative process and consists of

many activities including establishingobjectives, understanding background,organizing knowledge, and collectingrequirements

4

Recap of Requirements

Elicitation - 3

• Context (organization, environment,

project, constraints imposed by people)

• Guidelines for knowledge acquisition• Discussed in detail some requirements

elicitation techniques, especiallyinterviews

5

Requirements Engineering Process

RequirementsElicitation

RequirementsAnalysis andNegotiation

RequirementsSpecification

RequirementsValidation

User Needs, Domain Information,

Existing System Information, Regulations,

Standards, Etc.

RequirementsDocument

Agreed Requirements

7

Requirements Analysis - 1

  • The aim of requirements analysis is to

discover problems with the systemrequirements, especially incompletenessand inconsistencies

  • Some analysis is inter-leaved with

requirements elicitation as problems aresometimes obvious as soon as a requirementis expressed

8

Requirements Analysis - 2

• Detailed analysis usually takes place

after the initial draft of therequirements document is produced

• Analysis is concerned with incomplete

set of requirements, which has notbeen discussed by stakeholders

10

Comments on Requirements

Analysis - 1

• Analysts read the requirements,

highlight problems, and discuss themin requirements review meetings

• This is a time-consuming and

expensive activity

11

Comments on Requirements

Analysis - 2

• Analysts have to think about

implications of the draft statements ofrequirements

• People do not think in the same way

and different analysts tackle theprocess in different ways

13

Requirements Analysis Stages

• Necessity checking• Consistency and completeness

checking

• Feasibility checking

14

Necessity Checking

• The need for the requirement is

analyzed. In some cases, requirementsmay be proposed which don’tcontribute to the business goals of theorganization or to the specific problemto be addressed by the system

16

Feasibility Checking

• The requirements are checked to

ensure that they are feasible in thecontext of the budget and scheduleavailable for the system development

17

Requirements Analysis Process

Necessitychecking

Consistency andcompleteness

checking

Feasibilitychecking

Unnecessaryrequirements

Conflicting and

incompleterequirements

Infeasiblerequirements

Requirements Analysis

19

Analysis Checklists - 1

  • Each requirement may be assessed against

the checklist

  • When potential problems are discovered,

these should be noted carefully

  • They can be implemented as a spreadsheet,

where the rows are labeled with therequirements identifiers and columns are thechecklist items

20

Analysis Checklists - 2

  • The are useful as they provide a reminder of

what to look for and reduce the chances thatyou will forget some requirements checks

  • They must evolve with the experience of the

requirements analysis process

  • The questions should be general, rather than

restrictive, which can be irrelevant for mostsystems