Assosa University

College of Computing and Informatics

Department of Computer Science

SOFTWARE ENGINEERING
QA NOTES & MULTIPLE-CHOICE QUESTIONS JUN, 2024

GEBREIGZIABHER ABADI (LECTURER IN COMPUTER SCIENCE)

[email protected], [email protected]

Software Engineering QA Notes & Multiple-Choice Questions – Jun, 2024

JUNE 12, 2024

Assosa University Department of Computer Science

Software Engineering QA Notes & Multiple-Choice Questions

Part I: Requirement Elicitation

1. What’s a requirement?
• A requirement is a feature that the system must have or must satisfy to be accepted by
the client.
2. What is Requirement Elicitation?
• Requirement Elicitation is the systematic process of gathering and defining the functional
and non-functional requirements of a system from stakeholders and other sources to
ensure the final product meets user and business needs.
3. What are the two main activities in Requirements Engineering?
a. Requirements elicitation, which results in specification of system that the client understands
b. Analysis, which results into an analysis model that developers unambiguously interpret.
4. What are the tools for bridging the gap between users and developers?
Scenarios and use cases
5. Differentiate between scenarios and use cases?
A scenario describes an example of system use in terms of a series of interactions between
the user and system. A use case is an abstraction that describes a class of scenarios.
6. How do developers elicit requirements from users?
By observing and interviewing.
7. How do the client and users validate the system description?
By reviewing the scenarios and by testing small prototypes provided by developers.
8. List the errors encountered during requirement elicitation?
• Missing system functionality,
• Incorrectly specified functionality,
• Misleading or unusable user interfaces,
• Obsolete functionality.
9. Which one of the following is true about requirement elicitation?
a. Developers construct a model of application domain by observing users in their environment.
b. Developers select a representation that is understandable by clients and users (scenarios
and use cases).
c. Developers validate application domain model by constructing simple prototypes of the user
interface and collecting feedback from potential users (e.g., rapid prototyping, usability
testing).
d. All

2
Assosa University Department of Computer Science
10. What is System Specification?
System Specification is definition of system requirements that serves as a contract
between the client and developers.
11. Describe the three methods for eliciting information and making decisions with users & clients?
a. Joint Application Design (JAD) - building consensus among developers, users, and clients by
jointly developing the system specification.
b. Knowledge Analysis of Tasks (KAT) - eliciting information from users through observation.
c. Usability testing - validating the requirements elicitation model with the user
12. List the different sources of information developers access during requirements elicitation.
a. Client-supplied documents about the application domain,
b. Manuals and technical documentation of legacy systems that the future system will replace, and,
c. Most important, the users and clients themselves.
13. What are Functional Requirements?
• Functional requirement describe the interactions between the system and its
environment independent of its implementation. The environment includes the user and
any other external system with which system interacts.
14. What are Nonfunctional Requirements? Give examples.
• Nonfunctional Requirements Describe user-visible aspects of the system that are not
directly related with the functional behavior of the system. Example: Performance,
Availability, Reliability, Security, Portability, Maintainability, etc.
15. What are Pseudorequirements? Give examples.
• Pseudorequirements are requirements imposed by the client that restrict the
implementation of the system. Example: Implementation language and platform on which
the system is to be implemented.
16. Describe the Four Levels Description from most-general to most-specific.
a. Work division: define the boundaries between the users and the system.
b. Application-specific system functions: describes functions that system provides that are related
to application domain.
c. Work-specific system functions: describe supporting functions of system that are not directly
related with application domain. These include file management, grouping, undo functions, and
so on.
d. Dialog: describes interactions between the users and user interface of system.

3
Assosa University Department of Computer Science
17. Write criteria of Requirement Validation.
Requirement validation is checking if the specification is:
• Correct if it represents the client’s view of the system (i.e., everything in requirements model accurately
represents an aspect of system).
• Complete if all possible scenarios through system are described, including exceptional behavior (i.e., all
aspects of system are represented in requirements model).
• Consistent if it does not contradict itself.
• Unambiguous if exactly one system is defined (i.e., it is not possible to interpret the specification two or
more different ways).
• Realistic if the system can be implemented within constraints.

