Software Engineering & Project Management(21CS61)-2024

Module-2

Understanding Requirements: Requirements Engineering, Establishing the ground work, Eliciting Requirements,
Developing use cases, Building the requirements model, Negotiating Requirements, Validating Requirements

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.

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 EnvironmentDescription: 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
THANK YOU