formal methods and requirement ring qab

8/3/2019 Formal Methods and Requirement ring Qab

1/40

FORMAL METHODS AND REQUIREMENTS ENGINEERING

Two, Six and Ten Marks Questions and Answers

PART-A

UNIT-I

1. Write any two needs for modeling systems

i. Enhance communication

ii. Enable better planning and reduce risk

2. What are the different types of information that can be conveyed by diagrams?

i. Overall architecture of the system

ii. System dependenciesiii. Complexity

iv. Flow of information through a systemv. Business requirements

vi. Database organization and structure

vii. Source code including almost every aspect of object-oriented development

viii. Deployment configurations

3. What are the challenges that are faced in software development?

i. create the new logic for problem solving based on open-ended programmingenvironments for high performance computer systems

ii. develop a formal methodology that guides us toward the construction ofcorrect and portable parallel programs, and adopt an openness to radical andinnovative alternatives

4. What are the elements of system modeling?

i. Inputs

ii. Processes

iii. Outputs

5. What are the uses of system modeling?

i. It easier to understand the relationships among various activities and the

impact of each on the othersii. It shows the processes as part of a larger system whose objective is to serve

a specific client need.

iii. System modeling shows how direct and support services interact, wherecritical inputs come from, and how products or services are expected to meet

the needs in the community.

6. Write short notes on modeling computing systems


2/40

A computer model, or a computational model is a computer program, or network of

computers, that attempts to simulate an abstract model of a particular system. Generic

examples of types of computer modeling in science, which are derived from anunderlying mathematical description:

i. anumerical modeling

ii. a stochastic modeling

7. What are the types of computer models?

i. Stochastic ordeterministicii. Steady-state or dynamic

iii. Continuous ordiscrete

iv. Local or distributed.

8. What is meant by verification?

Formal verification is the act ofproving or disproving the correctness of intended

algorithms underlying a system with respect to a certain formal specification or property,

using formal methods ofmathematics

9. What are the usage of formal verification

Formal verification can be used for systems such as cryptographic protocols,

combinational circuits, digital circuits with internal memory, and software expressed as

source code.

10. Mention the different approaches to formal verification

i. model checking

ii. logical inference

11. List down any four techniques for formal verification

i. Automated theorem proving (ATP) or automated deductionii. Formal equivalence checking

iii. LURCH

iv. Intelligent Verification

12. Mention the different types in which formal verification can be done

i. Human-directed proof

ii. Automated proof

13. What is meant by formal specification?

A formal specification is a mathematical description of software orhardware that may be used to develop an implementation. It describes what the system

should do, not how the system should do it. A formal specification is the expression, in

some formal language and at some level of abstraction, of a collection of properties somesystem should satisfy.

14. What are the advantages of formal specification?
http://en.wikipedia.org/wiki/Computer_programhttp://en.wikipedia.org/wiki/Simulationhttp://en.wikipedia.org/wiki/Model_(abstract)http://en.wikipedia.org/wiki/Numerical_simulationhttp://en.wikipedia.org/wiki/Numerical_simulationhttp://en.wikipedia.org/wiki/Stochastichttp://en.wikipedia.org/wiki/Stochastic_processhttp://en.wikipedia.org/wiki/Deterministic_algorithmhttp://en.wikipedia.org/wiki/Continuous_functionhttp://en.wikipedia.org/wiki/Discrete_mathematicshttp://en.wikipedia.org/wiki/Distributed_computinghttp://en.wikipedia.org/wiki/Mathematical_proofhttp://en.wikipedia.org/wiki/Correctnesshttp://en.wikipedia.org/wiki/Algorithmshttp://en.wikipedia.org/wiki/Formal_specificationhttp://en.wikipedia.org/wiki/Formal_methodshttp://en.wikipedia.org/wiki/Mathematicshttp://en.wikipedia.org/wiki/Cryptographic_protocolhttp://en.wikipedia.org/wiki/Combinational_logichttp://en.wikipedia.org/wiki/Digital_circuithttp://en.wikipedia.org/wiki/Model_checkinghttp://en.wikipedia.org/wiki/Mathematicshttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Hardwarehttp://en.wikipedia.org/wiki/Implementationhttp://en.wikipedia.org/wiki/Computer_programhttp://en.wikipedia.org/wiki/Simulationhttp://en.wikipedia.org/wiki/Model_(abstract)http://en.wikipedia.org/wiki/Numerical_simulationhttp://en.wikipedia.org/wiki/Stochastichttp://en.wikipedia.org/wiki/Stochastic_processhttp://en.wikipedia.org/wiki/Deterministic_algorithmhttp://en.wikipedia.org/wiki/Continuous_functionhttp://en.wikipedia.org/wiki/Discrete_mathematicshttp://en.wikipedia.org/wiki/Distributed_computinghttp://en.wikipedia.org/wiki/Mathematical_proofhttp://en.wikipedia.org/wiki/Correctnesshttp://en.wikipedia.org/wiki/Algorithmshttp://en.wikipedia.org/wiki/Formal_specificationhttp://en.wikipedia.org/wiki/Formal_methodshttp://en.wikipedia.org/wiki/Mathematicshttp://en.wikipedia.org/wiki/Cryptographic_protocolhttp://en.wikipedia.org/wiki/Combinational_logichttp://en.wikipedia.org/wiki/Digital_circuithttp://en.wikipedia.org/wiki/Model_checkinghttp://en.wikipedia.org/wiki/Mathematicshttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Hardwarehttp://en.wikipedia.org/wiki/Implementation


3/40

Formal specifications may be analyzed mathematically and the consistency and

completeness of the specification demonstrated.

It may be possible to prove that the implementation corresponds to the specification.Formal specifications may be used to guide the tester of the component in identifying

appropriate test cases.

15. What are the conditions that a good specification must satisfy?

i. Adequate

ii. Internally consistentiii. Unambiguous

iv. Complete

v. Satisfied

vi. Minimal

16. What are the disadvantages of formal specification?

i. Limited scope.

ii. Costiii. Poor guidance.

iv. Poor tool feedback

17. Mention any four approaches to formal specification?

i. History-based specification

ii. State-based specificationiii. Transition based specification

iv. Algebraic specification

18. Write short notes on Algebraic specification

