LETS BREAK AN ICE

WHO I AM?

USMAN RAFIQUE ZUBERI

MASTERS IN PROJECT MANAGEMENT FROM FAST-NU
CURRENTLY WORKING @VENTUREDIVE AS HEAD OF PROCESS ENGINEERING
PREVIOUSLY WORKED AT: FOLIO3, MAZIK, MIXIT, SAKONENT, AXACT
SERVED CLIENTS LIKE BARNES & NOBLES, SAP, MICROSOFT, VISTAJET AND ETC.
MANAGED STREAM OF PROJECTS: SALESFORCE, GAMES, MOBILE AND WEB
APPLICATIONS.

SKYPE: XOBERI
EMAIL: USMANZUBERI@MSN.COM
GMAIL: XOBERI@GMAIL.COM
TELL ME ABOUT YOURSELF
Your Name?
Your so far understanding about Requirement Engineering?
Your expectation from this course?
MY RULES

• Pay attention to class lectures and discussions.

• Use of Mobile/Cell phones is strictly prohibited. If there is an emergency then you can inform and take your
call/attend text outside the class.
• I am honest and would like you all to be honest as well.
• I would like to share as many knowledge as I have.
• Punctuality: 9 Means 9.
• Minimum required attendance percentage is 75%.
WHAT IS A REQUIREMENT? WHAT FACTOR? WHAT
CLIENT NEEDS

• Simple definition – WHAT FACTOR? What is required by the client?

• Example of Requirements:
 I need to generate financial reports against my booking data.
 System should be able to generate a list of patients who are expected to attend appointments that day.
 SDLC Vs Requirement Engineering Phase

• Inception
• Elicitation
• Analysis
• Specifications
• Validation
 Ingredients of Journey from
Requirements to Specifications
5W1H Interrelationships
LEVEL/CLASSIFICATION OF REQUIREMENTS

• Written for Customers – User Requirements – Could be written in plain natural language with the help
of diagrams.
• Written as a contract between Client and Contractor/Vendor – System Requirements
• Written for Developers – Software Specifications – Functional and Non Functional
• Another type of Requirement is Constraints - “Pseudo Requirement” – Imposed by the client or an
environment
• Explicit – Software Requirements
• Implied – Quality Requirements
• Unimagined
Group Activity
INGREDIENTS FOR GOOD REQUIREMENT

• Correct
• Complete
• Consistent
• Ranked
• Verifiable
• Modifiable
• Traceable
BAD REQUIREMENTS – TESTER’S NIGHTMARE

• Missing Requirements
• Conflicting Requirements
• Incomplete or Unclear Requirements
HOW BAD REQUIREMENTS LOOK LIKE?

• “The system shall be completely reliable”

• “The system shall be maintainable”
• “Order rejections shall be less than 99%”
• “The system shall be fast”
• “The system should use artificial intelligence”
• “The system should be totally modular
WHAT YOU CAN DO TO GET ALL AND CLEAR REQUIREMENTS?

• Workshops with Stake holders

• Emails
• Meeting Notes
• Wireframes
THE REQUIREMENT TIPS
• Don’t Gather Requirements – Dig for Them
• Work with a User to Think Like a User
• Abstractions Live Longer than Details
• Don’t be too specific. Good requirement documents remain abstract.
• Requirements
• Are NOT architecture
• Are NOT design, NOR user interface
• Are need
REQUIREMENT MANAGEMENT

• Enduring
• Volatile – Mutable, Emergent,
Compatibility
• Documents/Process/Traceability
Matrix
REQUIREMENT ENGINEERING

• Requirements engineering is primarily a communication activity –

not a technical activity
• Requirements engineering is one of the most challenging aspects
of software development
• It is also the most important aspect, as it lays the foundation for all
the subsequent project work
SOME IMPORTANT CONCEPTS AROUND SCOPE STATEMENT,
FUNCTIONAL AND NON FUNCTIONAL REQUIREMENTS
• Scope statement means we need a house.
• Functional requirement is, we need doors that can be locked,
we need windows through which we could get fresh air. (how
you want things to work)
• Non Functional Requirement would be – it must comply with
building regulations.
• Business Requirements explains why and what of the project.
• Functional Requirements explains how of the project.
PRODUCT VS PROJECT

• Product requirements prescribe properties of a system or

product.
• Process requirements prescribe activities to be performed
by the developing organization. For instance, process
requirements could specify the methodologies that must
be followed, and constraints that the organization must
obey.
EXAMPLE OF BRD

• Vision of the project

• Objectives of the project
• Context or background of the project
• Scope of the project
• Stakeholder identification
• Detailed Business Requirements
• Scope of the solution
• Project constraints: Time Frame, Cost of the Project, and Available resource
EXAMPLE OF FUNCTIONAL REQUIREMENT
DOCUMENT

• Purpose of the project

• Scope of the project
• Detailed functional requirements
• Non-functional requirements
• Assumptions/constraints
• Representation of functional requirements using Information Architecture
REQUIREMENT STATUSES
• Proposed (someone suggested it)
• In Progress
• Drafted
• Approved (it was allocated to a baseline)
• Implemented (the code was designed, written, and unit tested)
• Verified (the requirement passed its tests after integration into the product)
• Deferred (the requirement will be implemented in a future release)
• Deleted (you decided not to implement it at all)
• Rejected (the idea was never approved)
Context Diagram And Use Cases Along
with Relationships
Context Diagram
• “The objective of a system context diagram is to focus attention on external
factors and events that should be considered in developing a complete set of
system requirements and constraints.”
• The goal is to get feedback from a project’s stakeholders and identify any
missing pieces while the project is still in the discovery stage.
• What are Parts of Context Diagram?
ESTABLISHING THE CONCEPT

• Establish the context of the system by identifying the actors that surround it
• For each actor, consider the behavior that each expects or requires the system to provide
• Name these common behaviors as use cases
• Factor common behavior into new use cases that are used by others; factor variant behavior into new
use cases that extend more main line flows
• Model these use cases, actors, and their relationships in a use case diagram
• Adorn these use cases with notes that assert nonfunctional requirements; you may have to attach some
of these to the whole system.
Use Case and Use Case Model Diagram
WHAT IS A USE CASE

• A requirements analysis concept.

• A case of a use of the system/product
• Describes the system's actions from a the point of view of a use.
• Tells a story.
• A sequence of events involving
• Interactions of a user with the system
• Specifies one aspect of the behavior of a system, without specifying the
structure of the system • Is oriented toward satisfying a user's goal
WHAT IS AN ACTOR

• Include all user roles that interact with the system.

• Include system components only if they responsible
for initiating/triggering a use case.
• Includes anyone who produce or consumes data.
EXAMPLE OF ACTORS
FINDING ACTORS?

• Who are the system’s primary users?

• Who requires system support for daily tasks?
• Who are the system’s secondary users?
• What hardware does the system handle?
• Which other (if any) systems interact with the system in question?
• Do any entities interacting with the system perform multiple roles as actors?
• Which other entities (human or otherwise) might have an interest in the
system's output?
USE CASE DIAGRAM OBJECTIVE

• Specify the context of a system.

• Capture the requirements of a system.
• Validate a systems architecture.
• Drive implementation and generate test cases.
• Developed by analysts and domain experts
LINKING USE CASES
• Association relationships
• Generalization relationships • One element (child) "is based on"
another element (parent) •
• Include relationships • One use case (base) includes the
functionality of another (inclusion case) supports re-use of
functionality
• Extend relationships • One use case (extension) extends the
behavior of another (base)
GENERALIZATION EXAMPLE
DETAILED GENERALIZATION EXAMPLE
STATEMENT OF WORK

• In other words Problem Statement is known as statement of work.

• A good problem statement describes
• Current Situation
• Functionality the new system should support
• Environment in which system would be deployed
• Deliverables expected by the client
• Delivery dates
• Set of Acceptance Criteria
HOW DO I FIND USE CASES?

• Select a narrow vertical slice of the system (i.e. one scenario)

• Discuss it in detail with the user to understand the user’s preferred style of interaction
• Select a horizontal slice (i.e. many scenarios) to define the scope of the system.
• Discuss the scope with the user
• Use illustrative prototypes (mock-ups) as visual support
• Find out what the user does
• Task observation (Good)
• Questionnaires (Bad)
HOW DO WE FIND SCENARIOS?

• Engage in a dialectic approach (evolutionary, incremental engineering)

• You help the client to formulate the requirements
• The client helps you to understand the requirements
• The requirements evolve while the scenarios are being developed
• Greenfield Engineering Projects – building system from scratch.
 Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements
RE PROCESS AND RELATED ACTIVITIES

Why? Identify Business Needs and Goals

What? Derive User & Functional Requirements

Time
How? Design Solutions
TIME

Who? Project Management Process

When?
Risk Management Process
If-Then

Quality Management Process

Does It?
Component & Configuration Management Process
Where?