SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Module-02

Chapter:-1 - Understanding Requirements

Requirements Engineering

The Challenge of Building Software:

o Software development is engaging and creative but can lead to premature action
without proper understanding of requirements.
o Some developers argue that understanding evolves during the build, stakeholders
understand better with early iterations, and rapid changes make detailed
requirements unnecessary.
o These arguments have elements of truth but can lead to project failure if not
managed properly.

Requirements Engineering:

o A crucial software engineering action starting during the communication activity

and continuing into the modelling activity.
o It builds a bridge to design and construction, originating from stakeholders' needs
or a broader system definition.

Tasks of Requirements Engineering:

o Inception: Establishes a basic understanding of the problem, stakeholders,

desired solution, and preliminary communication and collaboration.
o Elicitation: Involves gathering requirements from customers/users, often
encountering problems of scope, understanding, and volatility.
o Elaboration: Refines and expands the information obtained during inception and
elicitation, developing a detailed requirements model.

P a g e 1 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Negotiation: Reconciles conflicts between different stakeholders’ requirements

through prioritization, cost and risk assessment, and iterative discussions.
o Specification: Documents requirements in various forms, such as written
documents, graphical models, usage scenarios, prototypes, or combinations
thereof.
o Validation: Assesses the quality of requirements to ensure they are unambiguous,
consistent, complete, and conform to standards.
o Requirements Management: Tracks and controls changes to requirements
throughout the project's life, similar to software configuration management.

Inception Stage:

o Projects usually begin from a business need or market opportunity.

o Stakeholders define the business case, market scope, feasibility, and project
scope, initiating discussions with the software engineering team.

Elicitation Stage:

o Challenges include ill-defined system boundaries, misunderstandings about needs,

and evolving requirements.
o An organized approach to requirements gathering is essential.

Elaboration Stage:

o Focuses on developing a refined model that identifies software functions,

behaviours, and information.
o User scenarios are used to extract and define analysis classes and their attributes,
services, relationships, and collaborations.

Negotiation Stage:

P a g e 2 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Resolves conflicts between different stakeholders' requirements through iterative

prioritization and compromise to achieve mutual satisfaction.

Specification Stage:

o Requirements can be documented in various forms, with flexibility depending on

the project size and complexity.
o Consistent presentation of requirements is beneficial for clarity.

Validation Stage:

o Technical reviews are conducted to ensure requirements are clear, complete, and
correct, involving a review team of engineers, customers, users, and stakeholders.

Requirements Management Stage:

o Ongoing activity to manage changes to requirements throughout the project's

lifecycle, involving identification, control, and tracking of changes.

Establishing the ground work

Ideal vs. Real-world Settings:

 In an ideal scenario, stakeholders and software engineers work closely as a single

team.
 Reality often involves geographical separation, vague requirements, conflicting
opinions, limited technical knowledge, and time constraints.

Establishing Groundwork for Requirements:

 It’s crucial to lay a strong foundation for understanding software requirements to

ensure project success.

P a g e 3 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Identifying Stakeholders:

 Defined as anyone who benefits directly or indirectly from the system being
developed.
 Common stakeholders include business managers, product managers, marketing,
internal/external customers, end users, consultants, product engineers, software
engineers, and support/maintenance engineers.
 Begin with an initial list of stakeholders and expand it by asking each stakeholder
for additional contacts.

Recognizing Multiple Viewpoints:

 Different stakeholders have different views and priorities for the system.
 Marketing focuses on marketable features, business managers on budget and
timelines, end users on usability, software engineers on technical infrastructure,
and support engineers on maintainability.
 Collect and categorize stakeholder information to address inconsistencies and
conflicts in requirements.

Working toward Collaboration:

 Collaboration involves stakeholders providing their viewpoints and working

together to resolve conflicts.
 A requirements engineer identifies commonalities and conflicts, facilitating
decision-making.
 A strong project champion often makes final decisions on requirements.

Asking the First Questions:

 Initial questions should be context-free, focusing on identifying stakeholders,

project goals, and benefits:

P a g e 4 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Who is behind the request?

o Who will use the solution?
o What is the economic benefit of the solution?
o Are there alternative sources for the solution?
 Follow-up questions aim to understand the problem and solution context:
o What constitutes good output?
o What problems will the solution address?
o Describe the business environment for the solution.
o Any special performance issues or constraints?
 Meta-questions assess the effectiveness of communication:
o Are you the right person to answer these questions?
o Are your answers official?
o Are my questions relevant?
o Am I asking too many questions?
o Can anyone else provide more information?
o Should I ask anything else?

Moving Beyond Initial Q&A:

 Initial Q&A sessions are useful for the first encounter but should evolve into a
more dynamic format involving problem-solving, negotiation, and specification
for effective requirements elicitation.

Eliciting Requirements

1. Initial Meeting Preparation:

o Attendees: Include both software engineers and stakeholders.
o Rules and Agenda: Establish guidelines for preparation and participation,
ensuring the agenda is formal enough to cover key points but informal enough
to encourage idea exchange.

P a g e 5 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Facilitator: Assign a facilitator to control the meeting.

o Definition Mechanism: Use tools such as worksheets, flip charts, wall
stickers, or electronic platforms (bulletin boards, chat rooms) to organize and
display ideas.
2. Inception Phase:
o Conduct initial Q&A sessions to establish the scope of the problem and overall
perception of a solution.
o Develop a preliminary "product request" document summarizing the project's
aims and initial requirements.
o Distribute the product request to all attendees before the meeting.
3. Requirements Gathering Meeting:
o Before the Meeting:
 Attendees review the product request and prepare lists of objects,
