Software Engineering & Project Management(21CS61)-2024

Module-2

Syllabus

Understanding Requirements: Requirements Engineering, Establishing the ground work, Eliciting

Requirements, Developing use cases, Building the requirements model, Negotiating Requirements, Validating
Requirements
Textbook 1: Chapter 5: 5.1 to 5.7
Requirements Modeling Scenarios, Information and Analysis classes: Requirement Analysis, Scenario based
modeling, UML models that supplement the Use Case, Data modeling Concepts class Based Modeling.
Textbook 1: Chapter 6: 6.1 to 6.5

Chapter 5: Understanding Requirements

Requirements Engineering
The process of designing and building
computer software is both challenging and creative.
However, it can also be risky if developers jump into the project
without a clear understanding of the requirements. While some argue that requirements will
become clear as they build and that stakeholders can understand needs only after examining
early iterations, these arguments can lead to project failure.
Requirements engineering, a key software engineering action,
involves a spectrum of tasks and techniques aimed at understanding project needs. It begins
during communication and extends into modeling. This process must be tailored to fit the
needs of the project, product, and people involved.
The bridge of requirements engineering starts either with project
stakeholders defining business needs, user scenarios, and project constraints or with a broader
system definition. Regardless of the starting point, requirements engineering allows for a
comprehensive examination of the project context, specific needs, priorities, and the impact
on design.
Requirements engineering involves tasks such as inception,
elicitation, elaboration, negotiation, specification, validation, and management. These tasks
occur concurrently and are adapted to the project's needs.
Software project inception marks the beginning of a new
project, often triggered by the
identification of a business need or a potential market opportunity.
Stakeholders from the business community define a business case, assess market potential,
conduct feasibility analysis, and outline the project scope. While project details may change,
this information initiates discussions with the software engineering team.
During inception, a basic understanding of the problem,
stakeholders, desired solution, and initial communication effectiveness is established.
 Software Engineering & Project Management(21CS61)-2024

Elicitation involves gathering requirements from stakeholders, including customers and users,
to understand system objectives, business needs, and usage scenarios. Despite its apparent
simplicity, elicitation can be challenging and requires careful communication and
collaboration.
Christel and Kang [Cri92] outline several challenges encountered during requirements
elicitation:
 Scope issues arise when the system boundary is unclear, or customers/users provide
unnecessary technical details that may obscure overall system objectives.
 Understanding problems occur when customers/users are uncertain about their needs,
lack knowledge of their computing environment's capabilities and limitations, have
limited understanding of the problem domain, struggle to communicate with system
engineers, overlook "obvious" information, specify conflicting requirements, or
provide ambiguous or untestable requirements.
 Volatility issues arise when requirements change over time.

Elaboration involves expanding and refining the information gathered from customers during
inception and elicitation. This phase focuses on developing a detailed requirements model
that identifies various aspects of software function, behavior, and information. User scenarios
are created and refined to describe how end users interact with the system, leading to the
 Software Engineering & Project Management(21CS61)-2024

identification of analysis classes representing business domain entities. Attributes and

services required by each class are defined, and relationships between classes are established
through various supplementary diagrams.
Negotiation is essential to reconcile conflicts arising from customers or users requesting more
than can be achieved with limited resources, or proposing conflicting requirements. Through
an iterative process, stakeholders prioritize requirements, discuss conflicts, and work towards
satisfying each party's needs by eliminating, combining, or modifying requirements.
Specification encompasses various forms, including written documents, graphical models,
formal mathematical models, usage scenarios, or prototypes. While some advocate for
standard templates to ensure consistency, flexibility is often necessary based on the system's
size and complexity. Large systems may require detailed written documents with natural
language descriptions and graphical models, while smaller systems may only need usage
scenarios within well-understood technical environments.
Validation ensures that the work products from requirements engineering are of high quality.
During this step, the requirements specification is examined to verify that all requirements are
clearly stated, and any inconsistencies, omissions, or errors are identified and corrected. This
process ensures that the work products adhere to established standards for the process,
project, and product.

