02.

Modeling
Contents:
2.1 Understanding the Requirements:
• Requirements Engineering,
• Eliciting Requirements,
• Negotiating Requirements,
• Requirements Monitoring,
• Validating Requirements.
2.2 Requirement Modeling:
• Scenario Based Methods,
• class based Methods,
• Data Flow Diagram,
• SRS (Software Requirement Specification) document format (IEEE)
2.1 Understanding Requirements
Why is understanding requirements difficult?

• Developers are eager to start coding, believing clarity will come later.
• Stakeholders may only realize their needs after seeing prototypes.
• Fast-changing environments make detailed requirement gathering seem
wasteful.
• Producing a working program feels like the ultimate goal.
These arguments sound reasonable but can cause failed projects if
requirements are not well understood.
 What is Requirements Engineering (RE)?
• Definition: A systematic process of understanding, analyzing, defining,
documenting, validating and maintaining the requirements for a
software system.
• It ensures that the software system meets the needs of users,
customers, and stakeholders.
• It acts as a bridge between communication and design, ensuring that
what gets built aligns with business needs and user expectations.
Seven Core Tasks of Requirements Engineering
Requirements Engineering as a set of interrelated activities:
1. Inception (Understanding the Problem)
• Identify stakeholders.
• Understand their needs, expectations, and system goals.
• Ask questions like: Who will use the system? What will it do? What are
constraints?
2. Elicitation
• Collect requirements through interviews, questionnaires, observation, brainstorming,
prototyping, workshops.
• Goal: Discover what the customer really wants.
3. Elaboration
• Refining and detailing requirements.
• Develop models like Data Flow Diagrams (DFDs), UML diagrams, Use Cases.
• Captures both functional and non-functional requirements.
4. Negotiation
• Resolve conflicts among stakeholders (e.g., cost vs. features).
• Prioritization, cost/risk analysis, and compromise lead to a "win-win" agreement.
5. Specification
• Produce a Software Requirements Specification (SRS) document.
• Provides a precise, testable, and agreed-upon description of the system.
6. Validation
• Ensure the requirements are correct, complete, consistent, unambiguous, and
verifiable.
• Techniques: Reviews, prototyping, test-case generation.
7. Requirements Management
• Handle changes in requirements as the project evolves.
• Maintain traceability of requirements to design, code, and tests.
Eliciting requirements
• Eliciting requirements is the process of gathering and discovering the needs,
expectations, and constraints of stakeholders for a software system.
It is the first step of Requirements Engineering and critical for project
success.
Why it’s Important
• More than 40% of project failures are due to poor or incomplete
requirements.
• Correctly elicited requirements reduce cost, rework, and misunderstandings
later.
Techniques:- Interviews, Questionnaires/Surveys, Brainstorming, Workshops,
Observation (Job Shadowing) , Document Analysis , Prototyping , Use Cases /
Scenarios etc.
1. Interviews
• Structured, unstructured, or open-ended.
• Conducted with stakeholders to identify needs and expectations.
• Helps uncover hidden or conflicting requirements.

2. Brainstorming Sessions
• Brainstorming Sessions is a group technique
• It is intended to generate lots of new ideas hence providing a platform to share views
• A highly trained facilitator is required to handle group bias and conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of requirements and their priority if possible.

3. Facilitated Application Specification Techniques (FAST) OR Collaborative Requirements