Algebraic specification is a formal process of refining specifications to

systematically develop more efficient programs. The purpose of an algebraicspecification is to:

i. represent mathematical structures and functions

ii. while abstracting from implementation details such as the size ofrepresentations (in memory) and the efficiency of obtaining outcome of

computations

iii. as such formalizing computations on data

iv. allowing for automation due to a limited set of rules

19. Write short notes on formal specification language

A specification language is a formal language used in computer science.Unlike most programming languages, which are directly executable formal languages

used to implement a system, specification languages are used during systems analysis,

requirements analysis and systems design.

20. What is meant by model oriented specification language
http://en.wikipedia.org/wiki/Formal_languagehttp://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Systems_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Systems_designhttp://en.wikipedia.org/wiki/Formal_languagehttp://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Systems_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Systems_design


4/40

The "model oriented" specification languages are so called because they

are support the specification of systems by construction of a mathematical model of the

system. In a sense any formal specification can be thought of as providing a mathematicalmodel of a system so it may be helpful to expand on this.

21. Mention any four formal specification languagesi. Abstract State Machines (ASMs)

ii. Vienna Development Method (VDM)

iii. Petri netsiv. Assertion Definition Language

22. Write short notes on Abstract Machine Notation (AMN)

Abstract Machine Notation (AMN) is a specification language and (abstract)programming language for specifying abstract machines in the B-Method, based on the

mathematical theory ofGeneralised Substitutions.

23. Mention any four software tools that support formal specification?i. Alloy Analyzer

ii. B-Toolkitiii. ESC/Java

iv. ExSpecT

24. Write short notes on B Method

B is a tool-supported formal method based around AMN (Abstract Machine

Notation), used in the development of computersoftware. It was originally developed by

Jean-Raymond Abrial in France and the UK. B is related to the Z notation and supportsdevelopment of programming language code from specifications. B has been used in

majorsafety-critical system applications in Europe and is attracting increasing interest in

industry. It has robust, commercially available tool support for specification, design,proofand code generation.

25. Write short notes on B-Toolkit

The B-Toolkit is a collection of programming tools designed to support the use of

the B-Tool, a set theory based mathematical interpreter, for the purposes of a formal

software engineering methodology known as the B-Method.

UNIT-II

26. What is meant by Formal Methods?

Formal methods allow a software engineer to create a specification that is more

complete, consistent and unambiguous than those produced using conventional methods

set theory and logic notations are used to create a clear statement of facts (requirements).

27. Why formal methods are important?
http://en.wikipedia.org/wiki/Abstract_State_Machineshttp://en.wikipedia.org/wiki/Specification_languagehttp://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Abstract_machinehttp://en.wikipedia.org/wiki/B-Methodhttp://en.wikipedia.org/wiki/Mathematicshttp://en.wikipedia.org/w/index.php?title=Generalised_Substitutions&action=edit&redlink=1http://en.wikipedia.org/wiki/Formal_methodhttp://en.wikipedia.org/wiki/Abstract_Machine_Notationhttp://en.wikipedia.org/wiki/Abstract_Machine_Notationhttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Jean-Raymond_Abrialhttp://en.wikipedia.org/wiki/Francehttp://en.wikipedia.org/wiki/United_Kingdomhttp://en.wikipedia.org/wiki/Z_notationhttp://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Safety-critical_systemhttp://en.wikipedia.org/wiki/Europehttp://en.wikipedia.org/wiki/Program_specificationhttp://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/Logical_argumenthttp://en.wikipedia.org/wiki/Code_generationhttp://en.wikipedia.org/w/index.php?title=B-Tool&action=edit&redlink=1http://en.wikipedia.org/wiki/B-Methodhttp://en.wikipedia.org/wiki/Abstract_State_Machineshttp://en.wikipedia.org/wiki/Specification_languagehttp://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Abstract_machinehttp://en.wikipedia.org/wiki/B-Methodhttp://en.wikipedia.org/wiki/Mathematicshttp://en.wikipedia.org/w/index.php?title=Generalised_Substitutions&action=edit&redlink=1http://en.wikipedia.org/wiki/Formal_methodhttp://en.wikipedia.org/wiki/Abstract_Machine_Notationhttp://en.wikipedia.org/wiki/Abstract_Machine_Notationhttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Jean-Raymond_Abrialhttp://en.wikipedia.org/wiki/Francehttp://en.wikipedia.org/wiki/United_Kingdomhttp://en.wikipedia.org/wiki/Z_notationhttp://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Safety-critical_systemhttp://en.wikipedia.org/wiki/Europehttp://en.wikipedia.org/wiki/Program_specificationhttp://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/Logical_argumenthttp://en.wikipedia.org/wiki/Code_generationhttp://en.wikipedia.org/w/index.php?title=B-Tool&action=edit&redlink=1http://en.wikipedia.org/wiki/B-Method


5/40

Formal methods reduce specification errors dramatically and as a consequence,

serve as the basis for software that has very few errors once the customer begins using it.

28. What is the work product of formal methods?

A specification represented in a formal language such as OCL or Z is produced

when formal methods are applied.

29. How do you ensure that using formal method is right?

As formal methods use discrete mathematics as the specification mechanism,logic proofs can be applied to each system function to demonstrate that the specification

is correct.

30. When a method is said to be formal or define formal methods?

A method is formal if it has a sound mathematical basis, typically given by

a formal specification language. This basis provides a means of precisely definingnotions like consistency and completeness and more relevantly, specification,

implementation and correction.

31. List down the deficiencies of less formal approaches?

i. Contradictions

ii. Ambiguities.

iii. Vagueness.

iv. Incomplete Statements.

v. Mixed level of abstractions.

32. Write down the usage of mathematics in software development?

i. It can exactly describe a physical situation, an object or the

outcome of an action.

ii. It supports abstraction and is an excellent medium for modeling.

iii. It provides a high level of validation when it is used as a software

development medium.

33. Define data invariant with an example.

The statement which places a constraint on the table is a component of a condition

known as a data invariant.

Example: Data invariant for a symbol table is that the table will contain no more than

Max Id names.


6/40

34. Write short notes on state with example?

A system can be in one of several states, each representing an externally

observable mode of behavior. The state of a system is represented by the systems stored