The primary mechanism for requirements validation is the technical review. The review team,
consisting of software engineers, customers, users, and other stakeholders, scrutinizes the
specification to identify errors in content or interpretation, clarify ambiguous areas, find
missing information, resolve inconsistencies, address conflicting requirements, and assess the
feasibility of the requirements.
 Software Engineering & Project Management(21CS61)-2024

Requirements management involves activities that help the project team identify, control, and
track requirements and changes to requirements throughout the project's life. These activities
ensure that changes are properly documented, assessed, and implemented. Many of these
activities are similar to software configuration management (SCM) techniques.
Establishing the ground work
In an ideal setting, stakeholders and software engineers work closely, but in reality,
customers or end users often have limited technical knowledge, conflicting opinions, and
restricted availability. The following sections discuss the steps needed to establish a solid
understanding of software requirements, ensuring the project progresses successfully.
Identifying Stakeholders
Sommerville and Sawyer define a stakeholder as anyone benefiting directly or indirectly from
the system being developed. Initially, create a list of people contributing to requirements
elicitation, including business managers, product managers, customers, and engineers. This
list will grow as stakeholders are contacted and asked for further recommendations.
Recognizing Multiple Viewpoints
Different stakeholders have varying viewpoints on system requirements: marketing wants
exciting features, business managers focus on budget and timelines, end users seek familiar
and user-friendly features, software engineers focus on underlying infrastructure, and support
engineers prioritize maintainability. Each group contributes to the requirements engineering
process, which may result in conflicting or inconsistent requirements. These should be
categorized to enable decision makers to select a consistent set of system requirements.
 Software Engineering & Project Management(21CS61)-2024

Working toward Collaboration

In software projects with multiple stakeholders, differing opinions on requirements are
common. The requirements engineer's role is to identify agreed-upon requirements and
resolve conflicts or inconsistencies among stakeholders' needs. Successful collaboration
requires stakeholders to work together and with software engineers to achieve a consensus.

Asking the First Questions

Questions asked at the inception of a project should be "context-free" to gain a preliminary
understanding of the problem. Start with questions like:
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
Is there another source for the solution that you need?
These help identify stakeholders, benefits, and alternatives.
Next, ask to understand the problem and customer perceptions:
 How would you characterize “good” output from a
successful solution?
 What problem(s) will this solution address?
 Can you describe the business environment where the
solution will be used?
 Will special performance issues affect the solution?
Finally, focus on the communication process with "meta-
questions":
 Are you the right person to answer these questions?
 Are my questions relevant to the problem?
 Am I asking too many questions?
 Can anyone else provide additional information?
 Should I be asking you anything else?
 Software Engineering & Project Management(21CS61)-2024

These questions initiate communication, but the Q&A format should be used only initially
and replaced by a more interactive elicitation format involving problem solving, negotiation,
and specification.
Eliciting Requirements
Requirements elicitation combines problem solving, elaboration, negotiation, and
specification. Stakeholders collaborate to identify the problem, propose solutions, negotiate
approaches, and specify preliminary requirements.
Various approaches to collaborative requirements gathering exist, each with unique scenarios
but adhering to these basic guidelines:
 Meetings include software engineers and stakeholders.
 Preparation and participation rules are established.
 A flexible agenda encourages idea exchange.
 A facilitator oversees the meeting.
A definition mechanism (like work sheets or electronic forums) is used.
Meeting Preparation and Execution
During project inception, initial meetings define the scope and solution.
This leads to a
"product request" distributed to attendees before a requirements gathering meeting, where a
facilitator, selected beforehand, helps coordinate the session.
SafeHome Example
For example, consider a marketing narrative about SafeHome's home security function,
detailing system features like wireless sensors and automatic emergency calls. Stakeholders
review the product request, make lists of relevant objects, services, constraints, and
performance criteria, and prepare for the meeting.
Meeting Activities
During the meeting, stakeholders present their lists, which are combined and refined through
discussion led by the facilitator. Mini-specifications elaborate on items in the lists, with
further adjustments made based on group input. Issues requiring further resolution are noted
and addressed late
 Software Engineering & Project Management(21CS61)-2024

