requirments_management

8/7/2019 requirments_management

1/56

1

Requirements ManagementRequirements Management

Key Process AreaKey Process Area

Level 2Level 2

Presented by: Omar Kamal HosneyPresented by: Omar Kamal HosneyLucent TechnologiesLucent Technologies


2/56

2

Requirements Management KPA: PurposeRequirements Management KPA: Purpose

The purpose of Requirements Management

is to establish a common understandingbetween the customer and the software

project of the customer's requirements

that will be addressed by the software

project.


3/56

3

Requirements Management KPA: CustomerRequirements Management KPA: Customer

Customer

Customer

External

Internal

SecondaryPrimary


4/564

Requirements Management KPARequirements Management KPA

UserUser IndustryIndustryOther

Groups

Other

Groups

Software

Development

SoftwareDevelopment

System

Engineering

System

EngineeringCustomer

Customer

Requirements

allocated to

software

Requirements

allocated to

software

Customer

Requirements


5/565

Requirements Management KPA (Cont.)Requirements Management KPA (Cont.)

Establishing and maintaining an

agreement with the customer on the

requirements for the software

project.

This agreement is referred to as the"system requirements allocated to

the software."

Requirements Management involves:


6/566

Requirements Management KPA (Cont.)Requirements Management KPA (Cont.)

The agreement covers both thetechnical and non-technical (e.g.,

delivery dates) requirements.

The agreement forms the basis

for estimating, planning,performing, and tracking thesoftware project's activities

throughout the software lifecycle.

Technical Non-Technical

Planning


7/567

Goals For Requirements Management KPAGoals For Requirements Management KPA

System requirements allocated to software

are controlled to establish a baseline for

software engineering and management use.

Software plans, products, and activities are

kept consistent with the system requirements

allocated to software.


8/568

Common FeaturesCommon Features

Commitment to Perform

Commitment to Perform describes theactions the organization must take to ensure

that the process is established and will

endure. Commitment to Perform typically

involves establishing organizational policies

and senior management sponsorship.


9/569

RM Commitment to Perform: C1RM Commitment to Perform: C1

The project follows a written organizational policy for managing

the system requirements allocated to software.

Commitment 1Commitment 1


10/56

10





The system requirements allocated to the software are

referred to as "allocated requirements" in these practices.The allocated requirements are the subset of the system

requirements that are to be implemented in the software

components of the system. The allocated requirements are a

primary input to the software development plan. Software

requirements analysis elaborates and refines the allocated

requirements and results in software requirements which

are documented.

The system requirements allocated to the software are

referred to as "allocated requirements" in these practices.

The allocated requirements are the subset of the system

requirements that are to be implemented in the software

components of the system. The allocated requirements are a

primary input to the software development plan. Software

requirements analysis elaborates and refines the allocatedrequirements and results in software requirements which

are documented.

System Req.

Software Req.


11/56

11





This policy typically specifies that:

1. The allocated requirements are documented.

2. The allocated requirements are reviewed by:

the software managers, and

other affected groups.

This policy typically specifies that:

1. The allocated requirements are documented.

2. The allocated requirements are reviewed by:

the software managers, and

other affected groups.

SRS Document

SRS Review


12/56

12





Examples of affected groups include:

- system test,- software engineering (including all subgroups, such as

software design),

- system engineering,

- software quality assurance,- software configuration management, and

- documentation support.

Examples of affected groups include:

- system test,- software engineering (including all subgroups, such as

software design),

- system engineering,

- software quality assurance,- software configuration management, and

- documentation support.


13/56

13





3. The software plans, work products, and activities are

changed to be consistent with changes to the allocated

requirements.


changed to be consistent with changes to the allocated

requirements.


14/56

14


Ability to Perform.

Ability to Perform describes thepreconditions that must exist in the project

or organization to implement the software

process competently. Ability to Perform

typically involves resources, organizational

structures, and training.


15/56

15

RM Ability to Perform: A1RM Ability to Perform: A1

For each project, responsibility is established for analyzing the

system requirements and allocating them to hardware, software,and other system components.

Ability 1Ability 1


16/56


17/56

17


For each project, responsibility is established for analyzing the

system requirements and allocating them to hardware, software,and other system components.

Ability 1Ability 1

This responsibility covers:

1. Managing and documenting the system requirements and

their allocation throughout the project's life.

2. Effecting changes to the system requirements and their

allocation.

This responsibility covers:

1. Managing and documenting the system requirements and

their allocation throughout the project's life.

2. Effecting changes to the system requirements and their

allocation.


18/56

18