data.

E.g. Symbol table is a state.

35. Define pre condition with an example.

A Pre condition defines the circumstances in which a particular operation is valid.

Example: Pre condition for an operation that adds a name to the staff identifier symbol

table is valid only if the name that is to be added is not contained in the table and also if

there are fewer than max Ids staff identifier in the table.

36. Define Post-Condition with an example.

The post-condition of an operation defines what is guaranteed to be true upon

completion of an operation.

Example: In the example of an operation that adds an identifier to the staff identifier

symbol table, the post-condition would specify mathematically that the table has been

augmented with the new identifier.

37. What is cardinality? Give an example.

The number of items in a set is known as its cardinality. The # operatorreturns a sets cardinality.

Example: # {A, B, C, D} = 4

38. Write short notes on constructive set specification with example.

Constructive set specification is preferable to enumeration because it

enables a succinct definition of large sets. It also explicitly defines the rule that was used

in constructing the set.

Consider the example {A: N | n< 3. n}

This specification has three components, a signature n:N, a predicate n


7/40

40. Define sequence with example.

A sequence is a mathematical structure that models the fact that itselements are ordered. A sequence is a set of pairs whose elements range from 1 to the

highest number element. The items that form the first element of the pairs are collectively

known as domain of the sequence and the collection of second elements is known as the

range of sequence. Duplication is allowed in sequence. Ordering is important. Sequenceis designated using angle brackets.

e.g.

41. Write short notes on Z specification language.

Z is a specification language that has evolved over the past two decades to

become widely used within the formal methods. The Z language applies typed sets,relations and functions within the context of first order predicate logic to build scheme

a means of structuring a formal specification.

42. Write short notes on schema and generic structure of schema?

A schema is essentially the formal specification analog of the programming

language component. Schemas are used to structure a formal specification. A schemadescribes the stored data that a system access and alters. A schema identifies the

operations that are applied to change state and the relationships that occur within the

system.

The generic structure of schema takes the form

------------------------------ Schema Name -----------------------------------

Declarations

InvariantWhere declaration identify variables that comprise the symbol state and the invariant

compose constraints on the manner in which the state can evolve.

UNIT-III

43. Write short notes on B Abstract machine notation

The B Abstract machine notation specification language was developed in

the early and mid 1980s by J.R.Abrial and by research groups at BP research, MATRA

and GEC Alsthom.

44. What are the steps involved in a development process using B?

i. Requirements analysisii. Specification development

iii. Design

iv. Coding/Integration/Test

45. Write short notes on abstract machines


8/40


9/40

i. SEES

ii. USES

iii. INCLUDESiv. EXTENDS

55. Write short notes on B developmentA B development consists of set of subsystems or subsystem development,

each subsystem being defined by an abstract specification machine and a path of

refinement steps down to an executable description.

56. Define refinement

Refinement is the process of moving from abstract specifications to less

abstract specifications, via some data or operation transformation, which allows thebehavior of the abstract system to be simulated by the more refined system.

57. What are the two significant omissions from template and refinement templates

i. VARIABLES clauseii. INITIALISATION clause

58. Mention the general approaches to system construction

i. Create separate decomposition

ii. Mapping INCLUDES into IMPORTS

iii. Mapping SEES into SEES

59. What does B Tool mean?

The B Tool is proof tool, which provides the basis for theautomatic and interactive proof facilities offered by the B Toolkit, provides the ability to

define theories in which axioms and inference rules for mathematical structure can be

defined, and a notation for specifying the way in which these theories are to be used.

60. List down the proof rules in internal consistency obligations

i. P1 ^^ Pn =>= = r: rewrite rules;ii. P1 ^^ Pn =>Q: inferences;

iii. Q: axioms.

61. What are the conditions the user rules must satisfy?

i. Validity

ii. Minimal redundancy

iii. A correct level of generality.

62. What are the problems that can be identified in the failure to prove internal

consistency?

i. Empty state space

ii. Initialisation fails to establish the invariant

iii. Operations fail to maintain the invariant


10/40

63. What is meant by assertion?

An ASSERTIONS Asst clause is used to declare some additional

invariant properties Asst of a B machine, where Asst is expected to be of more use inestablishing the proof obligations of the machine than the basic invariant.

64. What is meant by definitionsThe DEFINITIONS clause of a machine lists useful abbreviations,

which will be macro-expanded throughout the text of the machine.

DEFINITIONSlhs1 == rhs1;

.

.

.lhsk == rhsk

65. What are the different rule guards in animation?

i. bnum(a)ii. btest(P)

iii. bsearch(d,a,s)

66. Mention the general heuristics for refinement proof

i. Existential goals

ii. Universally quantified invariantsiii. Use laws of generalized substitutions

iv. Use heuristics for loop invariant generation

UNIT-IV

67. What is the goal of software development?

The goal of software development is to develop quality software

on time and on budget that meets customers real needs

68. What are the factors that cause the project to be challenged?

The factors that cause the project to be challenged are

i. Lack of user input: 13 percent of all projects.

ii. Incomplete requirements and specifications; 12 percent of all projects.

iii. Changing requirements and specifications: 12 percent of all projects.


11/40

69. What is the requirement?

A software capability needed by the user to solve a problem to achieve an objective. A software capability that must be met or possessed by a system or system component

to satisfy a contract, standard, specification, or other formally imposeddocumentation.

70. Define requirement management?

Requirement management is defined as a systematic approach to

eliciting and documenting the requirements of the system, and a process that establishes

and maintains agreement between the customer and the project team on the changing

requirements of the system.

71. What do you mean by problem domain?

The problem domain is the home of real users and other

stakeholders, people whose needs must be addressed in order for us to build the perfect

system.

72. Define feature.

A feature is defined as a service that the system that provides to

fulfill one or more stakeholder needs.

73. Define problem analysis.

Problem analysis is the process of understanding real-world

problems and user needs and proposing solutions to meet those needs.

74. Define a problem.

A problem can be defined as the difference between things as

perceived and things as derived.


12/40

75. What is the goal of problem analysis and write down the steps that have to be

followed to achieve the goals?

The goal of problem analysis is to gain a better understanding,

before development begins, of the problem being solved. The specific steps must be

taken in order to achieve the goal are