Gathering(CRG)
• FAST is a team-based approach for eliciting and specifying software requirements.
• It brings together developers, customers, and end-users in a structured meeting environment.
• The focus is on collaboration, negotiation, and consensus to develop a shared understanding of system
1. Interviews
Start with Contextual Questions:-
• Understand the business goals, user environment, and pain points.
Ask Open-Ended Questions Encourage detailed responses:
• “What challenges do you face with the current system?”
Clarify Functional vs. Non-Functional Requirements
• Functional = what the system does.
• Non-functional = how well it does it (performance, security, usability)
Summarize and Validate
• Repeat back what you’ve heard to confirm
• understanding and build trust.
2. Brainstorming Sessions
• Brainstorming Sessions is a group technique
• It is intended to generate lots of new ideas hence providing a platform
to share views
• A highly trained facilitator is required to handle group bias and
conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists
of the list of requirements and their priority if possible.
3. Collaborative Requirements Gathering(CRG)
Or facilitated application specification technique (FAST)
1. Joint Participation
• Meetings are conducted with both software engineers and stakeholders
present.
• Ensures shared understanding and direct communication.
2. Rules for Preparation & Participation
• Guidelines are set before the meeting begins.
• Everyone knows expectations and responsibilities.
3. Agenda Setting
• An agenda is suggested, which is:
• Formal enough → to ensure all important issues are covered.
• Informal enough → to encourage creativity and free flow of ideas.
Collaborative Requirements Gathering(CRG)
Or facilitated application specification technique (FAST)
4. Facilitator Role
• A facilitator leads the session (can be a customer, developer, or outsider).
• Ensures discussions stay on track and productive.
5. Definition Mechanism
• Tools are used to record, organize, and refine ideas:
• Worksheets, flip charts, wall stickers
• Or electronic means like bulletin boards, chat rooms, or virtual forums.
Goals of CRG Meeting
• Identify the problem clearly.
• Propose possible solution elements.
• Negotiate different stakeholder viewpoints.
• Specify a preliminary set of solution requirements.
• Maintain an environment conducive to collaboration and creativity.
4. Quality Function Deployment (QFD) in
Requirements Elicitation
• QFD is a quality management and requirements elicitation technique that
translates customer needs into technical requirements.
• Main goal: maximize customer satisfaction by ensuring the most valuable
requirements are identified, prioritized, and deployed throughout the
software engineering process.
Key Idea
• Focuses on what is valuable to the customer.
• Prevents "requirements creep" (adding too many exciting features without
control).
• But also recognizes that exciting requirements can make a product
successful.
4. Quality Function Deployment (QFD) in Requirements
Elicitation
1. Normal Requirements
• Explicitly stated by customers during meetings.
• Presence → customer is satisfied.
• Examples: required performance level, specific system functions, graphical
display types.
2. Expected Requirements
• Implicit, fundamental requirements (often unstated).
• Absence → customer is dissatisfied.
• Examples: ease of use, correctness and reliability, easy installation.
3. Exciting Requirements
• Not expected by the customer but provide delight when included.
• Help create a breakthrough product.
• Example: new phone including multitouch screen, visual voicemail.
5. Usage Scenarios
Definition
• As requirements are elicited, we begin to form a vision of system functions and
features.
• But to move further into technical design, we need to understand how different
classes of users will actually use the system.
• To do this, developers and users create usage scenarios (also called use cases).
Key Idea
• Usage scenarios (use cases) describe a thread of usage through the system.
• Each scenario tells a story of how a user (actor) interacts with the system to
achieve a goal.
• Helps both customers and developers understand system behavior in practical,
real-world contexts
6. Elicitation Work Products
What information is produced as a consequence of requirements gathering?
1. Statement of Need and Feasibility
• Explains why the system is required and whether it is technically/economically viable.
2. Bounded Statement of Scope
• Defines the boundaries of the system or product (what is included, what is not).
3. List of Stakeholders
• Identifies customers, users, and other stakeholders who participated in requirements
elicitation.
4. System’s Technical Environment Description
• Specifies the hardware, software, network, and operating conditions in which the system
will work.
5. List of Requirements & Domain Constraints
• Functional requirements (organized by function).
• Constraints from the application domain (rules, regulations, standards).
6. Elicitation Work Products
6. Set of Usage Scenarios
• Describes how the system will be used under different conditions
(normal use, exceptional cases).
7. Prototypes (if any)
• Models or mock-ups created to clarify and refine requirements.

Each of these work products is reviewed and validated by everyone who

participated in the elicitation process to ensure completeness and
correctness.
 Negotiating Requirements
• Even after inception, elicitation, and elaboration, customer requirements
are rarely clear or complete. This leads to negotiation between stakeholders
and the software team.
Purpose of Negotiation
• Balance functionality, performance, and system characteristics against
→ cost
→ time-to-market
→ resources (time, people, budget)
• Goal: Arrive at a project plan that:
• Meets stakeholder needs (what they want).
• Fits realistic constraints (what the team can actually deliver).
Negotiating Requirements
Win-Win Approach
• Stakeholders win → they get a system/product that satisfies most of
their needs.
• Software team wins → they work with achievable budgets and
realistic deadlines.
 Validating requirement

