CSCI3907: Software Engineering

Fall 2023
Stephen H. Kaisler, D.Sc.

Week 3
Lecture 3b: Requirements Engineering - II
 Requirements Gathering
• Analysts gather requirements through:
– Observation of existing system(s)
– Studying existing procedures
– Discussions w/ customers, stakeholders, and end-users
– Analysis of the problem description and what needs to be done.
• If the project is to automate existing procedures, observe how
humans do it now, what they think the problems are, and what
suggestions they have.
– Watch once quietly; watch again w/ commentary; watch again with
questions
• In the absence of a working system, some imagination will be
required:
– Need to visualize how problems are solved
– Work with customers to understand their experiences

09/16/2023 CSCI 6231 - Software Engineering 3b-2

Stephen H. Kaisler, D.Sc.
 Data Gathering Techniques - I
• Questionnaires: A series of questions designed to elicit
specific information from users.
– The questions may require different kinds of answers: some
require a simple Yes/No, others ask user to choose from a set
of pre-supplied answers.
• Interviews: Interviews involve asking someone a set of
questions.
– Often interviews are face-to-face, but they don’t have to be
– Forum for talking to people
– Structured, unstructured, or semi-structured
– Props, e.g. sample scenarios of use, prototypes, can be used
in interviews
– Good for exploring issues
– But are time consuming and may be infeasible to visit everyone

09/16/2023 CSCI 6231 - Software Engineering 3b-3

Stephen H. Kaisler, D.Sc.
 Data Gathering Techniques - II
• Focus groups and workshops:
– Interviews tend to be one on one, and elicit only one person’s
perspective.
– It can be very revealing to get a group of stakeholders together to
discuss issues and requirements.
• Naturalistic Observation: It can be very difficult for humans to
explain what they do or to even describe accurately how they
achieve a task.
– Spend time with users in their day-to-day tasks, observing work
as it happens
– Gain insights into users’ tasks
– Good for understanding the nature and context of the tasks
– But, it requires time and commitment from a member of the
requirements and design team, and it can result in a huge
amount of data

09/16/2023 CSCI 6231 - Software Engineering 3b-4

Stephen H. Kaisler, D.Sc.
 Data Gathering Techniques - III
• Studying documentation: Procedures and rules are
often written down in a manual and these are a good
source of data about the steps involved in an activity and
any regulations governing a task.

• What are the constraints on data gathering?

– Time
– Money (e.g., budget)
– Availability of people
– Subject Matter Expertise
– Security
– Existing systems (e.g., transition, compatibility, user model,…)

09/16/2023 CSCI 6231 - Software Engineering 3b-5

Stephen H. Kaisler, D.Sc.
 Scenarios - I
• Scenarios
– Usually the first step in establishing requirements
– An informal narrative story of users’ tasks
– Describe
• What users are doing or
• How to achieve something
• Example: In an informal interview, one potential user
answered the question
” How to arrange a meeting
between several people
in the shared-calendar system ?”

09/16/2023 CSCI 6231 - Software Engineering 3b-6

Stephen H. Kaisler, D.Sc.
 Use Case - I
• A simple scenario for a system:
User :
– types in all the names of the meeting participants
– length of the meeting
– when is the meeting
– where is the meeting.
System:
– checks against the individuals’ calendars and the central
departmental calendar
– More…

• Use cases
– A special kind of scenario that breaks down system
requirements into user functions
– Use case is a sequence of events performed by a user
– Interaction between user and a system

09/16/2023 CSCI 6231 - Software Engineering 3b-7

Stephen H. Kaisler, D.Sc.
 Use Case - II
A sequence of events to arrange a meeting:
• 1. The user chooses the option to arrange a meeting.
• 2. The system prompts user for the names of attendees.
• 3. The user types in a list of names.
• 4. The system checks that the list is valid.
• 5. The system prompts the user for meeting constraints.
• More steps…

• Use UML to draw a graphical diagram

• Sometimes, a picture is more instructive since it shows
the interaction