Quality Function Deployment (QFD)

Quality Function Deployment (QFD) is a technique in quality management aimed at
maximizing customer satisfaction by translating customer needs into technical requirements
for software development. It categorizes requirements into three types:
Normal Requirements: Stated objectives and goals that, when met, satisfy the customer.
Examples include specific system functions and performance levels.
Expected Requirements: Fundamental requirements implicit to the product, whose absence
leads to significant dissatisfaction. Examples include ease of interaction and overall
reliability.
Exciting Requirements: Features that surpass customer expectations and greatly satisfy them.
Examples include unexpected capabilities that enhance user experience.
Applying QFD in Requirements Elicitation
QFD techniques, though applicable across the software process, are particularly relevant in
requirements elicitation. They utilize customer interviews, observation, surveys, and
historical data to gather raw requirements data. These data are then organized into a customer
voice table, which is reviewed with stakeholders. Various diagrams, matrices, and evaluation
methods are employed to extract and derive expected and exciting requirements.
 Software Engineering & Project Management(21CS61)-2024

Usage Scenarios (Use Cases)

Usage scenarios, commonly known as use cases, play a crucial role in understanding how
system functions and features will be utilized by various end users. They provide detailed
descriptions of how the system will be used in real-world situations, allowing developers and
users to visualize the system's functionality.
Importance of Usage Scenarios
Vision Clarity: Usage scenarios help clarify the overall vision of system functions and
features, making it easier to proceed with technical software engineering activities.
User-Centered Design: By focusing on how different classes of end users will interact with
the system, usage scenarios facilitate user-centered design, ensuring that the system meets the
needs and expectations of its users.
Concrete Understanding: They provide a concrete understanding of the system's behavior in
various situations, guiding the development process and helping prioritize features based on
user requirements.
Creating Usage Scenarios
Collaborative Approach: Developers and users collaborate to create scenarios that accurately
represent real-world usage.
Detailed Descriptions: Scenarios include detailed descriptions of user interactions with the
system, specifying inputs, outputs, and expected behaviors.
Use Case Modeling: Use case modeling techniques, such as UML diagrams, can be employed
to visualize and document usage scenarios effectively.
 Software Engineering & Project Management(21CS61)-2024

Elicitation Work Products

The work products resulting from requirements elicitation vary based on the system's size and
complexity. Typically, they include:
Statement of Need and Feasibility: Outlining the purpose and viability of the system or
product.
Scope Definition: Clearly defining the boundaries and objectives of the system or product.
Stakeholder List: Identifying all stakeholders who participated in the elicitation process.
Technical Environment Description: Detailing the system's technical context
and infrastructure.
Requirements List: Enumerating functional requirements and associated domain constraints.
Usage Scenarios: Describing scenarios that illustrate the system's usage under different
conditions.
Prototypes: Any developed prototypes aimed at refining and validating requirements.
Each work product undergoes thorough review by all involved stakeholders to ensure
alignment and completeness.
Developing use cases
Use Case and Actor Identification
The first step in writing a use case involves defining the "actors" involved in the scenario.
Actors represent external entities that interact with the system and have specific goals. While
users may play multiple roles, actors typically represent single roles within a use case. Once
actors are identified, use cases can be developed to describe the interactions between the
actors and the system. Each use case answers key questions about the actor's goals, system
preconditions, tasks performed, exceptions, and desired system information. For instance,
in
the SafeHome security system, actors like the homeowner interact with the system through
actions such as system activation via the control panel. The use case scenario outlines the
sequence of actions performed by the actor, such as observing the control panel, entering a
password, and selecting system activation modes like "stay" or "away". This high-level story
 Software Engineering & Project Management(21CS61)-2024