i. Gain agreement on the problem definition.

ii. Understand the root causes- the problem behind the problem.

iii. Identify the stakeholders and the users.

iv. Define the solution system boundary.

v. Identify the constraints to be imposed on the solution.

76. Write short notes on fish bone diagram?

Fish bone diagram is used to identify the problem behind the

problem. In the problem analysis, the company identified many sources contributed to

system problem. Each source was listed as one of the bones on the diagram. In many

cases, it is simple matter of asking the people directly involved what they think the root

cause is.

77. What is the use of Pareto chart?

Usually, the quality data routinely shows that a number of root

causes are simply not worth fixing, as the cost of the fix exceeds the cost of the problem.

Then determine the materiality, or contribution, of each root cause. The result of the

investigation can be plotted as a Pareto chart, or simple histogram that visually exposes

the real culprits.

78. Define stakeholders.

Stakeholders are defined as anyone who could be materially

affected by the implementation of a new system or application.

79. Define an actor.


13/40


14/40

The oval icon used to represent the

business use-case has the slash, indicating

a business-level use case.

Here, the actors and the use-cases

describe who is involved in the businessactivities and how these activities takes

place.

realize the business use cases.

The slashed circle represents a

business entity that business workers

produce.

The business use-case realizations

show that the business use-cases are

performed in terms of interacting

business workers and business

entities.

84. List down the techniques that are used for requirement elicitation.

The techniques that are used for requirement elicitation are

i. Interviewing and questionnaires.

ii. Requirements workshops.

iii. Brainstorming and idea reduction.

iv. Storyboards.

v. Use cases.

vi. Role Playing.

vii. Prototyping.

85. Define brainstorming.

Brainstorming is a collection of techniques that are useful

when stakeholders are collocated. The two phases are: idea generation and idea

reduction.

86. What are the benefits of elicitation technique?

The elicitation technique has a number of primary benefits:


15/40

i. It encourages participation by all parties present.

ii. It allows participants to piggyback on one others ideas.

iii. A facilitator or scribe maintains a written trail of everything discussed.

iv. It exhibits high bandwidth.

v. Typically, it results in a broad set of possible solutions to whatever

problem is posed.

vi. It encourages out-of-the-box thinking, that is, without being limited by

normal constraints.

87. What are the phases of brainstorming? Write short notes on each.

The phases of brainstorming are idea generation and idea

reduction.

a. Idea Generation:

The primary goal during idea generation is to delineate as many ideas as possible;

the goal is breadth of ideas, not necessarily depth.

b. Idea Reduction:

The primary goal during idea reduction is to analyze all of the ideas generated; Ideareduction includes pruning, organizing, ranking, expanding, grouping, refining, and

the like.

88. What do you mean by pruning?

Pruning is defined as the facilitator starts by visiting each

idea briefly and asking for concurrence from the group that the idea is basically valid.

There is no reason for any participant to be defensive or to claim authorship for any idea;

any participant may support or refute any idea.

89. What is meant by prototyping?


16/40

Prototyping is meant by a partial implementation of a

software system, built to help developers, users, and customers better understanding the

requirements of the system.

90. What are the advantages of prototyping?

The advantages of prototyping process should be twofold:

i. Fuzzy needs become better understood.

ii. Exercising the prototype inevitably elicits a Yes, But response from:

the user; therefore, previously unknown needs become known. Similarly

seeing a set of behaviors helps users understand other requirements that

must be imposed on the system.

UNIT-V

91. Define systems Engineering?

System Engineering refines a system into a subsystem,describing

the detailed interfaces among the the subsystems,allocating each of the system level

requirments to one or more subsystems.

92. What is meant by system level usecase model?

The system level usecase model records the usecase by which the

various actors in the system interact with the HOLIS (Home Lighting Automation

System).

93. Write Short notes about vision document?

The Vision document describes the applicatin in general terms including

descriptions of the target market,the system users, and the application feature.


17/40

94. List out the reason to have the a Vision Document?

There are 2 reasons to develop the Vision Document they are ..

i. Every project needs a vision document.

ii. It will help us to demonstrate the requirment process furthur,as some key

elements of this process will be recorded in this document.

95. List out the stakeholders who has to agree the vision document?

i. The stakeholders who has to agree for the vision doument are as follows..

ii. The Marketing Department which act as the proxy of the customer and

the user.

iii. The Project Team developing the application.

96. What is meant by Delta Vision document?

The Delta vison document will define the feature in a project and usecasesaroud the changes you are going to make to a legency systemBy following this the

software project team can focus on what is new and and whats different in the next

release should posses.In addition the requirment document we create will provide a

documentation trail for others to follow behind.

97. What is meant by project scope?

The project scope is the combination of the different product funtionality,project

resource and the time available to acheive the implementation.

98. What are the elements of Project Scope?

i. The Functionality that must be delivered to meet the users needs.

ii. The resource availabel to the project.iii. The Time available in which acheive the implimentation.

99. Define the Baseline?

Baseline is defined as the itemized set of features or requirments ,intended

to be delivered in a specific version of the application.

100. What are the condition that a baseline must have?

There are 2 conditions that a baseline must have.


18/40

i. Be atleast acceptable to the customer.

ii. Have the reasonable priority of sucess.

101. What are the types of priority levels?

The types of priority levels arei. Critical

ii. Important

iii. Useful

102. How will you engage the customer to manage the project scope?

We can actively engage our customers in managing thier requirments and

their project scope to ensure both the quality and the timelines of the software

outcomes.

103. List out the Guidelines for negotiating with the customer?

Start high but not unreasonable.Seperate the people from the problem.

Focus on intrest not on positions.

Understand the walk away position.

Invent option for mutual gain.Apply the objective criteria.

104. Different lifecycle in Iterative approach?

There are 4 lifecycle in Iterative approachInception

Elobration

Construction

Transition

105. Define Iteration?

An Iteration is a sequence of activities with an establised plan and evaluation criteria

resulting in a executable of some type.

106. What is meant by work flow?


19/40

Workflow consists of a logically related set of activities, and each defines

how the activities must be sequenced to produce a viable work product or artifact.

107. What are the advantages of the Iterative approach?

The Iterative approach has two significant advantages,

