Requirements Engineering Questions and Answers

Q: In object-oriented use-case methodology, following is one of the essential step for identifying the factors that serve as good requirement analysis methodology :

The keyed answer is boundary conditions, read as the system boundary of the use-case model.In use-case analysis the first step is to fix the system boundary, that is, what lies inside the system and what lies outside it. The actors are then the things outside the boundary that interact with it, and the use cases follow from them. Without the boundary neither the actors nor the use cases can be identified, which is why it is the essential step the question asks for.Stakeholders and viewpoints are sources of requirements to be consulted, and eliminating duplications is a clean-up of use cases already found; none of them fixes what the model covers. What could not be confirmed: the question's own wording ('factors that serve as good requirement analysis methodology') did not match any source found, and 'boundary conditions' is not the usual name for the system boundary, so this rests on the standard order of use-case modelling and on the official key.

Q: Which of the following may not be preferred as a tool to specify requirements during requirement gathering stage of a software development project ?

The tool least preferred at this stage is the class diagram, the fourth option.Requirements gathering records what users need the system to do, in terms they can check. A use case diagram does this directly by showing the actors and the goals they achieve with the system. A sequence diagram shows one scenario of those goals as a series of messages between the actors and the system, and a finite-state machine specifies how the system responds to events as it moves between states, so all three describe required behaviour.A class diagram describes the static structure of the software, its classes with attributes, operations and associations. Those are design decisions about how the software will be built, which stakeholders cannot validate at the gathering stage, so it is the one the question says 'may not be preferred'.The item is one of degree: a high-level class (domain) diagram is sometimes drawn during analysis, but it is the most design-oriented of the four, and that is the reading the official key follows.

Q: Which of the following provides a concise, unambiguous, and consistent method for documenting system requirements in software development process ?

The answer is Formal methods.Formal methods specify system requirements in a mathematical notation (such as Z or VDM), which gives a concise, unambiguous and consistent description that can be checked for contradictions and even used to prove properties of the design.CMM is a model of process maturity, ISO standards define quality management processes, and CASE tools support development activities. None of these is itself a precise notation for documenting requirements.

Q: Use-cases are not well suited for capturing ............. requirements.

Use cases are not well suited to non-functional requirements.A use case describes an interaction between an actor and the system to achieve a goal, so it captures functional behaviour and user interaction well.Non-functional requirements such as performance, reliability, security and usability are qualities of the whole system rather than steps in an interaction, and are usually recorded separately, for example in a supplementary specification.

Q: A report generation application prepares required reports from the data gathered from databases. Even though the application provides required output for given input, customer rejected the application. What may be the most appropriate reason for this rejection ?

The most likely reason is a failure to meet non-functional requirements.Functional requirements say what the system must do: here, produce the required reports for given inputs. Since the application does that, its functional requirements are met.A customer can still reject software that works if it fails non-functional requirements: it is too slow, hard to use, unreliable, insecure, or does not fit the required format or platform. Verification of output and validation of input are testing activities, not categories of requirement, so they do not explain the rejection.

Q: A user is describing a real-life example during requirement gathering stage of a software development project.This most appropriately represents which requirement discovery technique ?

The technique is a scenario.In requirements discovery, scenarios are real-life examples of how a system can be used: a description of a typical interaction, the starting situation, the normal flow of events, what can go wrong and the finishing state. Users find it easier to describe such a concrete example than to state abstract requirements.An interview is the method of questioning stakeholders, not the content of what they describe. Viewpoints organise requirements by the different stakeholders' perspectives, and use cases are a more formal, structured way of identifying actors and their interactions, often built from scenarios.

Q: ............. are a requirements discovery technique that were first introduced in the Objectory method.

The technique is use cases.Use cases were introduced by Ivar Jacobson in the Objectory method and became a central part of UML. Each use case describes an interaction between an actor and the system to achieve a goal, and they are widely used to discover requirements.Classes, objects and functions are design and programming constructs, not requirements discovery techniques.

Q: Which standard is used to prepare Software Requirement and Specification document ?

The SRS standard is from the IEEE.IEEE Std 830, Recommended Practice for Software Requirements Specifications, set out the structure and qualities of an SRS document; its content now forms part of ISO/IEC/IEEE 29148.ISO publishes many standards, but the standard traditionally named for preparing an SRS is the IEEE's. ACM is a professional society that does not issue this standard, and OSI is the network reference model, not a documentation standard.

In object-oriented use-case methodology, following is one of the essential step for identifying the factors that serve as good requirement analysis methodology :

A.stakeholders
B.eliminating duplications
C.viewpoints
D.boundary conditions

Exam Year(s)

MH SET - 2018, SET Exam - 2018,

Answer: D

The keyed answer is boundary conditions, read as the system boundary of the use-case model.

In use-case analysis the first step is to fix the system boundary, that is, what lies inside the system and what lies outside it. The actors are then the things outside the boundary that interact with it, and the use cases follow from them. Without the boundary neither the actors nor the use cases can be identified, which is why it is the essential step the question asks for.

Stakeholders and viewpoints are sources of requirements to be consulted, and eliminating duplications is a clean-up of use cases already found; none of them fixes what the model covers. What could not be confirmed: the question's own wording ('factors that serve as good requirement analysis methodology') did not match any source found, and 'boundary conditions' is not the usual name for the system boundary, so this rests on the standard order of use-case modelling and on the official key.

Discuss in Forum

