Assignment No-2

Q.1]Explain concept of Requirements Engineering?

ANS : Requirements Engineering (RE) is a critical step in the software development life
cycle. It involves defining, documenting, and maintaining the requirements of a software
system1. The process ensures that the software system being developed meets the needs and
expectations of stakeholders2. Here are the key steps involved in Requirements Engineering:

1. Requirements Elicitation: This is the process of gathering information about the needs
and expectations of stakeholders for the software system. Techniques such as interviews,
surveys, and focus groups are used to gather information2.
2. Requirements Analysis: This step involves analyzing the information gathered in the
requirements elicitation step to identify the high-level goals and objectives of the
software system. It also involves identifying any constraints or limitations that may affect
the development of the software system2.
3. Requirements Specification: This step involves documenting the requirements
identified in the analysis step in a clear, consistent, and unambiguous manner. The
requirements are also prioritized and grouped into manageable chunks2.
4. Requirements Validation: This step involves checking that the requirements are
complete, consistent, and accurate. It also involves checking that the requirements are
testable and that they meet the needs and expectations of stakeholders2.
5. Requirements Management: This step involves managing the requirements throughout
the software development life cycle, including tracking and controlling changes, and
ensuring that the requirements are still valid and relevant2.

In summary, Requirements Engineering is a systematic and disciplined approach to

understanding, recording, and managing the demands of stakeholders for a software system2.

Q.2] Explain Usage Scenarios?

ANS : Usage scenarios, also known as use scenarios, describe real-world examples of how
one or more people or organizations interact with a system. They detail the steps, events, and
actions that occur during the interaction1. Here are some key aspects of usage scenarios:
 1. Contextual Stories: Usage scenarios are stories that walk through typical situations
where the user encounters a problem2.
2. Personas and Problems: Usage scenarios, in conjunction with personas, provide
powerful context as they articulate the what, who, why, and when2.
3. Not Solution-Oriented: Usage scenarios do not provide the “how”. It’s not the job of
product management to define how to solve a problem2.
4. Benefits: Usage scenarios can help teams understand users’ problems, develop better
products, and come up with new ideas and solutions2.
5. Development: Product managers usually take the lead in developing usage scenarios, but
they can involve stakeholders from many aspects of the business2.
6. Evolution: The development of usage scenarios is an ongoing task that needs to account
for the evolution of both personas and problems2.

Remember, the goal of usage scenarios is to provide critical context that will set the stage for a
collaborative exploration of the solution. They help your team—designers, developers, analysts,
product owners, and testers—better understand who your users are, what problems they are
trying to solve, and envision how you can help them2.

Q.3]Write a note on: Establishing the Groundwork?

ANS : Establishing the Groundwork in Software Engineering

Establishing the groundwork is a crucial initial step in software engineering. It involves setting
the foundation for understanding software requirements and getting the project started in a way
that will keep it moving toward successful completion1. Here are the key components:

1. Identifying the Stakeholders: Stakeholders are individuals or groups who directly or

indirectly benefit from the system being developed1. They can include business
operations managers, product managers, marketing people, internal and external
customers, end-users, consultants, product engineers, software engineers, and
support/maintenance engineers1.
2. Recognizing Multiple Viewpoints: As there are many different stakeholders, the
system’s requirements will be examined from various perspectives1. Each stakeholder
contributes data to the requirements engineering process, and as information is gathered
from multiple viewpoints, emerging requirements may be inconsistent or contradictory1.
3. Working toward Collaboration: If there are multiple stakeholders involved in a
software project, there may be different opinions on the set of requirements1.
Stakeholders must work together, as well as with software engineering practitioners, to
create a successful system1. A requirements engineer’s job is to identify areas of
commonality as well as areas of conflict or inconsistency1.
4. Asking the First Questions: The first set of questions asked is context-free and focuses
on the customer and other stakeholders, as well as the overall project goals and benefits1.
 These questions aid in identifying all stakeholders who will be interested in the software
being developed1.

By establishing the groundwork, software engineers can ensure that they have a comprehensive
understanding of the project’s requirements, which is essential for the project’s success.

Q.4] Explain Building the Requirements Model?

ANS : Building the Requirements Model in Software Engineering

Building the requirements model is a key step in software engineering. It provides a description
of the informational, functional, and behavioral domains required for a computer-based system1.
The model evolves dynamically as you learn more about the system to be developed and other
stakeholders gain a better understanding of what they actually require1. Here are the main
elements:

1. Scenario-based Elements: A scenario-based approach is used to describe the system

