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:
- 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͘
- 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.
- 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
- 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.
- 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.
- 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.
- 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:
- 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.
- 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
