0% found this document useful (0 votes)
51 views8 pages

Software Engineering Notes

The document discusses characteristics of good requirements, challenges in requirement elicitation, types of requirements, and activities in software development methodologies like Waterfall, Prototyping, RAD, and Agile. Key points include clear requirements, stakeholder conflicts, functional and non-functional requirements, and core agile principles like frequent delivery and cooperation between business and development.

Uploaded by

mahnoornoor955
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
51 views8 pages

Software Engineering Notes

The document discusses characteristics of good requirements, challenges in requirement elicitation, types of requirements, and activities in software development methodologies like Waterfall, Prototyping, RAD, and Agile. Key points include clear requirements, stakeholder conflicts, functional and non-functional requirements, and core agile principles like frequent delivery and cooperation between business and development.

Uploaded by

mahnoornoor955
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

SOFTWARE ENGINEERING NOTES

LEC # 2

Characteristic of a Good Requirement

The characteristics of a good requirement, as outlined in the document, are as follows:

1. Clear and Unambiguous:

- Standard structure

- Has only one possible interpretation

- Not more than one requirement in one sentence

2. Correct:

- A requirement contributes to a real need

3. Understandable:

- A reader can easily understand the meaning of the requirement

4. Verifiable:

- A requirement can be tested

5. Complete

6. Consistent

7. Traceable
Why is getting good requirements hard?

Getting good requirements is hard due to several factors outlined in the document:

1. Stakeholders don’t know what they really want.

2. Stakeholders express requirements in their own terms.

3. Different stakeholders may have conflicting requirements.

4. Organizational and political factors may influence the system requirements.

5. The requirements change during the RE process. New stakeholders may emerge and the
business environment change.

What are the different types of requirements in software engineering?

The different types of requirements in software engineering are:

1. Functional Requirements (FRs):

- Express function or feature and define what is required

2. Non-functional Requirements (NFRs):

- Define how well, or to what level a solution needs to behave

- Describe solution attributes such as security, reliability, maintainability, availability,


performance, and response time

Some important conceptual questions from this lecture that are possible to be asked in your
university exam are:

1. What are the characteristics of a good requirement in software engineering?

2. Why is it essential for the software engineering team to understand the requirements of a
problem before trying to solve it?

3. What are the challenges in requirement elicitation in software engineering?


4. Explain the relationship between functional and non-functional requirements in software
engineering.

5. Describe the different tasks involved in the requirements engineering process.

6. Explain the difficulties in getting good requirements in software engineering.

7. Provide examples of functional and non-functional requirements in a software system.

8. Discuss the importance of requirements validation in software engineering.

Certainly! Here are conceptual answers to the questions:

1. Characteristics of a good requirement in software engineering include being clear and


unambiguous, correct, understandable, verifiable, complete, consistent, and traceable. These
characteristics ensure that the requirement is well-defined, unambiguous, and can be effectively
tested and validated.

2. It is essential for the software engineering team to understand the requirements of a problem
before trying to solve it because without a clear understanding of the problem, the resulting
software has a high probability of not meeting customer needs. Requirements understanding
establishes a solid base for design and construction.

3. Requirement elicitation in software engineering is challenging due to problems of scope,


understanding, and volatility. Customers may specify unnecessary technical details, have a poor
understanding of their problem domain, or experience changes in requirements over time,
making it difficult to elicit clear and concise requirements.

4. The relationship between functional and non-functional requirements in software engineering


is that functional requirements define what a software system should do, while non-functional
requirements place limitations on how the system will do so. Functional requirements express
functions or features, while non-functional requirements define how well or to what level a
solution needs to behave.

5. The different tasks involved in the requirements engineering process include inception,
elicitation, elaboration, negotiation, specification, and validation. These tasks encompass
activities such as establishing a basic understanding of the problem, drawing out requirements
from stakeholders, creating an analysis model, agreeing on a deliverable system, describing the
requirements formally, and reviewing the requirement specification for errors and
inconsistencies.

6. Difficulties in getting good requirements in software engineering arise from stakeholders not
knowing what they really want, expressing requirements in their own terms, conflicting
requirements from different stakeholders, and changes in requirements over time due to new
stakeholders or evolving business environments.

7. Examples of functional requirements in a software system could include specific actions or


operations that the software must perform, such as validating customers, generating lists, or
restricting access based on user roles. Non-functional requirements could include attributes such
as security, reliability, maintainability, and performance characteristics like response time and
availability.

8. Requirements validation in software engineering is important as it involves a formal technical


review mechanism that looks for errors, ambiguities, inconsistencies, and conflicts in the
requirement specification. This process ensures that the requirements are accurate, complete, and
align with the needs of the stakeholders and the business environment.

LECTURE # 3

