Software Engineering Fundamentals

COC2073
Module 2 – Software Requirements
Engineering
Muhammad Shahid
Department of Computer Science
National Textile University

[email protected]
Last Lecture Review

▪ Software Process
▪ The Waterfall Model
▪ Prototyping Model
▪ The V Model
▪ Phased Development
▪ Spiral Model
▪ Agile Software Development
▪ Extreme Programming (XP)
▪ Scrum
2 Software Engineering Fundamentals - COC2073
Agenda – What will you Learn Today?
Software Requirement Levels of Software
Engineering Requirements

Requirements Requirements
Engineering Process Validation Techniques

3 Software Engineering Fundamentals - COC2073

 Software Requirement Engineering

4 Software Engineering Fundamentals - COC2073

Software Requirement Engineering

▪ A condition or capability needed by user to

solve a problem or achieve an objective

▪ A condition or capability that must be met or

possessed by a system or system component
to satisfy a contract, standard, specification,
or other formally imposed document

▪ A documented representation of a condition

or capability as in 1 or 2
[IEEE 1990]
5 Software Engineering Fundamentals - COC2073
Software Requirement Engineering

Requirements are ... A specification of what

should be implemented. They are descriptions
of how the system should behave, or of a
system property or attribute. They may be a
constraint on the development process of the
system.
[Sommerville 1997]

6 Software Engineering Fundamentals - COC2073

Software Requirement Engineering

▪ "Software requirements express the needs

and constraints placed on a software product
that contribute to the solution of some real-
world problems."
[Kotonya and Sommerville 2000]

▪ Example:
When the user enters the degrees in
Fahrenheit, the system shall calculate and
write the degrees in Celsius

7 Software Engineering Fundamentals - COC2073

Requirement Origin v/s Costs
▪ Rate of Growth
250% ▪ Comparative Cost

200%

150%

100%

50%

0%

Feasibility Requirements Design Coding Testing

8 Software Engineering Fundamentals - COC2073

Inadequate Requirements Process Risks

▪ Insufficient user involvement leads to

unacceptable products

▪ Creeping user requirements contribute to

overruns and degrade product quality

▪ Ambiguous requirements lead to ill-spent time

and rework

▪ Gold-plating by developers and users adds

unnecessary features
9 Software Engineering Fundamentals - COC2073
 Inadequate Requirements Process Risks

▪ Minimal specifications lead to missing key

requirements

▪ Overlooking the needs of certain stake holders

leads to dissatisfied customers

▪ Incompletely defined requirements make

accurate project planning and tracking
impossible

10 Software Engineering Fundamentals - COC2073

 Levels of Software Requirements

11 Software Engineering Fundamentals - COC2073

 Levels of Software Requirements

Software Requirement
Business
Requirements
User
Requirements
Functional
Requirements
Non-Functional
Requirements

12 Software Engineering Fundamentals - COC2073

 Business Requirements

▪ Business requirements define the high-level needs

and objectives of a business or organization for a
system, project, or process

▪ They describe why the organization is undertaking a

project and the expected benefits, focusing on the
business goals and outcomes rather than technical
or detailed system functions

▪ Business requirements are typically written in a way

that can be understood by both business
stakeholders and technical teams
13 Software Engineering Fundamentals - COC2073
 Business Requirements: Examples

▪ Learning Management System (LMS)

– Goal: Enable efficient delivery of courses and
improve student engagement

– Requirement: The LMS must allow faculty to

upload course materials and students to access
them remotely

– Outcome: Increase course completion rates by

15% within the next academic year

14 Software Engineering Fundamentals - COC2073

 Business Requirements: Examples

▪ E-commerce Website

– Goal: Improve online sales and enhance

customer satisfaction

– Requirement: The system must allow customers

to search for products, make purchases, and track
orders online

– Outcome: Increase online sales by 25% over the

next six months

15 Software Engineering Fundamentals - COC2073

 Business Requirements: Examples

▪ Online Banking System

– Goal: Enhance customer experience and reduce

operational costs

– Requirement: The system must allow users to

perform online transactions without visiting a
branch

– Outcome: Reduce in-branch transactions by 30%

within the first year of implementation

16 Software Engineering Fundamentals - COC2073

 Business Requirements: Examples

▪ Healthcare Appointment System

– Goal: Improve patient access to care and

optimize appointment scheduling

– Requirement: The system must allow patients to

book, reschedule, and cancel appointments online

– Outcome: Decrease appointment no-shows by

20% and improve patient satisfaction scores

17 Software Engineering Fundamentals - COC2073

 Business Requirements: Examples

▪ Customer Relationship Management (CRM)

System

– Goal: Increase sales team efficiency and improve

customer retention

– Requirement: The system must allow sales

representatives to track customer interactions and
automate follow-up reminders

– Outcome: Increase customer retention rates by

10% over the next year
18 Software Engineering Fundamentals - COC2073
 User Requirements

▪ User requirements describe the specific needs and

expectations of end-users regarding a system or
software

▪ They focus on what users need from the system to

perform their tasks effectively and efficiently

▪ User requirements are typically articulated from the

perspective of the user and serve as a bridge
between business requirements (high-level goals)
and functional requirements (specific
functionalities)
19 Software Engineering Fundamentals- COC2073
 User Requirements - Examples

▪ Learning Management System (LMS)

– Users must be able to log in to the system using
their university credentials
– Students should be able to view and download
course materials in PDF format
– Faculty must be able to create and manage
assignments, including setting due dates and
grading criteria
– Users should receive notifications for assignment
deadlines and upcoming quizzes

20 Software Engineering Fundamentals- COC2073

 User Requirements - Examples

▪ E-commerce Website
– Customers must be able to create an account
using their email address and a password
– Users should be able to filter products by
categories, price range, and customer ratings
– Customers must receive an email confirmation
after placing an order
– Users should be able to track the status of their
orders from their account dashboard

21 Software Engineering Fundamentals- COC2073

 User Requirements - Examples

▪ Online Banking Application

– Users must be able to view their account balances
and recent transactions in real time
– Customers should be able to transfer funds
between their accounts or to other users
– Users must be able to set up recurring payments
for bills directly through the app
– The application should provide a secure and easy
way for users to change their passwords

22 Software Engineering Fundamentals- COC2073

 User Requirements - Examples

▪ Healthcare Appointment System

– Patients must be able to search for available
appointments with their healthcare provider
– Users should receive reminders for upcoming
appointments via SMS or email
– Patients must be able to cancel or reschedule
appointments online without needing to call the
office
– The users should be able to provide feedback on
their visit after an appointment

23 Software Engineering Fundamentals- COC2073

 User Requirements - Examples

▪ Customer Relationship Management (CRM)

System
– Sales representatives must be able to view
customer profiles and interaction history from a
single dashboard
– Users should be able to log new customer
interactions and set reminders for follow-up tasks
– The system must allow users to generate reports on
sales performance and customer engagement.
– Users should be able to customize their dashboard
to display the most relevant information
24 Software Engineering Fundamentals- COC2073
 Functional Requirements

▪ Functional requirements describe the specific

functions or capabilities a system or software must
provide to meet user needs and fulfill its purpose

▪ They define what the system should do and outline

the interactions between the system and its users, as
well as between the system and other systems

▪ Functional requirements are essential in defining the

core functionalities of a system and guiding
developers on how the system should behave under
various conditions
25 Software Engineering Fundamentals- COC2073
 Functional Requirements: Examples

▪ E-commerce Website
– The system must allow users to search for
products using keywords, categories, and filters
– The system must enable users to add products to
a shopping cart and proceed to checkout
– The system must support multiple payment
methods (credit card, PayPal, etc.)
– The system must generate and email a
confirmation receipt after a purchase is completed

26 Software Engineering Fundamentals- COC2073

 Functional Requirements: Examples

▪ Online Banking Application

– The system must allow users to view their account
balances and recent transactions
– The system must enable users to transfer money
between their accounts or to external accounts
– The system must send transaction alerts to users
via SMS or email for large withdrawals or deposits
– The system must support multi-factor
authentication (MFA) during login for security

27 Software Engineering Fundamentals- COC2073

 Functional Requirements: Examples

▪ Learning Management System (LMS)

– The system must allow students to view and
download course materials
– The system must allow faculty to upload
assignments and set due dates
– The system must allow students to submit
assignments and receive feedback from faculty
– The system must generate grades and display
them on a student’s dashboard

28 Software Engineering Fundamentals- COC2073

 Non-Functional Requirements

▪ Non-functional requirements (NFRs) describe the

system's operational qualities and constraints, focusing
on how a system should perform rather than what the
system should do

▪ They define the quality attributes and criteria that the

system must meet to ensure that it operates efficiently,
reliably, securely, and is user-friendly

▪ These requirements often address performance, security,

scalability, usability, and maintainability aspects, ensuring
the system delivers a satisfactory experience to users

29 Software Engineering Fundamentals- COC2073

 NFRs: Software Quality Factors

Portability Modifiability

Maintainability
Scalability
Reliability

Availability Performance

Safety Usability
Testability

30 Software Engineering Fundamentals - COC2073

 Non-Functional Requirements

▪ Performance
– Specifies how fast the system should respond and
operate

▪ Scalability
– Defines how well the system can handle growth in
terms of users, data, or transactions

▪ Availability
– Refers to the system’s ability to remain operational
and accessible over time

31 Software Engineering Fundamentals- COC2073

 Non-Functional Requirements

▪ Security
– Addresses how the system protects data and
prevents unauthorized access

▪ Usability
– Focuses on how easy the system is to use and
navigate

▪ Reliability
– Ensures the system performs consistently under
specific conditions

32 Software Engineering Fundamentals- COC2073

 Non-Functional Requirements

▪ Maintainability
– Specifies how easy it is to update, fix, or enhance
the system

▪ Compliance
– Ensures the system follows industry regulations or
standards

▪ Capacity
– Specifies the volume of data the system can
process and store

33 Software Engineering Fundamentals- COC2073

 Non-Functional Requirements: Examples

▪ E-commerce Website
– Performance: The website must load product
pages within 3 seconds, even during peak hours
– Security: All transactions must be encrypted using
SSL/TLS, and the website must comply with PCI-
DSS standards for payment security
– Scalability: The website must handle 50,000
simultaneous users during sales events without
crashing
– Availability: The website must be available 24/7
with 99.95% uptime
34 Software Engineering Fundamentals- COC2073
 Non-Functional Requirements: Examples

▪ Online Banking Application

– Performance: The application must process fund
transfers within 1 second
– Usability: The login process must be completed in
less than 30 seconds with no more than 3 user
interactions
– Security: Multi-factor authentication (MFA) must be
required for every login attempt
– Reliability: The system must provide uninterrupted
service for at least 364 days each year (99.9%
uptime)
35 Software Engineering Fundamentals- COC2073
 Non-Functional Requirements: Examples

▪ Learning Management System (LMS)

– Performance: The system must allow students to
load course materials in less than 2 seconds
– Usability: Students should be able to navigate
between courses with no more than 3 clicks
– Scalability: The system must support a 20% annual
increase in student enrollment without performance
degradation
– Backup: The system must automatically back up all
course data daily, with the ability to restore it within
30 minutes in case of failure
36 Software Engineering Fundamentals- COC2073
 Non-Functional Requirements: Examples

▪ Healthcare Appointment System

– Availability: The system must have 99.9% uptime
to allow 24/7 patient access to booking services
– Security: The system must comply with HIPAA
regulations to protect patient health information
– Usability: The booking process must be completed
in no more than 4 steps
– Recovery: The system must recover from critical
failures within 30 minutes without data loss

37 Software Engineering Fundamentals- COC2073

 Requirements Types: Summary
Requirement What they define Focus Example
Level
Business High-level goals and Why the project is Increase online sales
Requirements objectives of the needed (e.g., increase by 20% in the next
organization or project revenue, improve year
efficiency)

User Specific needs and What the user needs Users must be able to
Requirements expectations of the from the system to track their orders
end-users perform tasks online

Functional Specific features or What the system should The system must allow
Requirements functions the system do users to create accounts
must provide and log in
Non-Functional System qualities like How the system should The system must load
Requirements performance, security, perform pages within 3 seconds
and usability

38 Software Engineering Fundamentals- COC2073

 Ambiguous Requirements

▪ The system should be easy to use by medical

staff and should be organized in such a way
that user errors are minimized.
▪ Allows user to cancel sales orders.
▪ The system provides searching of data
quickly.
▪ "The system is user friendly."
▪ "Software produces a print normally in ten
seconds."
39 Software Engineering Fundamentals - COC2073
 Ambiguous Requirements

▪ The staff shall be able to use all the system

functionalities. The average number of errors
made by users shall not exceed two per hour
of system use.

▪ "The operator identity consists of the operator

name and password; the password consists
of six digits. It should be displayed on the
security screen and deposited in the login file
when an operator logs into the system."

40 Software Engineering Fundamentals - COC2073

 Problems with Natural Languages

▪ A natural language requirements specification

is over-flexible. You can say the same thing in
completely different ways

▪ It is not possible to modularize natural

language requirements. It may be difficult to
find all related requirements

▪ To discover the impact of a change, every

requirement have to be examined
41 Software Engineering Fundamentals - COC2073
 Problems with Natural Languages

▪ We must polish the Polish furniture.

▪ We now have dress shirts on sale for men
with 16 necks.
▪ I saw the man with the binoculars.
▪ Wanted: a nurse for a baby about twenty
years old.
▪ The girl in the car that needed water is
waiting.

42 Software Engineering Fundamentals - COC2073

 Characteristics of Good Requirements

Numbered Inspected Unambiguous

Testable Complete Consistent

Understandable Traceable Feasible

Modifiable

43 Software Engineering Fundamentals - COC2073

 Class Activity

▪ Write down Functional Requirements and Non-

functional Requirements of the following systems

44 Software Engineering Fundamentals - COC2073

 Class Activity

▪ Write down Functional Requirements and Non-

functional Requirements of the following systems

45 Software Engineering Fundamentals - COC2073

 Requirements Engineering Processes

46 Software Engineering Fundamentals - COC2073

 Requirements Engineering Process
• These focus on • Discovering
assessing if the Requirements
system is useful
to the business?

Feasibility Elicitation
Study and Analysis

Validation Specification

• Are requirements • Converting these

actually define requirements into
the system that some standard
customer wants? form

47 Software Engineering Fundamentals - COC2073

 Requirements Engineering Process

48 Software Engineering Fundamentals - COC2073

 Requirements Elicitation & Analysis

▪ Software Engineers work with customers and

system end-users to find out:
‒ The application domain
‒ What services the system should provide
‒ The required performance of the system
‒ Hardware constraints
‒ and so on …

▪ May involve a variety of different kinds of

people (stakeholder) in an organization
49 Software Engineering Fundamentals - COC2073
 Stakeholders

Customer
User Development
Pays for Organization
the system
Provides the
Uses the system system

Stakeholders

A person or organization with a Supplier

major interest in the project outcome

50 Software Engineering Fundamentals - COC2073

 Requirements Elicitation & Analysis

Requirements
Discovery

Requirements
Requirements
Classification and
Specification
Organization

Requirements
Prioritization and
Negotiation

51 Software Engineering Fundamentals - COC2073

 Requirements Discovery/Elicitation

▪ The process of interacting with stakeholders

of the system to discover their requirements
▪ Domain requirements from stakeholders and
documentation are discovered
▪ Several complementary techniques can be
used for requirements discovery Requirements
Discovery

a) Interviewing
Requirements
Requirements
b) Scenarios Specification
Classification and
Organization

c) Use cases Requirements

Prioritization and
Negotiation
d) Ethnography
52 Software Engineering Fundamentals - COC2073
 Requirements Classification & Organization

▪ The unstructured collection of

Requirements
Discovery

requirements, groups related Requirements

Requirements
Classification and
requirements, and organizes Specification
Organization

them into coherent clusters Requirements

Prioritization and
Negotiation

▪ The most common way of grouping

requirements is to use a model of the system
architecture to identify sub-systems and to
associate requirements with each sub-system

53 Software Engineering Fundamentals - COC2073

 Requirements Prioritization & Negotiation

▪ This activity is concerned with prioritizing

requirements and finding and resolving
requirements conflicts through negotiation

Requirements
Discovery

Requirements
Requirements
Classification and
Specification
Organization

Requirements
Prioritization and
Negotiation

54 Software Engineering Fundamentals - COC2073

 Requirements Specification

▪ The requirements are documented and input

into the next round of the spiral

▪ Formal or informal requirements documents

may be produced
Requirements
Discovery

Requirements
Requirements
Classification and
Specification
Organization

Requirements
Prioritization and
Negotiation

55 Software Engineering Fundamentals - COC2073

 Requirements Elicitation

56 Software Engineering Fundamentals - COC2073

 Requirements Elicitation

▪ The process of gathering information about

the required system and existing systems,
and distilling the user and system
requirements from this information

▪ Sources of information during the

requirements discovery phase include:
‒ Documentation
‒ System stakeholders
‒ Specifications of similar systems

57 Software Engineering Fundamentals - COC2073

 Requirements Elicitation

Purpose:
▪ Understand the true needs of the customer
▪ Trace future implementation to needs

Sources: Techniques:
▪ Goals ▪ Interviews
▪ Domain knowledge ▪ Scenarios
▪ Prototypes
▪ Stakeholders
▪ Facilitated meetings
▪ Environment ▪ Observation
58 Software Engineering Fundamentals - COC2073
 Requirements Elicitation - Interviewing

▪ Formal or informal interviews with system

stakeholders

▪ The requirements engineering team puts

questions to stakeholders about the system
that they currently use and the system to be
developed

▪ Requirements are derived from the answers

to these questions
59 Software Engineering Fundamentals - COC2073
 Requirements Elicitation - Interviewing

▪ Interviews may be of two types:

1) Closed interviews: Where the stakeholder

answers a pre-defined set of questions

2) Open interviews: In which there is no pre-

defined agenda. The requirements engineering
team explores a range of issues with system
stakeholders and hence develop a better
understanding of their needs

60 Software Engineering Fundamentals - COC2073

 Requirements Elicitation - Scenarios

▪ Scenarios can be particularly useful for

adding detail to an outline requirements
description
▪ They are descriptions of example interaction
sessions
▪ Each scenario usually covers one or a small
number of possible interactions
▪ Different forms of scenarios are developed
and they provide different types of information
at different levels of detail about the system
61 Software Engineering Fundamentals - COC2073
 Requirements Elicitation - Scenarios

1) A description of what the system and users

expects when the scenario starts
2) A description of the normal flow of events in
the scenario
3) A description of what can go wrong and how
this is handled
4) Information about other activities that might
be going on at the same time
5) A description of the system state when the
scenario finishes
62 Software Engineering Fundamentals - COC2073
 Use Case Modelling

63 Software Engineering Fundamentals - COC2073

 Use-Case Modeling

▪ Use cases are requirements discovery

technique

▪ First introduced by Ivary Jacobson

▪ Become a fundamental feature of

the Unified Modeling Language
(UML)
▪ Documented using a high-level use case
diagram
64 Software Engineering Fundamentals - COC2073
 Use-Case Modeling

▪ A use-case is … "A particular form or pattern

or exemplar of usage, a scenario that begins
with some user of the system initiating some
transaction of sequence of interrelated
events."
[Jacobson, 1992]

65 Software Engineering Fundamentals - COC2073

 Elements of the Use-Case Diagram
3. Use Case
2. System

5. Dependency

1. Actor

4. Association 6. Generalization

66 Software Engineering Fundamentals - COC2073

 Elements of the Use-Case Diagram

▪ System:
- Sets the boundary of the system in relation to
the actors who use it (outside the system) and
the features it must provide (inside the system)

▪ Actor:
- A role played by a person, system, or device
that has a stake in the successful operation of
the system

67 Software Engineering Fundamentals - COC2073

 Elements of the Use-Case Diagram

▪ Use Case:
- Identifies a key feature of the system. Each Use
Case expresses a goal that the system must
achieve

▪ Association:
- Identifies an interaction between actors and Use
Cases

68 Software Engineering Fundamentals - COC2073

 Elements of the Use-Case Diagram

▪ Dependency:
- Identifies a communication relationship between
two Use Cases

▪ Generalization:
- Defines a relationship between two actors or two
Use Cases where one Use Case inherits

69 Software Engineering Fundamentals - COC2073

 Use-Case System

System Name System Name

OR

70 Software Engineering Fundamentals - COC2073

 Use-Case Actors

<<actor>> <<actor>>
HR System Satellite Feed

Manager

Person Example System Example Device Example

71 Software Engineering Fundamentals - COC2073

 Stereotype Notation

▪ <<include>> dependency notation:

- Use when one Use Case will always call the
other Use Case
- Drawn as a dashed arrow from the “using” Use
Case to the “used” Use Case and labeled with
the <<include>> stereotype notation

Withdraw <<include>> Update

Cash Account

Customer

72 Software Engineering Fundamentals - COC2073

 Stereotype Notation

▪ <<extend>> dependency notation:

- Use when one Use Case might need help from
another Use Case
- Drawn as a dashed arrow from the “extension”
Use Case to the “main” Use Case that it is
helping

Withdraw <<extend>> Credit

Cash Limit

Customer

73 Software Engineering Fundamentals - COC2073

 Generalization

▪ Can apply to actors and to Use-Cases

Withdraw Cash

Customer Withdraw Cash

with Overdraft
Protection

74 Software Engineering Fundamentals - COC2073

 Generalization

▪ Can apply to actors and to Use-Cases

Download Books

Customer

Regular Premium
Customer Customer

75 Software Engineering Fundamentals - COC2073

 Steps in Use-Case Modeling

▪ Step 1: Identify Business Actors

▪ Step 2: Identify Business Use Cases

▪ Step 3: Construct Use-case Model Diagram

▪ Step 4: Documents Business Requirements

Use-case Narratives

76 Software Engineering Fundamentals - COC2073

 Use-Case Diagram - Hospital System

Add Record

View
Record

Edit Record

Nurse Doctor
Setup
Consultation

77 Software Engineering Fundamentals - COC2073

 Use-Case Diagram - Hospital System

Add Record

View
Record

Edit Record

Nurse Doctor
Setup
Consultation

78 Software Engineering Fundamentals - COC2073

 Task - 1

Reserve
Library System
Borrow
Browse
Borrow
Book
Browser
Book
Return
Borrower
Books

Extend
Loan
Update
Catalog
Librarian

79
Library
Software Management
Engineering Fundamentals System
- COC2073
 Task - 1 (Stereotypes)

Library System
Extend
Loan

Check for
Reservation
Book
Borrower Borrow
Copy of
Book
Refuse
Loan

80
Library
Software Management
Engineering Fundamentals System
- COC2073
 Task - 2
Course Registration System

Register
Course

<<include>>
Student
Registration
Confirm Clerk
Prerequisite

Finance
Office Pay Fee

81 Course Registration System

Software Engineering Fundamentals - COC2073
 Task - 3
Patient Appointment System

Make
Appointment

Produce
Schedule
Patient
Management

Manage Update
Schedule Schedule

Doctor

82 Patient Appointment
Software Engineering Fundamentals -System
COC2073
 Components of a Use-Case

83 Software Engineering Fundamentals - COC2073

 Elaborated Use-Cases
Use Case Name
Implementation Priority The relative implementation priority of the use case
Actors Names of the actors that use this use case
Summary A brief description of the use case
Pre-condition The condition that must be met before the use case can
be invoked
Post-Condition The state of the system after completion of the use case
Extend The use case it extends (if any)
Uses The use case it uses (if any)
Normal Course of Sequence of actions in the case of normal use
Events
Alternative Path Deviations from the normal course
Exception course of action in the case of some exceptional
condition
Assumption All the assumptions that have been taken for this use
case
84 Software Engineering Fundamentals - COC2073
 Elaborated Use-Cases
Record
Delete Transaction
Employee Cancel
User Deletion

Delete Employee
Implementation Priority 3
Actors User
Summary Deleting employee allows the user to permanently
remove employee from the system. Deleting employee is
only possible when the employee has not been used in
the system.
Precondition Employee’s information was previously saved to the
system and a user needs to permanently delete the
Employee’s information.
Post-Condition The Employee’s information is no longer available
anywhere in the system.
Extend
85 None
Software Engineering Fundamentals - COC2073
 Elaborated Use-Cases
Record
Delete Transaction
Employee Cancel
User Deletion

Delete Employee
Uses Record Transactions, Cancel Action
Normal Course of ▪ The use case starts when the user wants to delete an
Events Employee
▪ The user selects the Employee and directs the system
to delete the information - Exception 1, 2
▪ The system responds by asking the user to confirm
deletion
▪ The user confirms deletion
Alternative Path The user does not confirm Deletion
▪ If the user does not confirm deletion, the information
does not delete.
▪ Uses: Cancel Action
86 Software Engineering Fundamentals - COC2073
 Elaborated Use-Cases
Record
Delete Transaction
Employee Cancel
User Deletion

Delete Employee
Exception The system will not allow a user to delete information that
is being used in the system.
The system will not allow a user to delete another user
that has subordinates.
Assumption ▪ Deleting employee covers a permanent deletion of an
entire set of data.
▪ Deleted employee is not retained in the system.
▪ A user can only delete employee that has not been
used in the system.