can then be further elaborated to provide more detailed descriptions using a template like
Cockburn's, which includes elements such as preconditions, triggers, scenarios, exceptions,
priority, and availability.
Each use case should be reviewed meticulously to identify any ambiguities or potential issues
in the interaction process. Ambiguities may indicate underlying problems that need to be
addressed. For instance, questions such as whether there should be alternative methods to
activate the system without a password or if the control panel should display additional
messages need careful consideration. Similarly, issues like the duration allowed for entering
the password or the possibility of deactivating the system before activation require thorough
examination. This scrutiny ensures the use cases accurately capture the intended interactions
and functionalities, paving the way for a smoother development process.
 Software Engineering & Project Management(21CS61)-2024

Building the requirements model

The analysis model aims to describe the informational, functional, and behavioral aspects of a
computer-based system. It evolves dynamically as stakeholders gain more insight into their
requirements, making it subject to change. While some elements of the model become stable
over time, providing a foundation for design tasks, others remain volatile, indicating ongoing
uncertainty or evolving needs among stakeholders.
Elements of the Requirements Model
The elements of a requirements model vary based on the chosen analysis modeling method.
However, most models commonly include generic elements. These elements typically
encompass functional requirements, non-functional requirements, use cases, user stories,
system constraints, domain models, data models, interface specifications, and acceptance
 Software Engineering & Project Management(21CS61)-2024

criteria. Employing multiple modes of representation aids in uncovering potential issues and
ensuring comprehensive coverage of the system's requirements.
The requirements model encompasses scenario-based, class-based, behavioral, and flow-
oriented elements to comprehensively describe the system. Scenario-based elements, such as
use cases and activity diagrams, illustrate user interactions and serve as a foundation for other
modeling elements. Class-based elements organize objects into classes, defining their
attributes and behaviors. Behavioral elements, like state diagrams, depict system behavior
and state transitions. Flow-oriented elements describe the transformation of information as it
moves through the system, encompassing input, processing, and output stages.
 Software Engineering & Project Management(21CS61)-2024

Analysis patterns, recurring solutions to common problems within specific application

domains, expedite the development of abstract analysis models by providing reusable
examples and insights into advantages and limitations. Additionally, they aid in transforming
analysis models into design models by suggesting reliable solutions and design patterns.
Stored in repositories and referenced by name in the analysis model, these patterns are easily
accessible for use by requirements engineers, who can search for and apply them as needed.
Negotiating Requirements
In an ideal requirements engineering scenario, tasks like inception, elicitation, and
elaboration would sufficiently define customer requirements for subsequent software
engineering activities. However, in reality, negotiation with stakeholders becomes necessary.
 Software Engineering & Project Management(21CS61)-2024

This negotiation aims to balance functionality, performance, and other system characteristics
against constraints like cost and time-to-market. Successful negotiation seeks a "win-win"
outcome where stakeholders get a satisfying system while the software team works within
realistic budgets and deadlines. Boehm outlines negotiation activities, including identifying
key stakeholders, understanding their "win conditions," and reconciling these into mutually
beneficial conditions for all involved, marking successful progress toward subsequent
software engineering activities.
 Software Engineering & Project Management(21CS61)-2024

Validating Requirements
When reviewing requirements, consider:
 Consistency with system objectives
 Appropriate abstraction level
 Necessity vs. add-on features
 Clarity and boundedness
 Attribution for each requirement
 Potential conflicts
 Achievability in technical environment
 Testability post-implementation
 Reflectiveness of system information, function, and behaviour
 Proper partitioning for detailed information exposure
 Use of requirements patterns and validation.

Chapter 6: Requirements Modeling Scenarios, Information and Analysis classes

Requirement Analysis
Requirements analysis specifies the software's operational characteristics, interfaces with
other system elements, and the constraints it must meet. This process enables the
detailed
elaboration of basic requirements established during the inception, elicitation, and
negotiation phases of requirements engineering.
The requirements modeling action results in one or more of the following types of
models:
 Scenario-based models of requirements from the point of view of various system
“actors”
 Data models that depict the information domain for the problem
 Class-oriented models that represent object-oriented classes (attributes and operations)
and the manner in which classes collaborate to achieve system requirements
 Flow-oriented models that represent the functional elements of the system and how they
