Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

questions for software engineering, Exams of Software Engineering

this will contains all the questons for software engineering

Typology: Exams

2018/2019

Uploaded on 05/16/2019

pratik-kataria-1
pratik-kataria-1 🇮🇳

1 document

1 / 8

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Chameli Devi Group of Instuons
Department of Computer Science and Engineering
Class: Second Semester B.Tech. (CSE)
Subject: Soware Engineering (CS 403)
Session (Jan –June 2018-19)
UNIT II
Q1. Explain Funconal Requirement with an example.
Ans: It should describe all requirement funconality or system services. The customer should
provide statement of service. it should be clear how the system should be reacng to parcular
input and how a parcular system should behave in parcular situaon. Funconal requirement
is heavily depending upon he type of soware expected users and the type of system where the
soware is used. It describes system services in detail.
Example Funconal Requirements for Hotel Management System:
1. Reservaon/Booking
1.. The system shall record reservaons.
2.. 0 3
5 8
The system shall record the customer’s name .
3.. The system shall record the number of occupants.
4.. The system shall record the room number.
5.. The system shall display the room rate.
6.. The system shall record the customer’s phone number
2. Food
2.1. The system shall track all meals purchased in the hotel (restaurant and room
service).
2.2. The system shall record payment and payment type for meals.
3. Management
3.1. The system shall display the hotel occupancy for a specied period of me (days;
including past, present, and future dates).
3.2. The system shall display projected occupancy for a period of me
3.3 The system shall display an excepon report, showing where default room and food
prices have been overridden.
Q2. Explain Non Funconal Requirement with an example.
Ans: Requirements, which are not related to funconal aspect of soware, fall into this
category. They are implicit or expected characteriscs of soware; which users make
pf3
pf4
pf5
pf8

Partial preview of the text

Download questions for software engineering and more Exams Software Engineering in PDF only on Docsity!

Chameli Devi Group of Ins�tu�ons

Department of Computer Science and Engineering

Class: Second Semester B.Tech. (CSE)

Subject: So�ware Engineering (CS 403)

Session (Jan –June 2018-19)

UNIT II

Q1. Explain Func�onal Requirement with an example.

Ans: It should describe all requirement func�onality or system services. The customer should provide statement of service. it should be clear how the system should be reac�ng to par�cular input and how a par�cular system should behave in par�cular situa�on. Func�onal requirement is heavily depending upon he type of so�ware expected users and the type of system where the so�ware is used. It describes system services in detail.

Example Func�onal Requirements for Hotel Management System:

  1. Reserva�on/Booking

1.. The system shall record reserva�ons.

2.. The system shall record the customer’s name0 35 8.

3.. The system shall record the number of occupants.

4.. The system shall record the room number.

5.. The system shall display the room rate.

6.. The system shall record the customer’s phone number͘

  1. Food

2.1. The system shall track all meals purchased in the hotel (restaurant and room service).

2.2. The system shall record payment and payment type for meals.

  1. Management

3.1. The system shall display the hotel occupancy for a specified period of �me (days; including past, present, and future dates).

3.2. The system shall display projected occupancy for a period of �me

3.3 The system shall display an excep�on report, showing where default room and food prices have been overridden.

Q2. Explain Non Func�onal Requirement with an example.

Ans: Requirements, which are not related to func�onal aspect of so�ware, fall into this category. They are implicit or expected characteris�cs of so�ware; which users make

assump�on of. Non -func�onal are more cri�cal than func�onal requirement if the non- func�onal requirement do not meet then the complete system is of no use.

1 The load �me for user interface screens shall take no longer than two seconds.

2 The log in informa�on shall be verified within five seconds.

3 Queries shall return results within five seconds.

4 The Hotel Management System shall be a stand-alone system running in a Windows environment.

5 The system shall be developed using Java pla�orm.

6 There shall be consistency in variable names within the system.

7 The graphical user interface shall have a consistent look and feel.

8 Specify the factors required to establish the required reliability of the so�ware system at �me of delivery.

9 The system shall be available during normal hotel opera�ng hours.

10 Access to the various subsystems will be protected by a user log in screen that requires a user name and password.

Q3. Describe the Characteris�cs of good SRS.

