RQ1: Describe Requirements Analysis

Requirements analysis
l specifies software’s operational characteristics.
l indicates software's interface with other system elements.
l establishes constraints that software must meet.

Requirements analysis allows the software engineer to:

l elaborate on basic requirements established during earlier requirement
engineering tasks.
l build models that depict the user’s needs from several different perspectives.

1
RQ2 : Does Analysis Model Work as a
Bridge?

2
RQ3 : Describe Requirements Modeling Principles

• Principle 1. The information domain of a problem must be

represented and understood.
• Principle 2. The functions that the software performs must be
defined.
• Principle 3. The behavior of the software (as a consequence
of external events) must be represented.
• Principle 4. The models that depict information, function,
and behavior must be partitioned in a manner that uncovers
detail in a layered (or hierarchical) fashion.
• Principle 5. The analysis task should move from essential
information toward implementation detail.

3
 Non-Functional Requirements
Non-functional requirements are the ones that act to
constrain the solution. Non-functional requirements are
some times known as constraints or quality
requirements.
Ø Often apply to the system as a whole rather than individual
features or services
Ø They can be further classified according to whether they
are performance requirements, maintainability
requirements, safety requirements, reliability
requirements or one of many other types of software
requirements

4
Types of nonfunctional requirement
 Non-functional classifications

l Product requirements
l Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
l Organisational requirements
l Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation requirements,
etc.
l External requirements
l Requirements which arise from factors which are external to the system
and its development process e.g. interoperability requirements,
legislative requirements, etc.
 Metrics for specifying nonfunctional
requirements

Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
 Emergent Properties
l Some requirements represent emergent properties of software;
that is, requirements which cannot be addressed by a single
component, but which depend for their satisfaction on how all
the software components interoperate.
l For example, the throughput requirement for a call center
would depend on how the telephone system, information
system, and the operators all interacted under actual
operating conditions.
l Emergent properties are crucially dependent on the system
architecture
Emergent properties are characteristics or behaviors that arise
from the interactions of simpler components within a system,
which cannot be predicted simply by analyzing those components
in isolation.

These properties often manifest at a higher level of complexity 8

 Quantifiable Requirements

l Software requirements should be stated as clearly and as

unambiguously as possible, and, where appropriate,
quantitatively
l It is important to avoid vague and unverifiable requirements
which depend for their interpretation on subjective judgment
e.g.the software shall be reliable; the software shall be user-
friendly
l This is particularly important for non-functional requirements
e.g. a call center's software must increase the center ’ s
throughput by 20%; and a system shall have a probability of
generating a fatal error during any hour of operation of less
than 1*10-8

9
 Requirements Elicitation
l Requirements elicitation is concerned with where software
requirement come from and how the software engineer can
collect them
l It is the first stage in building an understanding of the problem
the software is required to solve
l One of the fundamental tenets of good software engineering is
that there be good communication between software users and
software engineers
l The process through which the customers, buyers, users of a
software system discover, reveal, articulate and
understand their requirements.
10
The requirements elicitation and
analysis process

11
 General Elicitation Procedure

l Five Steps
l Identify relevant source of requirements
l Ask appropriate questions to gain an understanding of
their needs.
l Analyze the gathered information, looking for implications,
inconsistencies, or unresolved issues.
l Confirm your understanding of the requirements with
the users.
l Synthesize appropriate statements of the requirements
 Requirements Sources
Goals : The term goal or business concern or critical success
factor refers to the overall, high level objective of the
software.
Domain Knowledge : The software engineer needs to
acquire, or have available, knowledge about the
application domain. This enables them to infer tacit
knowledge that the stakeholders do not articulate,
assess the trade-offs that will be necessary between
conflicting requirements
Stakeholders : Much software has proved unsatisfactory
because it has stressed the requirement of one group of
stakeholder at the expense of those of others. The
software engineers needs to identify, represent, and
manage the ‘view-points’ of many different types of
stakeholders 13
 Requirements Sources
The Operational Environment : Requirements will be
derived from the environment in which the software
will be executed. These may be, e.g. timing constraints
in real-time software or interoperability constraints in
an office environment. These must be actively sought
out, because they can greatly affect software cost, and
restrict design choices
The organizational environment : Software is often
required to support a business process, the selection
of which may be conditioned by the structure, culture,
and internal politics of the organization. The software
engineer needs to be sensitive to these, since, in
general, new software should not force unplanned 14
change of the business process
 Deliverables and Outcomes

l Deliverables for Requirements Determination:

l From interviews and observations
l interview transcripts, observation notes, meeting
minutes
l From existing written documents
l mission and strategy statements, business forms,
procedure manuals, job descriptions, training
manuals, system documentation, flowcharts
l From computerized sources
l Joint Application Design session results, CASE
repositories, reports from existing systems, displays
and reports from system prototype

15
Requirements evolution

16
Problems of requirements elicitation

l Stakeholders don’t know what they really want.

l Stakeholders express requirements in their own terms.
l Different stakeholders may have conflicting requirements.
l Organisational and political factors may influence the
system requirements.
l The requirements change during the analysis process.
New stakeholders may emerge and the business
environment may change.

17
Methods of Requirement Elicitation
 Methods of Requirement Elicitation

l Background Reading
l Study of Documents and software systems
l Interviewing Customers and Domain Expert
l Questionnaires
l Observation/Ethnography
l Prototyping
l Brainstorming
l JAD (Joint Application Development)
l RAD (Rapid Application Development)
 Background Reading

l Company reports
l Job description
l Policy manuals
l Documentation of existing systems
l Organization charts

Study the following Document

IGDTUW “Regulations for the Undergraduate and Post
Graduate Degree Programs”
Analyzing Procedures and Other Documents
l Document Analysis
l Review of existing business documents
l Can give a historical and “formal” view of system
requirements

• 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
• Reasons for current system design
21 • Rules for processing data
Analyzing Procedures and Other Documents (Cont.)

l Useful document: Written Work Procedure

l For an individual or work group
l Describes how a particular job or task is performed
l Includes data and information used and created in the
process

l Potential Problems with Procedure Documents:

l May involve duplication of effort
l May have missing procedures
l May be out of date
l May contradict information obtained through interviews

22
Analyzing Procedures and Other Documents (Cont.)

l Useful document: Report

l Primary output of current system
l Enables you to work backwards from the report to the data
needed to generate it
l Useful Documents: Business form
l Used for all types of business functions
l Explicitly indicates what data flow in and out of a system
and data necessary for the system to function
l Gives crucial information about the nature of the
organization
l Useful document: Description of current information
system

23
 Interviewing and Listening
l One of the primary ways analysts gather information
about an information systems project
l An interview guide is a document for developing,
planning and conducting an interview.

Guidelines for Effective Interviewing

• Plan the interview.
• Prepare interviewee: appointment, priming questions.
• Prepare agenda, checklist, questions.
• Listen carefully and take notes (tape record if permitted).
• Review notes within 48 hours.
• Be neutral.
• Seek diverse views.
24
Interviewing and Listening (Cont.)

25
FIGURE Typical interview guide
Interviewing and Listening (Cont.)

26
FIGURE Typical interview guide (cont.)
Choosing Interview Questions

l Each question in an interview guide can include both

verbal and non-verbal information.
l Open-ended questions: questions that have no
prespecified answers
l Closed-ended questions: questions that ask those
responding to choose from among a set of specified
responses

27
Interviewing Guidelines

l Don’t phrase a question in a way that implies a right or

wrong answer.
l Listen very carefully.
l Type interview notes within 48 hours after the interview.
l Don’t set expectations about the new system unless you
know these will be deliverables.
l Seek a variety of perspectives from the interviews.

28
 Interviewing Groups
l Drawbacks to individual interviews:
l Contradictions and inconsistencies between
interviewees
l Follow-up discussions are time consuming
l New interviews may reveal new questions that require
additional interviews with those interviewed earlier

l Interviewing several key people together

Advantages
l More effective use of time

l Can hear agreements and disagreements at once

l Opportunity for synergies

Disadvantages
29 l More difficult to schedule than individual interviews
 Questionnaires
l Questionnaires are special-purpose documents that allow
the analyst to collect information and opinions from
respondents
l The document can be mass produced and distributed to
respondents, who can then complete the questionnaires or
their own time.
l Questionnaires allows the Analyst to collect facts from a
large number of people while maintaining uniform
responses.

While dealing with the audience, no other fact-

finding technique can tabulate the same facts as
efficiently as Questionnaires.
 Questionnaires
l Used in addition to interviews not in lieu of them
l Less productive than interview
Questionnaires are of two Types
l Open-ended question should be avoided.
l Close ended questions should be used

While both types of questionnaires are useful:

l the fixed-format questionnaire has the advantage of
lending itself to rapid machine tabulation.
l For this reason, it is the type of questionnaire most
frequently employed, particularly when large numbers of
people are being surveyed.
 Questionnaires

Three forms of Close Ended Questions

l Multiple choice questions
l Rating Questions
l Ranking questions

Various formats of Questionnaires

Sample Feedback in form of Questionnaires

Home Work: Study and Analyse the student Feedback

32
Questionnaires of IITR, IITD, NITK and IGDTUW
Direct Observation
l Watching users do their jobs
l Used to obtain more firsthand and objective measures of
employee interaction with information systems
l Can cause people to change their normal operating behavior
l Time-consuming and limited time to observe

Types of Observations
l Passive observation
l Active observation
l Explanatory observation
Ethnography
l A social scientist spends a considerable time observing and
analysing how people actually work.
l People do not have to explain or articulate their work.
l Social and organisational factors of importance may be
observed.
l Ethnographic studies have shown that work is usually richer and
more complex than suggested by simple system models.
l Ethnography is a research method that involves the in-depth
study of people and cultures in their natural environments.
l Researchers/ethnographers, immerse themselves in the
community or social setting they are studying to observe and
sometimes participate in daily activities.
l Ethnographers keep detailed field notes to record their
observations, interactions, and reflections. These notes are
crucial for analyzing and interpreting the data collected. 34
Prototyping

l Most frequently used method

l Constructed to visualize the system to the customers
l A prototype is the demonstration system.
l Presents GUI and simulates system behaviour.
l Two types: throw-away and evolutionary
Using Prototyping During Requirements
Determination

l Quickly converts requirements to working version of

system
l Once the user sees requirements converted to
system, will ask for modifications or will generate
additional requests

36
Using Prototyping During Requirements Determination
(Contd...)

37
Using Prototyping During Requirements Determination
(Cont.)

Most useful when:

l User requests are not clear.
l Few users are involved in the system.
l Designs are complex and require concrete form.
l There is a history of communication problems
between analysts and users.
l Tools are readily available to build prototype.

38
Using Prototyping During Requirements Determination
(Cont.)

l Drawbacks
l Tendency to avoid formal documentation
l Difficult to adapt to more general user audience
l Sharing data with other systems is often not considered
l Systems Development Life Cycle (SDLC) checks are often
bypassed

39
 Brainstorming

l Conference technique.
l Not for problem analysis or for design making.
l Meant for generating new ideas and possible solutions
l Requires a person to lead and to moderate the session- the
facilitator
l Brainstorming applies to requirements elicitation because of
the difficulty of reaching consensus among stakeholder on
what the concrete requirements are
Brainstorming contd..
l Prior to the meeting, the facilitator should define the
Probortunity (Problem+opportunity) for which the ideas will
be generated
l Restricted to 12 to 20 people
l Ideas are prioritized
l Examples of trigger question in Brainstorming
l What features should be supported by the system?
l What are the input data and what are the output of the system?
l What questions should be raised in interviews or in
questionnaires
l What issues still need to be considered
l What are the main risks in the project
Joint Application Development
l Brainstorming like technique
l Introduced by IBM in late 1970.
l There are many consulting firms that offer the services of
organizing and running a JAD Sessions
l A JAD meeting can take a few hours, a few days or even a
couple of weeks
l Number of participants should not exceed 25 to 30.
l Meeting Participants are:-
l Leader :
l Scribe
l Customers
l Developers
JAD (Cont.)

43 FIGURE 6-6 Illustration of the typical room layout for a JAD

Source: Based on Wood and Silver, 1995.
Joint Application Design (JAD)

l Intensive group-oriented requirements determination

technique
l Team members meet in isolation for an extended period
of time
l Highly focused
l Resource intensive

44
Joint Application Development
l Leader :
l The person who conducts and moderates the meeting. This
person has excellent communication skills, is not a
stakeholder in the project and has a good knowledge of the
business domain
l Scribe
l The person who records the JAD session on computer. This
person should have touch-typing skills and should possess
strong knowledge of software development. The scribe can
use CASE tools to document the session and to develop initial
solution models
l Customers (users and managers)
l Are the main participants, who communicate and discuss
requirements, take decisions, approve project objectives etc.
l Developers
l Business analysts and other members of the development
team. They listen rather than speak – they are at the meeting
to find facts and gather information, not to dominate the
process
Joint Application Development

l JAD capitalizes on group dynamics.

l “Group Synergy” is likely to produce better solutions to
problems.
l Group increase productivity, learn faster, make more educated
judgment, eliminate more errors, take riskier decisions, focus
participants attention on the most important issues, integrate
people etc.
l When conducted according to rules, JAD session tend to
deliver surprisingly good outcomes
JAD End Result
l Documentation detailing existing system
l Features of proposed system

46
Rapid Application Development
l More than a requirements elicitation method
l Aims at delivering system solutions fast
l Technical excellence is secondary to the speed of delivery
l RAD combines five techniques:
l Evolutionary Prototyping
l CASE Tools with code generation
l SWAT (specialist with advance tools) – the RAD
development team
l The best analysts, designers, and programmers that the
organization can get. The team works under a strict time
regime and is co-located with the users
l Interactive JAD during which the scribe is replaced with
SWAT team with CASE Tools
l Time boxing – a project management method that imposes
a fixed time period on the SWAT team to complete the
project
Rapid Application Development

l RAD Objectives
l To cut development time and expense by involving the users in
every phase of systems development
l Successful RAD team must have IT resources, skills, and
management support
l Helps a development team design a system that requires a highly
interactive or complex user interface

48
Rapid Application Development

l RAD Phases and Activities

49
Problems Associated with RAD

l Inconsistent GUI designs

l Specialized rather than generic solution to facilitate software
reuse
l Deficient documentation
l Software that is difficult to maintain and scale up.
Radical Methods for Determining System
Requirements
l Business Process Reengineering (BPR): search for
and implementation of radical change in business
processes to achieve breakthrough improvements in
products and services
l Goals
l Reorganize complete flow of data in major sections of an
organization.
l Eliminate unnecessary steps.
l Combine steps.
l Become more responsive to future change.

51
 Disruptive Technologies
l Information technologies must be applied to radically improve
business processes.
l Disruptive technologies are technologies that enable the
breaking of long-held business rules that inhibit organizations
from making radical business changes.

52
The Relationship between Information Gathering and Model
Building
Home Work

Study and present the following Research Paper

Requirements engineering for autonomous vehicles: a systematic literature review
Authors: Quelita A. D. S. Ribeiro, Moniky Ribeiro, Jaelson Castro

Proceedings of the 37th ACM/SIGAPP Symposium on Applied Computing

https://doi.org/10.1145/3477314.3507004

54