The Punjab University will remain closed on Monday and Tuesday, November 27 and 28, 2017 as per Government's directive.
Sunday, 26 November 2017
Tuesday, 21 November 2017
SRE Lec # 9
>>>>> Download Link Here <<<<<
In this Slide:
__________________________________________________________
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 ?
Labels:
Lectures
,
Management
,
PUCIT
,
Requirements
,
Slides
,
Software Engineering
,
SRE
SRE Lec # 8
>>>>> Download Link Here <<<<<
In this Slide:
___________________________________________________________________
SRE –
Requirements Validation
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 ?
Labels:
Lectures
,
PUCIT
,
Requirements
,
Slides
,
Software Engineering
,
SRE
,
Validation
Friday, 17 November 2017
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.
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
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
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 ?
Labels:
Lectures
,
PUCIT
,
Requirements
,
Slides
,
Software Engineering
,
SRE
,
SRS
Subscribe to:
Posts
(
Atom
)