Question Bank

2 marks

UNIT – I

  1. Define requirements and requirements engineering.

Requirements are descriptions of the services that a software system must provide and the constraints under which it must operate.

Requirements can range from high-level abstract statements of services or system constraints to detailed mathematical functional specifications.

It the process of establishing the services that the customer requires from the system and the constraints under which it is to be developed and operated.

Requirements may serve a dual function:

  • As the basis of a bid for a contract.
  • As the basis for the contract itself.
  1. What are the steps involved in requirements validation?
  1. Requirement must be testable.
ii.Requirement must clearly distinguish success from failure.
iii.Requirements must specify a single attribute or behavior.
  1. Requirements must be precise and have a single, clear meaning.
v.Requirements must be consistent both with themselves and with other requirements.
  1. Requirements must be complete.
vii.Requirements should have enough detail to avoid the need for many derived requirements.
viii.Requirements must describe what is wanted, not how to implement it
  1. What are the techniques involved in requirements validation?
  1. hand checking - reading through the specification document.
  2. Fagan inspections - structured hand checking .
  3. using a prototype-as a test harness to validate functional requirements - as a simulator to validate functional and usability requirements .
  4. specification animation - like using a prototype a simulator .
  5. formal proofs of important properties .
  6. Choosing a Technique.
  1. Differentiate between verification and validation.

Validation. The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification.

Verification. The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation.

  1. What are the difficulties arises in business requirements?

Business requirements are often prematurely hardened due to the large stakeholder base involved in defining the requirements, where there is a potential for conflict in interests. The process of managing and building consensus can be delicate and even political by nature.

  1. What is meant by BRD?

The intent behind the BRD is to define what results would be wanted from a system, however it might eventually be designed.

  1. List out the types of requirements.

i)Functional requirements

ii)Non Functional requirements

iii)Domain requirements

  1. Draw the diagram for requirements engineering process.

  1. Applications of fish bone diagram.
  1. Project presentations to showcase root cause analysis
  2. Brainstorming session for developing new product design
  3. Review sessions for Quality defect prevention
  4. Define fishbone diagram.
  1. Define and benefits of activity diagram.

The basic purposes of activity diagrams are similar to other four diagrams. It captures the dynamic behavior of the system. Other four diagrams are used to show the message flow from one object to another but activity diagram is used to show message flow from one activity to another. Activity is a particular operation of the system. Activity diagrams are not only used for visualizing dynamic nature of a system but they are also used to construct the executable system by using forward and reverse engineering techniques. The only missing thing in activity diagram is the message part.

  1. What is meant by business requirements?

Business requirements are what must be delivered to provide value. Products, systems, software, and processes are the ways how to deliver, satisfy, or meet the business requirements whats. Consequently, the topic of business requirements often arises in the context of developing or procuring software or other system; but business requirements exist much more broadly. That is, 'business' can be at work or personal, for profit or non-profit.

  1. Define test cases

A test case, in software engineering, is a set of conditions or variables under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle.

UNIT – II

  1. What is meant by stakeholder’s needs?
  1. Stakeholders know what they want but may not be able to articulate it.
  2. Stakeholders may not know what they want.
  3. Stakeholders think they know what they want until you give them what they said they wanted.
  4. Analysts think they understand user problems better than users.
  5. Everybody believes everybody else is politically motivated.
  1. Define prototyping.

Prototyping is especially effective in addressing the “Yes, But” and the“Undiscovered Ruins” syndromes. A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understandsystemrequirements.

  1. List out the techniques available elicitation.
  1. Prototyping
  2. Interviewing
  3. Brainstorming
  4. Questionnaire
  5. Workshop
  1. What are the steps involved in preparing workshop?
  1. Conduct the Session
  2. Consolidate Results
  3. Define the scope and establish an agenda
  4. Invite the right people
  5. Plan the logistics
  1. What are the rules available in brainstorming?

• Criticism is absolutely forbidden; participants must feel free to express any idea.

• Wild, offbeat, or unconventional ideas are encouraged;they usually lead to really

creative approaches to the problem.

• Number of ideas generated should be very large.

• In addition to suggesting totally new ideas, participants should be encouraged to

combine or embellish ides of others.

  1. What is Requirements elicitation?