18. Describe the verifiability and traceability of a system specification.

• A specification is verifiable if, once system is built, a repeatable test can be designed to
demonstrate that the system fulfills requirement.
• A specification is traceable if each system function can be traced to its corresponding set of
requirements.
19. List the activities of Requirements Elicitation.
a. Identifying actors - Developers identify different types of users (Internal & external entities of
system – Actor is an entity that interact with the system under development).
b. Identifying scenarios - Developers develop a set of detailed scenarios for typical functionality.
c. Identifying use cases - Derive set of use cases from scenarios that completely represent the
system.
d. Refining use cases - Ensure that the system specification is complete (Refine, rewrite or drop use
cases)
e. Identifying relationships among use cases - Consolidate the use case model by eliminating
redundancies to ensure consistency of system spec.
f. Identifying participating objects - Identify, name, and describe main concepts unambiguously.
g. Identifying nonfunctional requirements - Identify aspects that are visible to the user but not
directly related to functionality.
20. What are usability parameters during usability testing?
a. The ease to learn the system,
b. The time to accomplish a task, or
c. The rate of errors a user makes when accomplishing a task.
21. What are the three types of usability tests?
a. Scenario test: Users are presented with a visionary scenario of system. Developers identify how
quickly users are able to understand scenario, how accurately it represents their model of work,
and how positively they react to the description of new system.
b. Prototype test: Users are presented with a piece of software that practically implements the
system.
c. Product test: Functional version of system is used in place of the prototype.

4
Assosa University Department of Computer Science
Part II: System Analysis

1. What is System Analysis?

• System analysis is the process of formalizing user requirements into a structured model
that ensures correctness, completeness, consistency, and verifiability of a software under
development.
2. What is Analysis Model?
• Analysis model describes the system completely from actors’ point of view.
3. How is System Analysis different from Requirements Elicitation?
• In analysis developers focus on structuring and formalizing requirements elicited from
users.
4. What are the three individual models of analysis model?
a. Functional model -represented by use cases and scenarios,
b. Analysis object model - represented by class and object diagrams, and
c. Dynamic model - represented by statechart and sequence diagrams.

5. List out the activities System Analysis.

a. Identifying entity objects - Examine each use case and identify objects.
b. Identifying boundary objects - Model the user interface
c. Identifying control objects - Coordinate boundary and entity objects.
d. Mapping use cases to objects - Sequence diagrams describe interactions among classes in terms
of an exchange of messages over time.
e. Identifying associations among objects - Identify relationship between two or more classes.
f. Identifying object attributes - Identify properties of individual objects.
g. Modeling nontrivial behavior with state charts - Represent behavior from the perspective of a
single object.
h. Modeling generalization relationships - To eliminate redundancy from the analysis model. If two
or more classes share attributes or behavior, the similarities are consolidated into a superclass.
6. What is the goal of reviewing Analysis Model?
• To make sure that system specification is correct, complete, consistent, and realistic.
7. Describe parts of the Requirements Analysis Document (RAD).
1. Introduction: provide a brief overview of function of the system and the reasons for its
development, its scope, and references to the development context (e.g., related problem
statement, references to existing systems, feasibility studies). The introduction also includes the
objectives and success criteria of the project.
2. Current system: Describe functionality and problems of the current system and how the tasks
supported by the new system are accomplished now.
3. Proposed system: documents requirements elicitation and analysis model of the new system.
3.1. Overview: presents a functional overview of the system.
3.2. Functional requirements: describes high-level system functionality.

5
Assosa University Department of Computer Science
3.3. Nonfunctional requirements: describes user-level requirements not directly related to
functionality. This includes performance, security, modifiability, error handling, hardware
platform, and physical environment.
3.4. Pseudorequirements: describes design and implementation constraints imposed by the
client. This includes the specification of the deployment platform, implementation
language, or DBMS
3.5. System models: Contains complete functional system specification.
3.5.1. Scenarios – an example of system use in terms of a series of interactions
between the user and system.
3.5.2. Use case Model -
3.5.3. Object models, documents all objects identified, their attributes, and operations.
Relationships among objects are illustrated with class diagrams.
3.5.4. Dynamic models, documents behavior of object model, in terms of statechart
diagrams and sequence diagrams.
3.5.5. User interface - mock-ups and navigational charts illustrating user interface of
system.