Which of the following may not be preferred as a tool to specify requirements during requirement gathering stage of a software development project ?

A.Use case diagram
B.Sequence diagram
C.Finite-state machine
D.Class diagram

Exam Year(s)

MH SET - 2019, SET Exam - 2019,

Answer: D

The tool least preferred at this stage is the class diagram, the fourth option.

Requirements gathering records what users need the system to do, in terms they can check. A use case diagram does this directly by showing the actors and the goals they achieve with the system. A sequence diagram shows one scenario of those goals as a series of messages between the actors and the system, and a finite-state machine specifies how the system responds to events as it moves between states, so all three describe required behaviour.

A class diagram describes the static structure of the software, its classes with attributes, operations and associations. Those are design decisions about how the software will be built, which stakeholders cannot validate at the gathering stage, so it is the one the question says 'may not be preferred'.

The item is one of degree: a high-level class (domain) diagram is sometimes drawn during analysis, but it is the most design-oriented of the four, and that is the reading the official key follows.

Discuss in Forum

Which of the following provides a concise, unambiguous, and consistent method for documenting system requirements in software development process ?

A.CMM
B.ISO standard
C.CASE tools
D.Formal methods

Exam Year(s)

MH SET - 2020, SET Exam - 2020,

Answer: D

The answer is Formal methods.

Formal methods specify system requirements in a mathematical notation (such as Z or VDM), which gives a concise, unambiguous and consistent description that can be checked for contradictions and even used to prove properties of the design.

CMM is a model of process maturity, ISO standards define quality management processes, and CASE tools support development activities. None of these is itself a precise notation for documenting requirements.

Discuss in Forum

Use-cases are not well suited for capturing ............. requirements.

A.functional
B.non-functional
C.user interaction
D.hardware interaction

Exam Year(s)

MH SET - 2020, SET Exam - 2020,

Answer: B

Use cases are not well suited to non-functional requirements.

A use case describes an interaction between an actor and the system to achieve a goal, so it captures functional behaviour and user interaction well.

Non-functional requirements such as performance, reliability, security and usability are qualities of the whole system rather than steps in an interaction, and are usually recorded separately, for example in a supplementary specification.

Discuss in Forum

A report generation application prepares required reports from the data gathered from databases. Even though the application provides required output for given input, customer rejected the application. What may be the most appropriate reason for this rejection ?

A.Failure to meet functional requirements
B.Failure to meet non-functional requirements
C.Failure to meet verification of output
D.Failure to meet validation of input

Exam Year(s)

MH SET - 2021, SET Exam - 2021,

Answer: B

The most likely reason is a failure to meet non-functional requirements.

Functional requirements say what the system must do: here, produce the required reports for given inputs. Since the application does that, its functional requirements are met.

A customer can still reject software that works if it fails non-functional requirements: it is too slow, hard to use, unreliable, insecure, or does not fit the required format or platform. Verification of output and validation of input are testing activities, not categories of requirement, so they do not explain the rejection.

Discuss in Forum

A user is describing a real-life example during requirement gathering stage of a software development project.

This most appropriately represents which requirement discovery technique ?

A.Viewpoint
B.Interview
C.Scenario
D.Use-case

Exam Year(s)

MH SET - 2023, SET Exam - 2023,

Answer: C

The technique is a scenario.

In requirements discovery, scenarios are real-life examples of how a system can be used: a description of a typical interaction, the starting situation, the normal flow of events, what can go wrong and the finishing state. Users find it easier to describe such a concrete example than to state abstract requirements.

An interview is the method of questioning stakeholders, not the content of what they describe. Viewpoints organise requirements by the different stakeholders' perspectives, and use cases are a more formal, structured way of identifying actors and their interactions, often built from scenarios.

Discuss in Forum

............. are a requirements discovery technique that were first introduced in the Objectory method.

A.Classes
B.Objects
C.Functions
D.Use cases

Exam Year(s)

MH SET - 2024, SET Exam - 2024,

Answer: D

The technique is use cases.

Use cases were introduced by Ivar Jacobson in the Objectory method and became a central part of UML. Each use case describes an interaction between an actor and the system to achieve a goal, and they are widely used to discover requirements.

Classes, objects and functions are design and programming constructs, not requirements discovery techniques.

Discuss in Forum

Which standard is used to prepare Software Requirement and Specification document ?

A.ISO
B.IEEE
C.ACM
D.OSI

Exam Year(s)

MH SET - 2025, SET Exam - 2025,

Answer: B

The SRS standard is from the IEEE.

IEEE Std 830, Recommended Practice for Software Requirements Specifications, set out the structure and qualities of an SRS document; its content now forms part of ISO/IEC/IEEE 29148.

ISO publishes many standards, but the standard traditionally named for preparing an SRS is the IEEE's. ACM is a professional society that does not issue this standard, and OSI is the network reference model, not a documentation standard.

Discuss in Forum

Loading…

Topics

Other Subjects

Tags: Requirements Engineering Questions and Answers || Requirements Engineering MCQ Questions and Answers || Requirements Engineering GK Questions and Answers || Requirements Engineering GK MCQ Questions || Requirements Engineering Multiple Choice Questions and Answers || Requirements Engineering GK || GK on Requirements Engineering || Software Engineering Questions and Answers || Software Engineering MCQ Questions and Answers || Software Engineering GK Questions and Answers || GK on Software Engineering

Requirements Engineering Questions and Answers

Topics

Other Subjects

About Us

Stay informed about all important Dates & Notifications