The process of identifying needs and bridging the disparities among the involved communities for the purpose of defining and distilling requirements to meet the constraints of these communities.Requirements elicitation involves social, communicative issues as well as technical issues.Research efforts should be directed towards methods…providing more support to the elicitation of requirements.

  1. Define interview.
  2. Identifying candidates
  3. Preparing for an interview
  4. Conducting the interview
  5. Following up
  1. What are the four phases available in interviewing?
  2. Identifying candidates
  3. Preparing for an interview
  4. Conducting the interview
  5. Following up
  1. What happens in a typical workshop?
  1. Ground rules are set at the beginning
  2. Participants may be split into multiple teams in order to get the discussion going with each team representing a mix of different interests
  3. Participants may be given a problem statement to discuss/objective(s) to achieve. They may also be asked to identify requirements, review existing ones or assign a priority to each requirement.
  1. What is a Requirements Document?

A requirements document explains why a product is needed, puts the product in context, and describes what the finished product will be like. A large part of the requirements document is the formal list of requirements.

  1. How to document a stakeholders needs?

Clear and accurate documentation is critical to the process. It is important that the needs are documented in the terminology of the key stakeholders so that no ambiguity can exist and a meaningful agreement can be achieved. In the analysis, the client's needs should be reviewed, constraints should be identified, the determined needs should be realistic, the findings should be documented and, most importantly, approval from the key stakeholders should be obtained in writing. The project manager must identify and resolve the needs of key stakeholders and make sure that needs are managed throughout the project.

  1. How Are Requirements Documents Prepared?

A lot of work happens before a requirements document is written. Your project will benefit from the time you spend finding out what the requirements are before writing them down. Once you have gathered and recorded requirements, they should be classified and prioritized. With the list of prioritized requirements and any other project documents you already have, you will be able to compile the requirements document.

Gathering Requirements

Recording Requirements

Classifying Requirements

Prioritizing Requirements

Writing the Document

  1. Define business use cases.

A Business Use-Case is a way in which a customer or some other interested party can make use of the business to get the result they want whether it’s to buy an item, to get a new driving license, to pay an invoice, or whatever. An important point is that a single execution of a Business Use-Case should encompass all the activities necessary to do what the customer (or other actor) wants, and also any activities that the business needs to do before the process is complete from its point of view.

UNIT – III

  1. Define functional requirements.

A functional requirement defines a function of a system or its component. A function is described as a set of inputs, the behavior, and outputs. Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish.

  1. Define use case.

A use case defines a goal-oriented set of interactions between external users and the system under consideration or development. Use cases have become a widespread practice for capturing functional requirements in software design, especially in the object-oriented community where they originated, but their applicability is much wider

  1. Differentiate between use cases and scenarios.

Usecases:

Each use case is one or more scenarios.

  • Add Subject Use Case :
  • Scenario 1 : Subject gets added successfully.
  • Scenario 2 : Adding the subject fails since the subject is already in the database.
  • Enroll Subject Use Case:
  • Scenario 1 : Student is enrolled for the subject.
  • Scenario 2 : Enrollment fails since the student is already enrolled in the subject.
  • Each scenario has a sequence of steps.

Scenarios:

Each scenario has a sequence of steps.

  • Scenario 1 : Student is enrolled for the subject.
  • Student chooses the “enroll subject” action.
  • Check the student has enrolled in less than 10 subjects.
  • Check if the subject is valid.
  • Assign the subject to the student.

Each scenario has a sequence of steps.

  • Scenario 2 : Enrolling fails since the student is already enrolled in 10 subjects.
  • Student chooses the “enroll subject” action.
  • Check the student has enrolled in less than 10 subjects.
  • Return an error message to the student.
  1. What are the steps involved in use case guidelines?
  1. Identify all the different users of the system
  2. Create a user profile for each category of user, including all the roles the users play that are relevant to the system.
  3. For each role, identify all the significant goals the users have that the system will support. A statement of the system’s value proposition is useful in identifying significant goals1.
  4. Create a use case for each goal, following the use case template. Maintain the same level of abstraction throughout the use case. Steps in higher-level use cases may be treated as goals for lower level (i.e., more detailed), sub-use cases.
  1. What is meant by SRS?

Software requirements specification (SRS), a requirements specification for a software system, is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements.

  1. How to capturing the functional requirements?

To document functional requirements you must capture three categories of information:

  1. Use cases
  2. Functional capabilities
  3. Business rules
  1. When to use usecases?

In short, always!!!

Requirements is the toughest part of software development

  • Use-Cases is a powerful tool to understand
  • Who your users are (including interacting systems)
  • What functions the system shall provide
  • How these functions work at a high level

Spend adequate time on requirements and in the elaboration phase

  1. Define use cases scenario.