Part III: System Design

1. What is System design?

• System Design is the transformation of the analysis model into a system design model.
2. What are the products of System Design?
• List of design goals, describing qualities of the system that developers should optimize, Software
architecture, describing subsystem decomposition in terms of subsystem responsibilities,
dependencies among subsystems, subsystem mapping to hardware, and major policy decisions
such as control flow, access control, and data storage
3. What are the two properties of Subsystems? Desirable property of Subsystem Decomposition?
• Coupling measures the strength dependencies between two subsystems, whereas Coherence
measures the dependencies among classes within a subsystem. Ideal subsystem
decomposition should minimize coupling and maximize coherence.
• A desirable property of subsystem decomposition is that it leads to subsystems with high
coherence and low coupling.
4. Differentiate between Loosely and Strongly coupled subsystems? Which one is desirable property of
subsystem decomposition?
• Loosely coupled - subsystems are relatively independent; modifications to one of subsystems will
have little impact on the other.
• Strongly coupled - modifications to one subsystem is likely to have impact on the other.
A desirable property of subsystem decomposition is that subsystems are as loosely coupled as
possible.

6
Assosa University Department of Computer Science
5. Why do we need Subsystem Decomposition?
• To reduce the complexity of the solution domain, we decompose a system into simpler parts,
called subsystems.
6. What is a service in Subsystem?
• A service is a set of related operations that share a common purpose.
7. What is the use of Deployment Diagrams?
Deployment Diagrams is used to depict the relationship among run-time components and
hardware nodes.
8. Write System Design Activities.
a. Identify design goals from the nonfunctional requirements - (Reliability, Security, Modifiability etc.)
b. Design initial subsystem decomposition - divide system into manageable pieces to deal with
complexity.
c. Map subsystems to processors and components - (Hardware (Node)/Software (UI, DBMS)
Mapping).
d. Decide storage - Persistent Data Management (DBMS)
e. Define access control policies - Specify who can and cannot access certain data, Security
(Encryption)
f. Select a control flow mechanism - Can System handle more than one user interaction at a time?
g. Identify boundary conditions - How is system initialized, shutdown, how are exceptional cases
detected & handled.
9. Discuss the Design Criteria of Design Goals?
• Performance Criteria (Speed & Space Requirements)
• Dependability Criteria(Robustness, Reliability, Availability, Fault Tolerance, Security, Safety)
• Cost Criteria(Development, Deployment, Upgrade, Maintenance, Administration Costs)
• Maintenance Criteria(Extensibility, Modifiability, Adaptability, Portability, Readability, Traceability
of Requirements)
• End User Criteria(Utility, Usability)
10. What should Software Architecture contain?
• Software Architecture includes System decomposition, global control flow, error-handling policies
and intersubsystem communication protocols.
11. Briefly discuss some Software Architectures?
• Repository architecture - subsystems access and modify data from a single data structure called
the central repository (DBMS).
• Model/View/Controller (MVC) - subsystems are classified into three d/t types: model subsystems
which maintain domain knowledge, view subsystems which display it to user, and controller
subsystems which manage sequence of interactions with user.
• Client/server architecture -a subsystem, server, provides services to instances of other
subsystems called clients, which are responsible for interacting with user. The request for a
service is usually done via a RPC, RMI CORBA.
• Peer-to-peer architecture - subsystems can act both as client and as servers.

7
Assosa University Department of Computer Science
• Pipe and filter architecture- subsystems process data received from a set of inputs and send
results to other subsystems via a set of outputs. The subsystems are called filters, and
associations between subsystems are called pipes. (E.g. Unix Shell)

12. What is the goal of reviewing System Design?