Ans: Characteris�cs of SRS:

  • Correct : Requirement must be correctly men�oned and realis�c by nature.
  • Unambiguous : Transparent and plain SRS must be wri�en.
  • Complete : To make the SRS complete I should be specified what a so�ware designer wants to create on so�ware.
  • Consistent : If there are not conflicts in the specified requirement then SRS is said to be consistent.
  • Stability : The SRS must contain all the essen�al requirement. Each requirement must be clear and explicit.
  • Verifiable : the SRS should be wri�en in such a manner that the requirement that is specified within it must be sa�sfied by the so�ware.
  • Modifiable : It can easily modify according to user requirement.
  • Traceable : If origin of requirement is properly given of the requirement are correctly men�oned then such a requirement is called as traceable requirement.

Q4. Design the Context Level DFD of ATM.

  • The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows the different processing ac�vi�es or func�ons that the system

Q6. Explain the following

**1. Actor 2. Include 3. Extend 4. Generaliza�on

  1. Actor:**
  • An actor represents a set of roles that users of use case play when interac�ng with these use cases.
  • Actors can be human or automated systems.
  • Actors are en��es which require help from the system to perform their task or are needed to execute the system’s func�ons.
  • Actors are not part of the system.
  1. Include
  • The base use case explicitly incorporates the behavior of another use case at a loca�on specified in the base.
  • The included use case never stands alone. It only occurs as a part of some larger base that includes it.
  1. Extend
  • The base use case implicitly incorporates the behavior of another use case at certain points called extension points.
  • The base use case may stand alone, but under certain condi�ons its behavior may be extended by the behavior of another use case.
  1. Generaliza�on
  • Use cases that are specialized versions of other use cases.
  • The child use case inherits the behavior and meaning of the parent use case.
  • The child may add to or override the behavior of its parent.

UNIT III

Q1. Explain Phases in the Design Process.

Ans: The system should be described at several different levels of abstrac�on.Design takes place in overlapping stages. It is ar�ficial to separate it into dis�nct phases but some separa�on is usually necessary

Architectural design

Abstract specificatio n

Interface design

Component design

Data structure design

Algorithm design

System architecture

Software specification

Interface specification

Component specification

Data structure specification

Algorithm specification

Requirements specification

Design activities

Design products

Q2. Draw the class diagram of food order delivary.

Q3. Draw the sequence diagram of ATM.

Q4. Explain Design Concept and its principles.

So�ware design sits at the technical core of so�ware engineering and is applie regardless of the so�ware process model that is used.

The design task produces a data design, an architectural design, an interface design, and a component design.

Data Design

Q5. Define Data Centric architecture with example.

Ans: A data store (e.g., a file or database) resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store. A typical Data-centered style. Clients of the are accesses a central repository. In some cases the data repository is passive. That is, client so�ware accesses the data independent of any changes to the data or the ac�ons of other client so�ware. A varia�on on this approach transforms the repository into a “blackboard” that sends no�fica�ons to client so�ware when data of interest to the client change.

Q6. Explain following:

  1. Cohesion and Coupling

Cohesion is an indica�on of the rela�ve func�onal strength of a module.

  • A cohesive module performs a single task, requiring li�le interac�on with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing.
  • Cohesion is a measure of func�onal strength of a module.
  • A module having high cohesion and low coupling is said to be func�onally independent of other modules. By the term func�onal independence, we mean that a cohesive module performs a single task or func�on.Coupling is an indica�on of the rela�ve interdependence among modules.
  • Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.
  • A module having high cohesion and low coupling is said to be func�onally independent of other modules. If two modules interchange large amounts of data, then they are highly interdependent.
  • The degree of coupling between two modules depends on their interface complexity.
  1. Informa�on Hiding
  • Principle of informa�on hiding says that a good split of modules is when modules communicate with one another with only the informa�on necessary to achieve the s/w func�on.
  • So informa�on hiding enforces access constraints to both
    • procedural detail with a module, and
    • local data structure used by that module.
  • Data hiding is a CRITERION for modular design.
  • How to know what modules to create.
  • Reduces the likelihood of side effects
  • Limits the global impact of local design decisions
  • Emphasizes communica�on through controlled interfaces
  • Discourages the use of global data
  • leads to encapsula�on—an a�ribute of high quality design
  • Results in higher quality so�ware

So�ware Architecture Design Descrip�on (SADD)

o�ware Requirement Analysis (SRS)

So�ware Detailed Design Descrip�on (SDDD)

Forward to architecture

Backward to architecture

Backward from architecture

Forward from architecture