services, constraints, and performance criteria.
o During the Meeting:
 Present individual lists for each topic area.
 Combine lists to eliminate redundancies and add new ideas.
 Engage in discussion to refine and achieve a consensus on the lists of
objects, services, constraints, and performance criteria.
o Post-Meeting:
 Develop mini-specifications for objects or services that need further
elaboration.
 Review and refine mini-specifications with all stakeholders, adding new
requirements as necessary.
 Maintain an issues list for unresolved topics.

Quality Function Deployment (QFD):

P a g e 6 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

QFD translates customer needs into technical requirements, focusing on maximizing

customer satisfaction. It distinguishes three types of requirements:

1. Normal Requirements:
o Objectives and goals explicitly stated by the customer (e.g., specific system
functions, performance levels).
2. Expected Requirements:
o Fundamental requirements implicit to the product (e.g., ease of use,
reliability, installation ease). Absence leads to dissatisfaction.
3. Exciting Requirements:
o Unexpected features that delight customers (e.g., innovative capabilities
like multitouch screens in smartphones).

Usage Scenarios:

Creating scenarios (or use cases) helps to understand how different user classes will use
the system. These scenarios describe the system's functions and features in practical use,
aiding in the transition to technical software engineering activities.

Elicitation Work Products:

The outputs of requirements elicitation vary by project size but typically include:

1. Statement of Need and Feasibility: Clarifies the necessity and practicality of the
project.
2. Bounded Statement of Scope: Defines the system or product's boundaries.
3. List of Participants: Documents the customers, users, and stakeholders involved.
4. Technical Environment Description: Details the system’s operational context.
5. Requirements List: Organized by function, with domain constraints for each
requirement.
6. Usage Scenarios: Provide insights into system use under different conditions.

P a g e 7 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

7. Prototypes: Developed as needed to better define requirements.

Each work product is reviewed by all participants to ensure accuracy and completeness.

Developing use cases

Writing Effective Use Cases

Alistair Cockburn defines a use case as a description of the system's behavior as it

responds to requests from its stakeholders, capturing a contract between the stakeholders
and the system. A use case typically tells a story about how an end user interacts with the
system under specific circumstances.

1. Actors:
o Definition: Actors are entities that interact with the system, playing
specific roles. These can be people or devices.
o Primary Actors: Directly interact with the system to achieve a goal.
o Secondary Actors: Support the system so that primary actors can perform
their roles.
o Example: For a home security system, actors might include the
homeowner, setup manager, sensors, and monitoring subsystem.
2. Identifying Actors:
o Not all actors are identified in the first iteration; primary actors are
identified early, and secondary actors are added as understanding of the
system evolves.
3. Developing Use Cases:
o Questions to Answer:
 Who are the primary and secondary actors?
 What are the actors’ goals?
 What preconditions should exist?
 What tasks or functions do the actors perform?

P a g e 8 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 What exceptions might occur?

 What variations in interactions are possible?
 What information does the actor acquire, produce, or change?
 How does the actor inform the system about changes?
 What information does the actor desire from the system?
 Does the actor need to be informed about unexpected changes?
4. Example Use Case: SafeHome System

Actors:

o Homeowner
o Setup Manager
o Sensors
o Monitoring Subsystem

Homeowner Interactions:

o Entering a password
o Inquiring about the status of security zones and sensors
o Pressing the panic button
o Activating/deactivating the system

Basic Use Case: System Activation

Homeowner checks if the system is ready via the control panel.

Homeowner enters a four-digit password.

Homeowner selects "stay" or "away" to activate the system.

The system confirms activation with a visual indicator.

P a g e 9 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Detailed Use Case: Initiate Monitoring

o Primary Actor: Homeowner

o Goal in Context: To set the system to monitor sensors.
o Preconditions: System programmed with a password and sensor
recognition.
o Trigger: Homeowner decides to activate the system.
o Scenario:
1. Homeowner observes the control panel.
2. Homeowner enters the password.
3. Homeowner selects "stay" or "away".
4. Homeowner sees the alarm light indicating the system is armed.
o Exceptions:
0. System not ready: Homeowner checks and closes all sensors.
1. Incorrect password: Homeowner re-enters the correct password.
2. Password not recognized: Contact support to reprogram.
3. "Stay" selected: Perimeter sensors activated.
4. "Away" selected: All sensors activated.
o Priority: Essential

P a g e 10 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o When Available: First increment

o Frequency of Use: Regular
o Channels to Actor: Via control panel
o Secondary Actors: Support technician, sensors
o Channels to Secondary Actors: Phone line, radio frequency interfaces
o Open Issues:
 Alternate activation methods (e.g., abbreviated password)
 Additional text messages on the control panel
 Time limit for entering the password
 Deactivation options before activation

Use cases should be reviewed meticulously to ensure clarity and completeness.

Ambiguities in the use case can indicate potential problems that need addressing.

Building the requirements model

The Intent of the Analysis Model

P a g e 11 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

The analysis model is designed to provide a comprehensive description of the

informational, functional, and behavioral domains required for a computer-based system.
It evolves as more is learned about the system and as stakeholders refine their
understanding of their needs, serving as a dynamic snapshot of requirements at any given
time. Elements of the model may stabilize over time, forming a solid foundation for
subsequent design tasks, while others may remain volatile, reflecting areas where
stakeholder understanding is still evolving.

Elements of the Requirements Model