transform data as it moves through the system
 Behavioral models that depict how the software behaves as a consequence of external
“events”
These models provide software designers with information for translating requirements into
architectural, interface, and component-level designs, and they allow developers and
customers to assess quality once the software is built. This chapter focuses on scenario-based
 Software Engineering & Project Management(21CS61)-2024

modeling, data modeling, and class modeling, each serving different needs in software
engineering. Additionally, it covers flow-oriented
models, behavioral models, pattern-based modeling,
and WebApp models.
Throughout requirements modeling, the primary
focus is on what the system must do, including user
interactions, manipulated objects, required functions,
exhibited behaviors, defined interfaces, and
applicable constraints. Given uncertainties from
both customers and developers, an iterative approach to requirements analysis and modeling
is favored. The requirements model aims to describe customer needs, establish a basis for
software design, and define a set of requirements for validation post-development, bridging
the gap between system-level descriptions and detailed software design. Notably, elements of
the requirements model must be traceable to the design model, though some overlap between
analysis and design tasks is inevitable.
Analysis Rules of Thumb
Arlow and Neustadt [Arl02] suggest a number of worthwhile rules of thumb that should be
followed when creating the analysis model:
The model should focus on requirements that are visible within the problem or business
domain. The level of abstraction should be relatively high. “Don’t get bogged down in
details” [Arl02] that try to explain how the system will work.
o Each element of the requirements model should add to an overall understanding of
software requirements and provide insight into the information domain, function, and
behavior of the system.
o Delay consideration of infrastructure and other nonfunctional models until design. That
is, a database may be required, but the classes necessary to implement it, the functions
required to access it, and the behavior that will be exhibited as it is used should be
considered only after problem domain analysis has been completed.
o Minimize coupling throughout the system. It is important to represent relationships
between classes and functions. However, if the level of “interconnectedness” is
extremely high, effort should be made to reduce it.
o Be certain that the requirements model provides value to all stakeholders. Each
constituency has its own use for the model. For example, business stakeholders should
use the model to validate requirements; designers should use the model as a basis for
design; QA people should use the model to help plan acceptance tests.
 Software Engineering & Project Management(21CS61)-2024

o Keep the model as simple as it can be. Don’t create additional diagrams when they add
no new information. Don’t use complex notational forms, when a simple list will do
Domain Analysis
In requirements engineering, analysis patterns reoccur across applications within a specific
business domain, expediting the creation of the analysis model and enhancing the use of
design patterns and components. Domain analysis identifies, analyzes, and specifies common
requirements within a domain for reuse across projects, focusing on common problem-
solving elements. This ongoing activity involves recognizing reusable capabilities in objects,
classes, subassemblies, and frameworks applicable to various fields. It aims to discover
reusable analysis patterns and classes by surveying domain knowledge to identify reusable
objects.

Requirements Modeling Approaches

Requirements modeling can follow structured analysis, which separates data and processes,
or object-oriented analysis, which defines classes and their collaborations. The requirements
model in this book combines features of both approaches, though software teams often
 Software Engineering & Project Management(21CS61)-2024

choose one and exclude the other. The best approach depends on what combination of
representations best models software requirements and bridges to design. Elements of the
requirements model include scenario-based (user interactions), class-based (objects and
operations), behavioral (state changes due to external events), and flow-oriented (data
transformations) elements. The specific content of each element may vary by project, and the
software team should use only those elements that add value.

Scenario based modeling

User satisfaction is paramount to the success of a computer-based system, and understanding
user interactions helps in accurately characterizing requirements and building effective
models. Therefore, requirements modeling with UML begins with creating scenarios using
use cases, activity diagrams, and swimlane diagrams.
Creating a Preliminary Use Case
Alistair Cockburn describes a use case as a "contract for behavior," defining how an actor
uses a system to accomplish a goal. A use case captures interactions between information
producers, consumers, and the system. It describes a specific usage scenario from the actor's
perspective, addressing what to write about, how much detail to include, and how to organize
the description. Information from inception and elicitation phases helps identify stakeholders,
define the problem scope, specify operational goals, and outline functional requirements. To
develop use cases, list functions or activities performed by an actor, obtained from system
functions, stakeholder conversations, or activity diagram evaluations.
 Software Engineering & Project Management(21CS61)-2024

