Software Engineering and Project Management

Module 2 Answers
1 Explain Requirements Engineering with suitable points
Requirements Engineering:
The broad spectrum of tasks and techniques that lead to an understanding of requirements is called
requirements engineering. From a software process perspective, requirements engineering is a major
software engineering action that begins during the communication activity and continues into the modelling
activity. It must be adapted to the needs of the process, the project, the product, and the people doing the
work.

Inception: At project inception, you establish a basic understanding of the problem, the people who want a
solution, the nature of the solution that is desired, and the effectiveness of preliminary communication and
collaboration between the other stakeholders and the software team

Elicitation: It certainly seems simple enough—ask the customer, the users, and others what the objectives
for the system or product are, what is to be accomplished, how the system or product fits into the needs of
the business, and finally, how the system or product is to be used on a day to-day basis.
 Problems of scope. The boundary of the system is ill-defined or the customers/users specify
unnecessary technical detail that may confuse, rather than clarify, overall system objectives
 Problems of understanding. The customers/users are not completely sure of what is needed, have
a poor understanding of the capabilities and limitations of their computing environment, don’t have
a full understanding of the problem domain, have trouble communicating needs to the system
engineer, omit information that is believed to be “obvious,” specify requirements that conflict with
the needs of other customers/users, or specify requirements that are ambiguous or untestable.
 Problems of volatility. The requirements change over time. To help overcome these problems, you
must approach requirements gathering in an organized manner.
Elaboration: The information obtained from the customer during inception and elicitation is expanded and refined
during elaboration. This task focuses on developing a refined requirements model that identifies various aspects of
software function, behaviour, and information. Elaboration is driven by the creation and refinement of user scenarios
that describe how the end user (and other actors) will interact with the system. Each user scenario is parsed to
extract analysis classes—business domain entities that are visible to the end user.

Negotiation: In negotiation, when customers and users have different needs, they talk together to find a way to meet
those needs. They list and rank what’s most important to them, then discuss back and forth to resolve any
disagreements. They consider how much things will cost and any potential risks. Through these discussions, they aim
to reach a solution that everyone is happy with. This might mean getting rid of some needs, merging some together,
or changing them so they fit within the available resources and satisfy everyone involved.

Specification: In the context of computer-based systems (and software), the term specification means different
things to different people. A specification can be a written document, a set of graphical models, a formal
mathematical model, a collection of usage scenarios, a prototype.

Validation: Validation in requirements engineering ensures that the outputs of the requirements process meet
quality standards. It involves checking that all software requirements are clearly stated, addressing any
inconsistencies, omissions, or errors found, and ensuring that the work conforms to established standards for the
project, process, and product. Essentially, it's about making sure that what was planned aligns with what has been
developed, and that it meets the necessary criteria for success.

Requirements management: Requirements management is like keeping track of a to-do list that's constantly
changing. It involves a set of activities to help the project team identify, control, and monitor requirements, as well as
any changes to those requirements, throughout the project's lifecycle. It's all about ensuring that everyone stays on
the same page regarding what needs to be done and how it may evolve over time.
2 Give the Sketch of Requirement Engineering process and explain the different stages?

Explanation is same

3 Indicate why requirement validation is needed. Discuss different checks to be carried out during requirement
validation process

As each element of the requirements model is created, it is examined for inconsistency, omissions, and
ambiguity. The requirements represented by the model are prioritized by the stakeholders and grouped
within requirements packages that will be implemented as software increments. A review of the
requirements model addresses the following questions:

• Is each requirement consistent with the overall objectives for the system/product?

• Have all requirements been specified at the proper level of abstraction? That is, do some requirements
provide a level of technical detail that is inappropriate at this stage?

• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the
objective of the system?

• Is each requirement bounded and unambiguous?

• Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for
each requirement?

• Do any requirements conflict with other requirements?

• Is each requirement achievable in the technical environment that will house the system or product?

• Is each requirement testable, once implemented?

• Does the requirements model properly reflect the information, function, and behavior of the system to be
built?

• Has the requirements model been “partitioned” in a way that exposes progressively more detailed
information about the system?

• Have requirements patterns been used to simplify the requirements model? Have all patterns been
properly validated? Are all patterns consistent with customer requirements?

4 With a neat diagram explain Developing Use Case Concept

