(a)Requirements analysis and specification (b) Software Design | Software Engineering Notes | Btech
top of page

(a)Requirements analysis and specification (b)Software Design: Software Engineering Class Notes

Updated: Oct 14, 2022

Mobiprep has created last-minute notes for all topics of Software Engineering to help you with the revision of concepts for your university examinations. So let’s get started with the lecture notes on Software Engineering.


7. UML


Our team has curated a list of the most important questions asked in universities such as DU, DTU, VIT, SRM, IP, Pune University, Manipal University, and many more. The questions are created from the previous year's question papers of colleges and universities.


(a)Requirements analysis and specification (b)Software Design


Question 1) State Requirement Elicitation Process

Answer) It is stated as follows:


State Requirement Elicitation Process in software engineering class notes


 

Question 2) Compare relative advantages of the object-oriented and function-oriented approaches to software design.

Answer)

Object-oriented software design

Function-oriented software design

The basic abstractions are not the real-world functions but are the data abstraction where the real world entities are represented.



The basic abstractions, which are given to the user, are real world functions.

Functions are grouped together on the basis of the data they operate since the classes are associated with their methods.



​Functions are grouped together by which a higher-level function is obtained.



In this approach the state information is not represented is not represented in a centralized memory but is implemented or distributed among the objects of the system.



In this approach the state information is often represented in a centralized shared memory.



​It is a bottom up approach.



​It is a top down approach.

​Begins by identifying objects and classes.

Begins by considering the use case diagrams and the scenarios.

​We decompose at class level.



In function-oriented design we decompose in function/procedure level.

​This approach is mainly used for evolving systems which mimics a business or business case.



​This approach is mainly used for computation sensitive application.


 

Question 3) State Software Requirements Characteristics

Answer) A complete Software Requirement Specifications must be:

  • Clear

  • Correct

  • Consistent

  • Coherent

  • Comprehensible

  • Modifiable

  • Verifiable

  • Prioritized

  • Unambiguous

  • Traceable

  • Credible source

 



Question 4) What do you mean by the terms cohesion and coupling in the context of software design?

Answer) Cohesion is the indication of the relationship within a module. The concept of intra-module (or) Cohesion is defined as the degree to which all elements of a module, class, or component work together as a functional unit. Cohesion has many types but usually highly cohesion is good for software.

Coupling is also the indication of the relationships between modules (or) is defined as the degree of interdependence between two or more classes, modules, or components. It is the concept of Inter-module. Tight coupling is bad, and loose coupling is good.


 

Question 5) What is an ADT? What advantages accrue when a software design technique is based on ADTs?

Answer) Abstract data types are an instance of a general principle in software engineering, which goes by many names with slightly different shades of meaning. Here are some of the names that are used for this idea:

  • Abstraction: Omitting or hiding low-level details with a simpler, higher-level idea.

  • Modularity: Dividing a system into components or modules, each of which can be designed, implemented, tested, reasoned about, and reused separately from the rest of the system.

  • Encapsulation: Building walls around a module (a hard shell or capsule) so that the module is responsible for its own internal behavior, and bugs in other parts of the system can’t damage its integrity.

  • Information hiding: Hiding details of a module’s implementation from the rest of the system, so that those details can be changed later without changing the rest of the system.

  • Separation of concerns: Making a feature the responsibility of a single module, rather than spreading it across multiple modules.

Question 6) What is the difference between the functional and the non-functional requirements of a system?

Answer)

Functional Requirements

Non-Functional Requirements

User specifies functional requirements

Technical people will provide the requirements. e.g. Architect, Technical leaders and software developers.

It is mandatory to provide functional requirements.



It is not mandatory to provide non-functional requirements

Easy to capture



Hard to capture



Use case diagrams are used to capture.

Quality attribute is used to capture

End result is Product feature



​End result is Product properties

It is defined at component level.



It is applied to a system as a whole

It focuses on user requirements.


It concentrates on the user's expectation.

It helps you verify the functionality of the software.



It helps you to verify the performance of the software.

Functional Testing like System, Integration, End to End, API testing, etc are done

Non-Functional Testing like Performance, Stress, Usability, Security testing, etc are done.



Test Execution is done before non-functional testing.



After the functional testing



Usually easy to define.



Usually more difficult to define.

Example:

  1. Authentication of a user whenever he/she logs into the system.

  2. System shutdown in case of a cyber-attack.

  3. A Verification email is sent to the user whenever he/she registers for the first time on some software system.



​Example:

  1. Emails should be sent with a latency of no greater than 12 hours from such an activity.

  2. The processing of each request should be done within 10 seconds

  3. The site should load in 3 seconds when the number of simultaneous users are > 10000



 

Question 7) State Software Metrics and Measures.

Answer) Software Metrics provide measures for various aspects of software processes and software products.

According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.”

Let us see some software metrics:

  • Size Metrics -

  • LOC (Lines of Code)

  • Function Point Count

  • Complexity Metrics - McCabe’s Cyclomatic complexity

  • Quality Metrics - Defects, their types and causes, consequence, intensity of severity and their implications.

  • Process Metrics - The company standards and the performance of development are software process metrics.

  • Resource Metrics - Effort, time and various resources used, represents metrics for resource measurement.


 

Question 8) What do you understand by the problems of over specification, forward reference, and noise in an SRS document?

Answer

Over specification

It occurs when the analyst tries to address the "how to" aspects in the SRS document. It limits the imagination of the developers/designers to come up with a good solution.

Forward references

It happens when the analyst refers to the aspects which are discussed much later in the SRS, this causes readability issues in the document.

Noise

Noise refers to the presence of material not directly relevant to the software development process. It is hardly of any use to the software developers and would unnecessarily clutter the SRS document, diverting the attention from the crucial points.





bottom of page