i. Getting the Yes, Buts out early.ii. Better scope management.

108. Define S/W requirement?

A Software Requirement is the software capability needed by the user

to solve a problem to achieve an objective. It is a software capability that must be

met or possessed by a system or a system component to satisfy a contract, standard,

specification or other formally imposed documentation.

109. What is meant by refining?

Refining is defined as the transition to elaborating the system features in detail

sufficient to ensure that the design and coding activities result in a system that fullyconforms to the user needs.

110. List out the major things that are needed to fully describe the system.

i. Inputs to the system.

ii. Outputs from the system.

iii. Functions of the system.iv. Attributes of the system.

v. Attributes of the system environment.

111. What are the types of Requirement compare them?

There are three types of Requirement, they are

i. Functional software requirement.ii. Nonfunctional software requirement.

iii. Design constraints.

112. Define Design Constraints with an example?

Design Constraint is the restriction on the degree of the system, or the

process by which a system is developed, that do not affect the external behavior of

the system but that must be fulfilled to meet technical, business or, contractualobligations.

113. What are the advantages of Use-case techniques?

i. Use-cases are relatively easy to write.

ii. Are written in the language of the user.

iii. Provide related, cohesive threads of behavior that can beunderstood by user and developer.

iv. Graphical representations provide a visual means of relationship

among use-cases, which can

v. Improve understandability of a complex software system.


20/40

114. What are the three conditions that have to be confirmed for building the

Right System right?

i. Continually confirm that the development is on track.

ii. Confirm that the development results are correct.

iii. Learn how to deal with change during development.

115. Define Software Verification?

Verification is an ongoing process we check that each step of thedevelopment is correct, meets the needs of the next step, and is not superfluous to

the needed activities. It is an important technique a team can apply in the struggle to

help ensure that you are designing and implementing the right system.

116.What is meant by Orthogonality Problem?

There is little correlation between the

requirements, design and implementation, and such cases are said to be Orthogonal,

or nearly so. In other words, the form of our requirement and the form of our designand implementation are different.

117.Define Traceability?

Traceability refers to the degree to which a

relationship can be established between two or more products of the development

process, especially products having a predecessor-successor or master-subordinaterelationship. Example is, the degree to which the requirements and design of a

given software component match.

118.Compare Implicit and Explicit Traceability?

Implicit Traceability Explicit TraceabilityIt is provided by the methodology and the

structure of the model.

It is the development of relationships

stemming from external considerationssupplied by your team

Implicit relationship need not e explicitly

stated as an explicit relationship, sincepossible confusions may arise.

There is no intrinsic relationship between

the elements , only external decisions canestablish the relationship.

Example for this is a parent-childhierarchical relationship.

Example for this is linkage, or relationshipbetween a product feature and a use-case

that supports that feature.

PART-B


21/40

UNIT-I

1.Write short notes on need for modeling

mmunication

er planning and reduce riskeam features

Refactoring

Patternsengineering

Reporting

Integration

2.Describe briefly about the challenges that are faced in software development

i. create the new logic for problem solving based on open-ended programming

environments for high performance computer systems

ii. develop a formal methodology that guides us toward the construction ofcorrect and portable parallel programs, and adopt an openness to radical and

innovative alternativesiii. design a programming language that incorporates a unifying intuitive model

of parallel computation, and which provides a coherent vehicle for the

natural description of parallel programs

iv. devise and construct software tools that resonate with the methodology andfacilitate a flexible, supportive environment

v. introduce widely available, substantial educational opportunities in parallel

programming that will create a pool of individuals with the experience andintuition necessary to work effectively in this setting.

3.Explain briefly about modeling computing systems

Definition

Types

Stochastic ordeterministic

Steady-state or dynamic

Continuous ordiscrete

Local ordistributed.1.Computer modeling in science

a numerical modeling

a stochastic modeling

4.Write short notes on Verification

Usage

ches to formal verification

ion and Verification

dustry usage

ation techniques
http://en.wikipedia.org/wiki/Stochastic_processhttp://en.wikipedia.org/wiki/Deterministic_algorithmhttp://en.wikipedia.org/wiki/Continuous_functionhttp://en.wikipedia.org/wiki/Discrete_mathematicshttp://en.wikipedia.org/wiki/Distributed_computinghttp://en.wikipedia.org/wiki/Numerical_simulationhttp://en.wikipedia.org/wiki/Stochastichttp://en.wikipedia.org/wiki/Formal_verification#Usage%23Usagehttp://en.wikipedia.org/wiki/Formal_verification#Approaches_to_formal_verification%23Approaches_to_formal_verificationhttp://en.wikipedia.org/wiki/Formal_verification#Validation_and_Verification%23Validation_and_Verificationhttp://en.wikipedia.org/wiki/Formal_verification#Industry_usage%23Industry_usagehttp://en.wikipedia.org/wiki/Stochastic_processhttp://en.wikipedia.org/wiki/Deterministic_algorithmhttp://en.wikipedia.org/wiki/Continuous_functionhttp://en.wikipedia.org/wiki/Discrete_mathematicshttp://en.wikipedia.org/wiki/Distributed_computinghttp://en.wikipedia.org/wiki/Numerical_simulationhttp://en.wikipedia.org/wiki/Stochastichttp://en.wikipedia.org/wiki/Formal_verification#Usage%23Usagehttp://en.wikipedia.org/wiki/Formal_verification#Approaches_to_formal_verification%23Approaches_to_formal_verificationhttp://en.wikipedia.org/wiki/Formal_verification#Validation_and_Verification%23Validation_and_Verificationhttp://en.wikipedia.org/wiki/Formal_verification#Industry_usage%23Industry_usage


22/40

5.Discuss briefly about formal specification

Definition

Good specification

Specifying formally

Formalization: scope and pitfalls

6.Discuss in detail about the advantages and disadvantages of formal specification

Advantages of formal specification

Disadvantages of formal specification:

7.Explain briefly about formal specification languages

Abstract Machine Notation (AMN)

Common Algebraic Specification Language

Vienna Development Method

LePUS3 The Perfect specification language

Assertion definition language

8.Describe briefly about software tools that support formal specification

Alloy Analyzer

B-Toolkit

CHIC (Checker for Interface Compatibility)

CPN-AMI

