CS708 PREVIOUS SOLVED MID TERM PAPER (Part 1)
Question 1: Impact
of wrong requirements?
Answer:
Impact of Wrong Requirements
• When requirements are wrong, systems are late, unreliable
and don’t meet customers’ needs
• This results in enormous loss of time, revenue, market
share, and trust of customers
Question 2: Input / Output of RE Processes?
RE Process – Inputs
It includes:
• Existing system information
– Information about the functionality of systems to be
replaced
– Information about other systems, which interact with the
system being specified
• Stakeholder needs
– Description of what system stakeholders need from the system
to support their work
• Organizational standards
– Standards used in an organization regarding system
development practice, quality management, etc.
• Regulations
– External regulations such as health and safety regulations,
which apply to the system
• Domain information
– General information about the application domain of the
system
RE Process – Outputs
It includes
• Agreed requirements
A description of the system requirements, which is
understandable by stakeholders and which has been agreed by them
• System specification
– This is a more detailed specification of the system, which
may be produced in some cases
• System models
– A set of models such as a data-flow model, an object model,
a process model, etc., which describes the system from different perspectives
RE Process Variability
• RE processes vary radically from one organization to
another, and even within an organization in different projects
• Unstructured process rely heavily on the experience of the
people, while systematic processes are based on application of some analysis
methodology , but they still require human judgment
Question 3: A question was given about online LMS. We had to tell answers to different questions about how we will do requirement elicitation for it.
Requirements Elicitation
Requirements elicitation activity is performed by
• Determining the system requirements through consultation
with stakeholders, from system documents, domain knowledge, and market studies
• Requirements acquisition or requirements discovery
Question 4: A question was given in which we were to tell
which were product, organizational, external or functional requirements from
the given requirements.
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
External Requirements
External
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
Observations on Non-Functional Requirements
• Non-functional requirements can be written to reflect
general goals for the system. Examples include:
– Ease of use
– Recovery from failure
– Rapid user response
• Goals are open to misinterpretation
• Objective verification is difficult
• Distinction between functional and non-functional is not
always very clear
• Non-functional requirements should be written in a
quantitative manner as much as possible, which is not always easy for customers
• For some goals, there are no quantitative measures, e.g.,
maintainability
• Goals can be useful to designers and developers, as they
give clues to them about priorities of the customers
• Chances of conflicts within non-functional requirements are
fairly high, because information is coming from different stakeholders. For
example, different stakeholders can give different response times or failure
tolerance levels, etc.
• Some negotiations must be done among different stakeholders,
to achieve an agreement in these situations
• Non-functional requirements should be highlighted in the
requirements document, so that they can be used to build the architecture of
the software product
Non-Functional Requirements Discussion
• NFRs are very important to capture the emergent behavior of
the system in these there major dimensions
• Product
– Usability, reliability, portability, efficiency
(performance, space)
• Organizational
– Standards, implementation, delivery
• External
– Interoperability, ethical, legislative (privacy, safety)
Question 5: Who are stakeholders?
Stakeholders (People affected in some way by the system),
Stakeholders (People affected in some way by the system),
Stakeholder Types
Software
engineers, System end-users, Managers of system end-users, External regulators,
Domain experts
Question 6: what benefits of process improvement.
Process Improvement
Process Improvement
• Process improvement is concerned with modifying processes in
order to meet some improvement objectives
• Improvement objectives
– Quality improvement
– Schedule reduction
– Resource reduction
Question 7: What are the questions to ask for process
improvement?
Planning Process Improvement
Some important questions arise:
• What are the problems with current processes?
• What are the improvement goals?
• How can process improvement be introduced to achieve these
goals?
• How should process improvements be controlled and managed?
Q 8. Role of
different actor involved in RE process.
Q2 define the
requirement is: functional, non- functional etc
1. The ATM customer shall be able to choose make the cash with drawal from any number of bank account.
2. The ATM shall not let the customer check their account without verifying pin code.
3. ATM communicates with bank computer via telephone line and modem.
4. The software runs MS WIN2000.
5. The software must ready in 6 month.
6. The word processor program shall include online document.
7. To improve reliability the program (excel) should periodically make a check point copy of page.
8. The traffic control system consisting no more $50000
9. The computer vision should work in low light.
10. The browser should be able to display all HTML pages.
1. The ATM customer shall be able to choose make the cash with drawal from any number of bank account.
2. The ATM shall not let the customer check their account without verifying pin code.
3. ATM communicates with bank computer via telephone line and modem.
4. The software runs MS WIN2000.
5. The software must ready in 6 month.
6. The word processor program shall include online document.
7. To improve reliability the program (excel) should periodically make a check point copy of page.
8. The traffic control system consisting no more $50000
9. The computer vision should work in low light.
10. The browser should be able to display all HTML pages.
Observations on Non-Functional Requirements
• Non-functional requirements can be written to reflect
general goals for the system. Examples include:
– Ease of use
– Recovery from failure
– Rapid user response
• Goals are open to misinterpretation
• Objective verification is difficult
• Distinction between functional and non-functional is not
always very clear
• Non-functional requirements should be written in a
quantitative manner as much as possible, which is not always easy for customers
• For some goals, there are no quantitative measures, e.g.,
maintainability
• Goals can be useful to designers and developers, as they
give clues to them about priorities of the customers
• Chances of conflicts within non-functional requirements are
fairly high, because information is coming from different stakeholders. For
example, different stakeholders can give different response times or failure
tolerance levels, etc.
Some negotiations must be done among different stakeholders,
to achieve an agreement in these situations
• Non-functional requirements should be highlighted in the
requirements document, so that they can be used to build the architecture of
the software product
User/Customer Requirements
• Functional and non-functional requirements should be stated
in natural language with the help of forms or simple diagrams describing the
expected services of a system by the User under certain constraints
• These are understandable by users, who have no, or little,
technical knowledge
• System design characteristics should be avoided as much as
possible
• It is a good practice to separate user requirements from
more detailed system requirements in a requirements document
• Including too much information in user requirements,
constraints the system designers from coming up with creative solutions
• The rationale associated with requirements is very
important. It helps in managing changes to requirements
Q3 A. Major Objective
of process improvement any also write Best Practices for RE Process Improvement
• RE processes can be improved by the systematic introduction
of best requirements engineering practices
• Each improvement cycle identifies best practice guidelines
and works to introduce them in an organization
• Best practices will be discussed throughout the semester
B. Major question for process improvement?
Answer:
Some important questions arise:
• What are the problems with current processes?
• What are the improvement goals?
• How can process improvement be introduced to achieve these
goals?
• How should process improvements be controlled and managed?
Q A. What are the advantage of involving different discipline stakeholder in review
B which stakeholder should be part of review team
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
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
Q6 a uni want
to make online LMS. You as requirement engineer appointed to gather requirements.
a) How will you start, what will your first step?
b) Source of requirement gathering
c) Techniques for requirement gathering
d) Documentrequirements
e) What RE process model you used.
f) How you analyze requirement of incomplete, inconsistent.
g) Method to manage requirements
h) How you Validate requirements
c) Techniques for requirement gathering
d) Documentrequirements
e) What RE process model you used.
f) How you analyze requirement of incomplete, inconsistent.
g) Method to manage requirements
h) How you Validate requirements
Q7 a lack of
defined responsibilities
B Stakeholder communication problems
B Stakeholder communication problems
RE Process Problems
• Lack of stakeholder involvement
• Business needs not considered
• Lack of requirements management
• Lack of defined responsibilities
• Stakeholder communication problems
• Over-long schedules and poor quality requirements documents
What
is Validation processes input output?
Answer:
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
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
List of
Problems: 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
Best techniques for finding defect n
error QFD and JAD
Q. 4. Requirment Identification difficulties Xnxm Xanzoor Last ma is tha dynamic renumbering, database identificatikn, symbol identification
Requirements
Identification
• It is essential for
requirements management that every requirement should have a unique
identification
• The most common
approach is requirements numbering based on chapter/section in the requirements
document
• 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
Requirements
Identification Techniques
Dynamic renumbering,
Database record identification, Symbolic identification
Dynamic
Renumbering: Some word processing systems allow for automatic renumbering of
paragraphs and the inclusion of cross-references. As you re-organize your
document and add new requirements, the system keeps track of the
cross-reference and automatically renumbers your 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. This database identifier is used in all subsequent references to the
requirement
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
Storing
Requirements
Requirements have to be stored in such a
way that they can be accessed easily and related to other system requirements
Key factor in review checklist n type of
volatile requirement lecture 17
slide 8 9
Review
Checklists
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?
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?
Which issues can be overcome by using process model?
Process Models
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
Variations
in Process Models
• A process model is
produced on the anticipated need for that model. We may need
– A model to help
explain how process information has been organized
– A model to help
understand and improve a process
– A model to satisfy some
quality management standard
No comments: