1) Approaches in Requirement Modeling

Requirement modelling is the process of analysing and representing the needs of a software system.
It ensures that all stakeholders clearly understand the system's objectives. Various approaches in
requirement modelling include scenario-based models, class models, behavioural models, and flow
models.

Requirements Modeling Approaches

• One view of requirements modeling, called structured analysis, considers data and the

processes that transform the data as separate entities. Data objects are modeled in a way

that defines their attributes and relationships.

• A second approach to analysis modeling, called object-oriented analysis, focuses on the

definition of classes and the manner in which they collaborate with one another to effect

customer requirements. UML and the Unified Process are predominantly object oriented.

1. Scenario-Based Models

 These focus on user interactions with the system in specific situations, making requirements
relatable and clear.

 Key Techniques:

o Use Cases: Describe the actions a user performs and how the system responds.
 o User Stories: Simple, one-sentence descriptions of user needs (e.g., "As a customer, I
want to track my order status").

 Purpose: To capture functional requirements and ensure the system meets user needs.

2. Class Models

 These represent the objects in the system, their attributes, and their relationships.

 Key Elements:

o Classes: Define entities like "User," "Product," or "Order."

o Relationships: Show how objects are connected, e.g., "User places Order."

 Purpose: To structure and organize data and relationships within the system.

3. Behavioral Models

 These focus on how the system behaves in response to events or over time.

 Key Techniques:

o State Diagrams: Show the states an object can be in and how it transitions between
them.

o Sequence Diagrams: Show the interactions between objects over time.

 Purpose: To understand the dynamic behavior and how the system responds to changes.

4. Flow Models

 These illustrate how data moves through the system. They focus on the input, processing,
and output of information.

 Key Techniques:

o Data Flow Diagrams (DFD): Represent processes, data stores, and data movement.

o Activity Diagrams: Show workflows and decision points.

 Purpose: To analyze processes and identify bottlenecks in information flow

Requirement Elicitation

Requirement elicitation is the process of gathering information from stakeholders to understand

what a software system needs to do. It’s the first step in software development, ensuring the system
meets user needs and expectations.

Key Steps in Requirement Elicitation

1. Identifying Stakeholders

o Stakeholders include users, clients, and anyone involved with the system.

o Example: For an e-commerce website, stakeholders could be customers, delivery

teams, and administrators.

2. Gathering Information

o Use different methods to collect information about the system’s needs and
constraints.

1)Techniques for Requirement Elicitation

1. Interviews

o Talk to stakeholders to understand their needs and expectations.

o Example: Asking users what features they want in a mobile app.

2. Surveys and Questionnaires

o Use forms with specific questions to gather input from many stakeholders.

o Example: Asking users about preferred payment methods.

3. Workshops

o Group discussions to brainstorm and gather requirements collaboratively.

2) Quality function deployment (QFD)

QFD is a quality management technique that translates the needs of the customer into

technical requirements for software. QFD “concentrates on maximizing customer satisfaction from

the software engineering process”. To accomplish this, QFD emphasizes an understanding of what

is valuable to the customer and then deploys these values throughout the engineering process.

QFD identifies three types of requirements:

• Normal requirements. The objectives and goals that are stated for a product or system

during meetings with the customer. If these requirements are present, the customer is
satisfied. Examples of normal requirements might be requested types of graphical displays,

specific system functions, and defined levels of performance.

• Expected requirements. These requirements are implicit to the product or system and may

be so fundamental that the customer does not explicitly state them. Their absence will be a

cause for significant dissatisfaction.

Exciting requirements. These features go beyond the customer’s expectations and prove

to be very satisfying when present.

3) Usage Scenarios: To accomplish this, developers and users can create a set of scenarios that
identify a thread of usage for the system to be constructed. The scenarios, often called use cases,
provide a description of how the system will be used.

4) Elicitation Work Products: A statement of need and feasibility.

• A bounded statement of scope for the system or product.

• A list of customers, users, and other stakeholders who participated in requirements

elicitation.

A Safe Home System is designed to enhance home security by managing devices like cameras,
alarms, and door locks. The preliminary use case diagram provides a basic overview of how users
interact with the system.
 1. Definition of a Preliminary Use Case

o It is an initial draft of how a system will interact with an actor to achieve a specific
goal.

o Captures basic interactions in a straightforward narrative format.

2. Purpose

o To provide an informal overview of system behavior.

o Helps stakeholders and developers understand how the system will meet user needs.

3. What to Write About