The allocated requirements are documented.

Ability 2Ability 2

A i i f A2RM Abili P f A2


19/56

19



Ability 2Ability 2

The allocated requirements include:

1. The non-technical requirements (i.e., the agreements,

conditions, and/or contractual terms) that affect anddetermine the activities of the software project.

Examples of agreements, conditions, and contractual terms

include:- products to be delivered,

- delivery dates, and

- milestones.

The allocated requirements include:

1. The non-technical requirements (i.e., the agreements,

conditions, and/or contractual terms) that affect anddetermine the activities of the software project.

Examples of agreements, conditions, and contractual terms

include:- products to be delivered,

- delivery dates, and

- milestones.

Non-Technical

RM Abilit t P f A2RM Abilit t P f A2


20/56

20



Ability 2Ability 2

2. The technical requirements for the software.

Examples of technical requirements include:

- end user, operator, support, or integration functions;

- performance requirements;

- design constraints;- programming language; and

- interface requirements.

2. The technical requirements for the software.

Examples of technical requirements include:

- end user, operator, support, or integration functions;

- performance requirements;

- design constraints;- programming language; and

- interface requirements.

Technical

RM Abilit t P f A2RM Abilit t P f A2


21/56

21



Ability 2Ability 2

3. The acceptance criteria that will be used to validate that

the software products satisfy the allocated requirements.

3. The acceptance criteria that will be used to validate that

the software products satisfy the allocated requirements.

Acceptance Criteria

Check List.

RM Abilit t P f A3RM Abilit to Perform: A3


22/56

22


Adequate resources and funding are provided for managing the

allocated requirements.

Ability 3Ability 3


23/56


24/56



25/56

25


Activities Performed

Activities Performed describes the roles andprocedures necessary to implement a key

process area. Activities Performed typically

involve establishing plans and procedures,

performing the work, tracking it, and taking

corrective actions as necessary.

RM Activities Performed: A1RM Activities Performed: A1


26/56

26


Activity 1Activity 1

1. Incomplete and missing allocated requirements are

identified.2. The allocated requirements are reviewed to determine

whether they

are:

feasible and appropriate to implement in software,clearly and properly stated,

consistent with each other, and

testable.

1. Incomplete and missing allocated requirements are

identified.2. The allocated requirements are reviewed to determine

whether they

are:

feasible and appropriate to implement in software,clearly and properly stated,

consistent with each other, and

testable.

The software engineering group reviews the allocated requirements before

they are incorporated into the software project.



27/56

27


The software engineering group reviews the allocated requirements before

they are incorporated into the software project.


3. Any allocated requirements identified as having

potential problems are reviewed with the group

responsible for analyzing and allocating system

requirements, and necessary changes are made.

3. Any allocated requirements identified as having

potential problems are reviewed with the group

responsible for analyzing and allocating system

requirements, and necessary changes are made.


28/56



29/56

29



The software engineering group uses the allocated requirements as the basis

for software plans, work products, and activities.



30/56

30





The allocated requirements:

1. Are managed and controlled.

"Managed and controlled" implies that the version of the

work product in use at a given time (past or present) is known(i.e., version control), and changes are incorporated in a

controlled manner (i.e., change control).

If a greater degree of formality than is implied by "managed

and controlled" is desired, the work product can be placedunder the full discipline of configuration management, as is

described in the Software Configuration Management key

process area.

The allocated requirements:

1. Are managed and controlled.

"Managed and controlled" implies that the version of the

work product in use at a given time (past or present) is known(i.e., version control), and changes are incorporated in a

controlled manner (i.e., change control).

If a greater degree of formality than is implied by "managed

and controlled" is desired, the work product can be placedunder the full discipline of configuration management, as is

described in the Software Configuration Management key

process area.



31/56

31

RM Activities Performed: A2




2. Are the basis for the software development plan.

3. Are the basis for developing the software

requirements.

2. Are the basis for the software development plan.

3. Are the basis for developing the software

requirements.



32/56

32

Changes to the allocated requirements are reviewed and

incorporated into the software project.


1. The impact to existing commitments is assessed, and

changes are negotiated as appropriate. Changes to commitments made to individuals and

groups external to the organization are reviewed with

senior management.

Changes to commitments within the organization are

negotiated with the affected groups.

1. The impact to existing commitments is assessed, and

changes are negotiated as appropriate.

Changes to commitments made to individuals and

groups external to the organization are reviewed with

senior management.

Changes to commitments within the organization are

negotiated with the affected groups.



33/56

33

Changes to the allocated requirements are reviewed and

incorporated into the software project.


