MS Computer Science Virtual University of Pakistan

CS708 Software Requirement Engineering midterm Past Papers

software requirement engineering

Software Requirement Engineering

CS708 Midterm Solved Past Papers

Q1. Requirements types or Functional Requirement in detail.

Software Requirements

  • Requirements form the basis for all software products
  • Requirements engineering is the process, which enables us to systematically determine the requirements for a software product
  • Complete specification of the desired external behavior of the software system to be built
  • What is external behavior?
  • Software requirements may be:
    • Abstract statements of services and/or constraints
    • Detailed mathematical functions
  • Software requirements may be:
    • Part of the bid of contract
    • The contract itself
    • Part of the technical document, which describes a product

 Kinds of Software Requirements

  • Functional requirements
  • Non-functional requirements
  • Domain requirements
  • Inverse requirements
  • Design and implementation constraints
  • Statements describing what the system does
  • Functionality of the system
  • Statements of services the system should provide

 Reaction to particular inputs

 Behavior in particular situations

  • Sequencing and parallelism are also captured by functional requirements
  • Abnormal behavior is also documented as functional requirements in the form of

exception handling

  • Functional requirements should be complete and consistent

Functional Requirements Examples:

  • The system shall solve a quadratic equation using the following formula

 x = (-b+sqrt(b2 – 4*a*c))/2*a

  • The user shall be able to search either the entire database of patients or select a subset

from it (admitted patients, or patients with asthma, etc.)

  • The system shall provide appropriate viewers for the user to read documents in the

document store

  • Every order shall be allocated a unique identifier (ORDER_ID) which the user shall use

to access that order

  • The system shall allow customers to return non-perishable items within fifteen days of

the purchase. A customer must present the original sale receipt to return an item

Q2 Requirement analysis and its stages and techniques.

Comments on Requirements Analysis

  • Analysts read the requirements, highlight problems, and discuss them in requirements

review meetings

  • This is a time-consuming and expensive activity
  • Analysts have to think about implications of the draft statements of requirements
  • People do not think in the same way and different analysts tackle the process in different


  • It is not possible to make this activity a structured and systematic process
  • It depends on the judgment and experience of process participants

Requirements Analysis Stages

  • Necessity checking

 The need for the requirement is analyzed. In some cases, requirements may be

proposed which don‟t contribute to the business goals of the organization or to

the specific problem to be addressed by the system

  • Consistency and completeness checking

 The requirements are cross-checked for consistency and completeness.

Consistency means that no requirements should be contradictory; Completeness

means that no services or constraints which are needed have been missed out

  • Feasibility checking

 The requirements are checked to ensure that they are feasible in the context of

the budget and schedule available for the system development

Analysis Techniques

  • Analysis checklists

 A checklist is a list of questions which analysts may use to assess each


  • Interaction matrices

 Interaction matrices are used to discover interactions between requirements and

to highlight conflicts and overlaps

Q3. Nonfunctional requirements. Describe any 3 critical systems and consequences of their failure.

Non-Functional Requirements

  • Most non-functional requirements relate to the system as a whole. They include

constraints on timing, performance, reliability, security, maintainability, accuracy, the

development process, standards, etc.

  • They are often more critical than individual functional requirements
  • Capture the emergent behavior of the system, that is they relate to system as a whole
  • Must be built into the framework of the software product
  • Failure to meet a non-functional system requirement may make the whole system


  • For example, if an aircraft system does not meet reliability requirements, it will not be

certified as „safe‟

  • If a real-time control system fails to meet its performance requirements, the control

functions will not operate correctly

  • Non-functional requirements arise through user needs, because of budget constraints,

because of organizational policies, because of the need of interoperability with other

software and hardware systems, or because of external factors such as safety

regulations, privacy legislation, etc.

Q 4.   Requirement engineering is lengthy process even if there is single requirement. Describe the role involve in this process also the communication problems in requirement.

Problems with Natural Languages

  • Requirement specification in natural language pose some problems which include

 Lack of clarity

 Requirements confusion

 Requirements amalgamation

  • Natural language understanding relies on the specification readers and writers using the

same words for same concept

  • A natural language requirements specification is over-flexible. “You can say the same

thing in completely different ways”

  • It is not possible to modularize natural language requirements. It may be difficult to find

all related requirements

 To discover the impact of a change, every requirement have to be examined

Q5. Validation input output in detail. And objectives.

 Validation Objectives

  • Certifies that the requirements document is an acceptable description of the system to be


  • Checks a requirements document for

 Completeness and consistency

 Conformance to standards

 Requirements conflicts

 Technical errors

 Ambiguous requirements

Validation Inputs and Outputs

  • Requirements Document

 Should be a complete version of the document, not an unfinished draft. Formatted and

organized according to organizational standards

  • Organizational Knowledge

 Knowledge, often implicit, of the organization which may be used to judge the realism

of the requirements

  • Organizational Standards

 Local standards e.g. for the organization of the requirements document

  • List of Problems

 List of discovered problems in the requirements document

  • Agreed Actions

 List of agreed actions in response to requirements problems. Some problems may have

several corrective actions; some problems may have no associated actions


Q6. What is requirement Review Process.

 Requirements Reviews

  • A group of people read and analyze the requirements, look for problems, meet and discuss the

problems and agree on actions to address these problems

Requirements Review Process

Review Activities

  • Plan review

 The review team is selected and a time and place for the review meeting is chosen

  • Distribute documents

 The requirements document is distributed to the review team members

  • Plan review

 The review team is selected and a time and place for the review meeting is chosen

  • Distribute documents

 The requirements document is distributed to the review team members

  • Plan review

 The review team is selected and a time and place for the review meeting is chosen

  • Distribute documents

 The requirements document is distributed to the review team members