from the user’s perspective. For example, basic use cases and their related use-case
diagrams evolve into more complicated template-based use cases21.
2. Class-based Elements: Each usage scenario involves a collection of objects that are
modified as an actor interacts with the system. These objects are classified as classes— a
collection of things with similar characteristics and behavior21.
3. Behavioral Elements: The behavior of a computer-based system can have a significant
impact on the design and implementation techniques used. As a result, the requirements
model must include modeling elements that represent behavior21.
4. Flow-oriented Elements: As data moves through a computer-based system, it is
transformed. The system accepts input in a variety of formats, transforms it using
functions, and produces output in a variety of forms2.

The goal of building the requirements model is to support the end goals of software
development3. It helps to identify and establish the best practices required to create an effective
model, outline the ways you intend to put said practices into action, and always have alternatives
to improve the overall modeling approach3.

Q.5] Explain Negotiating Requirements and Validating

Requirements?

ANS :
Negotiating Requirements

Negotiating requirements is a crucial step in software engineering. It involves discussions

between various stakeholders to balance functionality, performance, and other product or system
attributes against cost and time-to-market1. The goal of negotiation is to create a project plan that
meets the objectives of stakeholders while also reflecting the real-world restrictions (e.g., time,
personnel, and budget) imposed on the software team1. The successful negotiations aim for a
“win-win” outcome1. Here are the steps involved in negotiating requirements:

1. Identifying the major stakeholders in the system or subsystem1.

2. Establishing the stakeholders’ “win conditions”1.
3. Negotiation of the win conditions of the stakeholders in order to reconcile them into a set
of win-win conditions for all people involved1.

Validating Requirements

Requirements validation is the process of checking that requirements defined for development
define the system that the customer wants2. Each aspect of the requirements model is checked for
consistency, omissions, and ambiguity as it is developed1. The model’s requirements are
prioritized by stakeholders and bundled into requirements packages that will be implemented as
software increments1. Here are the checks performed during requirements validation:

1. Is each requirement aligned with the overall system/product objectives1?

2. Were all requirements expressed at the appropriate level of abstraction1?
3. Is the requirement truly necessary, or is it an optional feature that may or may not be
critical to the system’s goal1?
4. Is each requirement well defined and unambiguous1?
5. Is each requirement attributed? Is there a source noted for each requirement1?
6. Are there any requirements that conflict with others1?
7. Is each requirement attainable in the technical environment in which the system or
product will be housed1?
8. Is each requirement, once implemented, testable1?
9. Does the requirements model accurately represent the information, functionality, and
behavior of the system to be built1?
10. Has the requirements model been “partitioned” in such a way that progressively more
detailed information about the system is exposed1?
11. Have requirements patterns been used to reduce the complexity of the requirements
model1?
12. Have all patterns been validated properly1?
13. Are all patterns in accordance with the requirements of the customers1?

The output of requirements validation is the list of problems and agreed-on actions of detected
problems2. The lists of problems indicate the problem detected during the process of requirement
validation. The list of agreed actions states the corrective action that should be taken to fix the
detected problem2.
Q.6]Drow Use case diagram of Restaurant Management
System?
ANS :

Certainly! A Use Case Diagram in software engineering provides a visual representation of how
users interact with a system. It serves as a blueprint for understanding the functional
requirements of a system from a user’s perspective, aiding in communication between
stakeholders and guiding the development process1.

Here are the key components of a Use Case Diagram:

1. Actors:
o Actors are external entities that interact with the system. These can include users,
other systems, or hardware devices. In the context of a Use Case Diagram, actors
initiate use cases and receive the outcomes.
o Proper identification and understanding of actors are crucial for accurately
modeling system behavior.
2. Use Cases:
o Use cases represent specific things your system can do. They are like scenes in a
play.
o For a restaurant management system, examples of use cases could be:
▪ “Place Order”
▪ “Track Delivery”
▪ “Update Product Information”
o Use cases are represented by ovals.
3. System Boundary:
o The system boundary defines what is inside the system and what is outside. It
helps establish a clear distinction between the elements that are part of the system
and those that are external to it.
 o The boundary is typically represented by a rectangular box that surrounds all the
use cases of the system.
o Its purpose includes:
▪ Scope Definition: Outlining the boundaries of the system, indicating
which components are internal and which are external actors or entities
interacting with the system.
▪ Focus on Relevance: Illustrating essential functionalities provided by the
system without unnecessary details about external entities.
4. Relationships:
o Relationships play a crucial role in depicting interactions between actors and use
cases.
o Key types of relationships include:
▪ Association Relationship: Represents communication or interaction
between an actor and a use case. It is depicted by a line connecting the
actor to the use case.

Remember, a Use Case Diagram provides a high-level view of the system’s functionality and
illustrates how users can interact with it. It’s a powerful tool for system design and
communication among stakeholders1.

If you’d like, I can create a sample Use Case Diagram for a restaurant management system. Let
me know if you’d like me to proceed!