A Use Case Scenario is a description that illustrates, step by step, how a user is intending to use a system, essentially capturing the system behavior from the user's point of view. A use case scenario can include stories, examples, and drawings. Use cases are extremely useful for describing the problem domain in unambiguous terms and for communicating with the potential users of a system.

  1. Draw the usecase diagram for Student Assessment Management System .

  1. What are the steps involved in documenting usecase diagram.
  2. Opening use case details
  3. Entering basic information
  4. Entering flow of events
  5. Inserting requirement links
  6. Managing sub-Diagrams
  1. List the limitations of use case.

Limitations of use cases include:

  • Use cases are not well suited to capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
  • Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
  • For some products and systems, use cases are complex to write and to understand, for both end users and developers who are not well trained.
  • As there are no fully standard definitions of use cases, each project must form its own interpretation.

UNIT - IV

  1. Define quality attribute and list its category.

Quality attributes are orthogonal to functional requirements, as desired functionality can be accomplished with a variety of different architectures that make different sets of tradeoffs among the quality attributes. The various quality attributes have different importance in different projects / products - for example, a single user application would place much less emphasis on interoperability than a middleware product.

i.System qualities.

ii.Run time qualities.

iii.Design qualities.

iv.User qualities.

2. What are the benefits of usability requirements?

  • Highlights the importance of usability early in development
  • Provides concrete objectives for usability
  • Provides usability criteria that can be tested.

3. What is meant by QAW?

  • The Quality Attribute Workshop (QAW) is a facilitated method that engages system stakeholders early in the system development life cycle to discover the driving quality attributes of a software-intensive system. The QAW is system-centric and stakeholder focused; it is used
  • before the software architecture has been created. The QAW provides an opportunity to gather
  • stakeholders together to provide input about their needs and expectations with respect to key
  • quality attributes that are of particular concern to them.

4. What are the steps involved in QAW?

  • 1. QAW Presentation and Introductions
  • 2. Business/Mission Presentation
  • 3. Architectural Plan Presentation
  • 4. Identification of Architectural Drivers
  • 5. Scenario Brainstorming
  • 6. Scenario Consolidation
  • 7. Scenario Prioritization
  • 8. Scenario Refinement

5. What are the usability failures available?

  • Usability failuresfound during usability testing can be classified by severity:
  • Total Failure.Either the user cannot complete the task on his or her own, or else erroneously believes that the task has been completed.
  • Major Failure.Although the user successfully completes the task, the user also complains that the application is annoying or difficult to use.
  • Medium Failure.Although the user does not complain, the user nevertheless requires multiple attempts to successfully complete the task.
  • Minor Failure.The user requires a few short attempts to successfully complete the task.

6. What is meant by UI design?

User interface designoruser interface engineeringis the design ofwebsites,computers,appliances, machines,mobile communication devices, andsoftwareapplications with the focus on theuser's experienceand interaction. The goal of user interface design is to make the user's interaction as simple and efficient as possible, in terms of accomplishing user goals—what is often calleduser-centered design. Good user interface design facilitates finishing the task at hand without drawing unnecessary attention to itself.

7.What are the benefits available QAW?

QAW Benefits

The QAW provides a forum for a wide variety of stakeholders to gather in one room at onetime very early in the development process. It is often the first time such a meeting takes placeand generally leads to the identification of conflicting assumptions about system requirements.In addition to clarifying quality attribute requirements, the QAW provides increased stakeholdercommunication, an informed basis for architectural decisions, improved architecturaldocumentation, and support for analysis and testing throughout the life of the system.

UNIT - V

1 .Why is Requirements Management important?

Software development projects suffer most when changes in requirements set off a chain reaction of delays, revisions and rework. Existing processes for establishing requirements are often ad-hoc and inefficient, leading to mis-communication and insufficiently defined requirements. By ensuring effective Requirements Definition (RD) at the outset – involving elicitation, analysis, specification and validation – enterprises can reduce rework, speed up development and deliver dramatic time and cost savings.

2.Define traceability.

Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable.

3. Why is Scope important?

The scope changes that usually cause problems are those where the perception of what was in and out of scope was different between various parties. The Project Manager assumed there would only be four or five reports, and the business assumed ten to twenty. Nobody felt it was worth talking about because they assumed the other person thought the same way they did.

4.List the limitations of requirements metrics.

  1. The notations are difficult to read and understand.
  2. It has a steep learning curve.
  3. The mathematical notation is hard for clients to understand and may intimidate the client.
  4. it is difficult to express constraints such as processing speed, reliability and efficiency, in some formal specification languages.
  5. It forces to express a significant amount of functionality in the early life cycle.
  6. It is expensive to implement.

5.Define Requirements management tools.