There are various ways to represent requirements for a computer-based system, and
different modes of representation can provide different perspectives, helping to uncover
omissions, inconsistencies, and ambiguities. Here are some common elements in most
requirements models:

Scenario-Based Elements

Scenario-based elements describe the system from the user's point of view, often starting
with basic use cases and evolving into more elaborate template-based use cases. These
scenarios serve as input for creating other modeling elements.

Class-Based Elements

Each usage scenario implies a set of objects manipulated by the actor interacting with the
system. These objects are categorized into classes, collections of things with similar
attributes and behaviors. Class diagrams, such as a UML class diagram, depict these
classes and their relationships, showing attributes and operations that can modify these
attributes.

Behavioral Elements

P a g e 12 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

The behavior of a system is critical to its design and implementation. Behavioral

modeling elements, such as state diagrams, depict the system's states and the events that
cause state changes. These diagrams also indicate actions taken as a consequence of
specific events. Behavioural modelling extends to individual classes, detailing their
specific behaviours.

P a g e 13 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Flow-Oriented Elements

Flow-oriented elements model the transformation of information as it moves through the

system. This involves depicting the input, the transformations applied to it, and the output
produced. Flow models can be created for any computer-based system, regardless of size
or complexity.

Analysis Patterns

Analysis patterns are reusable solutions for common problems within a specific
application domain. These patterns provide two main benefits:

1. Speeding up Development: They help develop abstract analysis models that

capture the main requirements of a problem by providing reusable models with
examples and descriptions of their advantages and limitations.
2. Facilitating Transformation: They aid in transforming the analysis model into a
design model by suggesting design patterns and reliable solutions for common
problems.

Analysis patterns are referenced by name within the analysis model and stored in a
repository, making them accessible for reuse by requirements engineers. Information

P a g e 14 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

about an analysis pattern is presented in a standard template, further discussed in detail in

subsequent chapters.

Example: SafeHome System

Actors and Interactions

For the SafeHome system, consider the homeowner actor. The interactions include:

 Entering a password
 Inquiring about the status of security zones and sensors
 Pressing the panic button
 Activating/deactivating the system

Basic Use Case: System Activation

1. Homeowner observes the control panel to ensure the system is ready.

2. Homeowner enters a four-digit password.
3. Homeowner selects "stay" or "away" to activate the system.
4. Homeowner observes a red alarm light indicating system activation.

Detailed Use Case: Initiate Monitoring

 Primary Actor: Homeowner

 Goal in Context: Set the system to monitor sensors.
 Preconditions: System programmed with a password and sensor recognition.
 Trigger: Homeowner decides to activate the system.
 Scenario:
1. Homeowner observes the control panel.
2. Homeowner enters the password.
3. Homeowner selects "stay" or "away".
4. Homeowner sees the alarm light indicating the system is armed.

P a g e 15 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Exceptions:
1. System not ready: Homeowner checks and closes all sensors.
2. Incorrect password: Homeowner re-enters the correct password.
3. Password not recognized: Contact support to reprogram.
4. "Stay" selected: Perimeter sensors activated.
5. "Away" selected: All sensors activated.
 Priority: Essential
 When Available: First increment
 Frequency of Use: Regular
 Channels to Actor: Via control panel
 Secondary Actors: Support technician, sensors
 Channels to Secondary Actors: Phone line, radio frequency interfaces
 Open Issues:
o Alternate activation methods (e.g., abbreviated password)
o Additional text messages on the control panel
o Time limit for entering the password
o Deactivation options before activation

Use cases and other elements should be reviewed thoroughly to ensure clarity and
completeness, as ambiguities can indicate potential problems that need addressing.

Negotiating Requirements

Negotiation in Requirements Engineering

In an ideal scenario, the tasks of inception, elicitation, and elaboration determine

customer requirements in sufficient detail to proceed seamlessly to subsequent software
engineering activities. However, this ideal is rarely achieved. In reality, negotiation with
stakeholders often becomes necessary to balance functionality, performance, and other
product or system characteristics against constraints like cost and time-to-market.

P a g e 16 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Negotiation Goals and Approach

The primary goal of negotiation is to develop a project plan that meets stakeholder needs
while accommodating real-world constraints (e.g., time, budget, and personnel). The best
negotiations aim for a "win-win" outcome, where:

 Stakeholders win by getting a system or product that satisfies the majority of

their needs.
 The software team wins by working within realistic and achievable budgets and
deadlines.

Negotiation Activities

Barry Boehm defines a set of negotiation activities to be conducted at the beginning of

each software process iteration. These activities are designed to ensure effective
stakeholder communication and to reconcile differing priorities and constraints. The
activities include:

1. Identification of Key Stakeholders:

o Identify individuals or groups who have a vested interest in the system or
subsystem being developed.
o Stakeholders typically include end-users, customers, project sponsors,
developers, and possibly regulatory bodies.
2. Determination of Stakeholders' "Win Conditions":
o Understand the specific needs, desires, and success criteria for each
stakeholder.
o Win conditions may include specific functional requirements, performance
targets, budget limits, or deadlines.
3. Negotiation of Win Conditions:
o Reconcile the various win conditions to develop a set of mutually
acceptable goals.

P a g e 17 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Aim to create a scenario where all stakeholders feel their primary needs are
addressed.
o Ensure the negotiated plan is feasible within the given constraints.

Achieving a Win-Win Result

Successful completion of these initial negotiation steps results in a win-win outcome,

which serves as the key criterion for moving forward with subsequent software
engineering activities. Achieving a win-win result involves:

 Clear Communication: Ensure all stakeholders understand each other's priorities