09/16/2023 CSCI 6231 - Software Engineering 3b-8

Stephen H. Kaisler, D.Sc.
 Use Case - III

Need to drill down in each box to identify objects, actions and flows.

09/16/2023 CSCI 6231 - Software Engineering 3b-9

Stephen H. Kaisler, D.Sc.
 Hierarchical Task Analysis - I
• Requirements capture tasks to be performed by the user and/or the
system.
• Task descriptions versus Task analysis
– Task descriptions are often used to envision new systems or devices
– Task analysis is used mainly to investigate an existing situation
• Start with a user goal which is examined and the main tasks for
achieving it are identified
– Top-down analysis
• Involves breaking a task down into subtasks, then sub-sub-tasks
and so on.
• These are grouped into plans which specify how the tasks might be
performed in practice

• There are many other techniques

09/16/2023 CSCI 6231 - Software Engineering 3b-10

Stephen H. Kaisler, D.Sc.
 Hierarchical Task Analysis - II
0. In order to borrow a book from the library
1. go to the library
2. find the required book
2.1 access library catalogue
2.2 access the search screen
2.3 enter search criteria
2.4 identify required book
2.5 note location
3. go to correct shelf and retrieve book
4. take book to checkout counter

plan 0: do 1-3b-4. If book isn’t on the shelf as expected, do 2-3b-4.

plan 2: do 2.1-2.4-2.5. If book not identified do 2.2-2.3b-2.4.

09/16/2023 CSCI 6231 - Software Engineering 3b-11

Stephen H. Kaisler, D.Sc.
 Why Requirements Traceability?
• Traceability is concerned with the relationships between
requirements, their sources, and the system design.
– To ensure that the system has fully implemented the
requirements.
– Note: while not part of requirements process activities – it needs
to be started early.
• Trace requirements:
– Requirements from source (people and documents)
– Requirements from the existing system (specific modules or
functions)
– Requirements to later stages (design, implementation, test, &
release) – when you get there!!
• We need to link requirements to other “pre-requisite”
requirements.
09/16/2023 CSCI 6231 - Software Engineering 3b-12
Stephen H. Kaisler, D.Sc.
 Traceability Matrix
• Used for a reasonable number of requirements:
 A “U” is used when a requirement in a row uses the facilities of the
requirement in the column
 An “R” is used when there is a weaker relationship (e.g.
requirements are part of the same sub-system)

09/16/2023 CSCI 6231 - Software Engineering 3b-13

Stephen H. Kaisler, D.Sc.
 Traceability Table
Requirement Design Code Test Other related
requirements
1 compon. X Module 3 Test Case 32 2,3

2 compon. w Module 5 Test Case 16 1

compon. X Test Case 27
3 Module 2 1

09/16/2023 CSCI 6231 - Software Engineering 3b-14

Stephen H. Kaisler, D.Sc.
 Requirements Recap
• Detecting that a problem exists is different from defining the problem
and its causes, and solution constraints.
• Problems arise from many sources:
– Threats from adversaries
– Technology drivers
– Competition
– New product ideas
• Example: Health Monitoring:
– Problem: User is leading unhealthy lifestyle and experiencing health
problems
– Cause A: User is trying to be active but unsure about sufficient level of
activity
– Cause B: User is trying to be active but too busy with other duties
– Cause C: User cannot find affordable solutions for active lifestyle
– Cause D: User has poor sleep
– Cause E: User is aware of issues but not motivated to act
09/16/2023 CSCI 6231 - Software Engineering 3b-15
Stephen H. Kaisler, D.Sc.
 Requirements Validation - I
• Requirements are not desires!
• They are statements of explicit functions to be performed by the
system or explicit capabilities possessed by the system.
• Validation is the process of ensuring that the requirements actually
define the system that the customer wants and is an acceptable
description of the system to be implemented

Why is it important?

• The cost of fixing a requirements problem by making a system

change after code is written is much greater than repairing design
or coding errors.

09/16/2023 CSCI 6231 - Software Engineering 3b-16