What are the main activities in Waterfall Mode?

The main activities in the Waterfall Model are:

1. Plan-driven model

2. Separate and distinct phases of specification and development

3. Linear sequential

4. Use when Requirements are very well known

5. Freeze requirement before development

Advantages of Using a Prototyping Model


The advantages of using a Prototyping model are:

1. Clients find it easier to understand the design of the software with a prototype model.

2. Requirements get clear

3. The development experts who are working on the prototype can also measure if the software is
able to match up to the client’s expectations and make changes accordingly.

4. Risk factors are easily identified very early on and steps to correct these errors are also
possible with the prototype model.

5. Another benefit is that the designers are able to get important feedback earlier in the
development cycle from testers. This saves on unnecessary expenses post launch.

6. Real time tests and constant interaction between the client and the developer helps to forge a
positive relationship between the two.

When should the RAD methodology be used?

The RAD methodology should be used in the following scenarios:

1. When requirements are well understood.

2. When there is a requirement of developing a product in a short span.

3. If there are a large number of developers so that multiple components could be developed
simultaneously.

4. If there is an availability of resources who could gather all requirements at the initial stage.

5. When the project scope is constrained (i.e. goals/ are fixed / freezed).

6. When the RAD enables a development team to create a “fully functional system” within a
very short time (e.g. 60-90 days).

LECTURE # 4

What are the core principles of Agile development?

The core principles of agile development are:

1. Customer satisfaction by early and continuous delivery of valuable software

2. Welcome changing requirements, even in late development


3. Working software is delivered frequently (weeks rather than months)

4. Close, daily cooperation between business people and developers

5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication

7. Working software is the primary measure of progress

8. Sustainable development, able to maintain a constant pace

9. Simplicity—the art of maximizing the amount of work done—is essential

10. Best architectures, requirements, and designs emerge from self-organizing teams

11. Regularly, the team reflects on how to become more effective and adjusts accordingly

What are the advantages of using agile methods in software development?

The advantages of using agile methods in software development are:

1. Self testing in each iteration (small cycle)

2. Production of a product that can ease users to make better decisions in the early stage of
software

3. Quick adaptation of plan and change

4. Less tedious documentation with more focus on development

What are some popular agile software development frameworks?

Some popular agile software development frameworks include:

1. Adaptive software development (ASD)

2. Agile Unified Process (AUP)

3. Disciplined agile delivery

4. Dynamic systems development method (DSDM)

5. Extreme programming (XP)


6. Feature-driven development (FDD)

7. Lean software development

8. Kanban

9. Scrum

10. Scrumban

LECTURE # 5

What is the purpose of UML?

The purpose of UML (Unified Modeling Language) is to provide a standard language for
specifying, visualizing, constructing, and documenting software systems. It is used for business
modeling, communications, and representing different views for users, designers, and analyzers.
UML helps in understanding how software functions and features will be used by different end-
users, and it supports the modeling of intentions and user-visible functions through use cases.

How does UML support different views of a system?

UML supports different views of a system by providing a standard language for specifying,
visualizing, constructing, and documenting software systems. It allows for the representation of
different perspectives, such as business modeling, communications, and user scenarios. UML
also supports the modeling of user-visible functions through use cases, which describe how the
system will be used from the point of view of different actors interacting with the software. This
enables the representation of various aspects of the system from the perspectives of users,
designers, and analyzers.

What is a Use case and how is it related to UML?

A use case is a behavior-oriented analysis of a system that captures user-visible functions and
describes the sequence of events of an actor using a system to complete a process. It is a
narrative documentation that illustrates the activities performed by the users of the system and
the interaction of users with the system in terms of services and functions to achieve a final goal.

In the context of UML, a use case is related to UML as it is a fundamental concept in UML-
based modeling. UML uses use cases to represent the functional requirements of a system and to
describe how external actors interact with the system. Use cases are represented as ovals in UML
diagrams and are used to illustrate the functionality provided by the system. They are an essential
part of the UML-based modeling process for understanding and documenting the behavior of a
system.

LECTURE # 6

What is the purpose of an activity diagram in software engineering?

The purpose of an activity diagram in software engineering is to visualize workflows and


business processes. It provides a clear representation of how different activities or tasks are
organized and flow within a system or process. Additionally, the UML activity diagram can be a
useful alternative or assistant to writing the use case text.

How are different activities represented in an activity diagram?

Different activities are represented in an activity diagram using boxes to show data object flow
and data base/data set/data store. Additionally, objects such as receipt, application, form, etc., are
used as examples within the diagram to represent the activities.

Can an activity diagram be used as an alternative to writing use case text?

Yes, the UML activity diagram can be a useful alternative or assistant to writing the use case
text, as mentioned in the document.

You might also like