At this stage, every requirement is checked and validated before moving to design phase.
Requirements Model Review – Key Questions:-
1. Consistency with Objectives
• Does each requirement align with the overall goals of the system/product?
2. Level of Abstraction
• Are requirements described at the right level?
• At this stage, they should be what the system should do (functional/non-functional), not how to
technically implement it.
3. Necessity vs. Add-on
• Is the requirement essential to meet business objectives, or is it a “nice to have”?
• Helps in prioritization when time and resources are limited.
4. Bounded and Unambiguous
• The requirement must have clear boundaries and a single interpretation.
• Avoid vague statements like “system should be fast.” Instead, “system should respond within 2
Validating requirement
5. Attribution
• Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
• The attribution is like a tag that tells who said this requirement is needed or where it
came from.
• Each requirement should have a clearly identified source — the person, group, or
document that stated or requested it.
6. Conflicts
• Do any requirements contradict each other?
• Example: One requirement says “system auto-locks doors after 30 seconds,” another
says “system should not lock doors automatically.”
7. Achievability
• Can the requirement realistically be implemented with available technology, time,
and resources?
Validating requirement
8. Testability
• Can you design tests to verify the requirement once implemented?
• If not testable, the requirement is incomplete.
9. Reflection of System Information, Function, and Behavior
• Does the overall requirements model accurately represent the data
(information domain), functions (what system does), and behavior (how
system reacts to events)?

These checks ensure that the requirements model is complete, correct,

consistent, and practical, forming a solid foundation for design and
development.
Requirements Monitoring
Requirements Monitoring is the continuous process of tracking, validating, and
managing requirements throughout the software development life cycle (SDLC)
to ensure they:
Key Activities in Requirements Monitoring:-
1. Traceability
• Link requirements → design → implementation → testing.
• Ensures every requirement is covered and nothing is missed.
2. Validation and Verification
• Continuously check if requirements are valid (do they meet stakeholder
needs?) and verifiable (can they be tested?).
3. Change Management
• Monitor changes in business or environment that affect requirements.
• Update requirement documents and communicate to all stakeholders.
Requirements Monitoring
4. Prioritization
Monitor which requirements are critical and ensure they’re being addressed first.
5. Progress Tracking
• Measure how many requirements have been designed, implemented, and
tested.
6. Conflict Resolution
• Detect conflicts between evolving requirements and resolve them early.
2.2 Requirement Modeling

• Definition:
Requirements analysis is the process of defining what the software must do,
how it will interact with other system elements, and what constraints it must
satisfy.
• It elaborates on the basic requirements gathered during:
• Inception → project vision, goals.
• Elicitation → gathering stakeholder needs.
• Negotiation → resolving conflicts and setting priorities.
Types of Requirements Modelling
The requirements modeling action produces one or more of the following types of models:
1. Scenario-Based Models(Syllabus)
• Focus: System usage from the perspective of actors (users or external systems).
• Examples: Use cases, user stories, activity diagrams.
2. Data Models
• Focus: Information domain → what data is processed and how it relates.
• Examples: Entity-Relationship Diagrams (ERD), data dictionaries.
3. Class-Oriented Models(Syllabus) Focus: Object-oriented structure → classes, their
attributes, operations, and relationships.
• Examples: UML Class Diagrams, collaboration diagrams.
4. Flow-Oriented Models(Syllabus) Focus: Functional perspective → how data moves and is
transformed.
• Examples: Data Flow Diagrams (DFD), control flow diagrams.
5. Behavioral Models
• Focus: Dynamic behavior of the system → how it reacts to external events.
 1. Scenario Based Modelling
1. The success of a system is ultimately measured by user satisfaction.
2. To achieve this, the development team must understand how end users
(actors) want to interact with the system.
3. That understanding is captured using requirements models.

Requirements modeling with UML (Unified Modeling Language) usually begins

with scenario-based models, because they:
4. Are easy for stakeholders to understand.
5. Focus on what the user wants, not the internal design yet.
 Common Scenario-Based UML Models:
Common Scenario-Based UML Models are:-
1. Use Case Diagrams
1.Describe interactions between actors and the system.
Example: A student logs into an exam portal and downloads the hall ticket.
2. Activity Diagrams
1.Show the workflow of activities within the system.
2.Useful to model processes like “Online Payment Processing”.
3. Swimlane Diagrams
1.A specialized form of activity diagram.
2.Partition actions into lanes assigned to actors or subsystems.
3.Clearly shows who does what.
 Creating a Preliminary Use Case