Stephen H. Kaisler, D.Sc.
 Requirements Validation - II
• Validation Objectives:
– Completeness, Correctness, Consistency, Coherency
– Conformance to standards
– Identify Requirements conflicts
– Free from Technical errors
– Resolve ambiguous requirements
• Analysis works with raw requirements as elicited from
the system stakeholders
– “Have we got the right requirements” is the key question to be
answered at this stage
• Validation works with a final draft of the requirements
document, i.e., with negotiated and agreed
requirements
– “Have we got the requirements right” is the key question to be
answered at this stage
09/16/2023 CSCI 6231 - Software Engineering 3b-17
Stephen H. Kaisler, D.Sc.
 Requirements Validation - III
Questions to ask:
• Are the requirements correct? They must be stated without error.
• Are the requirements consistent? No conflicting or unambiguous
statements.
• Are the requirements complete? (Almost) All possible situations
must be described.
• Are the requirements realistic? Can the system be really built, e.g.,
is the technology available and not prohibitively expensive?
• Does each requirement specify something needed? Beware
extraneous requirements, but also unusual constraints.
• Are the requirements verifiable? Can they be tested and
demonstrated to have been met when the system is built?
• Are the requirements traceable? Can the requirements be traced
through to the system functions that satisfy them?

09/16/2023 CSCI 6231 - Software Engineering 3b-18

Stephen H. Kaisler, D.Sc.
 Requirements Validation - IV
• Validation inputs:
– Requirements document
• Should be a formatted and organized complete version of the
document, not an unfinished draft.
– Organizational knowledge
• Knowledge, often implicit, of the organization which may be used
to judge the realism of the requirements
– Organizational standards
• Local standards, e.g., for the requirements document
– Problem list
• List of discovered problems in the requirements document
– Agreed actions
• List of agreed actions re: requirements problems. Some
problems may have several corrective actions; some problems
may have no associated actions

09/16/2023 CSCI 6231 - Software Engineering 3b-19

Stephen H. Kaisler, D.Sc.
 Requirements Validation Processes - I
• System Requirements Review (SRR): Systematic manual analysis of the
requirements
– Stakeholders
– Requirements Analysts
– Subject Matter Experts (if necessary)
– System designers
• Prototyping: constructing executable models of parts of the system to test
viability
– Simulations
– Mathematical models
– DARPA Seedlings
• Test Case Generation: construct written test cases to determine if the
requirements can be tested eventually during the System Testing stage.
• Use a CASE Tool:
– Automatic checking of requirements formally represented in a logic language
– Rational ROSE

09/16/2023 CSCI 6231 - Software Engineering 3b-20

Stephen H. Kaisler, D.Sc.
 System Requirements Review
• A group of people read and analyze the requirements,
look for problems, meet and discuss the problems and
agree on actions to address these problems

09/16/2023 CSCI 6231 - Software Engineering 3b-21

Stephen H. Kaisler, D.Sc.
 Review Team Membership
• Reviews should involve a number of stakeholders drawn from
different backgrounds
– People from different backgrounds bring different skills and
knowledge to the review
– Stakeholders feel involved in the RE process and develop an
understanding of the needs of other stakeholders
• Review team should always involve at least a domain expert and
an end-user
• Review Team should involve the requirements gathering/analysis
team.
• Review team should include a system developer to assess the
feasibility of implementing a requirement.

09/16/2023 CSCI 6231 - Software Engineering 3b-22

Stephen H. Kaisler, D.Sc.
 Types of Problems?
• Requirements clarification
– The requirement may be badly expressed or may have
accidentally omitted information which has been collected during
requirements elicitation.
• Missing information
– Some information is missing from the requirements document. It
is the responsibility of the requirements engineers who are
revising the document to discover this information from system
stakeholders.
• Requirements conflict
– There is a significant conflict between requirements. The
stakeholders involved must negotiate to resolve the conflict.
• Unrealistic requirements
– A requirement does not appear to be implementable with the
technology available or given other constraints on the system.
Stakeholders must be consulted to decide how to make the
requirement more realistic.

09/16/2023 CSCI 6231 - Software Engineering 3b-23

Stephen H. Kaisler, D.Sc.
 User Manuals
• Yes, you need these!!
• Writing a user manual from the requirements forces a
detailed requirements analysis and thus can reveal
problems with the SRD.
• Information in the user manual
– Description of the functionality and how it is implemented
– Which parts of the system have not been implemented
– How to get out of trouble
– How to install and get started with the system

09/16/2023 CSCI 6231 - Software Engineering 3b-24

Stephen H. Kaisler, D.Sc.
 Requirements Diagrams
• A diagram can help to explain what has to be done.
• Ex: Data Flow Diagram for Library Item Issue

09/16/2023 CSCI 6231 - Software Engineering 3b-25

Stephen H. Kaisler, D.Sc.
 Issue Description

09/16/2023 CSCI 6231 - Software Engineering 3b-26

Stephen H. Kaisler, D.Sc.
 Requirements Testing
NOTE: We discuss here to get you to think about whether a
requirement is testable or not as you write it. The System Test
Plan is written later.
• The System Test Plan (STP) is written from both the finalized SRD
and the System Design Document (SDD).
– Start writing the STP after the final SRD has been approved.
• Each requirement should be testable.
– It should be possible to define tests to check whether or not that
requirement has been met.
• Creating requirements tests are an effective validation technique.
– Missing or ambiguous information in the requirements description may
make it difficult to formulate tests.
• Each functional requirement should have an associated test.
– A requirements test should test one and lonely one requirement.

09/16/2023 CSCI 6231 - Software Engineering 3b-27

Stephen H. Kaisler, D.Sc.
 The Test Case - I
• Requirements ID from the SRD:
– There should be at least one for each requirement.
• Related requirements
– These should be identified with the requirement.
– These should be referenced as the test may depend on their
results or they may depend on this test case’s result.
• Test description
– A brief prose description of the test and why this is an objective
requirements test.
– This should include system inputs and corresponding outputs.
• Input/Outputs:
– More detail on each as an itemized list.

09/16/2023 CSCI 6231 - Software Engineering 3b-28

Stephen H. Kaisler, D.Sc.
 The Test Case - II
• Requirements Problems:
– A description of problems which made test definition difficult to
write.
– You should suggest correction action, but this may/will
necessitate another round of review of the requirements and
revision to the SRD.
• Test File Name
• Test Steps: <may be filled in later>
• Test Results: <shown in final test document>
• Successful Test: <tester initials>, <test date>

09/16/2023 CSCI 6231 - Software Engineering 3b-29

Stephen H. Kaisler, D.Sc.
 The Test Form
• Documents the test performed and the results:
• Requirement(s) Tested: <<IDs>>
• Related Requirements:
– << results from other requirements>>
– << results affecting other requirements>>
• Test(s) Applied:
– << file name and function names(s)..
• Test Results: <success/failure/partial success>>
• Problems: <<itemized list of problems w/ possible
suggested corrective actions, if known>>

09/16/2023 CSCI 6231 - Software Engineering 3b-30

Stephen H. Kaisler, D.Sc.
 Test Coverage
Axiom: You cannot exhaustively test everything.
• Test Coverage estimates how much of the system that is
built is actually tested
• There is a difference between testing all of the system
and testing all of the requirements.
• System design and development can expand upon the
requirements and introduce functions that may not be
covered by the test plan.
– Thus, the System Test Plan must be evolved as system design
and development proceed.

09/16/2023 CSCI 6231 - Software Engineering 3b-31

Stephen H. Kaisler, D.Sc.
 Hard To Test Requirements - I
• System requirements:
– Requirements which apply to the system as a whole.
– In general, these are the most difficult requirements to validate
irrespective of the method used as they may be influenced by any of
the functional requirements.
– Tests cannot test for non-functional system-wide characteristics such
as usability.
• Often need a sophisticated test harness that allows for:
– End-to-end system testing
– Control and display of multiple parameters
– Gathering of designated variables for near-time and later
analysis
– Scripting of tests for automatic testing
– Dynamic visualization of internal sates of the system