For the SafeHome surveillance subsystem, homeowner functions include selecting cameras,
requesting thumbnails, controlling pan and zoom, recording and replaying camera output, and
accessing surveillance via the Internet. Stakeholder discussions further develop use cases,
such as accessing camera surveillance via the Internet to display camera views. In narrative
form, the homeowner logs onto the SafeHome website, selects surveillance, chooses a camera
from a floor plan, and views video output. Alternatively, a structured version lists sequential
actions, including logging in, selecting surveillance, choosing a camera, and viewing video
output. Use cases are initially written informally, then structured for formality if needed.
Refining a Preliminary Use Case
When developing a use case, examining alternative courses of action involves asking
questions about possible actor actions, error conditions, and other behaviors. Secondary
scenarios representing alternative behaviors are created based on these questions. For
example, in the primary scenario, selecting a camera could lead to viewing thumbnail
snapshots or encountering an error if no floor plan is configured. Exceptions are situations
 Software Engineering & Project Management(21CS61)-2024

causing the system to exhibit different behavior, such as failure conditions or alternative actor
choices. Cockburn suggests brainstorming to derive a complete set of exceptions, considering
validation functions, supporting function failures, and system performance issues. Exceptions
noted within a use case should be rationalized based on whether the software can detect and
handle the condition, potentially leading to the development of separate use cases to address
specific conditions.
Writing a Formal Use Case
While informal use cases suffice for many requirements, complex or critical activities may
warrant a formal approach. A formal use case typically includes sections detailing the goal,
precondition, trigger, scenario, and exceptions. Graphical representations, such as use-case
diagrams in UML, can aid comprehension, particularly for intricate scenarios. However,
written descriptions must be clear to avoid ambiguity, and use cases primarily address
functional and behavioral requirements, not nonfunctional ones. Despite limitations, properly
developed use cases offer substantial modeling benefits and are suitable for the majority of
software engineering situations.
 Software Engineering & Project Management(21CS61)-2024

UML models that supplement the Use Case

In situations where a text-based model like a use case may not convey information clearly,
UML graphical models, such as activity diagrams, offer a visual representation of interaction
flow within a scenario. Activity diagrams, similar to flowcharts, depict system functions,
flow of interaction, decision points, and parallel activities, providing additional detail not
explicitly stated in the use case.
Developing an Activity Diagram
 Software Engineering & Project Management(21CS61)-2024

Swimlane Diagrams
Swimlane diagrams, a variation of activity diagrams, allocate responsibilities to actors or
analysis classes vertically, akin to lanes in a swimming pool. In the context of a specific use
case, activities associated with different analysis classes or actors are depicted within
respective swimlanes. This visual representation aids in understanding the flow of activities
and responsibilities among different entities involved in the use case.

Swimlane diagram for Access camera surveillance via the Internet—display camera views
function.
In above Figure, activities associated with analysis classes are placed within respective
swimlanes, such as the Interface class managing prompts for reentry and another view.
However, arrows indicate homeowner actions within their swimlane, illustrating the flow of
interaction. Use cases, along with activity and swimlane diagrams, focus on procedural
aspects, depicting how actors invoke specific functions to fulfill system requirements. Yet,
this procedural view represents only one dimension of a system, as explored in Section 6.4,
which delves into representing data requirements within the information space.
 Software Engineering & Project Management(21CS61)-2024

Data modeling Concepts

For software requirements involving database creation, extension, or interfacing, a data
model may be incorporated into overall requirements modeling. This model, typically
represented by an entity-relationship diagram (ERD), defines data objects, their relationships,
and relevant information for processing within the system. The ERD encompasses all data
objects entered, stored, transformed, and produced by the application.
Data Objects
A data object represents composite information with multiple attributes, such as dimensions
incorporating height, width, and depth. It can encompass various entities like external
entities, occurrences, roles, places, or structures. For instance, a person or a car can be seen as
a data object with attributes defining them. Data objects encapsulate only data, devoid of
operations, and can be represented as tables with attributes as headings and specific instances
in the body.