o Use initial requirements gathering (e.g., meetings, stakeholder inputs) to identify:

 Actors: Who will interact with the system?

 Functions/Activities: What tasks will they perform using the system?

4. Example Process (SafeHome system example):

o Actor: Homeowner.

o Function: Access camera surveillance via the Internet.

the SafeHomehome surveillance function (subsystem) discussed in the sidebar

identifies the following functions (an abbreviated list) that are performed by the home owner.

Use case: Access camera surveillance via the Internet—display camera views

(ACS-DCV)

Actor: homeowner

1. The homeowner logs onto the SafeHome Products website.

2. The homeowner enters his or her user ID.

3. The homeowner enters two passwords (each at least eight characters in length).

4. The system displays all major function buttons.

5. The homeowner selects the “surveillance” from the major function buttons.

6. The homeowner selects “pick a camera.”

7. The system displays the floor plan of the house.

8. The homeowner selects a camera icon from the floor plan.

9. The homeowner selects the “view” button.

10. The system displays a viewing window that is identified by the camera ID.

11. The system displays video output within the viewing window at one frame per

second.

It is important to note that this sequential presentation does not consider any alterna

tive interactions (the narrative is more free-flowing and did represent a few alterna

tives). Use cases of this type are sometimes referred to as primary scenarios

Definition of Agile Process

An agile process is a framework or methodology designed to focus on delivering high-

quality software through adaptability, collaboration, and iterative progress. It emphasizes
responding to change effectively and values individuals, interactions, and customer
involvement over rigid processes and excessive documentation

Key Principles of Agile

1. Customer Satisfaction: Deliver valuable software early and continuously.

2. Embrace Change: Adapt to changing requirements, even late in development.

3. Frequent Delivery: Release working software frequently, preferring shorter cycles (weeks or
months).

4. Collaboration: Business stakeholders and developers work together daily.

5. Empowered Teams: Build projects around motivated individuals with the resources and trust
they need.

6. Face-to-Face Communication: The most efficient way to share information within the team.

7. Working Software: Progress is measured by functional software, not documentation.

8. Sustainable Pace: Maintain a constant pace for sponsors, developers, and users.

9. Technical Excellence: Focus on quality design and technical practices.

10. Simplicity: Maximize efficiency by prioritizing only essential work.

11. Self-Organizing Teams: Foster innovation through autonomous, collaborative teams.

12. Continuous Improvement: Reflect and adapt processes regularly to enhance team
effectiveness.

Extreme Programming (XP)

Extreme Programming (XP) is an Agile software development methodology that emphasizes

flexibility, collaboration, and customer satisfaction. It focuses on delivering high-quality software
quickly through continuous feedback, frequent releases, and a strong focus on the technical aspects
of development.

1. Planning:

 Customer Stories: Customers define user stories (short descriptions of desired functionality)
that drive the development process. Each story is written on an index card, prioritized based
on business value, and assigned an estimated development cost by the team.
 Story Splitting: Large stories are divided into smaller, manageable parts if their development
cost exceeds three weeks.
 Incremental Delivery: Stories are grouped into releases or increments, with the highest-
priority or riskiest stories developed first.
 Project Velocity: After delivering the first increment, the team calculates project velocity
(number of stories completed) to estimate timelines and adjust commitments for future
releases.

2. Design:

 Simplicity: XP adheres to the "Keep It Simple" (KIS) principle, designing only for the current
increment without adding unnecessary complexity.
 CRC Cards: Class-Responsibility-Collaborator (CRC) cards help identify and organize object-
oriented classes relevant to the increment.
 Spike Solutions: For complex problems, a prototype (spike solution) is created to test and
refine risky designs before full implementation.
 Continuous Refactoring: Design is continuously improved during development to maintain
code simplicity and optimize performance.
 3. Coding:

 Test-Driven Development (TDD): Unit tests are written before coding begins, defining the
required behavior for each story. Code is developed specifically to pass these tests, avoiding
unnecessary features.
 Pair Programming: Two developers work together at one workstation to write code, ensuring
real-time problem-solving, quality assurance, and adherence to coding standards.
 Continuous Integration: Code is integrated frequently (often daily) to detect and resolve
compatibility issues early, ensuring smooth system operation.

4. Testing:

 Automated Unit Tests: Tests created during the coding phase are automated for ease of
execution and consistency in regression testing.
 Acceptance Testing: Delivered increments are validated against customer-provided user
stories to ensure the software meets expectations.

Regression Strategy: Frequent refactoring and incremental delivery encourage

continuous testing to maintain software quality over time.

Steps to Build a Requirement Model

Steps for Building the Requirement Model

To create a robust requirement model, the following steps are taken, incorporating both elements of
the requirement model and analysis patterns:

1. Identify Scenario-Based Elements

 Begin by capturing the system's behavior from the user's perspective.

 Use use cases to represent real-world scenarios.

 Create use-case diagrams to visually map the interactions between actors and the system.

 This step provides an initial framework that serves as input for other modeling elements.

2. Define Class-Based Elements

 Analyze each use case to identify objects manipulated by the actors.

 Categorize these objects into classes based on shared attributes and behaviors.

 Use tools like UML class diagrams to specify:

o Attributes (e.g., name, type).

o Operations that modify these attributes.

  Additionally, define the relationships and collaborations between classes.

3. Model Behavioral Elements

 Represent how the system behaves in different situations.

 Focus on dynamic aspects, such as state changes and event-driven interactions.

 These models provide insights into design and implementation choices.

4. Depict Flow-Oriented Elements

 Map how information flows through the system.

 Identify:

o Inputs (e.g., signals, user inputs, or data files).

o Transformations (e.g., calculations, logic comparisons).

o Outputs (e.g., reports, notifications).

 Develop flow models to describe how data is processed and transformed across components.

5. Integrate Analysis Patterns

 Leverage reusable analysis patterns to speed up model development.

 Identify recurring problems in the application domain and apply corresponding patterns that
offer proven solutions.

 Use patterns to:

o Create abstract models for common problems.

o Suggest design patterns to facilitate the transition from the requirement model to
the design model.

 Store and retrieve patterns from a repository for future use.

Explain steps to be followed for validating requirements
1. Check Consistency with System Objectives
 Verify that each requirement aligns with the overall goals of the system or product.

2. Ensure Proper Level of Abstraction

 Confirm that requirements are specified at an appropriate level of detail, avoiding
technical specifics unsuitable for this stage.

3. Assess Necessity of Each Requirement

 Determine whether each requirement is essential to achieving the system objectives
or if it represents an unnecessary feature.

4. Validate Clarity and Boundaries

 Ensure that each requirement is well-defined, bounded, and free from ambiguity.

5. Verify Attribution
 Confirm that every requirement has a clear source, typically a stakeholder or a
specific individual, attributed to it.

6. Identify and Resolve Conflicts

 Check for any conflicting requirements and resolve inconsistencies to maintain
harmony in the requirements model.

7. Confirm Technical Feasibility

 Ensure that each requirement can be realistically implemented within the technical
environment of the system or product.

8. Test for Implementability

 Verify that each requirement is testable after implementation to assess its
functionality and correctness.

9. Review the Requirements Model

  Confirm that the model accurately reflects the system’s information, functionality,
and behavior.

10. Examine Requirements Partitioning

 Ensure that the model is organized hierarchically, exposing progressively detailed
information about the system.

11. Use and Validate Patterns

 Incorporate requirements patterns where applicable to simplify the model.
 Validate each pattern for consistency with customer needs and requirements.

By addressing these steps, the requirements model is validated to be accurate, complete,

and aligned with stakeholder expectations, forming a robust foundation for subsequent
design and implementation phases.

Swimlane diagram for Access camera surveillance via the Internet—display camera views
function
Narrate the core principles can be applied to the framework in all software process.

Core Principles of Software Process:

These principles guide the software process, ensuring quality and adaptability across all
process models, whether prescriptive or agile. They serve as a foundation for effective
software engineering practices.

1. Be Agile

Adopt the principles of agility regardless of the process model. Focus on:

 Keeping technical approaches and work products as simple and concise as possible.
  Making decisions locally to ensure efficiency and responsiveness to change.
Agility emphasizes economy of action and adaptability, ensuring that the process
evolves to meet dynamic project needs.

2. Focus on Quality at Every Step

Quality should be a priority at every phase of the process:

 Define clear exit conditions for every activity, action, or task.

 Ensure that work products meet the highest quality standards before proceeding.
Continuous focus on quality reduces errors and enhances overall project outcomes.

3. Be Ready to Adapt

Flexibility is critical in responding to constraints and challenges:

 Tailor the process to fit the problem, the team, and the project's unique requirements.

 Avoid rigid adherence to process models or methods, allowing adjustments as

necessary.
Adaptability ensures relevance and effectiveness throughout the software lifecycle.