09/16/2023 CSCI 6231 - Software Engineering 3b-32

Stephen H. Kaisler, D.Sc.
 Hard To Test Requirements - II
• Exclusive requirements
– These are requirements which exclude specific system behavior.
– For example, a requirement may state that system failures must
never corrupt the system database.
– It is not possible to test such a requirement exhaustively.
• Some non-functional requirements
– Some non-functional requirements, such as reliability requirements,
can only be tested with a large test set.
– Designing this test set does not help with requirements validation.
– May require multiple tests with sophisticated data gathering to
ascertain the results

Axiom: “Absence of evidence

is not evidence of absence!”
09/16/2023 CSCI 6231 - Software Engineering 3b-33
Stephen H. Kaisler, D.Sc.
 Requirements Change Management - I
Axiom: Requirements Change!
• How to manage this process?
• Stakeholders submit proposals for requirements changes using a
pre-defined form.
• The proposed change is analysed to see:
– if it is reasonable
– if it is valid. Sometimes stakeholders misunderstand the
requirements and suggest unnecessary changes.
– how many requirements and system components are affected
– how much it would cost, in both time and money, to make the
change
– what the benefits of the change are.
• Note: Just because changes are proposed does not mean any
or all have to be accepted.

09/16/2023 CSCI 6231 - Software Engineering 3b-34

Stephen H. Kaisler, D.Sc.
 Requirements Change Management - II
• Change requests are considered formally by a group or a person
who decide(s) whether or not the change should be accepted.
– Changes can correct missing requirements or information
– Changes can correct errors in stated requirements
– Changes may remove requirements due to infeasibility
• If the change is accepted:
– Update the requirements document.
– Inform all the necessary stakeholders.
• During system design, establish milestones for completing design
elements:
– Accept no changes when <TBD>% of the design has been completed on any
system element.
– Design is an iterative process
– May have to revisit requirements if system design identifies missing,
erroneous, or infeasible requirements

09/16/2023 CSCI 6231 - Software Engineering 3b-35

Stephen H. Kaisler, D.Sc.
 Requirements Engineering: Challenges - I
• Experienced analysts:
– take considerable time to understand the exact requirements
that the customer has in mind.
– Know that w/out a clear understanding of the problem, it is not
possible to develop a satisfactory system.
• In the initial set of requirements, there will always be
inconsistencies and anomalies:
– Some are easy to detect because of language
– Some are very subtle, require deep understanding
– Some will not surface until you start to design and/or develop the
system
• If new requirements are added after design/development
begins, may generate new inconsistence and anomalies
w/ what has already been done.
09/16/2023 CSCI 6231 - Software Engineering 3b-36
Stephen H. Kaisler, D.Sc.
 Requirements Engineering: Challenges - II
• Problems w/ SRDs:
• Narrative Description: often difficult to
understand
– Difficult to change Language Problems
– Difficult to be precise
– Difficult to be unambiguous
– Allows scope for contradictions
• Noise: Test may contain irrelevant information
about the problem, the environment, etc.
• Silence: important aspects are omitted

09/16/2023 CSCI 6231 - Software Engineering 3b-37

Stephen H. Kaisler, D.Sc.
 Requirements Engineering: Challenges - III
• Overspecification:
– Wandering into the “how to” aspects of system design
– Ex: “Library names should be stored in a sorted
ascending order”
– Restricts the flexibility of the solution space for the
designer
• Contradictions:
– Often arise, if the same concept is described in
several places in the document
– Often, difficult to find until the design/development
phases

09/16/2023 CSCI 6231 - Software Engineering 3b-38

Stephen H. Kaisler, D.Sc.
 Requirements Engineering: Challenges - IV
