Announcement !!!

The Punjab University will remain closed on Monday and Tuesday, November 27 and 28, 2017 as per Government's directive.

SRE Lec # 9

>>>>> Download Link Here <<<<<



In this Slide:
__________________________________________________________

SRE –  Requirements Management

BSEF15 (V)

Abdul Razaq Ali

Requirements Management

The process of managing change to the requirements for a system

The principal concerns of requirements management are:

Managing changes to agreed requirements

Managing the relationships between requirements

Managing the dependencies between the requirements

Requirements cannot be managed effectively without requirements traceability

Who suggested the requirement, why the requirement exists, what requirements are related to it and how that requirement relates to other information e.g. design, implementation, documentation

CASE tools for Requirements Management

Requirements management involves the collection, storage and maintenance of large amounts of information

There are a number of CASE tools available designed to support requirements management such as:

A database system for storing requirements.

Document analysis and generation facilities to help construct a requirements database and to help create requirements documents.

Change management facilities which help ensure that changes are properly assessed and costed.

Traceability facilities which help requirements engineers find dependencies between system requirements.

Stable and Volatile Requirements

Stable and volatile requirements

Type of Volatile requirements

Mutable requirements

These are requirements which change because of changes to the environment in which the system is operating

Emergent requirements

These are requirements which cannot be completely defined when the system is specified but which emerge as the system is designed and implemented

Consequential requirements

These are requirements which are based on assumptions about how the system will be used. When the system is put into use, some of these assumptions will be wrong.

Compatibility requirements

These are requirements which depend on other equipment or processes.

Requirements Change Factors

Requirements errors, conflicts and inconsistencies

Evolving customer/end-user knowledge of the system

Technical, schedule or cost problems

Changing customer priorities

Environmental changes

Organizational changes

Requirements Identification

Essential for requirements management that every requirement should have a unique identification

Requirements Identification Techniques

Dynamic numbering

Some word processing systems allow for automatic renumbering of requirement depending on its chapter, section and position within the section

Database record identification

When a requirement is identified it is entered in a requirements database and a database record identifier is assigned.

Symbolic identification

Requirements can be identified by giving them a symbolic name which is associated with the requirement itself. For example, EFF-1, EFF-2, EFF-3 may be used for requirements which relate to system efficiency

Requirements Storage

Requirements have to be stored in such a way that they can be accessed easily and related to other system requirements

Possible storage techniques are:

In one or more word processor files - requirements are stored in the requirements document

In a specially designed requirements database

Word Processor Documents

Advantages

Requirements are all stored in the same place

Requirements may be accessed by anyone with the right word processor

It is easy to produce the final requirements document

Disadvantages

Requirements dependencies must be externally maintained

Search facilities are limited

Not possible to link requirements with proposed requirements changes

No automated navigation from one requirement to another

Requirements Database

Each requirement is represented as one or more database entities

Database query language is used to access requirements

Advantages

Good query and navigation facilities

Support for change and version management

Disadvantages

Readers may not have the software/skills to access the requirements database

The link between the database and the requirements document must be maintained

Change Management

Change management is concerned with the procedures, processes and standards which are used to manage changes to system requirements

Change management process includes:

Some requirements problem is identified.

The proposed changes are analyzed

The change is implemented.

Change Analysis and Costing

Change request rejection

If the change request is invalid. This normally arises if a customer has misunderstood something about the requirements and proposed a change which isn’t necessary.

If the change request results in consequential changes which are unacceptable to the user.

If the cost of implementing the change is too high or takes too long.

Change processing

Proposed changes are usually recorded on a change request form which is then passed to all of the people involved in the analysis of the change

Change request forms (CRF) may include:

Fields for documenting the change analysis

data fields

responsibility fields

status field

comments field

Traceability

Traceability information is information which helps you assess the impact of requirements change.

Types of traceability information:

Backward-from traceability - Links requirements to their sources in other documents or people

Forward-from traceability Links requirements to the design and implementation components

Backward-to traceability Links design and implementation components backs to requirements

