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

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

1

Requirements Management - II

Lecture # 19

2

Recap of Last Lecture

• We talked about requirements

management and why is it necessary tomanage requirements changes ratherthan disallow changes in requirements

• We’ll continue our discussion on

requirements management today

4

Requirements Identification - 2

• Problems with this are:
  • Numbers cannot be unambiguously assigned

until the document is complete

• Assigning chapter/section numbers is an

implicit classification of the requirement. Thiscan mislead readers of the document intothinking that the most important relationshipsare with the requirements in the same section

5

Requirements Identification

Techniques

• Dynamic renumbering• Database record identification• Symbolic identification

7

Database Record Identification

• When a requirement is identified it is

entered in a requirements database anda database record identifier is assigned.This database identifier is used in allsubsequent references to therequirement

8

Symbolic Identification

• Requirements can be identified by

giving them a symbolic name which isassociated with the requirement itself.For example, EFF-1, EFF-2, EFF-3may be used for requirements whichrelate to system efficiency

10

Requirements Storage

Techniques

• In one or more word processor files• In a specially designed requirements

database

11

Word Processor Documents:

Advantages

•^

Requirements are all stored in the sameplace

-^

Requirements may be accessed byanyone with the right word processor

-^

It is easy to produce the finalrequirements document

13

Word Processor Documents:

Disadvantages - 2

• Not possible to have version control on

individual requirements

• No automated navigation from one

requirement to another

14

Requirements Database - 1

•^

Each requirement is represented asone or more database entities

-^

Database query language is used toaccess requirements

16

Requirements Database:

Disadvantages

• Readers may not have the

software/skills to access therequirements database

• The link between the database and the

requirements document must bemaintained

17

Requirements Database Choice

Factors - 1

• The statement of requirements• The number of requirements• Teamwork, team distribution and

computer support

• CASE tool use• Existing database usage

19

Requirements DB - Choice

Factors - 2

• Teamwork, team distribution and

computer support– If the requirements are developed by a

distributed team of people, perhaps fromdifferent organizations, you need adatabase which provides for remote,multi-site access

20

Requirements DB - Choice

Factors - 3

• CASE tool use
  • The database should be the same as or

compatible with CASE tool databases.However, this can be a problem with someCASE tools which use their own proprietarydatabase

• Existing database usage
  • If a database for software engineering support

is already in use, this should be used forrequirements management