and constraints.
 Compromise and Flexibility: Be prepared to adjust expectations and find middle
ground.
 Focus on Shared Goals: Emphasize the common objectives and benefits to all
parties.

Practical Example: SafeHome System

For instance, in the development of the SafeHome system:

1. Identification of Stakeholders:
o Homeowners (end-users)
o Setup managers (users with administrative roles)
o Monitoring and response subsystem operators
o Development team
o Budget managers
2. Determination of Win Conditions:
o Homeowners: Reliable security system with easy-to-use interface.
o Setup managers: Flexible configuration options.
o Monitoring subsystem: Seamless integration with existing systems.

P a g e 18 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Development team: Clear requirements and achievable deadlines.

o Budget managers: Cost-effective solution within budget.
3. Negotiation of Win Conditions:
o Homeowners may need to compromise on advanced features for a simpler
interface.
o Setup managers may agree to phased implementation of configuration
options.
o The development team may negotiate for extended deadlines for critical
features.
o Budget managers may adjust the budget for essential features, with cost-
saving measures for others.

By addressing these negotiation activities, the project can move forward with a shared
understanding and commitment to the project's success.

Validating Requirements

Reviewing requirements is a critical step to ensure the requirements model accurately

reflects stakeholder needs and provides a solid foundation for design. Here are the key
questions to consider during a requirements review:

1. Consistency with Objectives:

o Is each requirement consistent with the overall objectives for the system or
product?
2. Proper Level of Abstraction:
o Have all requirements been specified at the proper level of abstraction?
o Do some requirements provide a level of technical detail that is
inappropriate at this stage?
3. Necessity:

P a g e 19 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Is the requirement really necessary, or does it represent an add-on feature

that may not be essential to the system's objective?
4. Bounded and Unambiguous:
o Is each requirement bounded and unambiguous?
5. Attribution:
o Does each requirement have attribution?
o Is a source (generally a specific individual) noted for each requirement?
6. Conflict Checking:
o Do any requirements conflict with other requirements?
7. Achievability:
o Is each requirement achievable in the technical environment that will house
the system or product?
8. Testability:
o Is each requirement testable once implemented?
9. Reflection of Information, Function, and Behavior:
o Does the requirements model properly reflect the information, function, and
behavior of the system to be built?
10. Partitioning:
o Has the requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system?
11. Use of Requirements Patterns:
o Have requirements patterns been used to simplify the requirements model?
o Have all patterns been properly validated?
o Are all patterns consistent with customer requirements?

Additional Considerations

 Prioritization and Grouping:

o Have the requirements been prioritized by stakeholders?

P a g e 20 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Are the requirements grouped within requirements packages that will be

implemented as software increments?

By asking these questions, stakeholders and development teams can ensure that the
requirements model is comprehensive, clear, and aligned with the project's goals. This
process helps in identifying potential issues early, thereby reducing the risk of costly
changes later in the development process.

P a g e 21 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Chapter:-2

Requirements Modeling Scenarios, Information and Analysis classes

Requirements Analysis

1. Purpose and Outcome:

o Specifies software’s operational characteristics.
o Indicates software’s interface with other system elements.
o Establishes constraints that software must meet.
2. Tasks Involved:
o Elaborates on basic requirements from inception, elicitation, and
negotiation phases of requirements engineering.

Requirements Modeling Types

1. Scenario-Based Models:
o Focus on requirements from the perspective of various system actors.
2. Data Models:
o Depict the information domain for the problem.
3. Class-Oriented Models:
o Represent object-oriented classes (attributes and operations) and their
collaboration to achieve system requirements.
4. Flow-Oriented Models:
o Represent the functional elements of the system and data transformation.
5. Behavioral Models:
o Depict software behavior in response to external events.

P a g e 22 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Overall Objectives and Philosophy of Requirements Modeling

1. Focus on 'What', Not 'How':

o Identify what user interactions occur.
o Determine what objects the system manipulates.
o Define what functions the system must perform.
o Describe what behaviors the system exhibits.
o Specify what interfaces are defined.
o Establish what constraints apply.
2. Iterative Approach:
o Complete specification of requirements may not be possible initially.
o Customers may be unsure of precise requirements for certain system
aspects.
o Developers may be uncertain if specific approaches will meet function and
performance needs.
o Model what is known and use it as the basis for designing the software
incrementally.
3. Primary Objectives of the Requirements Model:
o Describe Customer Requirements:
 Clearly articulate what the customer needs from the system.
o Establish Basis for Software Design:

P a g e 23 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Provide essential information that guides the creation of the software

design.
o Define Validatable Requirements:
 Outline requirements that can be validated once the software is built.
4. Bridging Analysis and Design:
o The analysis model connects the overall system or business functionality
(achieved through software, hardware, data, human, and other elements) to
a detailed software design.
o The design includes the software’s application architecture, user interface,
and component-level structure.

By adhering to these principles, requirements modeling ensures a thorough understanding

of the system requirements, facilitating effective and efficient software design and
development.

Analysis Rules of Thumb (Arlow and Neustadt)

1. Focus on Visible Requirements:

o Keep the level of abstraction high, avoid unnecessary details.
2. Add to Understanding:
o Each model element should enhance understanding of the requirements.
3. Delay Nonfunctional Considerations:
o Focus on problem domain analysis before addressing infrastructure needs.
4. Minimize Coupling:
o Represent relationships but strive to reduce high levels of
interconnectedness.
5. Provide Stakeholder Value:
o Ensure the model is useful to all stakeholders involved.
6. Simplicity:
o Keep models simple and avoid unnecessary complexity.