DEVELOPING USE CASE
a use case depicts the software or system from the end user’s point of view. The first step in writing a use case is to
define the set of “actors” that will be involved in the story. Actors are the different people (or devices) that use the
system or product within the context of the function and behavior that is to be described. Actors represent the roles
that people (or devices) play as the system operates. Defined somewhat more formally, an actor is anything that
communicates with the system or product and that is external to the system itself. Every actor has one or more goals
when using the system. It is important to note that an actor and an end user are not necessarily the same thing. A
typical user may play a number of different roles when using a system, whereas an actor represents a class of external
entities that play just one role in the context of the use case.
Recalling basic Safe Home requirements, we define four actors: homeowner (a user), setup manager (likely the same
person as homeowner, but playing a different role),sensors (devices attached to the system), and the monitoring and
response subsystem (the central station that monitors the Safe Home home security function). For the purposes of this
example, we consider only the homeowner actor. The homeowner actor interacts with the home security function in a
number of different ways using either the alarm control panel or a PC:

• Enters a password to allow all other interactions.

• Inquires about the status of a security zone.

• Inquires about the status of a sensor.

• Presses the panic button in an emergency.

• Activates/deactivates the security system

Fig 3.1: Safe Home control pane

Considering the situation in which the homeowner uses the control panel, the basic use case for system
activation follows.
 1.The homeowner observes the Safe Home control panel to determine if the system is ready for input. If the
system is not ready, a not ready message is displayed on the LCD display, and the homeowner must physically close
windows or doors so that the not ready message disappears.
2. The homeowner uses the keypad to key in a four-digit password. The password is compared with the
valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for
additional input. If the password is correct, the control panel awaits further action.

3. The homeowner selects and keys in stay or away to activate the system. Stay activates only
perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors.

4. When activation occurs, a red alarm light can be observed by the homeowner.

The basic use case presents a high-level story that describes the interaction between the actor and the system
Use case: Initiate Monitoring

Primary actor: Homeowner.

Goal in context: To set the system to monitor sensors when the homeowner leaves the house or remains
inside.
Preconditions: System has been programmed for a password and to recognize various sensors.

Trigger: The homeowner decides to “set” the system, i.e., to turn on the alarm functions. Scenario:
1. Homeowner: observes control panel

2. Homeowner: enters password

3. Homeowner: selects “stay” or “away”

4. Homeowner: observes read alarm light to indicate that SafeHome has been armed
Exceptions:

1. Control panel is not ready: homeowner checks all sensors to determine which are open; closes them.

2. Password is incorrect (control panel beeps once): homeowner reenters correct password.

3. Password not recognized: monitoring and response subsystem must be contacted to reprogram
password.

4. Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated.

5. Away is selected: control panel beeps three times and an away light is lit; all sensors are activated.

Priority: Essential, must be implemented

When available: First increment

Frequency of use: Many times, per day

Channel to actor: Via control panel interface

Secondary actors: Support technician, sensors

Channels to secondary actors: Support technician: phone line Sensors: hardwired and radio frequency
interfaces
Open issues:
 1. Should there be a way to activate the system without the use of a password or with an abbreviated
password?

2. Should the control panel display additional text messages?

3. How much time does the homeowner have to enter the password from the time the first key is
pressed?

4. Is there a way to deactivate the system before it actually activates?

Use cases for other homeowner interactions would be developed in a similar manner. It is important to review
each use case with care. If some element of the interaction is ambiguous, it is likely that a review of the use case will
indicate a problem.

Fig 3.2: UML use case diagram for Safe Home security function

5 With a neat diagram explain UML activity diagrams for eliciting requirement

https://youtu.be/LyhTDsjjjrE?feature=shared

6 With neat diagram Explain Requirement Elicitation and Analysis process.

Eliciting requirements is a crucial aspect of software development, involving problem-solving, negotiation, and
collaboration among stakeholders to identify and specify solution requirements. Here are some key points about
requirements elicitation:

1. Collaborative Approach: Stakeholders, including software engineers, work together to identify problems, propose
solutions, negotiate approaches, and specify preliminary solution requirements.

2. Basic Guidelines: Various approaches exist for collaborative requirements gathering, but they typically involve
conducting meetings attended by stakeholders and establishing rules for preparation and participation. An agenda is
suggested to cover important points while encouraging the free flow of ideas, with a facilitator controlling the
meeting and a definition mechanism (e.g., worksheets, flip charts, electronic platforms) used to capture information.
3. Quality Function Deployment (QFD): QFD is a quality management technique translating customer needs into
technical requirements. It emphasizes understanding customer values and deploying them throughout the
engineering process. QFD identifies three types of requirements:

- Normal requirements: Stated objectives and goals essential for customer satisfaction.

- Expected requirements: Fundamental to the product or system, their absence leads to dissatisfaction.

- Exciting requirements: Features beyond expectations that provide significant satisfaction.

4. Usage Scenarios: Developers and users create scenarios to understand how system functions and features will be
used by different end users, providing insight into system usage under various conditions.

5. Elicitation Work Products: Work products produced during requirements elicitation may include:

- Statement of need and feasibility.

- Bounded statement of scope for the system or product.

- List of participating stakeholders.

- Description of the system's technical environment.

- List of requirements and domain constraints.

- Set of usage scenarios.

- Prototypes developed to refine requirements.

These practices ensure that requirements are effectively gathered, understood, and specified to guide the software
development process accurately.

7 Explain Requirement Modelling

The requirements modelling action results in one or more of the following types of models:

The requirements model must achieve three primary objectives:

(1) to describe what the customer requires,

(2) to establish a basis for the creation of a software design, and

(3) to define a set of requirements that can be validated once the software is built.
Analysis Rules of Thumb:

1. Focus on Visible Requirements: The model should concentrate on requirements that are apparent within
the problem or business domain.

2. Enhance Overall Understanding: Each element of the requirements model should contribute to a
comprehensive understanding of software requirements, shedding light on the information domain,
function, and behaviour of the system.

3. Delay Non-functional Considerations: Postpone consideration of infrastructure and nonfunctional aspects

until the design phase. While acknowledging their necessity, avoid detailing infrastructure-related elements
until after completing problem domain analysis.

4. Minimize Coupling: Strive to minimize coupling throughout the system. Although relationships between
classes and functions are important, high levels of interconnectedness should be reduced to enhance
system modularity.

5. Provide Value to Stakeholders: Ensure that the requirements model delivers value to all stakeholders.
Different stakeholders utilize the model for various purposes, such as validation, design basis, and planning
acceptance tests.

6. Keep it Simple: Maintain simplicity in the model. Avoid creating unnecessary diagrams or using complex
notations when a simpler approach suffices.

Domain Analysis:

Domain analysis involves surveying sources of domain knowledge to identify reusable objects across the
domain. It illustrates key inputs and outputs for the domain analysis process.

Requirements Modelling Approaches:

1. Structured Analysis: This approach considers data and processes as separate entities. Data objects are
modelled to define their attributes and relationships, while processes manipulating these objects are
modelled to illustrate how they transform data.

2. Object-Oriented Analysis: This approach emphasizes defining classes and their collaboration to fulfil
customer requirements. Classes and their interactions are central to understanding and modelling the
system's behaviour.
8 List and explain elements of Requirement model.

1. Scenario-Based Models: Represent how users interact with the system under various conditions or scenarios. They
focus on capturing user interactions and system responses.

2. Class Models: Represent the structure of the system by defining classes, their attributes, and relationships
between them. They provide a static view of the system's architecture.

3. Behavioural Models: Describe the dynamic behaviour of the system, showing how it responds to different stimuli
or events. Examples include state diagrams, activity diagrams, and sequence diagrams.

4. Flow Models: Depict the flow of data or control within the system. They illustrate how information or processes
move through the system, helping to understand the system's functionality and logic. Examples include data flow
diagrams and control flow diagrams.

9 What is the use of an activity diagram and draw an activity diagram for withdrawing money from a Bank ATM.

An activity diagram is a type of behavioural diagram in UML (Unified Modelling Language) that illustrates the flow of
activities or actions within a system. It depicts the sequence of actions or steps in a process, showing the decision
points, branching, parallel activities, and synchronization.
Here's the use of an activity diagram:
Understanding Processes: Activity diagrams help in visualizing and understanding the workflow or processes
within a system.
Communication: They serve as a communication tool between stakeholders, allowing them to discuss and refine
the workflow.
Modelling Complex Logic: Activity diagrams can model complex business logic or system behaviour, making it
easier to analyse and implement.
Documentation: They can be used as documentation to capture the steps involved in a process for future
reference.
activity diagram for withdrawing money from a Bank ATM

https://youtu.be/LyhTDsjjjrE?feature=shared