CoreASM

ESC/Java

UNIT-II

9.Describe briefly about the deficiencies of less formal approaches

Contradictions

Ambiguities

Vagueness

Incompleteness

Mixed levels of abstraction

10.Explain briefly about the usage of mathematics in s/w development Exactly describe a physical situation

Develop a specification of computer-based system

Supports abstraction

Excellent medium for modeling

Validation

Demonstrating design matches specification and program code

matches design
http://en.wikipedia.org/wiki/Specification_languagehttp://en.wikipedia.org/wiki/Specification_language


23/40

11.Discuss briefly about the concepts of formal methods

Data invariant

State

Operation

Precondition Postcondition

E.g. A block handler

12.Write short notes on sets and constructive specification

Sets

Cardinality

Constructive set specification

13.Explain briefly about set operators

Membership

Subset

Empty set

Union, intersection

Difference

Cross product

Power set

UNIT-III

14.Describe briefly about specification using abstract machines

- Fig: Schematic structure of abstract machine Mathematical notation

Machine parameters

Sets

Constants and properties

Variables and Invariants

Initialization

Operation definitions

15.Write short notes on semantics of abstract machines

Semantics of generalized substitutions- Definition of [S]P

- Intuition

- Meanings of obligations

16.Explain briefly about translation of analysis models

- Fig: Object model of air traffic control system

- Relationships


24/40

17.Describe briefly about the layered development paradigm

- Fig: General structure of B Development- Fig: Decomposition of development into layers

18.Write short notes on refinement- Definition of refinement with e.g.

- Fig: Example of refinement correspondence

- Fig: Schematic refinement step- Refinement proof obligations

- Refinement examples

19.Explain briefly about proof of internal consistency obligations

Proof rules and user rules

Assertions

Definitions

UNIT-IV

20.Write short notes on root causes of project success and failure

- Fig: Largest s/w development problems by category

The frequency of requirement errors- Table: Defect summary

The high cost of requirements errors

- Fig: Relative cost to repair a defect at different lifecyclephases

21.Write short notes on applications of requirements management Types of s/w applications

Systems applications

22.Explain briefly about the road map

The problem domain (with dig)

Stakeholder needs (with dig)

Moving toward the solution domain

Features of the system (with dig)

S/w requirements (with dig)

An introduction to use cases (with dig)

23.Explain briefly about using s/w engineering techniques for business modeling

Choosing the right technique

The unified modeling language (UML)

Business modeling using UML concepts

- Fig: Business use case model- Fig: Business object model


25/40


26/40

33.Explain briefly about the delta vision document

Vision document for release 1.0

- Fig: Vision document v1.0

Vision document for version 2.0

- Fig: Vision document v2.0- Fig: Delta Vision document v2.0

- Fig: Delta Vision document

Delta Vision document in a legacy system environment

34.Mention the components of project scope

Functionality

Resources

Time

- Fig: Project scope

35.How will you reduce scope? Explain A reasonable first estimate

- Table: scope prioritization techniques

- Table: Prioritized feature list

36.Write short notes on managing baseline

Official change

Unofficial change

37.Explain briefly about waterfall model

- Winston Royce (1970)

- Feedback loops- Prototype system

- Fig: Waterfall model of s/w development

- Fig: Applying the waterfall model to a project with 200% scope

piral model

- Fig: The spiral model of development

- Fig: Applying the spiral model to a project with 200% scope

38.Describe briefly about the iterative approach

cycle phases

- Fig: Lifecycle phases in the iterative approach

Iterations

- Fig: Phase iterations, resulting in viable releases

Workflows

- Fig: Workflows of the iterative approach

- Advantages

ts out early


27/40

management

39.Explain briefly about non functional requirements

Usability

Reliability

Performancepportability

40.Write short notes on design constraints

- Definition of design constraints

- Operating environments

- Compatibility with existing systems- Application standards

- Corporate best practices and standards

41.Explain briefly about refining use case specifications

- Use case- Actor

Evolution of use cases

Scope of use cases

42.Write short notes on techniques for disambiguation

Memorization heuristic

Keyword technique

Emphasis technique

Other techniques

43.How will you confirm that the development is on track

Principles of s/w verification

The cost of verification

Verification at all levels

The reason for verification

44.How mapping is done from requirements to design and code

- Fig: Requirements to design to implementation

Object orientation

The use case as a requirement

Managing the transition Modeling s/w systems architecture of s/w systems

Views of architecture- Fig: The 4+1 architectural view

Role of the use case model in architecture

45.Write short notes on Realizing use cases in the design model

Structural and behavioral aspects of collaborations


28/40

- Fig: Class diagram

- Fig: Behavioral aspects of collaboration

Using collaborations to realize the sets of individual requirements

- Fig: Model of req. implementation as a use case realization

46.Explain briefly about traceability tools- Fig: Augmented traceability relationships

- Fig: Matrix version of traceability relationships

Maintenance of traceability relationships- Fig: Document/element relationships

- Fig: Abbreviated tree view

47.Describe briefly about validation

Acceptance tests

Validation testing

Fig: Implementation documentation Validation traceability

Requirements-based testing

PART-C

UNIT-I

Explain in detail about need for modeling

Enhance communication

Types of information conveyed by diagrams

Enable better planning and reduce risk

Need from a modeling tool:

UML compliance

Team features

Refactoring

Patterns

Reverse engineering

Reporting

Integration

Discuss in detail about modeling systems Definition

Types

Stochastic ordeterministic

Steady-state or dynamic

Continuous ordiscrete

Local ordistributed.
http://en.wikipedia.org/wiki/Stochastic_processhttp://en.wikipedia.org/wiki/Deterministic_algorithmhttp://en.wikipedia.org/wiki/Continuous_functionhttp://en.wikipedia.org/wiki/Discrete_mathematicshttp://en.wikipedia.org/wiki/Distributed_computinghttp://en.wikipedia.org/wiki/Stochastic_processhttp://en.wikipedia.org/wiki/Deterministic_algorithmhttp://en.wikipedia.org/wiki/Continuous_functionhttp://en.wikipedia.org/wiki/Discrete_mathematicshttp://en.wikipedia.org/wiki/Distributed_computing


29/40

Computer modeling in science

a numerical modeling