4. Build an Effective Team

People are the cornerstone of successful software projects:

 Create a self-organizing team built on trust and mutual respect.

 Encourage collaboration and shared ownership of outcomes.

An empowered team drives innovation and ensures smooth execution of tasks.

5. Establish Mechanisms for Communication and Coordination

Effective communication prevents misunderstandings and project failures:

 Set up formal and informal channels for sharing important information.

  Coordinate efforts among stakeholders to align goals and expectations.
Proactive communication minimizes gaps and ensures cohesive project execution.

6. Manage Change

Changes are inevitable in software projects:

 Establish structured mechanisms to handle change requests.

 Ensure changes are assessed, approved, and implemented systematically.

Efficient change management keeps the project aligned with evolving needs while
maintaining stability.

7. Assess Risk

Identify and mitigate potential risks early:

 Develop contingency plans to address issues that may arise during development.

 Regularly review and update risk assessments to stay prepared for uncertainties.
Risk assessment ensures smooth progress and minimizes disruptions.

8. Create Work Products That Provide Value

Every deliverable should serve a clear purpose and add value:

 Develop work products that provide actionable and necessary information for
subsequent activities.

 Avoid creating unnecessary artifacts that do not contribute to project success.

This principle ensures efficiency and enhances collaboration across the development
pipeline.

Communication practice principles

1. Listen Actively
 o Focus on the speaker’s words, avoid interruptions, and ask for clarification if
needed.

2. Prepare Before Communicating

o Understand the problem, research the domain, and create an agenda if leading
a meeting.

3. Assign a Facilitator

o Have someone guide discussions, mediate conflicts, and ensure productive

conversations.

4. Prefer Face-to-Face Interaction

o Use visual aids or documents to support discussions when possible.

5. Document Key Points

o Take notes and record decisions to avoid forgetting critical information.

6. Encourage Collaboration

o Build trust and consensus by leveraging team knowledge to define features

and functions.

7. Stay Focused and Organized

o Discuss one topic at a time and avoid bouncing between unrelated issues.

8. Use Visuals for Clarity

o When words fail, a quick sketch or diagram can resolve confusion.

9. Know When to Move On

o Resolve or postpone unclear issues rather than lingering too long on a single
topic.

10. Aim for Win-Win Negotiations

 Approach compromises with a mindset where all parties benefit.

Requirements Engineering Tasks

1. Inception

o Establishes an initial understanding of the problem and solution.

o Defines stakeholders, their needs, and ensures effective communication

between the software team and other parties involved.

2. Elicitation

o Extracts and documents information about system objectives, functionality,

and business needs.

o Challenges:

 Scope Problems: Unclear system boundaries or unnecessary technical

details.

 Understanding Problems: Customers may lack clarity about their

needs or computing environment.

 Volatility Problems: Requirements may frequently change during

development.

3. Elaboration

o Refines the information gathered during inception and elicitation.

o Focuses on creating detailed requirements models and user scenarios that

describe interactions with the system.

4. Negotiation

o Resolves conflicts among stakeholders regarding priorities and expectations.

o Uses an iterative process to balance priorities, risks, and costs, ensuring all
parties are satisfied with the final requirements.

5. Specification

o Documents the requirements in various forms such as:

 Written documents
  Graphical models

 Formal mathematical models

 Usage scenarios

 Prototypes

6. Validation

o Ensures requirements are clear, complete, and error-free.

o Conducts technical reviews with stakeholders to identify and resolve

inconsistencies, ambiguities, and unrealistic expectations.

7. Requirements Management

o Tracks and manages changes to requirements throughout the project lifecycle.

o Uses activities like version control and traceability to manage evolving

requirements.

o Develops a Requirement Traceability Table to link requirements to their

implementation and changes.
Sensor Diagram:

Class-based elements. Each usage scenario implies a

set of objects that are

manipulatedasanactorinteractswiththesystem.Theseobjectsarecategorizedinto

classes—acollectionofthingsthathavesimilarattributesandcommonbehaviors.For

example, aUMLclassdiagramcanbeusedtodepictaSensorclassfortheSafeHome

securityfunction(Figure5.4).Notethatthediagramliststheattributesofsensors(e.g.,
name, type) and the operations (e.g., identify, enable) that can be applied to modify

these attributes. In addition to class diagrams, other analysis modeling elements de

pict the manner in which classes collaborate with one another and the relationships

andinteractions between classes. These are discussed in more detail in Chapter 7.