Forward-to traceability Links other documents (which may have preceded the requirements document) to relevant requirements.

Types of Traceability

Requirements-sources traceability- Links the requirement and the people or documents which specified the requirement

Requirements-requirements traceability- Links requirements with other requirements which are, in some way, dependent on them. This should be a two-way link (dependents and is-dependent on)

Requirements-architecture traceability- Links requirements with the sub-systems where these requirements are implemented.

Requirements-design traceability- Links requirements with specific hardware or software components in the system which are used to implement the requirement

Requirements-interface traceability - Links requirements with the interfaces of external systems which are used in the provision of the requirements

Traceability Table

Traceability tables show the relationships between requirements or between requirements and design components

Traceability List

Traceability tables become more of a problem when there are hundreds or thousands of requirements as the tables become large and sparsely populated.

Traceability lists are simple lists of relationships which can be implemented as text or as simple tables

Traceability Policies

Traceability policies define what and how traceability information should be maintained.

It may include:

What information should be maintained

Which techniques/ matrix should be used

Role of people e.g. traceability manager

Handling policy exceptions

Factors influencing traceability policy:

No. of requirements

Estimated system lifetime

Level of Organizational maturity

Project team size and composition

Type of system

Questions ?

SRE Lec # 8

>>>>> Download Link Here <<<<<



In this Slide:
___________________________________________________________________

SRE –
 Requirements Validation

BSEF15 (V)

Abdul Razaq Ali

Validation Objectives

Certifies that the requirements document is an acceptable description of the system to be implemented

 Checks a requirements document for

 Completeness and consistency

Conformance to standards

Requirements conflicts

Technical errors

Ambiguous requirements

Analysis: Focuses on the relevance of the requirements.

Validation: Focuses on the accuracy of the details.

Validation Input and Output!

Validation Inputs

Requirements document

 Should be a complete version of the document, not an unfinished draft. Formatted and organized according to organizational standards

Organizational knowledge

Knowledge, often implicit, of the organization which may be used to judge the realism of the requirements

Organizational standards

Local standards e.g. for the organization of the requirements document

Validation Outputs

Problem list

List of discovered problems in the requirements document

Agreed actions

List of agreed actions in response to requirements problems. Some problems may have several corrective actions; some problems may have no associated actions

Requirements Validation

1) Reviews

2) Prototyping

3) User Manual

4) Requirements Testing (VnV)

1) Reviews

  A group of people read and analyze the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems

Review Activities

Plan review

The review team is selected and a time and place for the review meeting is chosen.

Distribute documents

The requirements document is distributed to the review team members

Prepare for review

Individual reviewers read the requirements to find conflicts, omissions, inconsistencies, deviations from standards and other problems.

Hold review meeting

Individual comments and problems are discussed and a set of actions to address the problems is agreed.

Follow-up actions

The chair of the review checks that the agreed actions have been carried out.

Revise document

The requirements document is revised to reflect the agreed actions. At this stage, it may be accepted or it may be re-reviewed

Problem Actions

Requirements Clarification

REQ: There shall be a barrier at the entrance of the car park.

Define “barrier”, e.g.: porter’s kiosk, bar type, floor spikes. What is the barrier structure, dimensions, placement, etc. ? What is its action behavior?

Missing Information

No mention of the hours of operation of the barrier. Do not assume 24/7/365.

No mention of safety issues

Requirements Conflict

For emergency purposes, the South entrance to the car park shall always be open.

Conflict: Drivers can sneek into, or exit from, the car park through the South entrance/exit

Unrealistic requirements

100% reliability of the barrier operation is required at all times.

Hidden camera shall detect private vehicles exiting through the emergency exit and report to the administration.

Review-team Membership

Reviews should involve a number of stakeholders drawn from different backgrounds

People from different backgrounds bring different skills and knowledge to the review

Stakeholders feel involved in the RE process and develop an understanding of the needs of other stakeholders

Review team should always involve at least a domain expert and an end-user

Reviews Checklist

Understandability