What is a Use Case?

• A use case is a contract for behavior between an actor and a system.

• It specifies how an actor interacts with the system to accomplish a goal.
• Written in simple, natural language from the actor’s point of view.
• Helps in understanding system requirements clearly.
 Challenges in Writing Use Cases
When creating use cases, the analyst must decide:
1. What to write about?
1. Identify which functions or activities should be captured as use cases.
2. Derived from Requirements Engineering Activities( Inception,
Elicitation and Negotiation).
2. How much to write?
1. Balance detail vs. simplicity (too much detail early on may complicate
understanding).
3. How detailed should it be?
1. Start with informal narratives, refine into structured forms later.
4. How to organize them?
1. Organize use cases around actors and their goals.
Example: SafeHome Home Surveillance
The actor here is the Homeowner. Through discussions, the following
functions(use case) were identified:
1. Select camera to view.
2. Request thumbnails from all cameras.
3. Display camera views in a PC window.
4. Control pan and zoom for a specific camera.
5. Selectively record camera output.
6. Replay camera output.
7. Access camera surveillance via the Internet.

Each of these functions is developed into a use case.

Lets discuss point 7 Access camera surveillance via the Internet.
Illustration: Use Case – Access Camera Surveillance
via the Internet (ACS-DCV)
1. Narrative Use Case (Informal Style)
2. Sequential Use Case (Ordered Steps)
1. Narrative Use Case (Informal Style)
•story format from the actor’s perspective.
•Example (from the stakeholder’s viewpoint):
“If I’m at a remote location, I can use any PC with a browser to log in to the SafeHome Products website.
After entering my user ID and two levels of passwords, I get validated and gain access to all installed
SafeHome functionality.
To access surveillance, I select the surveillance option. Then, I choose pick a camera—the system displays
the floor plan of my house. I can select a specific camera or choose all cameras to view thumbnails from
all cameras. Once I pick a camera, I select view, and a live feed (one frame per second) is displayed in a
window identified by the camera ID. If I want to switch, I go back to pick a camera, the house floor plan is
displayed again, and I select another camera to open a new viewing window.”
Advantage: Easy for stakeholders to understand, since it reads like a story.
Limitation: Might lack structure and precision for developers.
Illustration: Use Case –(ACS-DCV)
2. Sequential Use Case :- Same use case but written (Ordered Steps)
Use Case: Access Camera Surveillance via the Internet – Display Camera Views (ACS-DCV)
1. The homeowner logs onto the SafeHome Products website.
2. The homeowner enters a valid user ID.
3. The homeowner enters two passwords (minimum 8 characters each).
4. The system validates credentials and displays all major function buttons.
5. The homeowner selects “surveillance” from the function menu.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon on the floor plan.
9. The homeowner clicks “view.”
10. The system displays the selected camera’s live feed (1 frame/sec) in a viewing window
labeled with the camera ID.
Refining a Preliminary Use Case:- SafeHome (ACS-DCV)
Step 6: The homeowner selects “pick a camera.”
Step 7: The system displays the floor plan of the house.
Now apply refinement:
1. Alternative Action
• Instead of picking a single camera, the actor may choose “View thumbnail snapshots of all
cameras”.
• This becomes a secondary scenario.
2. Error Condition
• If no floor plan has been configured, the system shows:
“Error: No floor plan configured for this house.”
• This becomes another secondary scenario (use-case exception).
3. External Behavior
• While steps 6 and 7 are happening, the system might detect an alarm condition.
• This is not just a variation, but a separate use case (“Alarm Condition Encountered”),
referenced by other use cases when needed.
Writing a Formal Use Case
Developing an Activity Diagram
Activity diagrams are one such graphical tool. They extend use cases by
showing the flow of interaction within a scenario in a way similar to a
flowchart.
 Data Flow Diagram