87 Software Engineering Fundamentals - COC2073

 Limitations of Use-Cases

▪ Domain rules are not documented

▪ Legal issues are not documented

▪ Non-Functional requirements are not

documented
- Usability
- Reliability
- Performance
- Portability
- Access
88 Software Engineering Fundamentals - COC2073
 Activity - Air Ticket Reservation System

▪ Reservations on local system

▪ Passenger goes to client terminal in local office
▪ Searches flights/seats
▪ Takes print of available seats
▪ Booking staff confirms seat
▪ Client terminal also displays flash news/updates
▪ Admin can Add/Edit/Cancel flight schedule
(Email is sent to passengers)
▪ Admin can cancel ticket
▪ Admin can Add/Edit/Cancel Reservation
89 Software Engineering Fundamentals - COC2073
 Activity Diagrams

90 Software Engineering Fundamentals - COC2073

 Activity Diagrams

▪ An activity diagram describes a system in

terms of activities

▪ Activities are states that represent the

execution of a set of operations

▪ The completion of these operations triggers a

transition to another activity

91 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Purpose

▪ Activity diagrams are not only used for

visualizing dynamic nature of a system but
they are also used to construct the executable
system by using forward and reverse
engineering techniques

▪ It does not show any message flow from one

activity to another

92 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Purpose

▪ So the purposes can be described as to:

‒ Draw the activity flow of a system

‒ Describe the sequence from one activity to

another

‒ Describe the parallel, branched and concurrent

flow of the system

93 Software Engineering Fundamentals - COC2073

 How to Draw Activity Diagram

▪ Have clear understanding about the elements

used in activity diagram

▪ Identify the following elements:

1. Activities

2. Association

3. Conditions
4. Constraints

94 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Symbols

Initial Node
▪ The filled circle is the starting point of the
diagram
Final Node
▪ The filled circle with a boarder is the ending
point
▪ An activity diagram can have zero or more
activity final state

95 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Symbols

Activity
▪ The rounded rectangle represents activities
that occur
▪ An activity is not necessarily a program, it
may be a manual thing also

Flow / Edge
▪ The arrows in the diagram
▪ No label is necessary

96 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Symbols

Fork
▪ A black bar(horizontal/vertical) with one flow
going into it and several leaving it
▪ This denotes the beginning of parallel
activities

Fork Fork

97 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Symbols

Join
▪ A black bar with several flows entering it and
one leaving it
▪ This denotes the end of parallel activities

Fork

Fork

98 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Symbols

Merge
▪ A diamond with several flows entering and
one leaving
▪ The implication is that all incoming flow to
reach this point until processing continues

99 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Symbols

Decision
▪ A diamond with one flow entering and several
leaving
▪ The flow leaving includes conditions as yes/
no state

Condition?

100 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Symbols

Swimlane
▪ A partition in activity diagram by means of
dashed line, called swim lane
▪ This swim lane may be horizontal or vertical

Swimlane 1 Swimlane 2

101 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Sample
Pre-condition
Actor Input

System Step Step 1

Basic Flow [True]

Step 2 [No] Alternate or Extension Flow

Returning Alternate Flow

Step 3

Parallel Activities Step 1 Step 1

Post-condition

102 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Example 1
Delete Employee

Confirm No
deletion?

Yes

Record Action Employee Maintained

Object Deleted

103 Software Engineering Fundamentals - COC2073

 Activity Diagrams - Example 2

Open Incident

Allocate Coordinate Document

Resources Resources Resources

Achieve Incident

104 Software Engineering Fundamentals - COC2073

 Class Activity - Modeling a Word Processor

▪ Open the word processing package

▪ Create a file
▪ Save the file under a unique name within its directory
▪ Type the document
▪ If graphics are necessary, open the graphics package,
create the graphics, and paste the graphics into the
document
▪ If a spreadsheet is necessary, open the spreadsheet
package, create the spreadsheet, and paste the
spreadsheet into the document
▪ Save the file
▪ Print a hard copy of the document
▪ Exit the word processing package
105 Software Engineering Fundamentals - COC2073
 Class Activity - Modeling a Word Processor
Open Word
Processing Package

Create File

Save File

Type the Document

[graphics needed] Open & Use Graphics

Package
[graphics not needed]
[tables needed] Open & Use Graphics
Package
[tables not needed]

Save the File

Print Hard Copy Exit Office Suit

106 Software Engineering Fundamentals - COC2073

 Swinlane

▪ A swimlane is a way to group activities

performed by the same actor on an activity
diagram or activity diagram or to group
activities in a single thread

108 Software Engineering Fundamentals - COC2073

 Class Activity - Student Enrollment

▪ A student wants to get register to appear in entry test

of National Textile University
▪ The student input his/her email ID
▪ If email already exists then the student is required to
input the email again
▪ If the email does not exists then input the student
requires to provide information
▪ The student information is verified
▪ If information is not verified then ask the student to
enter valid information
▪ If information is verified then display message of
registration successful
113 Software Engineering Fundamentals - COC2073
 Class Activity - Student Enrollment
Yes

Already
Get email ID exists?

No

Enter student Ask student to

information enter valid info.

Verify student Verified No

information information
?
Yes
Registration
successful

114 Signup Activity Diagram

Software Engineering Fundamentals - COC2073
 Class Activity - Hotel Reservation System

▪ Customer inquires about room reservation

▪ System provides details of rooms
▪ The customer enters required room details
▪ If the customer is already registered then
room is assigned
▪ If no then customer record is created
▪ The system generate invoice after assigning
room

115 Software Engineering Fundamentals - COC2073

 Class Activity - Hotel Reservation System
Customer System
Inquire about
reservation
Rooms details

Enters required Register Yes

room details customer?

No

Assign room

Create customer
record
Generate
invoice

116 Hotel Reservation System

Software Engineering Fundamentals - COC2073
 Class Activity - Online Shopping Cart

1. The user enters the choice for Search or Browse.

2. In case of Search option the user search for item
3. If items is found then the details of the item is displayed
4. If the searched item is not found then the user is
required to retry search
5. After displaying item the user is required to get more
shopping.
6. If the user is interested to have more shopping then the
user is redirected to Search option
7. If the user does not required more shopping then the
selected item(s) is added to cart
8. The cart is viewed
9. get address information
117 Software Engineering Fundamentals - COC2073
 Class Activity - Online Shopping Cart

