What is “Requirements Engineering (RE) ?

• The process of defining, documenting, and maintaining requirements in the

engineering design process.
• Requirements are descriptions of what a system should do, how it should behave, and
the constraints it must operate under.
The requirements engineering process
• The establishment and use of sound engineering principles
to gather, analyze, document and review software
requirements can be called software requirements
engineering.
• Requirements engineering can be divided into two main set
of activities
• Requirements Definition
• Requirement Management
 Requirements Definition

1. Requirements Elicitation or gathering of Requirements - collecting and identifying the requirements for a
system or project from various stakeholders, such as customers, end-users, business analysts, and subject matter
experts.

2. Requirements analysis or modeling - Requirements are gathered, modeled and analyzed using modeling tools
such as DFD, object oriented modeling techniques, ERD, etc.

3. Requirements documentation – Here the Requirements that are gathered and modeled are put together in a
document, typically know as the SRS

4. Requirements Review – This consists of, reviewing the SRS by all stakeholders. The reviewed and approved SRS
forms the basis for the work products to be created in the later parts of the Software life cycle.
Requirements Management

⚫ Change Management - This involves systematic handling of changes to agreed

requirement (SRS) during the course of the project.
⚫ Requirements Traceability - This consists of maintaining traceability of requirements
between the agreed (and changed) SRS and the other work products (like design
documents and test plans) created downstream in the SW life cycle, and upstream to the
origin of a requirement as well (backward traceability).
Requirements elicitation

• Stages include:
• Requirements discovery,
• Requirements classification and organization,
• Requirements prioritization and negotiation,
• Requirements specification.
Requirement Elicitation - Process activities

• Requirements discovery
• Interacting with stakeholders to discover their requirements. Domain requirements
are also discovered at this stage.
• Requirements classification and organization
• Groups related requirements and organizes them into coherent clusters.
• Prioritization and negotiation
• Prioritizing requirements and resolving requirements conflicts.
• Requirements specification
• Requirements are documented and input into the next round of the spiral.
Requirement Elicitation - Gathering

 Captures information from the view point of various users to identify what is
to be built
Requirement Elicitation - Evaluation

 The requirements that have been gathered have to be evaluated to

resolve inconsistencies and also to understand why each requirement has
been stated.

 For every requirement X, get answers to question, “why do you need X?”
Requirement Elicitation - Prioritization

 Determines the relative importance of the requirement

 The requirements are typically prioritized based on cost, dependency, and

user needs. Knowing the rationale behind each requirement helps in
deciding the priority.
Requirement Elicitation - Consolidation

 Brings together the information collected from the previous steps into a set
of requirements consistent with the goals identified during fact finding.
 Consolidation is required to put together all the requirements in a way that
can be analyzed further.
Requirements Analysis and Design

• Usually done with the use of a systems modeling technique(s)

• Appropriate models for the proposed system
• Unified Modeling Language (UML) -
 Class Diagram
 Use Cases
 Activity Diagrams
• Data Flow Diagrams
• Entity Relationship Diagrams
• Develop Prototypes
Requirements Documentation

• The software requirements document is the official statement of what is required of the
system developers.
• Should include both a definition of user requirements and a specification of the
system requirements.
Requirements Review

 During a requirement review, individuals or teams scrutinize the

documented requirements to identify any inconsistencies, ambiguities,
contradictions, or missing elements.
Requirements
Determination
 Introduction

 The systems development process transforms the existing (as is) system into the proposed (to
be) system
 Requirements determination
 The single most critical step of the entire SDLC
 Changes can be made easily in this stage
 Most (>50%) system failures are due to problems with requirements
 The iterative process of OOSAD is effective because:
 Small batches of requirements can be identified and implemented incrementally
 The system will evolve over time
Requirements Determination

 Purpose: to convert high level business requirements (from the

system request) into detailed requirements that can be used as
inputs for creating models
 What is a requirement?
 A statement of what the system must do or a characteristic it must have
 Will later evolve into a technical description of how the system will be
implemented
 Types:
 Functional: relates to a process or data
 Non-functional: relates to performance or usability
Requirements Definition

 Functional & non-functional requirements listed in outline format

 May be prioritized
 Provides information needed in subsequent workflows
 Defines the scope of the system
Sample of Requirements Definition
Determining Requirements

 Business & IT personnel need to collaborate

 Strategies for problem analysis:
 Root cause analysis
 Duration analysis
 Activity-based costing
 Informal benchmarking
 Outcome analysis
 Technology analysis
 Activity elimination
Determining Requirements

 Requirements are best determined by systems analysts and

business people together
 Techniques for identifying requirements
 Interviews, questionnaires and/or observation
 Joint application development (JAD)
 Document analysis
Interviews

 Gather facts, opinions and speculations

 Observe body language and emotions
 Guidelines
 Plan
 Checklist
 Appointment

 Be neutral
 Listen
 Seek a diverse view
Interviews Steps

Selecting Interviewees
 Based on information needs
 Best to get different perspectives
 Managers
 Users
 Ideally, all key stakeholders
 Keep organizational politics in mind
Designing Interview Questions
 Types of Questions
 Closed-Ended Questions
 How many telephone orders are received per day?
 How do customers place orders?
 What additional information would you like the new system to provide?
 Open-Ended Questions
 What do you think about the current system?
 What are some of the problems you face on a daily basis?
 How do you decide what types of marketing campaign to run?
 Probing Questions
 Why?
 Can you give me an example?
 Can you explain that in a bit more detail?
 Organizing Interview Questions
 Unstructured interview useful early in information gathering
 Goal is broad, roughly defined information
 Structured interview useful later in process
 Goal is very specific information
 Interview Preparation Steps

o Prepare general interview plan

 List of question
 Anticipated answers and follow-ups
o Confirm areas of knowledge
o Set priorities in case of time shortage
o Prepare the interviewee
 Schedule
 Inform of reason for interview
 Inform of areas of discussion
 Conducting the Interview
 Appear professional and unbiased
 Record all information
 Check on organizational policy regarding tape recording
 Be sure you understand all issues and terms
 Separate facts from opinions
 Give interviewee time to ask questions
 Be sure to thank the interviewee
 End on time
JOINT APPLICATION DESIGN (JAD)

 Joint Application Development

 A structured group process focused on determining requirements
 Involves project team, users, and management working together
 May reduce scope creep by 50%
 Very useful technique
Questionnaires

 A set of written questions, often sent to a large number of people

 Mostly closed-ended questions
 May be paper-based or electronic
 Select participants using samples of the population
 Design the questions for clarity and ease of analysis
 Administer the questionnaire and take steps to get a good response rate
 Questionnaire follow-up report
Document Analysis

 Study of existing material describing the current system

 Forms, reports, policy manuals, organization charts describe the formal system
 Look for the informal system in user additions to forms/report and unused form/report elements
 User changes to existing forms/reports or non-use of existing forms/reports suggest the system
needs modification
 Types of information to be discovered:
 Problems with existing system
 Opportunity to meet new need
 Organizational direction
 Names of key individuals
 Values of organization
 Special information processing circumstances
 Rules for processing data
Observation

 Watch processes being performed

 Serves as a good method to supplement interviews
 Users/managers often don’t accurately recall everything they do
 Checks validity of information gathered other ways
 Be aware that behaviors change when people are watched
 Often difficult to obtain unbiased data
 Be unobtrusive
 Identify peak and lull periods
Determining Requirements

 Three techniques help users discover their needs for the new system:
Business Process Automation (BPA)
Business Process Improvement (BPI)
Business Process Reengineering (BPR)
Creating a
Requirements Definition

 Determine the types of functional and non-functional requirements

applicable to the project
 Use requirements-gathering techniques to collect details
 Analysts work with users to verify, change and prioritize each requirement
 Continue this process through analysis workflow, but be careful of scope
creep
 Requirements that meet a need but are not within the current scope can
be added to a list of future enhancements
Problems in
Requirements Determination

 Analyst may not have access to the correct users

 Requirements specifications may be inadequate
 Some requirements may not be known in the beginning
 Verifying and validating requirements can be difficult
Requirements Analysis Strategies

Business Process Automation

Identifying Improvements in As-Is Systems
 Problem analysis
 Ask users to identify problems with the current system
 Ask users how they would solve these problems
 Good for improving efficiency or ease-of-use
 Root cause analysis
 Focus is on the cause of a problem, not its solution
 Create a prioritized list of problems
 Try to determine their causes
 Once the causes are known, solutions can be developed
 Requirements Analysis
Strategies(Cont.)
Business Process Improvement
 Duration analysis
 Determine the time required to complete each step in a business process
 Compare this to the total time required for the entire process
 Large differences suggest problems that might be solved by:
 Integrating some steps together
 Performing some steps simultaneously (in parallel)

 Activity-based costing
 Same as duration analysis but applied to costs
 Benchmarking
 Studying how other organizations perform the same business process
 Requirements Analysis
Strategies(Cont.)

Business Process Reengineering Steps

 Outcome analysis
 What does the customer want in the end?
 Technology analysis
 Apply new technologies to business processes & identify benefits
 Activity elimination
 Identify what would happen if each organizational activity were eliminated
 The System Proposal

 Combines all material created in planning & analysis

 Included sections:
 Executive summary
 Provides all critical information is summary form
 Helps busy executives determine which sections they need to read in more detail
 The system request
 The workplan
 The feasibility analysis
 The requirements definition
 Current models of the system (expected to evolve)