Software Engineering Notes
Software Engineering Notes
LEC # 2
- Standard structure
2. Correct:
3. Understandable:
4. Verifiable:
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:
5. The requirements change during the RE process. New stakeholders may emerge and the
business environment change.
Some important conceptual questions from this lecture that are possible to be asked in your
university exam are:
2. Why is it essential for the software engineering team to understand the requirements of a
problem before trying to solve it?
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.
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.
LECTURE # 3
1. Plan-driven model
3. Linear sequential
1. Clients find it easier to understand the design of the software with a prototype model.
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.
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
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
2. Production of a product that can ease users to make better decisions in the early stage of
software
8. Kanban
9. Scrum
10. Scrumban
LECTURE # 5
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.
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.
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
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.
Yes, the UML activity diagram can be a useful alternative or assistant to writing the use case
text, as mentioned in the document.