Search
item No Yes
Search
Yes More
Found? View item shop?

Choice? No

Browse
Add to cart
Browse
item

View cart

Address
information

118 Online Shopping Cart

Software Engineering Fundamentals - COC2073
 Data Flow Diagram

119 Software Engineering Fundamentals - COC2073

 Data Flow Model

▪ Captures the flow of data in a system

▪ It helps in developing an understanding of
system’s functionality
▪ What are the different sources of data, what
different transformations take place on data
and what are final outputs generated by these
transformations
▪ It describes data origination, transformations
and consumption in a system

120 Software Engineering Fundamentals - COC2073

 Data Flow Model

Process
External
Agent

Flow of data / information

Data Source

121 Software Engineering Fundamentals - COC2073

 Process

▪ Work or actions performed on data (inside the

system)
▪ Labels should be verb phrases
▪ Receives input data and produces output
1.0
Report Detail Generate Grade Report
Report

Report Detail Grade Report

Generate Report

122 Software Engineering Fundamentals - COC2073

 Process - Rule 1

▪ Can have more than one outgoing data flow

or more than one incoming data flow

Graded Work
Submit Work Mark
Assignments Student Grades

Hours Work
Calculate Gross Gross Pay
Pay Rate Pay

123 Software Engineering Fundamentals - COC2073

 Process - Rule 2

▪ Can connect to any other symbol (including

another process symbol)

Accepted Inventory
Order Order Change
Verify Order Assemble Order

124 Software Engineering Fundamentals - COC2073

 Typical Processes

▪ Perform Certain Computations

‒ Example Calculate Commission

▪ Decision Making
– Order Management System

▪ Change information
– Summarize data
– Filter data
– Sort data

125 Software Engineering Fundamentals - COC2073

 Typical Processes

▪ Triggering Processes
- Processes that trigger other processes
- Processes execution on a certain event

▪ Actions on stored data (CRUD)

- Create
- Read
- Update
- Delete

126 Software Engineering Fundamentals - COC2073

 Process - Correct / Incorrect?
5.0
Service Performed Create Invoice
Invoice

Policy No. Apply Payment Amount

Insurance

2.1
Hours Worked Calculate Pay Rate
Gross Pay

127 Software Engineering Fundamentals - COC2073

 Data Flow

▪ Is a path for data to move from one part of the

system to another
▪ Arrows depicting movement of data
▪ Can represent flow between process and data
store by two separate arrows
2.0
Payments Detail
Post Accounts
Payment
D1
Payments Detail Receivable

128 Software Engineering Fundamentals - COC2073

 Data Store

▪ Is used to represent data that the system

stores
▪ Labels should be noun phrases

D1 Students

129 Software Engineering Fundamentals - COC2073

 Context Diagram

▪ Top-level view of system

▪ Shows the system boundaries, external

entities that interact with the system, and
major information flows between entities and
the system

▪ Example: Order system that a company uses

to enter orders and apply payments against a
customer’s balance
130 Software Engineering Fundamentals - COC2073
 Context Diagram - Order System

131 Software Engineering Fundamentals - COC2073

 Level 0 - DFD

▪ Shows the system’s major processes, data

flows, and data stores at a high level of
abstraction

▪ When the Context Diagram is expanded into

DFD level-0, all the connections that flow into
and out of process 0 needs to be retained

132 Software Engineering Fundamentals - COC2073

 Level 0 - DFD

133 Software Engineering Fundamentals - COC2073

 DFD vs. Flow Charts

▪ Processes on a data ▪ Processes on

flow can operate in flowcharts are
parallel. sequential.
▪ Looping and ▪ Show the sequence
branching are of steps as an
typically not shown. algorithms and
▪ Each process path hence looping and
may have a very branching are part
different timing of flowcharts

134 Software Engineering Fundamentals - COC2073

 DFD-Bank Account Management System

Reconcile Deposit Other

Monthly A/C
Account Statement Funds into Income
Balance an Account Sources
Bank
Accounts

Account Employer
Transactions

Withdraw
Pay
funds from
Bill
an Account

Bank Creditor

135 Software Engineering Fundamentals - COC2073

 Patient Management System

136 Software Engineering Fundamentals - COC2073

 PMS – Level 0 DFD

Vital signs
Patient

Request for
Patient
Report
Monitoring
System

Report
Nurse Warning Message

137 Patient Monitoring

Software Engineering System
Fundamentals - COC2073(PMS)
 PMS – Level 1 DFD
Vital signs
Patient Patient Bounds

Local Patient data

Monitoring Vital signs
Bounds

Warning Message Central

Nurse
Report Monitoring

Request for
Report Log data
Report Patient Logs
Generator

138 Software Engineering Fundamentals - COC2073

 PMS – Level 2 DFD
Vital sign
Patient Pulse bounds
data Unpack Patient Bounds
Temperature
Signs

Evaluate Blood pressure,

Blood pressure temperature and pulse
Bounds
Violation
Violation

Produce Format
Date time
Warning Clock Patient
Message Data
Warning Formatted
messages patient data

139 Software Engineering Fundamentals - COC2073

 Illegal Data Flows

Patient Doctor

A process is
needed to
Patient exchange data Doctor
between
external agents

140 Software Engineering Fundamentals - COC2073

 Illegal Data Flows

Patient Data
Source

A process is
needed to Data
Patient update a data Source
store

141 Software Engineering Fundamentals - COC2073

 Illegal Data Flows

Data Data
Source Source

A process is
Data needed to
copy data from Data
Source Source
one data store
to another

142 Software Engineering Fundamentals - COC2073

 Common Mistakes in DFD

143 Software Engineering Fundamentals - COC2073

 Practice Session

144 Software Engineering Fundamentals - COC2073

 Class Activity

▪ Draw the Data Flow Diagram of Fast Food

Burger Bar Ordering System

145 Software Engineering Fundamentals - COC2073

 Proposed Solution (Context Diagram)

CUSTOMER
KITCHEN

Customer Order
Food Ordering Food Order
Receipt System Prepared Food

Management
Reports

RESTAURANT
MANAGER

146 Software Engineering Fundamentals - COC2073

 Proposed Solution (Level 0 Diagram)

CUSTOMER
KITCHEN

Customer Order
Food Ordering Food Order
Receipt System Prepared Food

Store Management
Data Reports

RESTAURANT
Inventory MANAGER

147 Software Engineering Fundamentals - COC2073

 Proposed Solution (Level 1 Diagram)