2. Changes that need to be made to the software plans,work products, and activities resulting from changes to

the allocated requirements are:

identified, evaluated, assessed for risk, documented,

planned, communicated to the affected groups and

individuals, and tracked to completion.

2. Changes that need to be made to the software plans,

work products, and activities resulting from changes to

the allocated requirements are:

identified, evaluated, assessed for risk, documented,

planned, communicated to the affected groups and

individuals, and tracked to completion.



34/56

34

Measurement and Analysis

Measurement and Analysis describes theneed to measure the process and analyze themeasurements. Measurement and Analysis

typically includes examples of themeasurements that could be taken todetermine the status and effectiveness of the

Activities Performed.

RM Measurement and Analysis: M1RM Measurement and Analysis: M1


35/56

35

y

Measurements are made and used to determine the status of the

activities for managing the allocated requirements.

Measurement 1Measurement 1

Examples of measurements include:

- status of each of the allocated requirements;- change activity for the allocated requirements; and

- cumulative number of changes to the allocated

requirements, including total number of changes

proposed, open, approved, and incorporated into thesystem baseline.

Examples of measurements include:

- status of each of the allocated requirements;- change activity for the allocated requirements; and

- cumulative number of changes to the allocated

requirements, including total number of changes

proposed, open, approved, and incorporated into thesystem baseline.



36/56

36

Verifying Implementation

Verifying Implementation describes thesteps to ensure that the activities areperformed in compliance with the process

that has been established. Verificationtypically encompasses reviews and audits bymanagement and software quality

assurance.

RM Verifying Implementation: V1RM Verifying Implementation: V1


37/56

37

The activities for managing the allocated requirements are

reviewed with senior management on a periodic basis.

Verification 1Verification 1

The primary purpose of periodic reviews by senior

management is to provide awareness of and insightinto software process activities at an appropriate level

of abstraction and in a timely manner. The time

between reviews should meet the needs of the

organization and may be lengthy, as long as adequatemechanisms for exception reporting are available.

The primary purpose of periodic reviews by senior

management is to provide awareness of and insightinto software process activities at an appropriate level

of abstraction and in a timely manner. The time

between reviews should meet the needs of the

organization and may be lengthy, as long as adequatemechanisms for exception reporting are available.



38/56

38

The activities for managing the allocated requirements are

reviewed with the project manager on both a periodic andevent-driven basis.




39/56

39

The software quality assurance group reviews and/or audits the

activities and work products for managing the allocatedrequirements and reports the results.




40/56

40

The software quality assurance group reviews and/or audits the

activities and work products for managing the allocatedrequirements and reports the results.


At a minimum, these reviews and/or audits verify that:1. The allocated requirements are reviewed, and problems are

resolved before the software engineering group commits to

them.


appropriately revised when the allocated requirements change.

3. Changes to commitments resulting from changes to the

allocated requirements are negotiated with the affected groups.

At a minimum, these reviews and/or audits verify that:

1. The allocated requirements are reviewed, and problems are

resolved before the software engineering group commits to

them.


appropriately revised when the allocated requirements change.

3. Changes to commitments resulting from changes to the

allocated requirements are negotiated with the affected groups.


41/56

AppendixAppendix


42/56

42

This Section is not a part of the

presentation show. It is used only

for further discussions.

Hint: The Requirement Engineering ProcessHint: The Requirement Engineering Process


43/56

43

Requirements AnalysisRequirements Analysis

Feasibility StudyFeasibility Study

Feasibility ReportFeasibility Report Requirements DefinitionRequirements Definition

Requirements SpecificationRequirements Specification

System ModelsSystem Models

Definition of

Requirements

Definition of

Requirements

Specifications of RequirementsSpecifications of RequirementsRequirements

DocumentRequirementsDocument

Ian Sommerville, Software Engineering" Addison Wesley, 5th Edition, 1998.

Hint: Requirements ValidationHint: Requirements Validation


44/56

44

ValidityValidity CompletenessCompleteness


ConsistencyConsistencyRealismRealism

Requirements ValidationRequirements Validation

PrototypingPrototyping

EvolutionaryEvolutionary Throw AwayThrow Away

Hint: Requirements Document (Analysis)Hint: Requirements Document (Analysis)


45/56

45

Requirements DocumentRequirements Document

Requirements DefinitionRequirements Definition




This is the process of deriving the system requirements through observation of

existing systems, discussions with potential users and procurers, task analysis and so

on. This may involve the development of one or more different system models. These

help the analyst understand the system to be specified. System prototypes may also bedeveloped to help understand the requirements.