• A Data Flow Diagram (DFD) is a graphical tool used to represent how data moves
through a system. It shows processes, data stores, data flows, and external entities,
helping to visualize how inputs are transformed into outputs.
Key Components of a DFD
1. External Entities (Sources/Sinks)
• Represent people, systems, or organizations outside the system that provide input or receive output.
• Drawn as rectangles.
2. Processes
• Represent actions or functions that transform inputs into outputs.
• Drawn as circles or rounded rectangles.
3. Data Stores
• Represent where data is stored within the system.
• Drawn as open-ended rectangles or parallel lines.
4. Data Flows
• Represent movement of data between entities, processes, and stores.
DFD Symbols
Symbol Name Purpose

▭ (Rectangle) External Entity Source/sink of data

outside the system

○ or ⬯ (Circle / Rounded
Rectangle) Process Transformation of data

⎔ or ‖‖ (Open-ended
Rectangle / Parallel lines) Data Store Storage of data

→ (Arrow) Data Flow Movement of data

 Levels of DFD

•Level 0 DFD (Context Diagram):

Shows the entire system as a single process with its interactions with
external entities. (High-level view)
•Level 1 DFD:
Breaks down the main process into sub-processes to show more detail.
•Level 2 DFD and beyond:
Provide further breakdown of processes for detailed analysis.
DFD rules
• Each process should have at least one input and an output.
• Each data store should have at least one data flow in and one data flow out.
• Data stored in a system must go through a process.
• All processes in a DFD go to another process or a data store.

DFD levels and layers

• A data flow diagram can be represented into progressively more detail by
using levels and layers, zeroing in on a particular piece.
• DFD levels are numbered 0, 1 or 2, and occasionally go to even Level 3 or
beyond.
• The necessary level of detail depends on the scope of what you are trying to
accomplish.
Context-level DFD for the SafeHome security
function
Level 1 DFD for SafeHome
security function
Level-2 DFD that refines the monitor sensors process
Group Discussion topics
1. Is the Waterfall Model still relevant for modern software development
projects?
2. Waterfall vs. Agile – Which ensures better project success?
3. Incremental Model vs Waterfall – Which gives better customer satisfaction?
4. For what kinds of projects does the Waterfall Model work best?
5. Does the strict linear nature of Waterfall ensure better project
management?
6. Waterfall Model: Strong foundation or a barrier to flexibility?
7. In education and training, is Waterfall still the best model to teach
beginners?
Group Discussion topics
1. “Incremental Model vs Waterfall – Which delivers better customer
satisfaction?”
2. “Does the Incremental Model strike the right balance between flexibility
and structure?”
3. “For which types of projects is the Incremental Model the most effective
choice?”
4. “Is the Incremental Model suitable for large-scale software projects?”
5. “Incremental delivery: Does it truly reduce project risk?”
6. “Incremental Model vs Agile – Is Incremental just a lighter form of
Agile?”
7. “Does the Incremental approach improve project management or create
hidden complexity?”
 Group Discussion topics
1. “No single software process model fits all projects – Do you agree?”
2. “Traditional Models (Waterfall, V-Model) vs Modern Models (Agile, Spiral) –
Which ensures better project success?”
3. “Are hybrid software process models the future of software development?”
4. “Documentation-heavy models vs lightweight models – Which is more
practical today?”
5. “Does project size decide the choice of software process model?”
6. “Customer involvement: Advantage in Agile, or unnecessary burden?”
7. “Is Agile replacing all traditional process models, or do they still have a
place?”
Group Discussion topics
1. Waterfall vs Agile – Which is more practical in today’s world?
2. Spiral Model – Best risk management approach or too costly for small
projects?
3. Incremental vs Prototyping – Which gives better customer
satisfaction?
4. RAD Model – Speed at the cost of quality?
5. Do all projects need Agile, or are traditional models still useful?
6. Spiral Model – Too costly or worth the risk management?
7. Agile: A buzzword or a real solution?
Group Discussion topics
• Agility is about responding to change, not following a rigid plan.” Do
you think this makes Agile better than prescriptive models?
• Scrum emphasizes self-organizing teams. Do you think students can
manage projects without a formal leader using Scrum?
• Extreme Programming (XP) encourages practices like pair
programming. Do you think this is efficient or a waste of resources?
Group Discussion topics
• DevOps is often called “Agile taken to the next level.” Do you agree?
• Among the Nine Pillars of DevOps, which one is most challenging to
implement in organizations, and why?
• Do you think DevOps culture can work in academic group projects?
Why or why not?