SRE Lec # 13 - Non-Functional Requirements

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



In this slide
_______________________________________________________

SRE – 
 Non-Functional Requirements

BSEF15 (V)

Abdul Razaq Ali

Objectives

● To introduce non-functional requirements

● To explain the schemes used to classify non-functional requirements

● To illustrate various derivation techniques for non-functional requirements

● To demonstrate the importance of non-functional requirements in critical systems

Non-Functional Requirements (NFRs)

Non-functional requirements:

● Define the overall qualities or attributes of the resulting system

● Place restrictions on the product being developed & its development process

● Specify external constraints that the product must meet.

Types of NFRs

The ‘IEEE-Std 830 - 1993’ lists 13, non-functional requirements to be included in a Software Requirements Document.

● Performance requirements

● Interface requirements

● Verification requirements

● Documentation requirements

● Security requirements

● Quality requirements

● Reliability requirements

● Maintainability requirements

Classification of NFRs

● NFRs may be classified n terms of qualities that a software must exhibit (Boehm)

● A more general classification distinguishes between product, process and external requirements

Product Requirements

● Specify the desired characteristics that a system or subsystem must possess.

● Most NFRs are concerned with specifying constraints on the behaviour of the executing system.

● The System service X shall have an availability of 999/1000 or 99%. This is a reliability requirement which means that out of every 1000 requests for this service, 999 must be satisfied.

● System Y shall process a minimum of 8 transactions per second. This is a performance requirement.

● The executable code of System Z shall be limited to 512Kbytes. This is a space requirement which specifies the maximum memory size of the system.

Source-code requirements

There are product requirements which relate to the source code of the system

Examples:

The system shall be developed for PC and Macintosh platforms. This is a portability requirement which affects the way in which the system may be designed

The system must encrypt all external communications using the RSA algorithm. This is a security requirement which specifies that a specific algorithm must be used in the product

Process Requirements

Process requirements are constraints placed upon the development process of the system

Process requirements include:

● Requirements on development standards and methods which must be followed

● CASE tools which should be used

● The management reports which must be provided

● Examples:

● The development process to be used must be explicitly defined and must be conformance with ISO 9000 standards

● The system must be developed using the XYZ suite of CASE tools

● Management reports setting out the effort expanded on each identified system component must be produced every two weeks

● A disaster recovery plan for the system development must be specified

External Requirements

● May be placed on both the product and the process

● Derived from the environment in which the system is developed

● External requirements are based on:

● Application domain information

● Organisational considerations

● The need for the system to work with other systems

● Health and safety or data protection regulations

● OR even basic natural laws such as the laws of physics

Relationship between User needs, concerns and NFRs

Goal-based Derivation

● Relates non-functional requirements to the goals of the enterprise

● Goal converted into a NFR:

● Goal (unverifiable)

● The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized

● Non-functional requirement (verifiable)

● Experienced controllers shall be able to use all the system functions after a total of two hours’ training. After this training, the average number of errors made by experienced users shall not exceed two per day

Testable NFRs

● Stakeholders may have vague goals which cannot be expressed precisely

● Vague and imprecise ‘requirements’ are problematic

● NFRs should satisfy two attributes for being Testable:

● Make it objective

● Use measurable metrics

Objective NFR is based on facts, can be measured and can be verified.

Subjective NFR is based on personal choices and desires

** It is not always possible to express NFRs objectively

Examples of measurable metrics for NFRs

Reliability

● Describe the run-time behaviour of the system

● Can be considered under two separate headings:

● Availability - is the system available for service when requested by end-users.

● Failure rate - how often does the system fail to deliver the service expected by end-users.

Performance

● Describe the speed of operation of a system

● Types of performance requirements:

● Response requirements

Security

● Security requirements are included in a system to ensure:

● Unauthorised access to the system and its data is not allowed

● Ensure the integrity of the system from accidental or malicious damage

● Examples of security requirements are:

● The access permissions for system data may only be changed by the system’s data administrator

● All system data must be backed up every 24 hours and the backup copies stored in a secure location which is not in the same building as the system

● All external communications between the system’s data server and clients must be encrypted

Usability

Concerned with specifying the user interface and end-user interactions with the system.

Well structured user manuals, informative error messages, help facilities and consistent interfaces enhance usability

Questions ?

SRE Term Project - Market based case Study (Success/failure story)

Select a product in industry of your choice, provide RE feedback report (Success/failure story)

You have to submit report till 8th Jan, 2018
The presentations of your term project will be schedule in makeup classes starts from 1st Jan, 2018. So be prepared in your winter vacations.

Please follow this format for your reports => Download File

SRE Lec # 11 - MDRE and Bespoke RE

>>>>> Download link here <<<<<


--------------------------------------------------
in this slide:

Differences  Between Bespoke RE & MDRE( Market Driven Requirement Engineering)

1. Start or Initiation of the project
2. Objective
3. Success Criteria
4. Elicitation.
5. Analysis and negotiation
6. Validation
7. Financial Risk
8. Relationship
9. Constraint Based Delivery.
 Start Of the Project
In market Driven model the project is
initiated, and it’s a continuous process because the focus of
MDRE is on large pool of customers, According to their
needs the requirements also change (each customer may
have different needs),in order to fulfill the requirements of
the customers the products are released in different version
according to the changes in the requirements.
              Objective

Delivering right product at the right time
 is the key to be successful.
This is done by envisioning and fostering the new set of requirements on the existing software products to capture market before the competitor companies
In MDRE the key objective is time to market besides this the other objectives are :
 to achieve the large number of Customers Satisfaction
Concentrate on the correct market for the product ,where
,when and how to release the product in to the market with
right time and in right place.
 These objectives that are defined depends on the success Criteria of the product. I.e., if the product is success full in the market it implies that
the objective of the company is achieved..

            Success Criteria

Success rate depends on the acceptance of the product   by the customers.
In MDRE the Success depends onthe
      product value
product  reviews,
     market share ,
                     time to release(correct time ),
the satisfaction of large number of  customers

ELICITATION PHASE:

in MDRE the source of requirements will be huge and
it will be difficult to satisfy each and every requirement of the customer .
 In order to achieve this goal the requirements are identified by the team in the first release of the particular product
ANALYSIS AND NEGOTIATION

in MDRE though analysis of the product is done ,negotiation with the
customer is not possible alternatively to satisfy the customer new versions of the product is released into the market.
Nature of requirements

The requirements are innovative and new ideas are implemented.
 It is important that market needs should be considered important in defining requirements along with the new ideas implementation.
VALIDATION:

Validation of the product is done to prove that a particular product meets the essential requirements of a customer for a particular purpose.
In MDRE the product is validated after the release i.e., the validation is done by the customers on the beta version of the product,
If there are any flaws in the product those flaws are corrected and the original version of the product is released.

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 ?