To ensure that system design model is correct, complete, consistent, realistic, and readable.
• Correct if the analysis model can be mapped to the system design model.
• Complete if every requirement and every system design issue has been addressed.
• Consistent if it does not contain any contradictions.
• Realistic if the corresponding system can be implemented.
• Readable if developers not involved in the system design can understand the model.
13. Describe Parts of System Design Document.
1. Introduction - provide a brief overview of the software architecture and design goals, references
to other documents and traceability information (e.g., related requirements analysis document,
references to existing systems, constraints impacting the software architecture).
2. Current software architecture - describes architecture of the system being replaced. If no previous
system, survey current architectures for similar systems. The purpose of this section is to make
explicit the background information that system architects used, their assumptions, and common
issues the new system will address.
3. Proposed System Architecture - documents the system design model of the new system.
3.1. Overview presents a bird’s eye view of the software architecture and briefly describes the
assignment of functionality to each subsystem.
3.2. Subsystem decomposition - describes the decomposition into subsystems and the
responsibilities of each. This is the main product of system design.
3.3. Hardware/Software Mapping - describes how subsystems are assigned to hardware and
off-the-shelf components. Lists the issues introduced by multiple nodes and software
reuse.
3.4. Persistent Data Management - describes persistent data stored by system and the data
management infrastructure required for it. Typically includes the description of data
schemes, selection of a database, and the description of the encapsulation of database.
3.5. Access Control and Security - describes the user model of the system in terms of an access
matrix. Describes security issues (selection of an authentication mechanism, the use of
encryption, and the management of keys).
3.6. Global Software Control - Describe how requests are initiated and how subsystems
synchronize. List and address synchronization and concurrency issues.
3.7. Boundary Conditions - describes the start-up, shutdown, and error behavior of the system.
3.8. Subsystem Services, describes services provided by each subsystem in terms of
operations.

8
Assosa University Department of Computer Science
Part IV: Software Quality Assurance

1. Differentiate between Debugging and Testing?

• The elimination of the syntactical bug is the process of debugging, whereas the detection and
elimination of the logical bug is the process of testing.
2. What is Scenario-based Testing?
• Scenario-based testing called usage-based testing, concentrates on what user does, not what
product does. This means capturing use cases and the tasks users perform, then performing
them & their variants as tests.
3. Discuss Testing Strategies?
• Black Box Testing - System internal workings/logic is unknown/hidden. Try input and examine
output.
• White Box Testing - System internal workings/logic is tested for errors(bugs) - error based testing
• Top-Down Testing - supports testing the user interface and event-driven systems. Testing
interface navigation.
• Bottom-Up Testing – Starts testing individual objects/details of the system and proceeds to
higher levels.

9
Assosa University Department of Computer Science
Multiple Choice:

1. Which one of the following is not true regarding the two orthogonal views of software?
A. The traditional development techniques view software as a collection of programs (or functions)
and isolated data, i.e. it focuses on the functions of the system.
B. Object Oriented system development approach defines a system as a collection of integrated
objects instead of separating the system into data and functionality.
C. Object Oriented system development approach centers on the object, which combines data and
functionality in to a single object.
D. None of the above.
2. Which one of the following is not true about OOSD (Object-Oriented Systems Development)
Methodology?
A. OOSD is a way to develop software by building self-contained modules or objects that can be
easily replaced, modified, and reused.
B. In OOSD, software is viewed as a collection of discrete objects that encapsulate their data as
well as the functionality to model real-world objects.
C. Object-oriented methods enable to create sets of objects that works together synergistically to
produce software that better model their problem domains.
D. Object-Oriented Systems are easier to adapt to changing requirements, easier to maintain, more
robust, and promote greater de-sign and code reuse.
E. None of the above.
3. Which of the following is the importance of Object-Orientation?
A. Allows higher level of abstraction.
B. Provides seamless transition among different phases of software development.
C. Encourage good development techniques.
D. Promotes reusability.
E. All of the above
4. ________________ is a methodology that combine the best practices, processes, and
guidelines along with UML notations and diagrams for better understanding of OO concepts
and system development.
A. Unified Approach (UA)
B. Software Requirement Specification (SRS)
C. Software Design Description (SDD)
D. Software Coding and Testing