Q7.  Define user manual development and model validation, it is beneficial for requirement validation

 User Manual Development

  • Writing a user manual from the requirements forces a detailed requirements analysis and thus

can reveal problems with the document

  • Information in the user manual

 Description of the functionality and how it is implemented

 Which parts of the system have not been implemented

 How to get out of trouble

 How to install and get started with the system

Model Validation

  • Validation of system models is an essential part of the validation process
  • Some checking is possible with automated tools
  • Paraphrasing the model is an effective checking technique

Objectives of Model Validation

  • To demonstrate that each model is self-consistent
  • If there are several models of the system, to demonstrate that these are internally and

externally consistent

  • To demonstrate that the models accurately reflect the real requirements of system

stakeholders. This is very difficult

Q8. How inspection is better technique for removal of defects.


  • Inspections, by all accounts, do a better job of error removal than any competing

technology, and they do it at a lower cost

 Robert Glass

  • Inspections are conducted by a group of people working on the project, with the

objective to remove defects or errors

  • Every member of the inspection team has to read and evaluate requirements documents

before coming to the meeting and a formal meeting is conducted to discuss

requirements errors

  • Requirements errors detected during this inspection save lot of money and time as

requirements errors do not flow into the design and development phases of software

development process

  • A complete description of inspections must address five dimensions:

 Technical

 Managerial

 Organizational

Q9. What is checklist items.

 Checklist Items Description

  • Premature design

 Does the requirement include premature design or implementation information?

  • Combined requirements

 Does the description of a requirement describe a single requirement or could it

be broken down into several different requirements?

  • Unnecessary requirements

 Is the requirement „gold plating‟? That is, is the requirement a cosmetic addition

to the system which is not really necessary

  • Use of non-standard hardware

 Does the requirement mean that non-standard hardware or software must be

used? To make this decision, you need to know the computer platform


  • Conformance with business goals

 Is the requirement consistent with the business goals defined in the introduction

to the requirements document?

  • Requirements ambiguity

 Is the requirement ambiguous i.e., could it be read in different ways by different

people? What are the possible interpretations of the requirement?

  • Requirements realism

 Is the requirement realistic given the technology which will be used to implement

the system?

  • Requirements testability

 Is the requirement testable, that is, is it stated in such a way that test engineers

can derive a test which can show if the system meets that requirement?

Q10. What are Requirements Elicitation techniques and its stages.

  • Elicit means to gather, acquire, extract, and obtain, etc.
  • Requirements elicitation means gathering requirements or discovering requirements
  • Activities involved in discovering the requirements for the system

Requirements Elicitation Techniques

  • Individual
  • Group
  • Modeling
  • Cognitive

Requirements Elicitation Stages

  • Objective setting
  • Background knowledge acquisition
  • Knowledge organization
  • Stakeholder requirements collection
  • Organization

 Submitters of input

 Users of output

 Ways in which the new system changes the business process

  • Environment

 Hardware and software

 Maturity of the target system domain

 Certainty of the target system’s interfaces to the larger system

 The target system’s role in the larger system

Q11: change management sources identify the problem if change.

Sources of Change

 New business or market conditions dictate changes in product requirements or business rules

  • New customer needs demand modification of data produced by information systems,

functionality delivered by products, or services delivered by computer-based system

  • Reorganization or business growth/downsizing causes changes in project priorities or software

engineering team structure

  • Budgetary or scheduling constraints cause a redefinition of the system or product

The change request is checked for validity. Customers can misunderstand requirements and

suggest unnecessary changes

The costs of making the changes are estimated.

Change Request Rejection Reasons

  • If the change request is invalid. This normally arises if a customer has misunderstood something about the requirements and proposed a change which is not necessary.
  • If the change request results in consequential changes which are unacceptable to the user.
  • If the cost of implementing the change is too high or takes too long

Q12. Changes in requirements factors and type of volatile requirements.

Requirements Change Factors

  • Changing customer priorities

 Customer priorities change during system development as a result of a changing

business environment, the emergence of new competitors, staff changes, etc.

  • Environmental changes

 The environment in which the system is to be installed may

  • Organizational changes

 The organization which intends to use the system may change its structure and

processes resulting in new system requirements

 Types of Volatile Requirements

  • Mutable requirements

 These are requirements which change because of changes to the environment in which

the system is operating

  • Emergent requirements

 These are requirements which cannot be completely defined when the system is

specified but which emerge as the system is designed and implemented

  • Consequential requirements

 These are requirements which are based on assumptions about how the system will be

used. When the system is put into use, some of these assumptions will be wrong

  • Compatibility requirements

 These are requirements which depend on other equipment or processes

Q13. From error removal and prevention which is more efficient. How JAD and QFD are efficient for error prevention

 Prevention vs. Removal

  • For requirements errors, prevention is usually more effective than removal
  • Joint application development (JAD), quality function deployment (QFD), and prototyping

are more effective in defect prevention

  • Requirements inspections and prototyping play an important role in defect removal

Defect Prevention

  • Don’t let defects/errors become part of the requirements document or requirements

model in the first place

  • How is it possible?
  • Understanding application domain and business area is the first step in defect


  • Training in different requirements engineering activities (elicitation, analysis and

negotiation, specification, and validation) is also very important for defect prevention

  • Allocating enough time to conduct requirements engineering activities also is very

important in this regard

  • Willing and active participation of stakeholders in different activities of requirements

engineering. That is why JAD is very useful in defect prevention as far as requirements

errors are concerned

  • An overall commitment to quality and emphasis on using documented processes is also

a very important

  • An overall commitment to process improvement