P a g e 24 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Domain Analysis

1. Purpose and Importance:

o Recognition of Recurrent Patterns:
 Identify and categorize analysis patterns that often reoccur across
applications within a specific business domain.
o Expedited Model Creation:
 Recognizing and applying these patterns expedites the creation of
the analysis model.
o Improved Time-to-Market and Reduced Costs:
 Increases the likelihood of using design patterns and executable
software components, leading to faster development and lower costs.
2. Domain Analysis Definition (Firesmith):
o Software Domain Analysis:
 Identification, analysis, and specification of common requirements
within a specific application domain for reuse across multiple
projects.
o Object-Oriented Domain Analysis:
 Focuses on identifying, analyzing, and specifying common, reusable
capabilities in terms of common objects, classes, subassemblies, and
frameworks.
3. Application Domains:
o Examples include avionics, banking, multimedia video games, and software
for medical devices.
o The goal is to find or create broadly applicable analysis classes and patterns
for reuse.
4. Ongoing Activity:
o Domain analysis is a continuous software engineering activity, not tied to a
specific project.

P a g e 25 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Role of Domain Analyst:

 Similar to a master toolsmith who designs and builds reusable tools.
 Discover and define reusable analysis patterns and classes for
multiple applications.
5. Inputs and Outputs of Domain Analysis:
o Sources of Domain Knowledge:
 Surveyed to identify objects that can be reused across the domain.
o Outputs:
 Analysis patterns, analysis classes, and related reusable information.

By conducting domain analysis, software engineers can leverage common patterns and
classes across multiple projects, enhancing efficiency and fostering consistency in
software development.

Requirements Modeling Approaches

1. Structured Analysis:

o Data and Process Separation:

 Treats data and the processes that transform it as separate entities.

o Data Object Modeling:

 Defines attributes and relationships of data objects.

o Process Modeling:

P a g e 26 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Shows how processes manipulate data as it flows through the system.

2. Object-Oriented Analysis (OOA):

o Class Definition and Collaboration:

 Focuses on defining classes and how they collaborate to meet customer

requirements.

o Use of UML and Unified Process:

 Predominantly uses object-oriented approaches such as Unified

Modeling Language (UML) and the Unified Process.

3. Combining Approaches:

o The book proposes a model that combines features of both structured and
object-oriented analysis.

o Choosing an Approach:

 Software teams may choose one approach and exclude representations

from the other.

 The choice depends on which combination provides stakeholders with

the best model and the most effective bridge to software design.

4. Elements of the Requirements Model:

o Scenario-Based Elements:

 Depict user interactions with the system and the sequence of activities.

o Class-Based Elements:

P a g e 27 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Model objects the system will manipulate, the operations on these

objects, relationships (including hierarchical), and collaborations
between classes.

o Behavioral Elements:

 Show how external events change the system or class states.

o Flow-Oriented Elements:

 Represent the system as an information transform, showing data

transformation as it flows through system functions.

5. Derivation and Specific Content:

o Analysis modeling leads to the derivation of these modeling elements.

o Project-Specific Content:

 The specific content and diagrams used to construct these elements may
vary from project to project.

o Simplicity Principle:

 Only those modeling elements that add value to the model should be
used to keep the modeling process simple.

By understanding and effectively combining these approaches, software teams can create
comprehensive and useful models that accurately represent system requirements and
provide a solid foundation for design.

P a g e 28 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Scenario based modeling,

Importance of User Satisfaction in Requirements Modeling

 User Satisfaction:
o User satisfaction is the primary measure of a computer-based system or
product's success.
o Understanding end user interactions helps in characterizing requirements
and building effective models.

Requirements Modeling with UML

 Scenarios in Requirements Modeling:

o Begins with creating use cases, activity diagrams, and swimlane diagrams.
o Use cases capture interactions between users (actors) and the system.

Creating a Preliminary Use Case

 Definition by Alistair Cockburn:

P a g e 29 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o A use case is a "contract for behavior," detailing how an actor uses a system
to achieve a goal.
o Captures interactions between information producers/consumers and the
system.

Writing Use Cases

1. What to Write About:

o Derived from inception and elicitation tasks.
o Identify stakeholders, define problem scope, set operational goals, and
outline functional requirements.
2. Developing Use Cases:
o List functions or activities performed by an actor.
o Use lists of required system functions, stakeholder conversations, and
activity diagrams.
3. Example: SafeHome Surveillance System:
o Functions like selecting cameras, viewing thumbnails, controlling cameras,
recording, and accessing via the Internet.
4. Informal Narrative Use Case:
o Written in straightforward language from the actor's point of view.
o Example narrative for accessing camera surveillance via the Internet,
detailing steps and interactions.
5. Sequential Use Case:
o Represents user actions as a sequence of declarative sentences.
o Example sequence for the ACS-DCV function with step-by-step actions.

Refining a Preliminary Use Case

 Secondary Scenarios:

P a g e 30 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Evaluate each primary scenario step for alternative actions, error

conditions, and other behaviors.
o Create secondary scenarios for alternative interactions and error conditions.
 Example of Refinement:
o Identify secondary scenarios like viewing all camera thumbnails or
handling error conditions.

Writing a Formal Use Case

 Formal Use Case Structure:

o Goal in Context: Defines the overall scope.
o Precondition: What is true before the use case starts.
o Trigger: Event or condition that starts the use case.
o Scenario: Specific actions by the actor and system responses.
o Exceptions: Situations uncovered during refinement.
 Graphical Representation:
o Use-case diagrams in UML can help visualize complex scenarios.
o Example: Preliminary use-case diagram for SafeHome, showing various
use cases.

P a g e 31 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Limitations and Benefits of Use Cases

 Limitations:
o Quality depends on the author's clarity.
o Focuses on functional and behavioral requirements, not suitable for
nonfunctional requirements.
o May not be sufficient for detailed and precise requirements, especially in
safety-critical systems.
 Benefits:
o Scenario-based modeling is appropriate for most situations encountered in
software engineering.
o Properly developed use cases provide substantial benefits as a modeling
tool.

UML models that supplement the Use Case

Enhancing Requirements Modeling with UML Graphical Models

Developing an Activity Diagram

 Purpose: Provides a graphical representation of interaction flow within a scenario,

supplementing text-based models like use cases.
 Components:
o Rounded Rectangles: Represent specific system functions.
o Arrows: Indicate the flow through the system.
o Decision Diamonds: Depict branching decisions with labeled arrows.
o Solid Horizontal Lines: Indicate parallel activities.

P a g e 32 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Example: An activity diagram for the ACS-DCV use case (Figure 6.5) shows
details like the limited number of attempts a user has to enter their user ID and
password.

Swimlane Diagrams

Purpose: The UML swimlane diagram is a variation of the activity diagram designed to
represent the flow of activities within a use case while highlighting the responsibilities of
different actors or analysis classes. This is achieved by dividing the diagram into parallel
segments, resembling the lanes in a swimming pool.

P a g e 33 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Structure:

 Parallel Segments (Lanes): Each lane represents a different actor or analysis

class responsible for certain actions within the use case.
 Activity Rectangles: Placed within the lanes, these rectangles depict specific
actions or system functions.
 Arrows: Indicate the flow of activities and the sequence of operations.
 Decision Diamonds: Used to show branching decisions, with arrows leading to
different paths based on conditions.

Example:

 Analysis Classes: Consider three analysis classes—Homeowner, Camera, and

Interface. Each has distinct responsibilities depicted within their respective
swimlanes.
 Interface Class: Responsible for user prompts like "prompt for reentry" and
"prompt for another view." These activities fall within the Interface swimlane.
 Homeowner Actions: Arrows from the Interface swimlane lead back to the
Homeowner swimlane, indicating the homeowner's actions following the prompts.

Context: Swimlane diagrams, like activity diagrams and use cases, are procedurally
oriented. They focus on how various actors invoke specific functions or follow
procedural steps to meet system requirements.

Procedural View vs. Information Space

Procedural View:

 Use Cases: Describe interactions between actors and the system.

 Activity Diagrams: Show the flow of activities within a use case.

P a g e 34 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Swimlane Diagrams: Illustrate responsibilities of different actors or classes along

with the flow of activities.

Information Space:

 Data Requirements: Beyond the procedural view, it's essential to represent and
understand the data requirements of the system.
 Upcoming Sections: Will explore how to model the information space to ensure
comprehensive coverage of all system requirements.

P a g e 35 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Data Modeling for Requirements

Purpose: In software requirements modeling, creating a data model is crucial, especially

when there is a need to interact with a database or handle complex data structures. Data
modeling helps in defining and understanding data objects, their attributes, and their
relationships.

Entity-Relationship Diagram (ERD)

Entity-Relationship Diagram (ERD):

 Purpose: Represents all data objects that are processed within an application and
illustrates the relationships between these objects.
 Components: Data objects, attributes, and relationships.

Data Objects

Definition: A data object is a composite piece of information that is processed within the
system. It consists of multiple attributes.

Types of Data Objects:

1. External Entity: Produces or consumes information.

2. Thing: Example, a report or a display.
3. Occurrence/Event: Example, a telephone call or an alarm.
4. Role: Example, salesperson.
5. Organizational Unit: Example, accounting department.
6. Place: Example, a warehouse.
7. Structure: Example, a file.

Example: A car can be a data object defined by attributes such as make, model, ID
number, body type, color, and owner.

P a g e 36 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Table Representation: Data objects can be represented in a tabular form where:

 Headings: Represent attributes of the data object.

 Body: Represents specific instances of the data object.

Data Attributes

Definition: Properties that define a data object. Attributes can:

1. Name an instance of the data object.

2. Describe the instance.
3. Reference another instance in another table.

Identifier: One or more attributes that serve as keys to uniquely identify an instance of
the data object. For example, the ID number for a car.

Example: For a department of motor vehicles, attributes for the data object car might
include make, model, ID number, body type, color, and owner. For a manufacturing
control software, additional attributes like interior code, drive train type, trim package
designator, and transmission type might be needed.

Relationships

Definition: Connections between data objects that define how they interact or relate to
one another.

P a g e 37 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Example Relationships Between Person and Car:

 Owns: A person owns a car.

 Insured to Drive: A person is insured to drive a car.

Graphical Representation:

 Simple Connection: Shows basic relationship (e.g., person and car are
connected).
 Object/Relationship Pairs: Defines specific relationships (e.g., owns, insured to
drive).
 Directionality: Arrows indicate the direction of the relationship, which helps in
reducing ambiguity.

Class-Based Modeling

1. Definition and Purpose:

o Class-based modeling represents the objects the system manipulates,

operations on those objects, relationships between objects, and
collaborations among classes.

P a g e 38 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o It includes elements such as classes, objects, attributes, operations, CRC

(Class-Responsibility-Collaborator) models, collaboration diagrams, and
packages.