10
Assosa University Department of Computer Science
5. What is Unified Modeling Language (UML)?
A. UML is a set of notations and conventions used to describe and model an application.
B. UML is modeling language or graphical/diagrammatic notation for object-oriented programming.
C. UML is standardized visual modeling language specifically designed for modeling, designing, and
documenting software systems.
D. UML offers comprehensive set of graphical notations and tools, enabling software engineers and
designers to represent and communicate the various aspects of a system in a clear and
standardized manner.
E. All.

6. An Abstraction in Object-Oriented Systems Development refers to:

A. The process of binding or combining attributes and methods in to single entity called object.
B. Hiding unnecessary implementation details and exposing only the essential characteristics and
behaviors of an object or system.
C. The ability to dynamically choose a method at run time (take many forms)
D. The process by which a child or sub-class acquires properties of its parent or super-class
7. An Encapsulation in Object-Oriented Systems Development refers to:
A. The property, state or data of an object
B. The process of binding attributes and methods in to single entity called object.
C. Process by which a class acquires properties of another class
D. Defining methods in super and sub classes with the same signature.
8. A Polymorphism in Object-Oriented Systems Development refers to:
A. Blueprint or prototype or template from which objects are created
B. The ability to dynamically choose a method at run time (method take many forms)
C. Restriction or concealing of external access to attribute or state of an object
D. Instance or occurrence of a class that can be created, modified, or destroyed.
9. Which of the following tool bridges the gap between users and developers?
A. Scenario
B. Participating Objects
C. Usecase
D. A and B
10. Which of the following are errors faced during requirement elicitation?
A. Misleading or unusable user interfaces
B. Missing system functionality
C. Incorrectly specified functionality
D. All

11
Assosa University Department of Computer Science
11. Which Requirement Elicitation Activity deals with observing users and developing a set of
detailed narrative descriptions for typical functionality?
A. Identifying actors
B. Identifying relationships among use cases
C. Identifying scenarios
D. Identifying usecases
12. The most important source of information developers access during Requirements Elicitation
is:
A. Client-supplied documents about the application domain,
B. Manuals and technical documentation of legacy systems that the future system will replace, and,
C. Users and Clients
D. None
13. Which method of eliciting information and making decisions with users and clients involves
validating requirements elicitation model with the user through a variety of methods (feel and
look up of User Interface, Hardware)?
A. Joint Application Design (JAD)
B. Knowledge Analysis of Tasks (KAT)
C. Usability Testing
D. All

14. Which of the following technique is used to elicit requirement?

A. Interview
B. Observation
C. Document Analysis
D. All
15. Specification is said to be _____________ if, once system is built, a repeatable test can be
designed to demonstrate that the system fulfills requirement?
A. Complete
B. Realistic
C. Consistent
D. Verifiable
16. Which of the following analysis model is represented by use cases and scenarios?
A. Functional Model
B. Analysis Object Model
C. Dynamic Model
D. Design Object Model
17. Which of the following Object is used to model the interactions between actors and system?
A. Entity Object
B. Boundary Object
C. Control Object
D. All

12
 Assosa University Department of Computer Science
18. Which of the following Analysis Activity involves Business Logic that coordinate boundary and
entity, as well as identifying one object per Usecase and actor?
A. Identifying entity objects
B. Identifying boundary objects
C. Identifying control objects
D. Mapping use cases to objects
19. In which stage of software development do developers define the design goals of the project
and decompose the system into smaller subsystems that can be realized by individual
teams?
A. Requirement Elicitation
B. System Analysis
C. System Design
D. System Testing
20. Which of the following design goal deals with authentication and authorization of a system?
A. Response Time
B. Throughput
C. Memory
D. Security
21. Which of the following UML Diagram depicts the associations among objects and object
attributes?
A. Usecase Diagram
B. Class Diagram
C. Deployment Diagram
D. Sequence Diagram
22. In multi-level access matrix, how will a system prevent unauthorized accesses?
A. Access Control Policy
B. Subsystem Decomposition
C. Boundary Conditions
D. Control Flow Mechanism
23. Which of the following is maintenance criteria of design goal that deals with how easy it is to
change functionality of a system?
A. Extensibility
B. Portability
C. Modifiability
D. Traceability

13