This is the process of deriving the system requirements through observation of

existing systems, discussions with potential users and procurers, task analysis and so

on. This may involve the development of one or more different system models. These

help the analyst understand the system to be specified. System prototypes may also bedeveloped to help understand the requirements.

Hint: Requirements Document (Definition)Hint: Requirements Document (Definition)


46/56

46






Requirements definition is the activity of translating the information gathered during

the analysis activity into a document that defines a set of requirements. These should

accurately reflect what the customer wants. This document must be written so that itcan be understood by the end-user and the system customer.

Requirements definition is the activity of translating the information gathered during

the analysis activity into a document that defines a set of requirements. These should

accurately reflect what the customer wants. This document must be written so that itcan be understood by the end-user and the system customer.

Hint: Requirements Document (Specification)Hint: Requirements Document (Specification)


47/56

47






A detailed and precise description of the system requirements is set out to act as a

basis for a contract between client and software developer. The creation of this

document is usually carried out in parallel with some high-level design. The designand requirements activities influence each other as they develop.

A detailed and precise description of the system requirements is set out to act as a

basis for a contract between client and software developer. The creation of this

document is usually carried out in parallel with some high-level design. The designand requirements activities influence each other as they develop.


48/56

Hint: Requirements ValidationHint: Requirements Validation


49/56

49

ValidityValidity CompletenessCompleteness


ConsistencyConsistencyRealismRealism

Requirements ValidationRequirements Validation

PrototypingPrototyping

EvolutionaryEvolutionary Throw AwayThrow Away

Hint: Requirements AnalysisHint: Requirements Analysis


50/56

50

View PointsView Points System ModelsSystem Models


Use CasesUse Cases


Data-flow models.

Semantic Data modelsObject models

Data dictionaries

Data-flow models.


Data dictionaries

Use case model

Use case scenariosSequence diagrams

State charts

Use case model


State charts

Bruce Powel Douglass, Real-Time UML" Addison Wesley, 2th Edition, 1999.

Hint: Req. Definition and SpecificationHint: Req. Definition and Specification


51/56

51

Functional RequirementsFunctional Requirements



Non-functional RequirementsNon-functional Requirements


Structured natural languageDesign description language

Requirements specification languages

Graphical notationsMathematical specifications.

Structured natural languageDesign description language

Requirements specification languages

Graphical notationsMathematical specifications.

Hint: Requirements AnalysisHint: Requirements Analysis


52/56

52

View PointsView Points System ModelsSystem Models


Use CasesUse Cases


Data-flow models.


Data dictionaries

Data-flow models.


Data dictionaries

Use case model


State charts

Use case model


State charts

Bruce Powel Douglass, Real-Time UML" Addison Wesley, 2th Edition, 1999.

Example: Requirements TemplatesExample: Requirements Templates

Template Notes


53/56

53

Template Notes

General Description

Assumptions and Dependencies

Product Functions

Product Prospective

Requirements SpecificationFunctional Requirements

Non Functional Requirements

Other Requirements

Constraints/LimitationsAcceptance

Apportioning of Requirements

Prioritisation of Requirements

Dependencies between Requirements

Traceability of Req. To SOW

Example: Requirements Templates (Cont.)Example: Requirements Templates (Cont.)



54/56

54


Product Requirements

Efficiency Requirements

Performance Requirements

Space Requirements

Reliability Requirements

Portability Requirements

Usability Requirements

Process Requirements

Delivery RequirementsImplementation Requirements

Standards Requirements

Legislative Requirements

External RequirementsEthical Requirements

Interoperability Requirements

Notes: How to measure nonNotes: How to measure non--functional req.?functional req.?


55/56

55

Requirements measures

Speed: Processed transactions/second, User event

response time, Screen refresh time.

Size: Kbytes, Number of RAM Chips.Ease of Use: Training time, Numbers of help frames.

Reliability: Mean time to failure, Probability of

unavailability, Rate of failure occurrence.

Robustness: Time to restart after failure, Percentage of

events causing failure, probability of data corruption on

failure.

Portability: Percentage of target-dependant statements, No.of target systems

Hint 1: Process DefinitionHint 1: Process Definition


56/56

56

Process DefinitionProcess Definition Implementation and DeploymentImplementation and Deployment

Process Analysis and ChangeProcess Analysis and Change

Pankaj Jalote, CMM in Practice" Addison Wesley, SEI Series in Software Engineering, 2000.

Date post:	08-Apr-2018
Category:	Documents
Upload:	erwin-setiawan
View:	221 times
Download:	0 times

requirments_management

Documents