• Ambiguity:
– Literary expressions
– Unquantifiable aspects, e.g. “good user interface”
• Forward References:
– References to aspects of problem which are defined only later
on in the text.
• Wishful Thinking:
– Descriptions of aspects
• For which realistic solutions will be hard to find
• Or, “bells and whistles” beyond the basic functionality

09/16/2023 CSCI 6231 - Software Engineering 3b-39

Stephen H. Kaisler, D.Sc.
 Requirements Engineering: Challenges - V
• Axiom: Customers don’t often know what they want:
– While they may be able to articulate high-level goals and
objectives, extracting detailed functionality is often difficult if a
working system does not exist.
– Attempt to identify the assumptions the customer is making –
They know what they do, but you don’t! So, they may glide over
items that they believe are not important.
– Never let them say “That’s not important!”
– Question everything, no matter how mundane or trivial it may
seem.
– Revisit requirements if mentioned again to be sure there is not
something added or conflicting with previous statements.
– For major subsystems, write a concrete vision statement.

09/16/2023 CSCI 6231 - Software Engineering 3b-40

Stephen H. Kaisler, D.Sc.
 Requirements Engineering Challenges - VI
Axiom: You will have to accept some changes to
requirements after the SRD is approved.
• Changes occur because the system design may clearly
elucidate functions and data structures that are needed
in the solution.
• Make sure any changes are approved by the appropriate
stakeholder and decision-maker.
• In the case of conflicting opinions, try to achieve
consensus, including reduction in scope, of the change.
Remember!! Requirements engineering and system
design – taken together – is an iterative process.

09/16/2023 CSCI 6231 - Software Engineering 3b-41

Stephen H. Kaisler, D.Sc.
 Requirements Engineering Challenges - VII
Axiom: Customers have unreasonable timelines.
• Yesterday is often not soon enough!
• You will hear” This an emergency and we need this done
in <timeframe>!”
• Don’t readily agree to such declarations.
• Conduct an analysis first to understand scope and
resources to execute it.
– It most likely will draw resources away from some other critical
element
– If your project is already late, it will become even later (Brooks).
• Negotiate, Negotiate!!
Axiom: Usually something has to give way to do this!

09/16/2023 CSCI 6231 - Software Engineering 3b-42

Stephen H. Kaisler, D.Sc.
 Requirements Engineering Challenges - VIII
Axiom: There will usually be a gap in understanding
between the customer and the engineers!
• May lead to confusion and misunderstanding over goals,
objectives, and contractual terms.
• Precision is required during the requirements analysis
phase.
• Restate requirements several ways.
• Take notes at every meeting; disseminate to all
attendees.
• Use consistent terminology!
• Step by step agreement is often necessary.

09/16/2023 CSCI 6231 - Software Engineering 3b-43

Stephen H. Kaisler, D.Sc.
 Requirements Engineering Challenges - IX
Axiom: Customer organization politics is extremely
important!
• In a customer organization, there is power, conflict,
negotiation, and coalitions!
• Understand who are the key deciders, the key power
brokers, and the channels to both.
• Who has the data and knowledge – cultivate them!

09/16/2023 CSCI 6231 - Software Engineering 3b-44

Stephen H. Kaisler, D.Sc.
 Data Gathering Summary

09/16/2023 CSCI 6231 - Software Engineering 3b-45

Stephen H. Kaisler, D.Sc.
 Functional Requirements Example - I
• List all functional requirements with proper
numbering.
• Requirement 1: Select “Search” Option
– Once the user selects the “search” option,
• s/he is asked to enter the key words for:
– Author
– Title
– Subject
– <<Some combination of the above>
– The system should output details of all books:
• whose title or author name matches any of the key
words entered.
• Details include: Title, Author Name, Publisher
Name, Year of Publication, ISBN Number, Catalog
Number, Location in the Library.

09/16/2023 CSCI 6231 - Software Engineering 3b-46

Stephen H. Kaisler, D.Sc.
 Functional Requirements Example - II
• Requirement 2: Select Renew Option
– When the “renew” option is selected,
• the user is asked to enter his membership number and
password.
– After password validation,
• the list of the books borrowed by him are displayed
• perhaps with due dates
• Maybe notation if book has been requested by someone
else
– The user can renew any of the books:
• by clicking in the corresponding renew box
• unless the book has been requested by someone else
• or, the maximum number of renewals has been reached

09/16/2023 CSCI 6231 - Software Engineering 3b-47

Stephen H. Kaisler, D.Sc.
 Functional Requirements Example - III
• R.1.1:
– Input: “search” option,
– Output: user prompted to enter the key words.

• R1.2:
– Input: key words
– Output: Details of all books whose title or author
name matches any of the key words.
• Details include: Title, Author Name, Publisher name, Year of
Publication, ISBN Number, Catalog Number, Location in the
Library.
– Processing: Search the book list for the keywords

09/16/2023 CSCI 6231 - Software Engineering 3b-48

Stephen H. Kaisler, D.Sc.
 Functional Requirements Example - IV
• R2.1:
– Input: “renew” option selected,
– Output: user prompted to enter his membership
number and password.

• R2.2:
– Input: membership number and password
– Output:
• list of the books borrowed by user are displayed. User
prompted to enter books to be renewed or
• user informed about bad password
– Processing: Password validation, search books
issued to the user from borrower list and display.

09/16/2023 CSCI 6231 - Software Engineering 3b-49

Stephen H. Kaisler, D.Sc.
 Functional Requirements Example - V
• R2.3:
– Input: user choice for renewal of the books issued to
him through mouse clicks in the corresponding renew
box.
– Output: Confirmation of the books renewed
– Processing: Renew the books selected by the in the
borrower list.

09/16/2023 CSCI 6231 - Software Engineering 3b-50

Stephen H. Kaisler, D.Sc.
 Review Checklist - I
• Consistency
– Do the descriptions of different requirements include
contradictions?
– Are there contradictions between individual requirements and
overall system requirements?
• Organization
– Is the document structured in a sensible way?
– Are the descriptions of requirements organized so that related
requirements are grouped?
• Conformance to standards
– Does the requirements document and individual requirements
conform to defined standards?
– Are departures from the standards, justified?

09/16/2023 CSCI 6231 - Software Engineering 3b-51

Stephen H. Kaisler, D.Sc.
 Review Checklist - II
• Traceability
– Are requirements unambiguously identified?
– Include links to related requirements and to
the reasons why these requirements have
been included?
• Understandability
– Can readers of the document understand
what the requirements mean?
• Redundancy
– Is information unnecessarily repeated in the
requirements document?
09/16/2023 CSCI 6231 - Software Engineering 3b-52
Stephen H. Kaisler, D.Sc.
 Review Checklist - III
• Completeness
– Does the checker know of any missing
requirements?
– Is there any information missing from
individual requirement descriptions?
• Ambiguity
– Are the requirements expressed using terms
which are clearly defined?
– Could readers from different backgrounds
make different interpretations of the
requirements?
09/16/2023 CSCI 6231 - Software Engineering 3b-53
Stephen H. Kaisler, D.Sc.
 Stable vs. Mutable Requirements
• Stable requirements are derived from the core
activity of the customer organisation.
– Ex: A hospital will always have doctors, nurses, etc.
– Requirements may be derived from domain models
• Mutable requirements: Requirements which
change during development or when the system
is in use.
– Ex: In a hospital, requirements derived from health-
care policy

09/16/2023 CSCI 6231 - Software Engineering 3b-54

Stephen H. Kaisler, D.Sc.
 Volatile Requirements
• Mutable requirements:
– Requirements that change due to the system’s
environment
• Emergent requirements:
– Requirements that emerge as understanding of the system
develops
• Consequential requirements:
– Requirements that result from the introduction of the
computer system (change of working processes)
• Compatibility requirements:
– Requirements that depend on other systems or
organisational processes

09/16/2023 CSCI 6231 - Software Engineering 3b-55

Stephen H. Kaisler, D.Sc.