Data attributes define properties of a data object and can name instances, describe them, or
reference other instances. At least one attribute must be an identifier, such as an ID number
for a car. Attributes are determined by the problem context, with different contexts requiring
different sets of attributes. For example, attributes for a car in a department of motor vehicles
application may differ from those in a manufacturing control software for an automobile
company, which may require additional attributes like interior code and trim package
designator.
 Software Engineering & Project Management(21CS61)-2024

Data objects, like person and car, are related, as illustrated in Figure 6.8a. Understanding
their roles in the software context helps establish relevant object/relationship pairs. For
instance, a person owns a car, and a person is insured to drive a car, defining connections
between person and car. Figure 6.8b visually represents these pairs, with arrows indicating
the directionality of the relationships to reduce ambiguity.

class Based Modeling

Class-based modeling encompasses representing objects, operations, relationships, and
collaborations within a system. It includes elements such as classes, attributes, operations,
CRC models, collaboration diagrams, and packages, each contributing to the comprehensive
representation of the system's structure and behavior.
Identifying Analysis Classes
Identifying analysis classes involves examining usage scenarios and performing a
"grammatical parse" on use cases to underline and record nouns. These nouns are then
categorized as part of the solution space if they're required to implement a solution, or part of
the problem space if they're necessary only to describe a solution. This process helps in
understanding the objects and classes relevant to the software application, which can be
challenging compared to identifying physical objects in a room.
 Software Engineering & Project Management(21CS61)-2024

