Sunday, 26 November 2017

Announcement !!!

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

Tuesday, 21 November 2017

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 ?

Sunday, 5 November 2017

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 ?