a stochastic modeling

Elements of system modeling

A model of system modeling

Describe in detail about verification

Usage

Approaches to formal verification

Validation and Verification

Industry usage

Verification techniques

Automated theorem proving (ATP)

Formal equivalence checking

LURCH

Model checking

Automated proof checking

Static code analysis

Temporal logic in finite-state verification

Intelligent verification

Verification and validation

Runtime verification

Describe in detail about the challenges that are faced in software development

Challenges for software development

Challenges and Improvements

Communication

Group Awareness

Software Configuration Management

Knowledge Management

Coordination

Collaboration

Project and Process Management

Quality and Measurement

Risk Management

5. Explain in detail about formal specification Definition

Good specification

Specifying formally

Formalization: scope and pitfalls

Advantages of formal specification

Disadvantages of formal specification
http://en.wikipedia.org/wiki/Numerical_simulationhttp://en.wikipedia.org/wiki/Stochastichttp://en.wikipedia.org/wiki/Formal_verification#Usage%23Usagehttp://en.wikipedia.org/wiki/Formal_verification#Approaches_to_formal_verification%23Approaches_to_formal_verificationhttp://en.wikipedia.org/wiki/Formal_verification#Validation_and_Verification%23Validation_and_Verificationhttp://en.wikipedia.org/wiki/Formal_verification#Industry_usage%23Industry_usagehttp://en.wikipedia.org/wiki/Numerical_simulationhttp://en.wikipedia.org/wiki/Stochastichttp://en.wikipedia.org/wiki/Formal_verification#Usage%23Usagehttp://en.wikipedia.org/wiki/Formal_verification#Approaches_to_formal_verification%23Approaches_to_formal_verificationhttp://en.wikipedia.org/wiki/Formal_verification#Validation_and_Verification%23Validation_and_Verificationhttp://en.wikipedia.org/wiki/Formal_verification#Industry_usage%23Industry_usage


30/40

6. Explain in detail the different approaches to formal

specification

History-based specification

State based specification

Transition based specification Functional specification

Algebraic specification

Higher order functions

Operational specification

Property based specification

Model based specification

Structured specification

Error based specification

7. Discuss in detail about formal specification languages

Abstract Machine Notation (AMN)

Common Algebraic Specification Language

Vienna Development Method

LePUS3

The Perfect specification language

Assertion definition language

Alloy (specification language)

Larch family

Petri net

Property Specification Language

8. Describe in detail about software tools that support

formal specification

Alloy Analyzer

B-Toolkit

CHIC (Checker for Interface Compatibility)

CPN-AMI

CoreASM

ESC/Java

ExSpecT

FSA Utilities Frama-C

Perfect Developer (PD)

UNIT-II

9. Explain in detail about formal methods concepts
http://en.wikipedia.org/wiki/Specification_languagehttp://en.wikipedia.org/wiki/Specification_language


31/40

Data invariant

State

Operation

Precondition

Postcondition

- E.g.: 1 A symbol tableFig: A symbol table

- E.g.: A block handler

Fig: A block handler

10. Explain in detail about Mathematical preliminaries

Sets and constructive specification

Sets

Cardinality

Constructive set specification

Set operators

Membership

Subset

Empty set

Union, intersection

Difference

Cross product

Power set

Logic operators

Sequences

11. Describe briefly about applying mathematical notation

for formal specification

Description of

State

Data invariant

Operation

Precondition

Postcondition

12. Describe in detail about the Z specification languageA brief overview of Z syntax and semantics

- Generic structure of schema- Summary of z notation

An e.g. using Z- BlockHandler

- RemoveBlocks

- AddBlocks


32/40

13. Explain in detail about formal methods

Basic concepts

Deficiencies of less formal approaches

Contradictions

Ambiguities Vagueness

Incompleteness

Mixed levels of abstraction

Mathematics in s/w development

Formal methods concepts

State

Data invariant

Operation

Precondition

Postcondition

UNIT-III

14. Explain in detail about abstract machines

Software development lifecycles

Specification using abstract machines

Fig: Schematic structure of abstract machine

Mathematical notation

Machine parameters

Sets

Constants and properties

Variables and Invariants

Initialization

Operation definitions

Semantics of abstract machines

Semantics of generalized substitutions

Definition of [S]P

Intuition

Meanings of obligations

Internal Consistency

Animation

15. Describe in detail about constructing specifications

Machine composition mechanisms- Fig: Architecture of vending system

- Fig: Statechart of vending machine

- Fig: Specification structure of vending machine


33/40

- Fig: Typical use of SEES, INCLUDES and EXTENDS

mechanism

Structuring mechanisms and proof

Translation of analysis models

- Fig: Object model of air traffic control system

Relationships Renaming

- Fig: Specification structure of ATC system

16. What is meant by design and refinement in abstract

machine? Explain

The layered development paradigm- Fig: General structure of B development

- Fig: Decomposition of development into Layers

Refinement

- Fig: Example of refinement correspondence

- Fig: Schematic refinement step Refinement examples

Implementation

Examples of implementation

- Fig: Development Architecture of vending machine development- Fig: Global structure of vending machine development

System construction

Create separate decomposition

Mapping INCLUDES into IMPORTS

Mapping SEES into SEES

- Implementation example- Vending machine

17. How will you prove the abstract machine? Explain in

detail

The B Tool

Proof of internal consistency obligations

Example-ATC Development

Assertions

Definitions

Proof Listings

Animation

Refinement proof Refinement proof example- Vending system

18. Explain in detail about implementation in abstract

machines

Prototype generation

Implementing complex data


34/40

Base generation

Coding and integration

UNIT-IV

19. Explain in detail about the requirements problem The goal

Root causes of project success and failure

- Fig: Largest s/w development problems by category

The frequency of requirement errors

- Table: Defect summary

The high cost of requirements errors- Fig: Relative cost to repair a defect at different lifecycle phases

20. Explain briefly about requirements management

Applications of requirements management

Types of s/w applications

Systems applications

The road map

The problem domain (with dig)

Stakeholder needs (with dig)

Moving toward the solution domain

Features of the system (with dig)

S/w requirements (with dig)

An introduction to use cases (with dig)

21. Explain in detail about the steps involved in problemanalysis

Gain agreement on the problem definition

- The problem statement

- Table: Problem statement format

Understand the root causes-the problem behind the problem

- Fig: Fishbone diagram of root causes

- Addressing the root cause- Fig: Pareto chart of root causes

- Table: sales order problem statement

Identify the stakeholders and the users

- Table: Users and Stakeholders of new system Define the solution system boundary

- Fig: System boundary

- Fig: System perspective

Identify the constraints to be imposed on the solution.

- Table: Potential system constraints- Table: Constraints, sources, and rationale for sales order entry

system


35/40

22. Describe in detail about business modeling

Purpose of business modeling

Using s/w engineering techniques for business modeling

Choosing the right technique

The unified modeling language (UML) Business modeling using UML concepts

- Fig: Business use case model

- Fig: Business object model

From the business models to the systems model

Use of business modeling

23. Explain in detail the challenge of requirements

elicitation

Barriers to elicitation

The Yes, But syndrome

The undiscovered ruins syndrome

The user and the developer syndrome- Table: The user and the developer syndrome

Techniques for requirements elicitation

24. What is brainstorming and idea reduction? Explain it

in detail

Live brainstorming- Fig: Rules for brainstorming

Idea reduction

Pruning Grouping ideas

Feature definition

Prioritization

- Cumulative voting: The hundred dollar test- The Critical, Important, Useful Categorization

Web-based Brainstorming

25. Describe in detail about applying use cases

Building the use case model

- Fig: The initial warehouse system, with actors identified

Applying use case to requirements elicitation- Fig: Use-case specification for manual distribution b/w

warehouses

26. Explain in detail about prototyping

Types of prototypes

Throwaway versus evolutionary versus operational


36/40

Vertical versus horizontal

User Interface versus algorithmic

- Fig: Decision tree for prototype selection

Requirements prototypes

What to prototype

Building the prototype- Fig: continuum of understanding user needs

Evaluating the results

UNIT-V

27. Describe in detail about organizing requirements

information

Organizing requirements of h/w and s/w systems

- Fig: A system of systems- Fig: Hierarchy of specifications resulting from system design

- Fig: Hierarchy of resulting specifications, including s/w and h/wsystems

Organizing requirements for product families- Fig: requirements organization for a s/w product family

On future requirements

Business and marketing requirements versus product requirements

28. Describe briefly about vision document

Components of the vision document- Fig: Scope of the Vision Document

- Table: Template for a s/w product vision document

The delta vision document

Vision document for release 1.0

- Fig: Vision document v1.0

Vision document for version 2.0- Fig: Vision document v2.0

- Fig: Delta Vision document v2.0

- Fig: Delta Vision document

The Delta Vision document in a legacy system environment

29. Explain in detail about the champion

The role of product championThe product champion in a s/w product environment

The product champion in an IS/IT shop

30. Explain briefly about problem of project scope

Components of project scope

Functionality

Resources


37/40

Time

- Fig: Project scope

The hard question

31. Explain in detail about establishing project scope

The requirements baseline- Fig: Requirements baseline

Setting priorities

- Table: Prioritized features

Assessing effort

- Table: Features list with effort added

Adding the risk element- Table: Features list with risk added

Reducing scope

A reasonable first estimate- Table: scope prioritization techniques

- Table: Prioritized feature list

32. Describe in detail about Managing your customer

Engaging customers to manage their project scope

Communicating the result

Managing the baseline

Official change

Unofficial change

33. Describe briefly about s/w development process models Waterfall model

- Fig: Waterfall model of s/w development

- Fig: Applying the waterfall model to a project with 200% scope

Spiral model- Fig: The spiral model of development

- Fig: Applying the spiral model to a project with 200% scope

The iterative approach

Lifecycle phases

- Fig: Lifecycle phases in the iterative approach

Iterations

- Fig: Phase iterations, resulting in viable releases Workflows

- Fig: Workflows of the iterative approach- Advantages

a) Getting the Yes, Buts out early

b) Better scope management

34. Explain briefly about software requirements


38/40

Definition of software requirements

- Fig: System elements

R/p b/w features and s/w requirements

The requirements dilemma: what versus how

Exclude project information

Exclude design information More on requirements versus design

Iterating requirements and design

A further characterization of requirements

Functional software requirements

Non functional software requirements

- Usability- Reliability

- Performance

- Supportability

Design constraints

Design constraints are true requirements

Using parent-child requirements to increase specificity

Organizing parent-child requirements

35. Describe in detail about refining use cases

Use of use-case methodology

Use-cases not the best choice

The redundancy problem

Refining use case specifications

Evolution of use cases

Scope of use cases

36. Explain briefly about ambiguity and specificity

Finding the Sweet Spot

Techniques for disambiguation

Memorization heuristic

Keyword technique

Emphasis technique

Other techniques

37. Describe in detail about Build right system rightContinually confirm that the development is on track

Principles of s/w verification

The cost of verification

Verification at all levels

The reason for verification

Confirm that the development results are correct

Cope with change that occurs during the development process


39/40

38. How mapping is done from requirements to

implementation

Mapping requirements to design and code

- Fig: Requirements to design to implementation

Object orientation The use case as a requirement

Managing the transition

Modeling s/w systems

The architecture of s/w systems

Views of architecture

- Fig: The 4+1 architectural view

Role of the use case model in architecture

Realizing use cases in the design model

Structural and behavioral aspects of collaborations- Fig: Class diagram

- Fig: Behavioral aspects of collaboration

Using collaborations to realize the sets of individual requirements- Fig: Model of req. implementation as a use case realization

From design to implementation

39. How will you use traceability to support verification

The role of traceability in requirements verification

- Fig: traceability link from vision document to s/w requirement- Fig: project relationships

Implicit and explicit relationships

Additional traceability options to consider Using traceability tools

- Fig: Augmented traceability relationships

- Fig: Matrix version of traceability relationships

Maintenance of traceability relationships- Fig: Document/element relationships

- Fig: Abbreviated tree view

Proceeding without traceability tools

Omitted verification relationships

Excess verification relationships

Verification and traceability

40. Describe in detail about validating the system

Validation

Acceptance tests

Validation testing

- Fig: Implementation documentation

Validation traceability


40/40

formal methods and requirement ring qab

Documents