Can readers of the document understand what the requirements mean?

Redundancy

Is information unnecessarily repeated in the requirements document?

Completeness

Does the checker know of any missing requirements or is there any information missing from individual requirement descriptions?

Ambiguity

Are the requirements expressed using terms which are clearly defined? Could readers from different backgrounds make different interpretations of the requirements?

Consistency

Do the descriptions of different requirements include contradictions? Are there contradictions between individual requirements and overall system requirements?

Reviews Checklist - II

Organization

Is the document structured in a sensible way? Are the descriptions of requirements organized so that related requirements are grouped?

Conformance to standards

Does the requirements document and individual requirements conform to defined standards? Are departures from the standards, justified?

Traceability

Are requirements unambiguously identified, include links to related requirements and to the reasons why these requirements have been included?

Pre-review Checking

Reviews are expensive because they involve a number of people spending time reading and checking the requirements document

Less expensive but Risky [misses multiple perspectives]

This expense can be reduced by using pre-review checking where a couple of people checks the document and looks for straightforward problems such as missing requirements, lack of conformance to standards, typographical errors, etc.

Document may be returned for correction or the list of problems distributed to other reviewers

Pre-review Checking - II

2) Prototyping

Prototypes for requirements validation demonstrate the requirements and help stakeholders discover problems

Validation prototypes should be complete, reasonably efficient and robust.

Prototyping Activities

Choose prototype testers

The best testers are users who are fairly experienced and who are open-minded about the use of new systems. End-users who do different jobs should be involved so that different areas of system functionality will be covered.

Develop test scenarios

Careful planning is required to draw up a set of test scenarios which provide broad coverage of the requirements. End-users shouldn’t just play around with the system as this may never exercise critical system features.

Execute scenarios

The users of the system work, usually on their own, to try the system by executing the planned scenarios.

Document problems

Its usually best to define some kind of electronic or paper problem report form which users fill in when they encounter a problem.

3) User Manual

Writing a user manual from the requirements forces a detailed requirements analysis and thus can reveal problems with the document

Information in the user manual

Description of the functionality and how it is implemented

Which parts of the system have not been implemented

How to install and get started with the system

4) Requirements Testing

Each requirement should be testable i.e. it should be possible to define tests to check whether or not that requirement has been met.

Inventing requirements tests is an effective validation technique as missing or ambiguous information in the requirements description may make it difficult to formulate tests

Each functional requirement should have an associated test

Requirements Testing – global perspective

Test Case definition

What usage scenario might be used to check the requirement?

Does the requirement, on its own, include enough information to allow a test to be defined?

Is it possible to test the requirement using a single test or are multiple test cases required?

Could the requirement be re-stated to make the test cases more obvious?

Test Record form

The requirement’s identifier

There should be at least one for each requirement.

Related requirements

These should be referenced as the test may also be relevant to these requirements.

Test description

A brief description of the test and why this is an objective requirements test. This should include system inputs and corresponding outputs.

Requirements problems

A description of problems which made test definition difficult or impossible.

Comments and recommendations

These are advice on how to solve requirements problems which have been discovered.

Test Record form – II

Questions ?

University of the Punjab will remain closed on Monday 20th November on Account of its 126th Convocation.

University of the Punjab will remain closed on Monday 20th November on Account of its 126th Convocation.

SRE - IEEE Recommended Practice for Software Requirements Specifications

>>>>> Download Link Here <<<<<


In this Document
__________________________________________________________


Contents
CLAUSE PAGE

1 . Overview .............................................................................................................................................. 1
1.1 Scope ............................................................................................................................................ 1
2 . References ............................................................................................................................................ 2
3 . Definitions ............................................................................................................................................ 3
4 . Considerations for producing a good SRS ........................................................................................... 4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Nature of the SRS ........................................................................................................................ 4
Environment of the SRS .............................................................................................................. 4
Characteristics of a good SRS ...................................................................................................... 5
Joint preparation of the SRS ........................................................................................................ 9
SRS evolution .............................................................................................................................. 9
Prototyping ................................................................................................................................... 9
Embedding design in the SRS .................................................................................................... 10
Embedding project requirements in the SRS ............................................................................. 10
5 . The parts of an SRS ........................................................................................................................... 11
5.1
5.2 Overall description (Section 2 of the SRS) ................................................................................ 12
5.3 Specific requirements (Section 3 of the SRS) ............................................................................ 15
5.4 Supporting information .............................................................................................................. 20
Introduction (Section 1 of the SRS) ........................................................................................... 11
Annex A ...................................................................................................................................................... 21
A.l Template of SRS section 3 organized by mode: Version 1 ............................................... 21
A.2
A.3
Template of SRS section 3 organized by mode: Version 2 ............................................... 21
Template of SRS section 3 organized by user class .......................................................... 22
A.4 Template of SRS section 3 organized by object ................................................................ 22
AS Template of SRS section 3 organized by feature ............................................................... 23
A.6 Template of SRS section 3 organized by stimulus ............................................................ 24
A.7 Template of SRS section 3 organized by functional hierarchy .......................................... 24
A.8 Template of SRS section 3 showing multiple organizations ............................................. 26

SRE Lec # 7

>>>>> Download Link <<<<<



In this Slide
____________________________________________________________

SRE – Requirements Analysis, Prioritization and Specification

BSEF15 (V)

Abdul Razaq Ali

Requirements Analysis & Prioritization

Reasons (Why)

Occurrences (When)

Techniques (How)

Trigger !

Requirements Engineer: “what requirements are the most important to you…”

Customer: ”All are… I need everything, otherwise they wouldn’t be specified…!”

Why Prioritize ?

We don’t have enough money!

We don’t have enough time!

We don’t have enough people!

Avoid risk or penalty!

We have to improve maintainability!

We have to improve the performance!

We have to meet the new customer demands!

We have to fix improve software already in use!

When Prioritize ?

Pre-project (sometimes at initial stages of project)

Stakeholder prioritization

Operator prioritization

During project

Re-prioritization (Change management)

Continuous

Important

Ask stakeholders and keep them informed throughout the project

Establish an understanding of why things change

Establish an understanding of what impact new requirements / changed requirements and the project as a whole

Prioritization Techniques

Define scale for requirements –prioritization can be done informally in small projects where you rate requirements on different scales

Prioritization Techniques

Cost-Value

Some requirements are High-value and low-cost, others are Low-value and high-cost

Pareto-principle(vital few, trivial many)

20% of the requirements for 80% of value

20% of the requirements for 80% of cost

20% of the requirements for 80% of risk

Binary Tree

Requirements are divided and subdivided till they are atomic

Logical path are defined which makes it easy to prioritize while knowing their dependencies

100 –Point method

Assign values to requirements till 100 points threshold are reached, the more points, the more important

Cost-Value

Prioritization Techniques

MoSCoW

M -MUST: Describes a requirement that must be satisfied in the final solution

S -SHOULD: Represents a high-priority item that should be included in the solution if it is possible.

C -COULD: Describes a requirement which is considered desirable but not necessary.

W -WON'T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

Benefits of Prioritization

Establish what really matters / is important to the stakeholders (which includes customers)

Establish development factors

What to implement

Implementation order

What requirements. can be downsized from projects if necessary (in case of problems, new requirements etc)

Gives project management Options to handle change and real world occurrences –balance

Better to establish priority at an early stage than when the crisis occurs, i.e. planned vs. panic initiated.

Establish trust

As the customer realizes why prioritization is done, he/she will see that making money isn’t your primary goal. (CUSTOMER SATISFACTION IS!)

Requirements Specification

Requirement elicitation and specification runs in parallel for initial phase until complete set of requirements is not identified.

We already have studied all the methods for Requirements Elicitation like Interviewing, scenarios, prototyping etc.

SRS –IEEE document overview

Section 4 –Important considerations in writing a Good SRS

Section 5 –Parts of SRS

Reference Book1, chap 10

Questions ?