Analysis classes manifest themselves in one of the following ways:

 External entities (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-based system.
 Things (e.g., reports, displays, letters, signals) that are part of the information domain
for the problem.
 Occurrences or events (e.g., a property transfer or the completion of a series of robot
movements) that occur within the context of system operation.
 Roles (e.g., manager, engineer, salesperson) played by people who interact with the
system.
 Organizational units (e.g., division, group, team) that are relevant to an application.
 Places (e.g., manufacturing floor or loading dock) that establish the context of the
problem and the overall function of the system.
 Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of
objects or related classes of objects
Different taxonomies for class categorization have been proposed in the literature, such as
Budd's classification including producers, consumers, data managers, view or observer
classes, and helper classes. It's crucial to understand what classes or objects should not be—
generally avoiding imperative procedural names. For instance, naming an object
"InvertImage" for a medical imaging system would blur the line between data and operations,
contrary to the principles of object-orientation. Instead, operations like inversion should be
applied to the object Image without creating a separate class for "image inversion." This
emphasizes the need to encapsulate data and operations separately.
 Software Engineering & Project Management(21CS61)-2024

The SafeHome security function oversees system configuration during installation, sensor
monitoring, and homeowner interaction through various interfaces. These functionalities
involve actions like programming sensors, setting a master password, and dialing monitoring
services in case of events. Homeowner interaction occurs via control panels, PCs, or
browsers. Coad and Yourdon propose six selection characteristics to assess potential classes:
retained information, needed services, multiple attributes, common attributes, common
operations, and essential requirements. To be included in the requirements model, a potential
class should meet most of these criteria, with decisions subject to later evaluation and
refinement. Applying these criteria to SafeHome classes aids in identifying relevant objects
for analysis.

It's important to recognize that (1) the list provided isn't exhaustive, requiring additional
classes for a complete model; (2) rejected potential classes may become attributes for
accepted ones (e.g., "number" and "type" for "Sensor," "master password" and "telephone
number" for "System"); and (3) different problem formulations might lead to different
acceptance decisions (e.g., individual passwords or voice print identification for homeowners
could change the acceptance criteria for the "Homeowner" class).
Specifying Attributes
Attributes, integral to a class within the problem context, provide a detailed definition of the
class. They vary depending on the specific application; for instance, attributes for a class like
"Player" differ between a baseball statistics tracking system and a professional baseball
pension system. To establish meaningful attributes for an analysis class, each use case should
be examined to determine what elements are relevant. For example, in the SafeHome System
 Software Engineering & Project Management(21CS61)-2024

class, attributes encompass sensor information, alarm response details, activation/deactivation

data, and identification information. Sensor objects, although part of the SafeHome system,
are not listed as attributes because they are already defined as a separate class and multiple
instances may be associated with the System class.

Operations define object behavior and typically manipulate data, perform computations,
inquire about object state, or monitor events. Derived from studying processing narratives or
use cases, operations are identified by isolating verbs, such as "assign" for the Sensor class or
"program" for the System class in the SafeHome security system. Operations may involve
suboperations for detailed configuration tasks, like specifying phone numbers or setting
system characteristics. Additionally, understanding object communication aids in identifying
operations, as objects exchange messages to interact.
 Software Engineering & Project Management(21CS61)-2024

CRC modeling provides a structured approach for identifying and organizing relevant classes
in system requirements. Each class is represented by index cards, detailing responsibilities
and collaborators. Responsibilities encompass attributes and operations, while collaborators
are classes required to fulfill these responsibilities. Classes are categorized into entity,
boundary, and controller classes, each serving distinct roles in the system. Collaborations are
established based on relationships such as is-part-of, has-knowledge-of, and depends-upon.
Reviewing CRC models involves aligning use-case scenarios with class responsibilities,
ensuring the model adequately addresses system requirements.
 Software Engineering & Project Management(21CS61)-2024

Associations and Dependencies

Associations in UML represent relationships between analysis classes, such as the
connections between FloorPlan, Camera, and Wall in a surveillance system. These
associations can be further defined with multiplicity constraints to indicate the number of
objects involved. Dependencies, often depicted with stereotypes, represent client-server
relationships where one class relies on another. For instance, a Camera object providing
video to a DisplayWindow object establishes a dependency association, crucial for system
functionality. Stereotypes like <<access>> can denote special conditions, such as requiring a
password for accessing camera output, ensuring secure system operations.

Analysis Packages
Analysis packages are essential for organizing elements within an analysis model. By
categorizing components like use cases and analysis classes into packages, they can be
grouped logically and given representative names. For instance, in a video game analysis
model, classes may be organized into packages based on their focus, such as environment
elements like Tree and Landscape, character descriptions like Player and SupportingRoles, or
game rules like RulesOfMovement. Each package can contain classes with different
 Software Engineering & Project Management(21CS61)-2024

visibility, denoted by symbols like a plus sign for public visibility. This organizational
structure enhances clarity and accessibility within the analysis model.
Question Bank:
1. Explain the main activities involved in requirements engineering. Why is it important
in software development?
2. Describe the steps involved in establishing the groundwork for requirements
engineering. How does this groundwork benefit the overall project?
3. Discuss three common techniques used for eliciting requirements from stakeholders.
Provide examples for each technique.
4. What is a use case? Explain how use cases are developed with an example.
5. Outline the process of building a requirements model. What are the key components
that should be included?
6. Explain the importance of negotiating requirements in a software project. Describe a
scenario where negotiation might be necessary.
7. Describe the process of validating requirements. What techniques can be used to
ensure that requirements are correctly defined?
8. What is requirement analysis? Discuss its importance and the main activities
involved.
9. Explain scenario-based modeling. How does it help in understanding system
requirements? Provide an example.
10. Identify and describe two UML diagrams that can supplement use cases. How do
these diagrams enhance the understanding of requirements?
11. Explain the concept of data modeling in the context of software engineering. What are
the main elements of a data model?
12. Describe class-based modeling. What are the key components of a class diagram, and
how do they relate to system requirements?

Text Book:
1. Roger S. Pressman: Software Engineering-A Practitioners approach, 7th Edition, Tata
McGraw Hill.

Notes by : Veena Bhat

THANK YOU