CS708 PREVIOUS SOLVED MID TERM PAPER (Part 2)
What Prototyping in requirement validation?
Prototyping
• A prototype is an
initial version of a system which may be used for experimentation
• Prototypes are
valuable for requirements elicitation because users can experiment with the
system and point out its strengths and weaknesses. They have something concrete
to criticize.
Prototyping
for Validation
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
– It’s usually best
to define some kind of electronic or paper problem report form which users fill
in when they encounter a problem
Question: Process Model and its Types.
Process
Models
• A process model is
a simplified description of a process presented from a particular perspective
• There may be
several different models of the same process
• No single model
gives a complete understanding of the process being modeled
Types
of Process Model
Coarse-grain activity
models, Fine-grain activity models, Role-action models, Entity-relation models
Coarse-grain
Activity Model
• This type of model
provides an overall picture of the process
• Describes the
context of different activities in the process
• It doesn’t document
how to enact a process
Fine-grain
Activity Models
• These are more
detailed models of a specific process, which are used for understanding and
improving existing processes
• We’ll discuss some
fine-grain processes within the general requirements engineering processes in
later lectures
Role-action
Models
• These are models,
which show the roles of different people involved in the process and the
actions which they take
• They are useful for
process understanding and automation
Entity-relation
Models
• The models show the
process inputs, outputs, and intermediate results and the relationships between
them
• They are useful in
quality management systems
Q2) What Requirement
Analysis stages and its Techniques (lecture
# 12)
Requirements
Analysis Stages:
Necessity checking,
Consistency and completeness checking, Feasibility checking
Necessity
Checking
The need for the
requirement is analyzed. In some cases, requirements may be proposed which
don’t contribute to the business goals of the organization or to the specific
problem to be addressed by the system
Consistency
and Completeness Checking
The requirements are
cross-checked for consistency and completeness. Consistency means that no
requirements should be contradictory; Completeness means that no services or
constraints which are needed have been missed out
Feasibility
Checking
The
requirements are checked to ensure that they are feasible in the context of the
budget and schedule available for the system development
Analysis
Techniques
• Analysis checklists
A checklist is a list
of questions which analysts may use to assess each requirement
• Interaction
matrices
– Interaction
matrices are used to discover interactions between requirements and to
highlight conflicts and overlaps
Analysis
Checklists
• Each requirement
may be assessed against the checklist
• When potential
problems are discovered, these should be noted carefully
• They can be
implemented as a spreadsheet, where the rows are labeled with the requirements
identifiers and columns are the checklist items
• They are useful as
they provide a reminder of what to look for and reduce the chances that you
will forget some requirements checks
• They must evolve
with the experience of the requirements analysis process
• The questions
should be general, rather than restrictive, which can be irrelevant for most
systems
• Checklists should
not include more than ten items, because people forget items on long checklists
reading through a document
• Example of analysis
checklist
Checklist
Items
Premature
design, Combined requirements, Unnecessary requirements, Use of non-standard
hardware, Conformance with business goals, Requirements ambiguity, Requirements
realism, Requirements testability
Q3) Do u think that
social and cultural issues affect Requirement engineering. (lecture # 8)
Social
Issues in RE
• Requirements
engineering is a social process, as it involves interaction among clients,
engineers, and other systems
• Requirements
engineering is not an entirely formal process, because it involves discovering
client needs and reconciling them with technical possibilities
Six
Areas of Social Issues
• Within the client
organization
• Within the
requirements team
• Between the client
and the requirements team
• Between the
development and requirements teams
• Within the
development team
• Between the
development team and the client
Cultural
Issues in RE
Advances in the
internet and communication technologies has enabled customers and developers to
collaborate with each other in geographically and temporally dispersed
environments
There may be
• Time zones
differences
Language and
terminology differences
• Religious and
racial differences
• Ethical issues
• Political
differences
• Differences in
business environment
Example:
A Billion
• Scientific
community and US consider the following number to be a billion 1,00,00,00,000
• For the rest of the
world, a billion is 10,00,00,00,00,000
Differences
in Time Zones
• Working hours of
clients and developers may differ by eight hours or more
• Arranging phone
calls and video conferences become a hassle as one party has to come to office
very early or stay very late
• Analysts start
assuming requirements
Language
and Terminology Differences
• Clients and
developers may speak different languages or different dialects
• Requirements errors
are introduced by not understanding other partner’s language and terminology
properly
• People and
government in the US, and worldwide scientific community consider the following
number to be a billion 1,00,00,00,000
• For the rest of the
world, a billion is 10,00,00,00,00,000
• Globally, people
communicate with fellow citizens using sports lingo to convey certain
situations and concepts, even in the business environment
• This can cause
misunderstandings
• Use of the word
‘hockey’ in Pakistan and US means two different sports: ‘field hockey’ and ‘ice
hockey’ respectively
Q4) Requirement Elicitation Techniques. (lecture 9 slide # 6 && lecture # 11)
Requirements
Elicitation Techniques
Individual,
group, modeling, cognitive
Specific
Elicitation Techniques
Interviews,
Scenarios, Observations and social analysis, Requirements reuse
Interviews
• The requirements
engineer or analyst discusses the system with different stakeholders and builds
up an understanding of their requirements
• Interviews are less
effective for understanding the application domain and the organizational
issues due to terminology and political factors
Scenarios
• Scenarios are
stories which explain how a system might be used. They should include
– A description of
the system state before entering the scenario
– The normal flow of
events in the scenario
– Exceptions to the
normal flow of events
– Information about
concurrent activities
– A description of
the system state at the end of the scenario
• Scenarios are
examples of interaction sessions which describe how a user interacts with a
system
• Discovering
scenarios exposes possible system interactions and reveals system facilities
which may be required
Observation
and Social Analysis
• People often find
it hard to describe what they do because it is so natural to them. Sometimes,
the best way to understand it is to observe them at work
• Ethnography is a
technique from the social sciences which has proved to be valuable in
understanding actual work processes
• Actual work
processes often differ from formal, prescribed processes
• An ethnographer
spends an extended time observing people at work and building up a picture of
how work is done
Requirements
Reuse
• Reuse involves
taking the requirements which have been developed for one system and using them
in a different system
• Requirements reuse
saves time and effort as reused requirements have already been analyzed and
validated in other systems
• Currently,
requirements reuse is an informal process but more systematic reuse could lead
to larger cost savings
Reuse
Possibilities
• Where the
requirement is concerned with providing application domain information
• Where the
requirement is concerned with the style of information presentation. Reuse
leads to a consistency of style across applications
• Where the
requirement reflects company policies such as security policies
Q5). Different
Checklist items.
(Lecture # 12 slide # 22)
Checklist
Items
Premature design, combined
requirements, unnecessary requirements, Use of non-standard hardware,
Conformance with business goals, Requirements ambiguity, Requirements realism,
Requirements testability
Checklist
Items Description
Premature design:
Does the requirement include premature design or implementation information?
Combined
requirements: Does the description of a requirement describe a single
requirement or could it be broken down into several different requirements?
Unnecessary
requirements: Is the requirement ‘gold plating’? That is, is the requirement a
cosmetic addition to the system which is not really necessary
Use of non-standard
hardware: Does the requirement mean that non-standard hardware or software must
be used? To make this decision, you need to know the computer platform
requirements
Conformance with
business goals: Is the requirement consistent with the business goals defined
in the introduction to the requirements document?
Requirements
ambiguity: Is the requirement ambiguous i.e., could it be read in different
ways by different people? What are the possible interpretations of the
requirement?
Requirements realism:
Is the requirement realistic given the technology which will be used to
implement the system?
Requirements
testability: Is the requirement testable, that is, is it stated in such a way
that test engineers can derive a test which can show if the system meets that
requirement?
1. Problems with
listening
Listening
• The art of listening is most important. You can best impress
your client by listening and giving due attention to what the client or
customer is saying
• This requires
effort on part of the interviewer
Listening
Steps: Hear, Interpret, Respond, Evaluate
Hear
the Message
• Listen to learn as much as you can so that you will know how to
respond
• Give the speaker your undivided attention; don’t just wait for
your turn to speak
• Concentrate on the message, not the person
• Don’t interrupt
• Tune out distractions such as interfering noises, wandering
thoughts, and emotional reactions to the speaker’s message
• Suspend judgment about the message until you have heard all the
facts
• Take notes on the speaker’s key points, if appropriate
• Learn to manage
your own emotional filters, personal blinders, and biases, which can keep you
from hearing what is really being said
2. Types of requirements
Basic
Types of Requirements Traceability
• Pre-RS traceability
– Concerned with
those aspects of a requirement’s life prior to its inclusion in the RS
(requirements production)
• Post-RS
traceability
– Concerned with
those aspects of a requirement’s life that result from its inclusion in the RS
(requirements deployment)
Pre-RS
Traceability
• Depends on the ability to trace requirements from and back to,
their originating statements, through the process of requirements production
and refinement, in which statements from diverse sources are eventually
integrated into a single requirement in the RS
• Changes in the
process need to be re-worked into the RS
Post-RS
Traceability
• Depends on the ability to trace requirements from, and back to,
a baseline (the RS), through a succession of artifacts in which they are
distributed
• Changes to the
baseline need to be re-propagated through this chain
3. Data storage
techniques
Storing
Requirements
Requirements have to
be stored in such a way that they can be accessed easily and related to other
system requirements
Requirements
Storage Techniques
• In one or more word processor files
• In a specially
designed requirements database
4. Requirement
Identification difficulties?
Answer:
Problems with this
are:
– Numbers cannot be unambiguously assigned until the document is
complete
– Assigning
chapter/section numbers is an implicit classification of the requirement. This
can mislead readers of the document into thinking that the most important
relationships are with the requirements in the same section
5. Changes in requirements and type of
volatile requirement?
Requirements
Change Factors
• Requirements errors, conflicts and inconsistencies
• Evolving customer/end-user knowledge of the system
• Technical, schedule
or cost problems
Types
of Volatile Requirements
Mutable requirements,
Emergent requirements, Consequential requirements, Compatibility requirements
1.
Mutable
Requirements: These are requirements which change because of changes to the
environment in which the system is operating
2.
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
3.
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
4.
Compatibility
Requirements: These are requirements which depend on other equipment or
processes.
What is Nonfunctional
requirements with 2 examples.
For example, if an
aircraft system does not meet reliability requirements, it will not be
certified as ‘safe’
• If a real-time
control system fails to meet its performance requirements, the control
functions will not operate correctly
• Non-functional requirements
arise through user needs, because of budget constraints, because of
organizational policies, because of the need of interoperability with other
software and hardware systems, or because of external factors such as safety
regulations, privacy legislation, etc.
Are changes in requirements bad? Negative sides of changes, how changes can be handled?
Answer:
In requirement management enlist sources of changes.
Sources of Change
• New business or market conditions dictate changes in product
requirements or business rules
• New customer needs demand modification of data produced by
information systems, functionality delivered by products, or services delivered
by computer-based system
• Reorganization or business growth/downsizing causes changes in
project priorities or software engineering team structure
• Budgetary or
scheduling constraints cause a redefinition of the system or product
Key components of object setting components.(5marks)
Objective
Setting
• Overall organizational objectives should be established at this
stage
• These include
general goals of business, an outline description of the problem to be solved
and why the system may be necessary, and the constraints on the system such as
budget, schedule, and interoperability constraints
Requirement Review activities. (5 marks)
Review Activities
Review Activities
1.
Plan review: The review team is
selected and a time and place for the review meeting is chosen
2.
Distribute documents: The
requirements document is distributed to the review team members
3.
Prepare for review:
Individual reviewers read the requirements to find conflicts, omissions,
inconsistencies, deviations from standards and other problems
4.
Hold review meeting:
Individual comments and problems are discussed and a set of actions to address
the problems is agreed
5.
Follow-up actions: The chair
of the review checks that the agreed actions have been carried out
6.
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
Write 2 nonfunctional requirements with example. (5 marks)
1.
Organizational
Requirements Examples
• The system development process and deliverable documents shall
conform to the MIL-STD-2167A
• Any development
work sub-contracted by the development organization shall be carried out in
accordance with Capability Maturity Model
2.
External
Requirements Examples
• The system shall not disclose any personal information about
members of the library system to other members except system administrators
• The system shall
comply with the local and national laws regarding the use of software tools
No comments: