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 dependencies iii. Complexity iv. Flow of information through a system v. 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 programming environments for high performance computer systems ii. develop a formal methodology that guides us toward the construction of correct and portable parallel programs, and adopt an openness to radical and innovative 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 others ii. 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, where critical 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

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 an underlying mathematical description: i. a numerical modeling ii. a stochastic modeling 7. What are the types of computer models? i. Stochastic or deterministic ii. Steady-state or dynamic iii. Continuous or discrete iv. Local or distributed. 8. What is meant by verification? Formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics 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 deduction ii. 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 or hardware 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 some system should satisfy. 14. What are the advantages of formal specification?

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 consistent iii. Unambiguous iv. Complete v. Satisfied vi. Minimal 16. What are the disadvantages of formal specification? i. Limited scope. ii. Cost iii. Poor guidance. iv. Poor tool feedback 17. Mention any four approaches to formal specification? i. History-based specification ii. State-based specification iii. 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 algebraic specification is to: i. represent mathematical structures and functions ii. while abstracting from implementation details such as the size of representations (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

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 mathematical model of a system so it may be helpful to expand on this. 21. Mention any four formal specification languages i. Abstract State Machines (ASMs) ii. Vienna Development Method (VDM) iii. Petri nets iv. 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 of Generalised Substitutions. 23. Mention any four software tools that support formal specification? i. Alloy Analyzer ii. B-Toolkit iii. 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 computer software. It was originally developed by Jean-Raymond Abrial in France and the UK. B is related to the Z notation and supports development of programming language code from specifications. B has been used in major safety-critical system applications in Europe and is attracting increasing interest in industry. It has robust, commercially available tool support for specification, design, proof and 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?

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 defining notions like consistency and completeness and more relevantly, specification, implementation and correction. 31. List down the deficiencies of less formal approaches? i. ii. iii. iv. v. Contradictions Ambiguities. Vagueness. Incomplete Statements. Mixed level of abstractions.

32. Write down the usage of mathematics in software development? i. ii. iii. It can exactly describe a physical situation, an object or the outcome of an action. It supports abstraction and is an excellent medium for modeling. 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.

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 # operator returns 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<3, and a term n. The signature specifies the range of values that will be considered when forming a set. The predicate defines how the set is to be constricted; the term gives the general form of the item of the set. 39. What is meant by power set? Give an example. The power set of a set is the collection of subsets of that set. The symbol used for the power set is P E.g. P{1,2,3} = { , {1}, {2}, {3}, {1,2} , {1,3}, {2,3}, {1,2,3}}

40. Define sequence with example. A sequence is a mathematical structure that models the fact that its elements 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. Sequence is designated using angle brackets. e.g. <Jones, Wilson, Anu> 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 schema describes 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 Invariant Where 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 analysis ii. Specification development iii. Design iv. Coding/Integration/Test 45. Write short notes on abstract machines

An abstract machine is a module encapsulating both constant and variable, data and operations on that data. It is similar to an Ada package- defining a set of features which can be considered private to that module or exported selectively to other modules to use to support their own definitions. 46. What is the role of abstract machine The role of an abstract machine in a B specification is to abstractly describe the required facilities to be provided by a complete system, or by a subsystem of that system. 47. What are the two variants of notation in B AMN? i. ASCII representation ii. LATEX representation 48. What are the two types of machine parameters? i. Scalar parameters ii. Set parameters 49. Write short notes on sets in B AMN SETS clause defines local types setdef1;

setdefn ss={val1,,valn} 50. Write short notes on constants and properties CONSTANTS is a list con1,,conn of identifiers PROPERTIES clause use static data CONSTANTS ok, notok PROPERTIES ok=0 ^ notok=1 51. What is meant by generalized substitution It is an abstract mathematical programming construct,built up from basic substition x:=e, corresponding to assignments to state variables. 52. Mention the difference b/w P|S and P= =>S P|S should not be invoked when P fails to hold P= => cannot be executed when P fails to hold. 53. What is meant by animation? Animation focuses on the validation of the specification-whether its expression of the perceived requirements matches the users expectations of the system. 54. Mention the general properties in the structuring mechanisms

i. ii. iii. iv.

SEES USES INCLUDES EXTENDS

55. Write short notes on B development A 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 the behavior 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 clause ii. 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 the automatic 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 consistency? i. ii. iii. the problems that can be identified in the failure to prove internal Empty state space Initialisation fails to establish the invariant Operations fail to maintain the invariant

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 in establishing the proof obligations of the machine than the basic invariant. 64. What is meant by definitions The DEFINITIONS clause of a machine lists useful abbreviations, which will be macro-expanded throughout the text of the machine. DEFINITIONS lhs1 == 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 invariants iii. 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. ii. iii. Lack of user input: 13 percent of all projects. Incomplete requirements and specifications; 12 percent of all projects. Changing requirements and specifications: 12 percent of all projects.

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 imposed documentation.

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.

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. ii. iii. iv. v. Gain agreement on the problem definition. Understand the root causes- the problem behind the problem. Identify the stakeholders and the users. Define the solution system boundary. 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.

An actor is defined as someone or something, outside the system, that interacts with the system.

80. What is meant by constraint? Constraint is meant by a restriction on the degree of freedom we have in providing a solution.

81. What is the purpose of business modeling? The purpose of business modeling is twofold: i. ii. To understand the structure and dynamics of the organization. To ensure that customers, end users and developers have a common understanding of the organization.

82. Write short notes on UML. Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing and documenting the artifacts of a software intensive system was adopted as an industry standard. The UML provides a set of modeling elements, notations, relationships and rules that could be applied to a software development activity. The UML can be used to model other applications, such as system modeling and business modeling.

83. What are the two key modeling constructs? Distinguish among them. The two key modeling constructs that can be used for this purpose are a business use-case model and business object model.

Business Use-Case Model

Business Object Model

A Business use-case model is a model of The business object model describes the intended functions of the business and the entities and how they interact to is used as an essential input to identify deliver the functionality necessary to roles and deliverables in the organization.

The oval icon used to represent the realize the business use cases. business use-case has the slash, indicating The slashed circle represents a a business-level use case. business entity that business workers Here, the actors and the use-cases produce. describe who is involved in the business activities and how these activities takes The business use-case realizations show that the business use-cases are place. 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. ii. iii. iv. v. vi. vii. Interviewing and questionnaires. Requirements workshops. Brainstorming and idea reduction. Storyboards. Use cases. Role Playing. 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:

i. ii. iii. iv. v. vi.

It encourages participation by all parties present. It allows participants to piggyback on one others ideas. A facilitator or scribe maintains a written trail of everything discussed. It exhibits high bandwidth. Typically, it results in a broad set of possible solutions to whatever problem is posed. 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; Idea reduction 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?

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. ii. Fuzzy needs become better understood. 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.

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

There are 2 reasons to develop the Vision Document they are .. i. ii. Every project needs a vision document. 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. ii. iii. The stakeholders who has to agree for the vision doument are as follows.. The Marketing Department which act as the proxy of the customer and the user. 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 usecases aroud 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. ii. iii. The Functionality that must be delivered to meet the users needs. The resource availabel to the project. 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.

i. ii. 101.

Be atleast acceptable to the customer. Have the reasonable priority of sucess.

What are the types of priority levels? The types of priority levels are i. 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 approach Inception 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?

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. 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. 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 fully conforms to the user needs. 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. 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. 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, contractual obligations. 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 be understood 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.

108.

109.

110.

111.

112.

113.

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 the development 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 design and 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-subordinate relationship. 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 Traceability It is provided by the methodology and the It is the development of relationships structure of the model. stemming from external considerations supplied by your team Implicit relationship need not e explicitly There is no intrinsic relationship between stated as an explicit relationship, since the elements , only external decisions can possible confusions may arise. establish the relationship. Example for this is a parent-child Example for this is linkage, or relationship hierarchical relationship. between a product feature and a use-case that supports that feature.

PART-B

UNIT-I

1.Write short notes on need for modeling e communication better planning and reduce risk Team features Refactoring Patterns verse engineering 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 of correct and portable parallel programs, and adopt an openness to radical and innovative alternatives iii. 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 and facilitate a flexible, supportive environment v. introduce widely available, substantial educational opportunities in parallel programming that will create a pool of individuals with the experience and intuition necessary to work effectively in this setting. 3.Explain briefly about modeling computing systems Definition Types Stochastic or deterministic Steady-state or dynamic Continuous or discrete Local or distributed. 1.Computer modeling in science a numerical modeling a stochastic modeling 4.Write short notes on Verification

Usage pproaches to formal verification alidation and Verification Industry usage erification techniques

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

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

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 lifecycle phases 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

24.Describe briefly about the barriers to elicitation The Yes, But syndrome The undiscovered ruins syndrome The user and the developer syndrome - Table: The user and the developer syndrome 25.Write short notes on live brainstorming - Fig: Rules for brainstorming 26.Write short notes on idea reduction Pruning Grouping ideas Feature definition Prioritization Cumulative voting: The hundred dollar test The Critical, Important, Useful Categorization 27.Explain briefly about building use case model - Fig: The initial warehouse system, with actors identified 28.Describe briefly applying use case to requirements elicitation - Fig: Use-case specification for manual distribution b/w warehouses 29.Explain briefly about types of prototypes Throwaway versus evolutionary versus operational Vertical versus horizontal User Interface versus algorithmic - Fig: Decision tree for prototype selection 30.Write short notes on 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/w systems 31.Explain briefly about organizing requirements for product families - Vision document - Set of use cases - Common s/w requirements specification - Each product Vision document, Set of use cases, Common s/w requirements specification 32.Write short notes on components of vision document - Fig: Scope of the Vision Document - Table: Template for a s/w product vision document

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 on spiral 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 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

es,Buts out early

ope management 39.Explain briefly about non functional requirements Usability Reliability Performance Supportability 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

- 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 or deterministic Steady-state or dynamic Continuous or discrete Local or distributed.

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

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

 Data invariant State Operation Precondition Postcondition - E.g.: 1 A symbol table Fig: 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 language A brief overview of Z syntax and semantics - Generic structure of schema - Summary of z notation An e.g. using Z - BlockHandler - RemoveBlocks - AddBlocks

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

- 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

 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 problem analysis 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

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

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/w systems 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 champion The 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

 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 - 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

Spiral model

 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 right Continually 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

38. How mapping is done from requirements 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

to

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

Requirements-based testing Testing Discrete requirements Omitted verification relationships Excess verification relationships Testing design constraints