CUSTOMER KITCHEN
Receive and
Customer Order transform
Customer Food Order
Receipt Food Order Prepared Food

Update Goods Inventory Update

Sold Data Inventory Data
Goods Inventory
Sold file file
Goods Sold
Data

Goods Inventory
D2 D1
Sold File Produce File
Management
Reports Daily Inventory Depletion Amounts
Daily Goods Sold Amount

RESTAURANT
Management Reports
MANAGER

148 Software Engineering Fundamentals - COC2073

 Decision Tables

149 Software Engineering Fundamentals - COC2073

 Decision Tables

▪ Used to lay out in tabular form all possible

situations which a decision may encounter
and to specify which action to take in each of
these situations

▪ A matrix representation of the logic of a

decision

▪ Specifies the possible conditions and the

resulting actions
150 Software Engineering Fundamentals - COC2073
 Decision Tables - Components

▪ Condition
‒ Condition describe the conditions or factors that
will affect the decision or policy
‒ They are listed in the upper section of the
decision table

151 Software Engineering Fundamentals - COC2073

 Decision Tables - Components

▪ Action
‒ Action describe, in the form of statements, the
possible policy actions or decisions
‒ They are listed in the lower section of the
decision table

152 Software Engineering Fundamentals - COC2073

 Decision Tables

▪ Rules
‒ Rules describe which actions are to be taken
under a specific combination of conditions
‒ They are specified by first inserting different
combinations of condition attribute values and
then putting X's in the appropriate columns of
the action section of the table

153 Software Engineering Fundamentals - COC2073

 Decision Tables

Decision Rules
Condition Rule 1 Rule 2 Rule 3 Rule 4 Rule 5

Action

154 Software Engineering Fundamentals - COC2073

 Decision Table

Decision Rules
Rule 1 Rule 2 Rule 3 Rule 4
C1 Y Y Y Y
C2 Y N N N
C3 N N N N
A1 X
A2 X
A3 X X

An ambiguous decision table

155 Software Engineering Fundamentals - COC2073

 Example - Chemical Tracking System

1) Whether the user is authorized

2) Whether the chemical is available either in
the chemical stockroom or from a vendor
3) Whether the chemical is on the list of
hazardous chemicals that require special
training in safe handling
4) Whether the user has been trained in
handling this type of hazardous chemical

156 Software Engineering Fundamentals - COC2073

 Example - Chemical Tracking System

Requirement Number
Condition R1 R2 R3 R4 R5
User is authorized F T T T T
Chemical is available -- F T T T
Chemical is hazardous -- -- F T T
User is trained -- -- -- F T
Action
Accept request X X
Reject request X X X

157 Software Engineering Fundamentals - COC2073

 Decision Trees

158 Software Engineering Fundamentals - COC2073

 Decision Trees

▪ Map of a reasoning process

▪ Describes in a tree like structure

▪ A graphical representation of a decision

situation

▪ Decision situation points are connected

together by arcs and terminate in ovals

159 Software Engineering Fundamentals - COC2073

 Decision Trees - Components

‒ Decision points represented by nodes

‒ Actions Top
‒ Particular choices from a decision point
represented by arcs (or straight lines)

Down

Left Right

160 Software Engineering Fundamentals - COC2073

 Example - Chemical Tracking System

No No
Reject Accept
request request

Yes
Authorized? Hazardous? Yes Accept
request

Yes Yes
Available? Trained?

No No Reject
Reject
request request

161 Software Engineering Fundamentals - COC2073

 Example - Chemical Tracking System

No No
Reject Accept
request request

Yes
Authorized? Hazardous? Yes Accept
request

Yes Yes
Available? Trained?

No No Reject
Reject
request request

162 Software Engineering Fundamentals - COC2073

 Example - Chemical Tracking System

No No
Reject Accept
request request

Yes
Authorized? Hazardous? Yes Accept
request

Yes Yes
Available? Trained?

No No Reject
Reject
request request

163 Software Engineering Fundamentals - COC2073

 Think!!!

Decision Tables
OR
Decision Trees???

164 Software Engineering Fundamentals - COC2073

 Practice Session

165 Software Engineering Fundamentals - COC2073

 Task

▪ A marketing company wishes to construct a decision

table to decide how to treat clients according to three
characteristics:
1) Gender
2) City Dweller
3) Age Group: A(under 30), B(b/w 30 and 60), C(over 60)
▪ The company has four products (W, X, Y and Z) to
test market
‒ Product W will appeal to male city dwellers
‒ Product X will appeal to young males
‒ Product Y will appeal to Female middle aged shoppers
who do not live in cities
‒ Product Z will appeal to all but older males
166 Software Engineering Fundamentals - COC2073
 1. Identify Conditions & Values

▪ The three data attributes tested by the

conditions in this problem are
a) Gender, with values M and F;
b) City Dweller, with value Y and N;
c) Age group, with values A(under 30), B(b/w 30
and 60), C(over 60)

167 Software Engineering Fundamentals - COC2073

 2. Compute Maximum No. of Rules

▪ The maximum number of rules is:

2 x 2 x 3 = 12

168 Software Engineering Fundamentals - COC2073

 3. Identify Possible Actions

▪ The four actions are:

1) Market product W
2) Market product X
3) Market product Y
4) Market product Z

169 Software Engineering Fundamentals - COC2073

 4. Enter All Possible Conditions

Decision Rules
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12
Gender M F M F M F M F M F M F
City Y Y N N Y Y N N Y Y N N
Age A A A A B B B B C C C C

170 Software Engineering Fundamentals - COC2073

 5. Define Actions for each Rule

Decision Rules
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12
Gender M F M F M F M F M F M F
City Y Y N N Y Y N N Y Y N N
Age A A A A B B B B C C C C
Action
W X X X
X X X
Y X
Z X X X X X X X X X X

171 Software Engineering Fundamentals - COC2073

 Requirements Validation

172 Software Engineering Fundamentals - COC2073

 Characteristics of Good Requirements

Numbered Inspected Unambiguous

Testable Complete Consistent

Understandable Traceable Feasible

Modifiable

173 Software Engineering Fundamentals - COC2073

 Requirements Validation

Elicitation Analysis

Validation Specification

174 Software Engineering Fundamentals - COC2073

 Requirements Validation

▪ Requirements validation is the process of

checking that requirements actually define the
system that the customer really wants

▪ Requirements validation is important because

errors in a requirements document can lead
to extensive rework costs when these
problems are discovered during development
or after the system is in service

175 Software Engineering Fundamentals - COC2073

 Requirements Validation

▪ Requirement validation is an iterative process

that ensures that customer requirements are
accurately and clearly specified in the SRS
document

176 Software Engineering Fundamentals - COC2073

 Requirements Validation - Techniques

Requirements Requirements
Walkthroughs
Review Inspection

Test-Case
Reading Prototyping
Generation

Models to check
Interviews functions and Scenarios
relationships

177 Software Engineering Fundamentals - COC2073

 Requirements Validation - Techniques

▪ Requirements Review
- Requirements Review is a formal process of
requirement validation
- Performed by group of people
- Review plan is prepared in which
o Review team is selected
o Time & place of meeting is decided
- The review team checks the SRS for
completeness and consistency
- Feedback of individual team member

178 Software Engineering Fundamentals - COC2073

 Requirements Validation - Techniques

▪ Requirements Inspection
- Similar to review
- Effective way for detect defect at early stages
- Defects are detected and corrected

179 Software Engineering Fundamentals - COC2073

 Requirements Validation - Techniques

▪ Requirements Inspection

Moderator • provides documents for inspection

Organizer • holds the inspection meeting

Producer • explains the document in front of inspectors

• understand the document and identify defects

Inspectors in the requirement artifacts

Reader • collects, document and compile the defects

180 Software Engineering Fundamentals - COC2073

 Requirements Validation - Techniques

▪ Walkthroughs
- In this approach, one of the document’s author
presents the requirements to the rest of the
stakeholders and ask for feedback
- Walkthroughs work best when there are a large
numbers of varied stakeholders

181 Software Engineering Fundamentals - COC2073

 Requirements Validation - Techniques

▪ Test-Case Generation
- Ensures that requirements are good enough for
the product and planning activities
- It removes defects before a project starts and
during the project execution and development
- The product manager and tester select and review
the high priority requirements
- Black box test cases are created for the
requirements for inspection

182 Software Engineering Fundamentals - COC2073

 Requirements Validation - Techniques

▪ Reading
- Reader applies knowledge to find the defects
- There are various reading techniques
a) Ad-Hoc Based Reading
- Documents are given to reviewers without any
guidelines
- Detection of defects are based on experience and
knowledge of reviewer
b) Checklist Based Reading
- Set of questions is given to the reviewer as a checklist
- Covers the quality characteristics of requirements

183 Software Engineering Fundamentals - COC2073

 Requirements Validation - Techniques

▪ Prototyping
- It is used to understand, analyze and validate the
requirements
- In this approach, an executable model of the
system is demonstrated to end- users and
customers
- Developed in incremental manner
- In each increment defects are identified and
discussed with stockholders and corrective
actions are taken

184 Software Engineering Fundamentals - COC2073

 Software Prototyping

185 Software Engineering Fundamentals - COC2073

 Software Prototyping

▪ Software prototyping makes the requirements

more real and closes gaps in understanding
of the requirements

▪ Prototyping puts a mock-up of a new system

▪ Early feedback on prototypes helps the

stakeholders arrive at a shared understanding
of the system’s requirements

186 Software Engineering Fundamentals - COC2073

 Types of Software Prototyping

1. Horizontal Prototypes

2. Vertical Prototypes

3. Throwaway Prototypes

4. Evolutionary Prototypes

187 Software Engineering Fundamentals - COC2073

 1. Horizontal Prototypes

▪ Also called Behavioral Prototype or Mock-up

▪ It doesn’t dive into all the layers of an

architecture or into system details but depicts
a portion of the user interface

▪ This type of prototype lets you explore some

specific behaviors of the intended system,
with the goal of refining the requirements

188 Software Engineering Fundamentals - COC2073

 2. Vertical Prototypes

▪ Also known as Structural Prototype

▪ It implements a slice of application
functionality from the user interface through
the technical services layers
▪ A vertical prototype works like the real system
is supposed to work because it touches on all
levels of the system implementation
▪ Develop a vertical prototype when you’re
uncertain whether a proposed architectural
approach is feasible or not
189 Software Engineering Fundamentals - COC2073
 3. Throwaway Prototypes

▪ Build a throwaway prototype to answer

questions, resolve uncertainties, and improve
requirements quality

▪ Throwaway prototype emphasizes quick

implementation and modification over
robustness, reliability, performance, and long-
term maintainability

190 Software Engineering Fundamentals - COC2073

 3. Throwaway Prototypes

▪ The throwaway prototype is most appropriate

when the team faces uncertainty, ambiguity,
incompleteness, or vagueness in the
requirements

▪ A prototype that helps users and developers

visualize how the requirements might be
implemented can reveal gaps in the
requirements

191 Software Engineering Fundamentals - COC2073

 3. Throwaway Prototypes

Use case Throwaway Detailed user

Dialog Map
description prototype interface design

feedback feedback
feedback

Activity sequence from use cases to user interface design using a throwaway
prototype

192 Software Engineering Fundamentals - COC2073

 4. Evolutionary Prototypes

▪ An evolutionary prototype provides a solid

architectural foundation for building the
product incrementally as the requirements
become clear over time

▪ Evolutionary prototyping is a component of

the spiral software development life cycle
model and of some object-oriented software
development processes

193 Software Engineering Fundamentals - COC2073

 4. Evolutionary Prototypes

▪ In contrast to the quick-and-dirty nature of

throwaway prototyping, an evolutionary
prototype must be built with robust,
production-quality code from the outset

▪ An evolutionary prototype must be designed

for easy growth and frequent enhancement,
so developers must emphasize software
architecture and solid design principles

194 Software Engineering Fundamentals - COC2073

 4. Evolutionary Prototypes
Gather Use
Requirements
Refine user
requirements Begin next
increment

Develop throwaway Construct Construct vertical

horizontal prototype evolutionary prototype
prototype

Design User Design Software

Verify and deliver
Interface architecture
increments

Construct and
verify product

Deliver product

Possible ways to incorporate prototyping into the software development process

195 Software Engineering Fundamentals - COC2073

 Recap

▪ Software Requirement Engineering

▪ Levels of Requirements
▪ Software Quality Factors
▪ Requirements Engineering Process
▪ Use-Case Modeling
▪ Activity Diagrams
▪ Data Flow Model
▪ Decision Tables & Decision Trees
▪ Requirements Validation Techniques
196 Software Engineering Fundamentals - COC2073
 Questions

197 Software Engineering Fundamentals - COC2073