2. Identifying Analysis Classes:

o Start with usage scenarios from the requirements model.

o Perform a grammatical parse on use cases to identify nouns or noun phrases

as potential classes.

o Synonyms should be noted, and classes needed for the solution are part of
the solution space; those needed only for description are in the problem
space.

3. Categories of Analysis Classes:

o External entities: Other systems, devices, people.

o Things: Reports, displays, letters, signals.

o Occurrences/Events: Property transfers, completion of robot movements.

o Roles: Manager, engineer, salesperson.

o Organizational units: Division, group, team.

o Places: Manufacturing floor, loading dock.

o Structures: Sensors, vehicles, computers.

4. Examples and Non-Examples of Classes:

o Classes should not have imperative procedural names.

o Example: An image is a class; image inversion is an operation on the image

class, not a separate class.

P a g e 39 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

5. Applying Selection Characteristics (Coad and Yourdon's guidelines):

o Retained information: Must retain information for system functionality.

o Needed services: Must have identifiable operations that can change its
attributes.

o Multiple attributes: Should have multiple significant attributes.

o Common attributes: Attributes apply to all instances.

o Common operations: Operations apply to all instances.

o Essential requirements: Produce or consume essential information for the

system.

6. Example of Analysis for SafeHome Security Function:

o Grammatical parsing of a narrative identifies potential classes.

o Example classes: Homeowner, sensor, control panel, installation, system,

number, type, master password, telephone number, sensor event, audible
alarm, monitoring service.

7. Selection and Evaluation of Classes:

o Apply selection characteristics to potential classes.

o Example evaluation:

 Accepted: Sensor, control panel, system, sensor event, audible

alarm.

 Rejected: Homeowner, installation, number, type, master password,

telephone number, monitoring service.

8. Notes:

P a g e 40 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o The list of classes is not exhaustive; additional classes may be needed.

o Rejected classes may become attributes of accepted classes.

o Different problem statements may lead to different decisions regarding

class acceptance or rejection.

Specifying Attributes in Class-Based Modeling

1. Purpose of Attributes:
o Attributes define a class and clarify its meaning in the problem space.
o The relevance of attributes depends on the context in which the class is
used.
2. Context-Specific Attributes:
o Attributes for the same class can vary significantly based on the context of
the system.
o Example:
 For a baseball statistics system: name, position, batting average,
fielding percentage, years played, games played.
 For a baseball pension system: average salary, credit toward full
vesting, pension plan options chosen, mailing address.
3. Developing Attributes:
o Study each use case to identify relevant attributes that belong to the class.
o Answer the question: "What data items (composite and/or elementary) fully
define this class in the context of the problem at hand?"
4. Example: SafeHome System Class Attributes:
o Identification Information:
 System ID
 Verification phone number
 System status
o Alarm Response Information:

P a g e 41 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Delay time
 Telephone number
o Activation/Deactivation Information:
 Master password
 Number of allowable tries
 Temporary password
5. Composite Data Items:
o Each composite data item can be further broken down into elementary data
items if needed.
o For practical purposes, composite data items provide a reasonable list of
attributes.
6. Class vs. Attribute:
o Avoid defining an item as an attribute if multiple instances of the item are
associated with the class.
o Example: Sensors are not attributes of the System class but are defined as a
separate Sensor class associated with the System class.

Defining Operations in Class-Based Modeling

1. Purpose of Operations:
o Operations define the behavior of an object.
o They manipulate data, perform computations, inquire about object states, or
monitor for events.
2. Categories of Operations:
o Data manipulation: Adding, deleting, reformatting, selecting data.
o Computation: Performing calculations or processing data.
o State inquiry: Checking or retrieving the state of an object.
o Event monitoring: Watching for specific events to occur.
3. Relationship with Attributes and Associations:

P a g e 42 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Operations work with the class's attributes and associations.

o They require knowledge of these elements to function correctly.
4. Deriving Operations from Use Cases:
o Study processing narratives or use cases to identify relevant operations.
o Use grammatical parsing to isolate verbs, which often indicate operations.
5. Example: SafeHome System Operations:
o From the narrative:
 "Sensor is assigned a number and type" suggests an assign()
operation for the Sensor class.
 "A master password is programmed for arming and disarming the
system" suggests a program () operation for the System class.
 arm() and disarm() operations for the System class.
6. Refining Operations:
o Initial operations might be high-level and can be broken down into more
specific suboperations.
o Example: program() might include suboperations like specifying phone
numbers, configuring system characteristics, and entering passwords.
7. Communication Between Objects:
o Objects interact by passing messages to each other.
o Understanding this communication helps identify additional operations.

P a g e 43 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

By following these guidelines, operations for each class can be effectively identified and
defined, ensuring that the behavior of each object in the system is thoroughly understood
and documented.

Class-Responsibility-Collaborator (CRC) Modeling

CRC modeling is a technique used to identify and organize classes relevant to system or
product requirements. This model is typically represented using index cards, each card
detailing a class, its responsibilities, and its collaborators.

CRC Card Structure

Each CRC card is divided into three sections:

1. Class Name: The name of the class.

2. Responsibilities: Attributes and operations that define what the class knows or
does.
3. Collaborators: Other classes that provide necessary information or actions for the
class to fulfill its responsibilities.

P a g e 44 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Identifying Classes

Classes can be categorized into:

1. Entity Classes: Represent entities derived from the problem statement, e.g.,
FloorPlan, Sensor.
2. Boundary Classes: Interface elements the user interacts with, e.g.,
CameraWindow.
3. Controller Classes: Manage operations from start to finish, e.g., creation or
update of entity objects, complex communication, validation of data.

P a g e 45 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Identifying Responsibilities

Responsibilities are anything a class knows or does, including both attributes and
operations. The following guidelines help in allocating responsibilities:

1. Distribute System Intelligence: Ensure intelligence is evenly distributed across

classes to improve cohesiveness and maintainability.
2. General Responsibilities: State responsibilities generally to allow for high-level
abstraction and reuse.
3. Encapsulation: Keep information and behavior related to it within the same class.
4. Localize Information: Information about one thing should reside within a single
class.
5. Share Responsibilities When Appropriate: Related classes should share
responsibilities when they need to exhibit the same behavior.

Identifying Collaborations

Collaborations represent requests from one class (client) to another (server) to fulfill a
responsibility. These collaborations are necessary when a class cannot fulfill a
responsibility on its own.

P a g e 46 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Three types of relationships help identify collaborators:

1. Is-Part-Of: Aggregate relationships where one class is part of another, e.g.,

PlayerBody is part of Player.
2. Has-Knowledge-Of: One class acquires information from another, e.g.,
ControlPanel determining sensor status from Sensor.
3. Depends-Upon: Classes dependent on each other without direct knowledge,
facilitated by a third class.

Review Process

The CRC model is reviewed through a collaborative process:

1. Distribute CRC Cards: Participants receive a subset of CRC cards, ensuring no

one has collaborating cards.
2. Organize Use-Case Scenarios: Use-case scenarios are categorized.
3. Read Use Case: The review leader reads the use case, passing a token to the
holder of the corresponding class card.
4. Describe Responsibilities: The cardholder describes the responsibilities, verifying
if they satisfy the use-case requirement.

P a g e 47 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

5. Modify Cards: If necessary, define new classes or modify responsibilities and

collaborations on existing cards.

This process ensures the model accurately represents the requirements and guides further
development.

Associations and Dependencies

In UML (Unified Modeling Language), associations and dependencies represent

relationships between classes.

Associations

Definition: Associations are relationships between two or more classes. These

relationships often signify how objects of one class interact or are connected to objects of
another class.

Example: In the context of a floor plan system, a FloorPlan class may be associated with
Camera and Wall classes. Similarly, a Wall class might be associated with WallSegment,
Window, and Door classes.

Multiplicity: Associations can have multiplicity, which defines how many instances of
one class are associated with instances of another class.

Multiplicity Notation:

 1..* indicates one or more instances.

 0..* indicates zero or more instances.

Example of Multiplicity:

 A Wall object can be constructed from one or more WallSegment objects (1..*).

P a g e 48 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 A Wall object may contain zero or more Window objects (0..*) and zero or more
Door objects (0..*).

The relationships and multiplicities can be illustrated in UML diagrams, as shown below:

Dependencies

Definition: Dependencies represent a client-server relationship where one class (the

client) depends on another class (the server) for some functionality or service. A
dependency indicates that a change in the server class may affect the client class.

P a g e 49 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Stereotypes: Dependencies are often defined using stereotypes, which are special
modeling elements with custom-defined semantics. In UML, stereotypes are enclosed in
double angle brackets (e.g., <<stereotype>>).

Example: In the SafeHome surveillance system, a Camera object (server class) provides
video images to a Display Window object (client class). This relationship is more
complex than a simple association and can be represented as a dependency.

Example of Dependency:

 The Display Window depends on the Camera for video images. Additionally,
access to specific camera views may be controlled by a special password.

This can be represented as shown in Figure 6.14: DisplayWindow <<access>> Camera

In this diagram, <<access>> implies that the use of the camera output by the
DisplayWindow is controlled by a special password.

Associations: Represent general relationships between classes and may include

multiplicities to indicate how many instances of one class relate to instances of another.

P a g e 50 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Dependencies: Indicate that one class relies on another, often represented with
stereotypes to provide additional semantics. These relationships are crucial for
understanding the interactions and dependencies within a system.

Analysis Packages

Analysis packages are used in analysis modeling to group related elements, such as use
cases and analysis classes, into categorized units. This organization helps manage
complexity by structuring the model into coherent sections.

Example: Video Game Analysis Packages

Consider a video game analysis model, which consists of numerous classes. These classes
can be categorized into different analysis packages based on their roles and
functionalities within the game.

Categories of Classes:

1. Game Environment:
o Classes that describe the visual scenes and environment elements the user
sees during gameplay.
o Examples: Tree, Landscape, Road, Wall, Bridge, Building, VisualEffect.
2. Game Characters:
o Classes that define the physical features, actions, and constraints of
characters within the game.
o Examples: Player, Protagonist, Antagonist, SupportingRoles.
3. Game Rules:
o Classes that define the rules of the game, including how players navigate
the environment and interact with objects and characters.
o Examples: RulesOfMovement, ConstraintsOnAction.

P a g e 51 | 52
SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Illustration:

Figure 6.15: Analysis Packages for a Video Game

Visibility Symbols

In UML, symbols are used to indicate the visibility of elements within and across
packages:

 Public (+): The element is accessible from other packages.

 Private (-): The element is hidden from other packages.
 Protected (#): The element is accessible only to packages contained within a
given package.

In Figure 6.15, the plus sign (+) before the class names indicates that these classes have
public visibility, meaning they can be accessed from other packages. Other symbols
(minus sign - for private and hash # for protected) are not shown in this figure but are
used similarly to control the visibility of elements.

P a g e 52 | 52