You are on page 1of 155

CSDPPreparationCourse

ModuleII:SoftwareRequirements

Specifications
The exam specific topics covered in this module are listed
below, and are the basis for the outline of its content.
A. Requirements Engineering Process
B. Requirements Elicitation
C. Requirements Analysis
D. Software Requirements Specification
E. Requirements Validation
F. Requirements Management

Module II. Software

Objectives
After completing this module, you should be able to
To present an overview of software requirements
engineering

Module II. Software

Organization
The organization of information for each specification topic is as
follows:
Topic Content Slides - detail the important issues concerning
each topic and support the module objectives
Topic Reference Slides - detail the sources for the topical
content and provides additional references for review
Topic Quiz Slides - allow students to prepare for the exam

Module II. Software

Introduction

What is Software?
software -- Computer programs, procedures, and possibly
associated documentation and data pertaining to the
operation of a computer system. Contrast with hardware.
[IE610]
What is a Requirement?
requirement -- (1) A condition or capability needed by a user
to solve a problem or achieve an objective. (2) 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 documents. (3) A
documented representation of a condition or capability as in
(1) or (2). [IE610]

Module II. Software

Introduction2
A Perspective

These definitions imply concern for the user of the software


as well as the developer.

Wiegers emphasizes that the term users in such a definition


should be generalized to stakeholders, because not all
stakeholders are users.

CAUTION: Dont assume that all your project stakeholders


share a common notion of what requirements are. Establish
definitions up front so that youre all talking about the same
things. [KW03, p. 8]

Module II. Software

Introduction3

Major Issues in Software Requirements


The incorrect and incomplete software requirements
specification
The truncation of requirements activities over programming
and testing
The lack of cooperation by customers:
To verify that the software requirements are correct
To understood the structure and purpose of the software
requirements specifications
The problems associated with identifying which tool and/or
methodology to use in developing and representing a
software requirements specification [RT04, p. 4-9]

Module II. Software

Introduction4

Fundamentals of Requirements
In order to properly identify a requirement, we may apply the
general property distinctions that the SWEEBOK Guide has
identified [SW04, p. D-3]:
Product and process requirements
Functional and non-functional requirements
Emergent properties
Quantifiable requirements
System requirements and software requirements

Module II. Software

Introduction5

Product and Process Requirements - I


Product parameter a requirement on software to be
developed
Product requirement Requirements which apply to the
product of services to be developed
Qualitative parameters not directly measurable
Functional What it does
External Interfaces Data or command inputs or
outputs
Quantitative parameters directly measurable
Performance metrics How fast, how much memory
Quality metrics Reliability, maintainability, security
[RT04, p. 4-13]

Module II. Software

Introduction6

Product and Process Requirements - II


Process parameter essentially a constraint on the
development of the software (AKA process requirements)
Process (Program) requirements Applies to the activities
associated with enabling the creation of a product or service
Task Perform and analyze, develop a product, operate
a system
Compliance evaluation Measure compliance with a
product parameter
Regulatory/Standards Compliance with laws,
standards, regulations, and rules

Module II. Software

10

Introduction7

Functional and Non-functional Requirements


Functional requirements describes functions software is to
execute
Example: formatting text
Non-functional requirements ones that act to constrain the
software solution
Further classes performance, maintainability, safety,
reliability, and others.

Module II. Software

11

Introduction8

Emergent Properties
Emergent properties those which cannot be addressed by
a single component, but system component interoperability
Highly sensitive to the system architecture
Sommerville provides three examples [IS01, p. 22]:
Overall weight of the system
Reliability of the system
Usability of the system

Module II. Software

12

Introduction9

Quantifiable Requirements
Avoid vague and unverifiable requirements which depend for
their interpretation on subjective judgment

This is critical for non-functional requirements

Module II. Software

13

Introduction10

System Requirements and Software Requirements


System requirements - are for the system as a whole;
sometimes referred to as user requirements
Includes hardware, software, firmware, people,
information, techniques, facilities, services, and other
support elements
Software requirements derived from system requirements

Module II. Software

14

Introduction11
Recognizing the Importance of Software Requirements
Engineering [RT04, p. 4-7]

Better quality in the software development process and the


software product can be obtained if our methods and tools
for gathering, modeling and analyzing user requirements are
more effective, robust and codified in practice, i.e. an
engineering approach

Therefore, software requirements engineering (SRE) has


emerged as an engineering approach to what used to be
called requirements analysis and specifications

Module II. Software

15

Introduction12
Role of Software Requirements in the Lifecycle [RT04, p. 4-17]

Describes what the user wants or needs done


Describes the final product, not methods and techniques
for building the software
Provides the basis for cost, schedule, and other resource
estimates

Primarily developed during the requirements phase of the


lifecycle

Can be developed in other phases of the lifecycle

Module II. Software

16

IntroductionQuiz
1. Which of the following requirement properties would be
considered an emergent property of a software program?
A.
B.
C.
D.

The fault detection system of the software


The programming language of the system
The reliability of the software
The number of lines of code

Module II. Software

17

IntroductionQuiz2
2. Which of the following would most likely be considered a
product requirement?
A. The software shall be written in Ada.
B. The student name shall be entered before the student grade.
C. The system requirements for the software shall be formatted
according to IEEE Std 1233.
D. The software is built with company standards.

Module II. Software

18

IntroductionQuiz3
3. Which of the following is most true about a non-functional
requirement?
A.
B.
C.
D.

Describes functions software is to execute.


Is highly sensitive to the system architecture.
Is derived from hardware requirements.
Acts to constrain the software solution.

Module II. Software

19

IntroductionReferences

[IE610] IEEE Std 610.12-1990, Standard Glossary of


Software Engineering Terminology
[IE1233] IEEE Std 1233-1998, Guide for Developing System
Requirements
[IS01] Sommerville, Ian, Software Engineering, 6th Edition,
Addison-Wesley, NY, 2001
[KW03] Weigers, Karl E., Software Requirements, 2nd
Edition, Microsoft Press, Redmond, WA, 2003
[RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 4: Software Requirements Engineering Concepts
[SW04] SWEBOK Guide to the Software Engineering Body
of Knowledge: 2004 Version, IEEE Computer Society, Los
Alamitos, CA, Chapter 2 Software Requirements

Module II. Software

20

A.RequirementsEngineering
Process
A Process Defined

process -- (1) A sequence of steps performed for a given


purpose; for example, the software development process.
(2) An executable unit managed by an operating system
scheduler. (3) To perform operations on data. [IE610]

Software requirements engineering (SRE) is a process, not a


discrete activity

Module II. Software

21

A.RequirementsEngineering
Process2
Software Requirements Engineering Process - I
1. Collect and categorize the various requirements
(requirements elicitation)
a. Identify relevant sources of requirements (usually the
customers)
b. Determine what information is needed (this will change
as the requirements are developed)
c. Collect the requirements from all parties

Module II. Software

22

A.RequirementsEngineering
Process3
Software Requirements Engineering Process - II
2. Analyze the gathered information, looking for implications,
inconsistencies, or unresolved issues (analysis)
3. Synthesize appropriate statements of the requirements
(specifications)
4. Confirm your understanding of the requirements with the
users (verification)
5. Plan and control the effort from beginning to end
(management) [RT04, p. 4-20]

Module II. Software

23

A.RequirementsEngineering
Process4
SRE Process Activities - I

Software requirements elicitation The process through


which the customers (buyers and/or users) and developers
(contractors) of a software system discover, review,
articulate, and understand their requirements

Software requirements analysis Reasoning and analyzing


the customers and users needs to arrive at a definition of
software requirements

Module II. Software

24

A.RequirementsEngineering
Process5
SRE Process Activities - II
Software requirements specification A document that clearly
and precisely records each of the requirements of the software
system
Software requirements verification The assurance that
software requirements specifications are in compliance with the
system requirements, conforms to document standards of the
requirements phase, and is an adequate basis for the
architectural (preliminary) design phase
Software requirements management - Planning and controlling
the requirements elicitation, analysis, and verification activities
[RT04, p. 4-19]

Module II. Software

25

A.RequirementsEngineering
Process6
Process Models

Provide a basic outline of the requirements process


Obtaining software requirements is not a discrete front-end
activity
Initiated at the beginning of the project, and is refined
throughout the life cycle
Software requirements are configuration items for
management
The process is adapted to the organization and the project
Four major activities: elicitation, analysis, specification, and
validation

Module II. Software

26

A.RequirementsEngineering
Process7
Process Actors - I

Those who participate in the process

The requirements specialist mediates between domain of the


stakeholder and software engineer

Always include users (or operators) and customers (they


may not be the same)

Module II. Software

27

A.RequirementsEngineering
Process8
Process Actors - II
Typical software stakeholders
Users Will operate software
Customers Commissioned the software
Market analyst Act as proxy customers
Regulators Authorities from application domains (EX:
banking,)
Software engineers Have a stake in reusing components
in successful products; must weigh their personal against
the stake of the customer
Must negotiate trade-offs with stakeholders to their satisfaction,
within project constraints
Stakeholders must be identified before this negotiation to occur
[SW04, p. 2-3]

Module II. Software

28

A.RequirementsEngineering
Process9
The Importance of Software Requirements
These People
Acquisition management
Project management
System engineers
Testers
SW engineers
Configuration control
Everyone
- [RT04, p. 4-22]

Depend on SW Req. to:


Establish their needs
Determine tasks and schedule
Req. allocated to SW
Establish what is to be tested
Establish top-level design
Establish req. baseline
Guide their effort

Module II. Software

29

A.RequirementsEngineering
Process10
Process Support and Management

Linked to the four major process activities: elicitation,


analysis, specification, and validation

Concerned with issue of cost, human resources, training,


and tools

Module II. Software

30

A.RequirementsEngineering
Process11
Process Quality and Improvement

Concerned with assessment of the process

Measured by cost, schedule, and customer satisfaction

Uses:
Process improvement standards and models
Requirements process measures and benchmarking
Improvement planning and implementation

Module II. Software

31

A.RequirementsEngineering
Process12
Other Issues in Software Requirements Engineering I

Requirements specifications often do not reflect the need


and desires of the users and the customer

Software requirements specifications are often incomplete


and incorrect

Users knowledge, experience, and cooperation greatly


influence the quality of the specifications

Developers knowledge of the customer domain greatly


influence the quality of the specifications

Module II. Software

32

A. RequirementsEngineering
Process13
Other Issues in Software Requirements Engineering II

Software requirements are constantly undergoing change

Requirements sometimes specify the software design (a


design constraint)

Design is changed without a corresponding change in


requirements [RT04, p. 4-22]

Module II. Software

33

A.References

[IE610] IEEE Std 610.12-1990, Standard Glossary of


Software Engineering Terminology
[RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 4: Software Requirements Engineering Concepts
[SW04] SWEBOK Guide to the Software Engineering Body
of Knowledge: 2004 Version, IEEE Computer Society, Los
Alamitos, CA, Chapter 2 Software Requirements

Module II. Software

34

A.Quiz
1. According to the SWEBOK Guide, what are the four major
activities of the requirements engineering process?
A.
B.
C.
D.

Identification, specification, construction, and testing


Elicitation, analysis, specification, and validation
Analysis, planning, construction, and verification
Elicitation, planning, construction, and testing

Module II. Software

35

A.Quiz2
2. Which of the following property is least critical to the
interaction between process actors and the requirements
process?
A.
B.
C.
D.

Process actor identification


The nature of their stake in the process
The education of the actor
The requirements they elicit

Module II. Software

36

A.Quiz3
3. The requirements engineering process is:
A. A discrete front-end activity of the software life cycle.
B. Initiated at the beginning of a project and continues to be
refined throughout the lifecycle.
C. A continuous process that ends when requirements are
specified and documented.
D. The same for each organization and process.

Module II. Software

37

A.Quiz4
4. Process quality and improvement relies most on which of the
following?
A.
B.
C.
D.

Product operator performance


Human factors
Requirements process measures
Customer preferences

Module II. Software

38

A.Quiz5
5. Product requirement validation occurs primarily after:
A.
B.
C.
D.

Elicitation
Analysis
Specification
Testing

Module II. Software

39

B.RequirementsElicitation
What is Requirements Elicitation?

Concerned with where software requirements come from


and how the software engineers can collect them.

Stakeholders are identified and relationships established


between the development team and the customer

Also known as requirements capture, requirements


discovery, and requirements acquisition [SW04, p. 2-4]

Module II. Software

40

B.RequirementsElicitation2
Major Issues Involving Requirements Elicitation - I

It is not always clear who your customers or users are.

Your customers/users cannot always state their requirements


clearly or completely.

Users dont know what they want; they only know what they
do.

What they say they want may not be what they need or you
may begin to define what you think they need, instead of
what they want.

Module II. Software

41

B.RequirementsElicitation3
Major Issues Involving Requirements Elicitation - II

Their concept of the solution may not solve their problem.

The customers or users will have expectations that may be


unreasonable or unknown to you.

Not all of your customers or users talk to or agree with one


another, so you must talk to all of them.

Your customers or users may change. [RT04, p. 4-25]

Module II. Software

42

B.RequirementsElicitation4
Requirements Sources - I
From the SWEBOK Guide [SW04, p. 2-4]
Goals
Sometimes called business concern or critical success
factor
Provides motivation for the software, but are often vaguely
formulated
Focus is to assess the value (relative priority) and cost of
goals
A feasibility study can do this at low cost
Domain knowledge The software engineer needs to be knowledgeable of the
application domain
Allows for assessment of that which is not articulated

Module II. Software

43

B.RequirementsElicitation5
Requirements Sources - II

Stakeholders
Also known as Process Actors
The software engineer needs to identify, represent, and
manage the viewpoints of many different types of
stakeholders

The operational environment


The environment that software will be executed in will
reveal system constraints and system element
interoperability

The organizational environment


May impose previously unidentified user processes

Module II. Software

44

B.RequirementsElicitation6

Elicitation Techniques - I
From SWEBOK Guide [SW04, p. 2-4]
Once requirements sources have been identified, the
software engineer can start eliciting requirements from them.

Even if sources are cooperative and articulate, the relevant


information must be captured.
Some of these techniques are:

Interviews
A traditional means of eliciting requirements

Module II. Software

45

B.RequirementsElicitation7
Elicitation Techniques - II
Scenarios
Provides a context for elicitation of user requirements
Asks what if and how is this done questions
The most common type of scenario is the use case
Link to Conceptual Modeling because of scenario notations
such as use cases and diagrams are common in modeling
software
Prototypes
Form paper mock-ups of screen designs to beta-test
versions of software products
Valuable tool for clarifying unclear requirements
Overlap for use in requirements elicitation and
requirements validation

Module II. Software

46

B.RequirementsElicitation8
Elicitation Techniques - III

Facilitated meetings
A group of people may bring more insight to achieve a
summative effect to the requirements
Conflicting requirements may surface earlier in this
setting
Beware of stakeholder politics

Observation
Software engineers are immersed in the environment to
observe the user interact between the software and other
users
Expensive to implement
Helps reveal process subtleties and complexities

Module II. Software

47

B.RequirementsElicitation9
ConOps - An Elicitation Tool - I

Definition concept of operations (ConOps) document A


user oriented document that describes a systems
operational characteristics from the end users viewpoint.
[IE1362, Definition 3.4]

It describes the user organization(s), mission(s), and


organizational objectives from an integrated systems point of
view.

Applied to all types of software intensive systems: softwareonly or software/hardware/people systems

Module II. Software

48

B.RequirementsElicitation10
ConOps - An Elicitation Tool - II

Describes the users general system goals, missions,


function, and components

Helps bring the users views and expectations to the surface

Provides an outlet for the users wishes and wants

Helps the user feel in control

May or may not be the responsibility of the acquisition


manager [RT04, p. 4-29]

Module II. Software

49

B.RequirementsElicitation11
The ConOps Document Style
A ConOps document must be written in the users language
using the users format
A ConOps document should be written in narrative prose (in
contrast to a technical requirements specification)
ConOps should make use of visual forms (diagrams,
illustrations, graphs, etc.) and storyboards wherever possible

ConOps provides a bridge between the user needs and the


developers technical requirements documents [RT04, p. 4-28]

Module II. Software

50

B.RequirementsElicitation12
Elements of IEEE 1362 (ConOps) - I

Clauses describe essential elements


Provides information the writer wants the reader to know
prior to reading the document

Title and revision notice:


Project name
Version number of the document,
Date of release,
Approval signatures,
A list of sub clauses that have been changed in the
current version of the document

Module II. Software

51

B.RequirementsElicitation13
Elements of IEEE 1362 (ConOps) - II

Scope (Clause 1)
Identification
Document overview
System overview

Referenced documents (Clause 2)

Current system or situation (Clause 3)


Background, objectives, and scope
Operational policies and constraints
Description of the current system or situation
Modes of operation for the current system or situation
User classes and other involved personnel (Note)

Module II. Software

52

B.RequirementsElicitation14
Elements of IEEE 1362 (ConOps) - III

Justification for and nature of changes (Clause 4)


Justification for changes
Description of desired changes
Priorities among changes
Changes considered but not included
Assumptions and constraints

Concepts for the proposed system (Clause 5)


Background, objectives and scope
Operational policies and constraints
Description of the proposed system
Modes of operation
User classes and other involved personnel (Note)

Module II. Software

53

B.RequirementsElicitation15
Elements of IEEE 1362 (ConOps) - IV

Operational scenarios (Clause 6)

Summary of impacts (Clause 7)


Operation impacts
Organizational impacts
Impacts during development

Analysis of the proposed system (Clause 8)


Summary of improvements
Disadvantages and limitations
Alternatives and trade-offs considered

Notes (Clause 9)
Appendices of the ConOps
Glossary of the ConOps

Module II. Software

54

B.References

[IE1362] IEEE Std 1362-1998, Guide for Information


Technology System Design Concept of Operations
Document
[JC04] Cleland-Huang, Jane, Software Requirements, in
R.H. Thayer and M. Carstensen, Software Engineering, Vol.
1: The Development Process. IEEE Computer Society
Press, Los Alamitos, CA 2004
[RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 4: Software Requirements Engineering Concepts
[SW04] SWEBOK Guide to the Software Engineering Body
of Knowledge: 2004 Version, IEEE Computer Society, Los
Alamitos, CA, Chapter 2 Software Requirements

Module II. Software

55

B.Quiz
1. As requirements are elicited, what source is most likely to
impose previously unidentified user processes?
A.
B.
C.
D.

The organizational environment


The operational environment
Stakeholders
Application domain specialists

Module II. Software

56

B.Quiz2
2. What is considered the traditional means or requirements
elicitation?
A.
B.
C.
D.

Observations
Scenarios
Interviews
Prototypes

Module II. Software

57

B.Quiz3
3. What is the most common type of scenario elicitation
technique?
A.
B.
C.
D.

The prototype
The use case
The facilitator meeting
Observation

Module II. Software

58

B.Quiz4
4. Which technique overlaps for use in requirements elicitation
and requirements validation?
A.
B.
C.
D.

Prototypes
Facilitator meetings
Interviews
Observations

Module II. Software

59

B.Quiz5
5. A concept of operations document (ConOps) should not be
written
A.
B.
C.
D.

In the users language using the users format


Mostly in narrative prose
With visual forms
Primarily in the developers technical language

Module II. Software

60

B.Quiz6
6. In the IEEE Std 1362 Concept of Operations (ConOps)
Document, which of the following is fundamentally not
included under the Concepts for the Proposed System
(Clause 5)?
A.
B.
C.
D.

Proposed design method of system


Operational policies and constraints
Description of the proposed system
Modes of operation

Module II. Software

61

B.Quiz7
7. In the IEEE Std 1362 Concept of Operations (ConOps)
Document, which of the following is fundamentally not
included in the document?
A.
B.
C.
D.

Current system or situation


Proposed design method of system
Justification for the nature of the change
Operational scenarios

Module II. Software

62

C.RequirementsAnalysis
Definitions

software requirements analysis -(1) The process of studying user needs to arrive at a
definition of system, hardware, or software requirements.
(2) The process of studying and refining system, hardware,
or software requirements. [IE610]
(3) Reasoning and analyzing the customers and users needs
to arrive at a definition of software requirements. [RT02, p.
93]

Module II. Software

63

C.RequirementsAnalysis2
First, Find Requirements Sources

Systems requirements specifications


Statements of work (SOW) and procurement specifications
Customer prepared needs documents
Concept of operations (ConOps) documents
Observations and measurements of the current system
Interviews with the customers and users
Current system documentation
Feasibility studies
Models and prototypes [RT04, p. 4-33]

Module II. Software

64

C.RequirementsAnalysis3
Software Requirements Analysis - I

Software requirements analysis: The process of:


Studying and refining system, hardware, or software
requirements [IE610]
Determining the feasibility of the requirements
Detecting and resolving conflicts between requirements
Discovering the system boundaries and its external
interfaces
Conducting trade-offs between requirement features
Producing of the software requirements specification

Module II. Software

65

C.RequirementsAnalysis4
Software Requirements Analysis - II

Other activities during the requirement analysis phase:


Determine the project management plan
Determine the test plan and test specifications
Determine draft users manual
Determine the system interfaces [RT04, 4-32]

Module II. Software

66

C.RequirementsAnalysis5

Distinct Processes of Requirements Analysis


The SWEBOK has identified several distinct processes that
occur during a successful requirements analysis
Requirements classification (RC)
Helps to inform trade-offs
Conceptual modeling (CM)
To understand the problem
Architectural design and requirements allocation (AD & RA)
What parts will meet requirements
Requirements negotiation (RN)
Establishes trade-offs

Module II. Software

67

C.RequirementsAnalysis6
Requirements Classification - I
Several dimensions:

Whether it is functional or non-functional

Whether it is derived from high-level requirement or is


emergent
Imposed by stakeholder or other source

Whether it is on the product or the process

Module II. Software

68

C.RequirementsAnalysis7
Requirements Classification - II

The requirement priority: The higher, the more essential

The requirement scope: A global requirement may affect


architecture

Volatility/stability: Identification for tolerant design

Others are possible, and some may overlap

Module II. Software

69

C.RequirementsAnalysis8

RC / Attributes - I
Each Software Requirement Shall Have:

Identifier: Every requirement must be assigned a unique


identifier that allows it to be unambiguously referenced.

Source: The source of the requirement may be (e.g.) a


stakeholder from whom it was elicited or a higher-level
requirement from which it was derived

Date: When the requirement was formulated

Module II. Software

70

C.RequirementsAnalysis9
RC / Attributes - II
Each Software Requirement Shall Have:
Rationale: The rationale explains the purpose of the
requirement. This helps subsequent analysis, particularly if the
requirement is challenged or needs to be reworked at a later
stage.
Type: This attribute records, for example, whether the
requirement is functional or non-functional; whether it is a user
interface requirement, a safety requirement, etc., or it is an
original requirement or a derived requirement
Priority: Each requirement need to be prioritized in relationship
to other requirements, e.g., essential, conditional, optional
(IEEE Std 830)

Module II. Software

71

C.RequirementsAnalysis10

RC / Attributes - III
Each Software Requirement Shall Have:

Stability: Uncertainty surrounds a requirement should be


recorded so that its likely volatility is made explicit and
appropriate risk containment measures can be taken.

Verification procedure: This attribute defines how to verify


that the requirement has been satisfied once the software
has been implemented.

Status: The requirements status records its current position


in the life-cycle of the requirement. [RT04, p. 4-43,44]

Module II. Software

72

C.RequirementsAnalysis11

RC / Types of Software Requirements I


Functional requirements A requirement that specifies a
function that a system or system component must be capable
of performing

Performance requirements A requirement that specifies a


performance characteristic that a system or system
component must posses
For example, speed, accuracy, or frequency

External interface requirements A requirement that specifies


a hardware, software, or database element with which a
system component must interface, or that sets forth
constraints on formats, timing or other factors caused by such
an interface

Module II. Software

73

C.RequirementsAnalysis12

RC / Types of Software Requirements II


Design constraints A requirement that impacts or
constrains the design of a software system or system
component (sometimes called a negative requirement);
For example, functional requirements, physical
requirements, performance requirements, software
development standards, software quality assurance
standards
Quality Attributes A requirement that specifies the degree
of an attribute that affects the quality the software must
possess;
For example: correctness, reliability, maintainability, or
portability [RT04, 4-35]

Module II. Software

74

C.RequirementsAnalysis13

RC / Examples of Design Constraints


Execution speed Use maximum of 50% of available cycle
time (also called performance requirement)
Language Use Ada
Maintenance Meet available requirements of 0.98 (also
called quality attribute)
Human computer interface Menus are require for system
interface
Memory utilization Use maximum of 75% of available
memory (also called performance requirements)
Reliability Meet reliability requirements of 0.99 (also called
quality attributes)
Security Meet security requirements of 4 hours to break
into the system (also called quality attributes)

Module II. Software

75

C.RequirementsAnalysis14

RC / Examples of Quality Requirements


Reliability Probability that the software will perform its
logical operation in the specified environment without failure
Survivability Probability that the software will continue to
perform or support critical functions when a portion of the
system is inoperable
Maintainability - Average effort required to locate and fix a
software failure
User friendliness The degree of ease of use or learning of
a software system
Securability The probability that the software system can
be made secure for a predetermined amount of time

Module II. Software

76

C.RequirementsAnalysis15

Conceptual Modeling I
Their purpose is to aid in understanding the problem, not
begin a design solution

Types of models include data and control flows, state


models, event traces, and others

Factors that influence choice of model:


The nature of the problem
The expertise of the software engineer
The process requirements of the customer
The availability of methods and tools

Module II. Software

77

C.RequirementsAnalysis16
Conceptual Modeling II

Useful to start with building model of the software context


explains operational environment and identifies interfaces

UML (Unified Modeling Language) is a widely used set of


notations

Module II. Software

78

C.RequirementsAnalysis17
CM / Structured Analysis
(Yourdon)
[RT04, p. 4-38]

Module II. Software

79

C.RequirementsAnalysis18
CM / Real Time Structured
Analysis (Ward & Miller)
[RT04, p. 4-39]

Module II. Software

80

C.RequirementsAnalysis19
CM / Object-Oriented Analysis
(Object Diagram)
[RT04, p. 4-40]

Module II. Software

81

C.RequirementsAnalysis20
CM / Use Cases

Module II. Software

82

C.RequirementsAnalysis21
Architectural Design and Requirements Allocation
Point the requirements process overlaps with software or system
design.
Allocation is the assigning of responsibility to components for
satisfying requirements.
Permits detailed analysis of requirements
Allows requirements to be broken down further
IEEE Std 1471-2000 is a Recommended Practice for
Architectural Description of Software Intensive Systems

Module II. Software

83

C.RequirementsAnalysis22

Requirements Negotiation
Also known as conflict resolution

Conflicts between stakeholders arise from differences:


Between incompatible features
Between requirements and resources
Between functional and non-functional requirements

Unwise for software engineer to make unilateral decision


Consultation leads to consensus trade-off
Decision traceable back to the customer for contractual
reasons

Module II. Software

84

C.References

[IE610] IEEE Std 610.12-1990, Standard Glossary of


Software Engineering Terminology
[RT02] Thayer, Richard H., Software Engineering, Volume 1:
The Development Process, 2nd Edition, IEEE Computer
Society, Los Alamitos, CA, 2002
[RT04] Thayer, Richard H., 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 4: Software Requirements Engineering Concepts
[SW04] SWEBOK Guide to the Software Engineering Body
of Knowledge: 2004 Version, IEEE Computer Society, Los
Alamitos, CA, Chapter 2 Software Requirements

Module II. Software

85

C.Quiz
1. Which dimension of requirement classification is critical for
consideration of tolerant design?
A.
B.
C.
D.

Whether the requirement is functional or non-functional.


Whether the requirement is on the product or process.
Whether the requirement is volatile or stable.
Whether the requirement is a high or low priority.

Module II. Software

86

C.Quiz2
2. What is the most important attribute of a requirement?
A.
B.
C.
D.

Identifier
Source
Verification procedure
Priority

Module II. Software

87

C.Quiz3
3. Which of the following is not a type of software requirement?
A.
B.
C.
D.

Functionality
Performance
External Interface
Complexity

Module II. Software

88

C.Quiz4
4. What does allocation try to satisfy in the assigning of
responsibility to components?
A.
B.
C.
D.

Requirements
Validation
External interfaces
Testing

Module II. Software

89

C.Quiz5
5. What is a software engineer most likely to resolve by making
a unilateral decision?
A. Differences between incompatible features
B. Differences between developer perception and developer
reality
C. Differences between requirements and resources
D. Differences between functional and non-functional
requirements

Module II. Software

90

D.SoftwareRequirements
Specification
Two Descriptions
software requirements specification (software requirements)
1. A document that specifies the requirements for a system
or component. Typically included are functional
requirements, performance requirements, interface
requirements, design requirements, and development
standards. [IE610] 2. A document that clearly and precisely
records each of the requirements of the software system.
[RT02, p. 143]
In software engineering jargon, software requirements
specification typically refers to the production of a document,
or its electronic equivalent, which can be systematically
reviewed, evaluated, and approved. [SW04, p. 2-7]

Module II. Software

91

D.SoftwareRequirements
Specification2
Role in Software Development
Foundation for the software project
Describes the system to be delivered
Separates essential, desirable, and optional requirements
Identifies which items are stable and which might be volatile
States problems, not solutions
States what not how [RT04, p. 4-47]

Module II. Software

92

D.SoftwareRequirements
Specification3
In Context with Other Requirement Documents

The System Definition Document defines high-level system


requirements

System Requirements Specification for system


components

Software Requirements Specification for software


components of the system

Module II. Software

93

D.SoftwareRequirements
Specification4

The System Definition Document


Sometimes known as the user requirements document or
concept of operations document
Records the system requirements
Defines high level system requirements in language/terms
understood by the system users or customers
It may include conceptual models, usage scenarios, data,
information, or workflows to illustrate the system concept
[SW04, p. 2-7]
The IEEE Std 1362 is a guide which describes the elements
of a ConOps document

Module II. Software

94

D.SoftwareRequirements
Specification5
IEEE 1362 - The ConOps Document

The IEEE Std 1362 is a guide which describes the elements


of a ConOps document

Module II. Software

95

D.SoftwareRequirements
Specification6

System Requirements Specification (SyRS)


Software is always an element of a larger system
EXAMPLES: Airplanes, the Space Shuttle, a cell phone
Is a systems engineering activity
System requirements are specified here, not software
requirements
Software requirements are derived from the system
requirements
The requirements for the software components of the system
are then specified [SW04, p. 2-7]
The IEEE Std 1233 is a guide for developing system
requirements specifications

Module II. Software

96

D.SoftwareRequirements
Specification7
IEEE Std 1233 (SyRS)

Recommended practice for developing system requirements


specifications

Module II. Software

97

D.SoftwareRequirements
Specification8

Software Requirements Specification (SRS) - I


Establishes understanding of the software product is to do,
as well as what it is not expected to do
Often accompanied by definition document for clarity
Written in natural language
Supplemented by formal or semi-formal description
This allows for a more precise and concise description of
software architecture
Permits rigorous assessment of requirements before design
Provides realistic basis for estimating product costs, risks,
and schedules

Module II. Software

98

D.SoftwareRequirements
Specification9

Software Requirements Specification (SRS) - II


Choice of notation constrained by the documents writers
Training, skills, preferences
Quality indicators for SRS statements
Imperatives, directives, weak phrases, opinions, and
continuances
Quality indicators for entire SRS
Size, readability, specification, depth, and text structure
The IEEE Std 830 is a guide for developing software
requirements specifications

Module II. Software

99

D.SoftwareRequirements
Specification10

IEEE Std 830 (SRS)


Recommended practice for developing software
requirements specifications (You should read this standard!)

Lists Considerations for producing a good SRS

Identifies The Parts of an SRS

Module II. Software

100

D.SoftwareRequirements
Specification11
Considerations for Producing a Good SRS - I

Nature of the SRS The writer(s) shall address the following


issues
Functionality
External interfaces
Performance
Attributes
Design constraints imposed on an implementation
The SRS writer(s) should avoid placing either design or
project requirements in the SRS Environment of the SRS

Module II. Software

101

D.SoftwareRequirements
Specification12
Considerations for Producing a Good SRS - II

Environment of the SRS The SRS writer(s) plays a specific


role in the software development process
Should correctly define all of the software requirements.
Should not describe any design or implementation
details.
Should not impose additional constraints on the software.
The SRS limits the range of valid designs, but does not
specify any particular design

Module II. Software

102

D.SoftwareRequirements
Specification13
Considerations for Producing a Good SRS - III

Characteristics of a good SRS (I) An SRS should be


Correct Only if every stated SRS is one the software
shall meet
Unambiguous The particular context of the SRS is
clear and there is only one interpretation
Natural language pitfalls
Requirements specification languages
Representation tools
Complete Only if it addresses:
All significant requirements
Definition of the software response
Identification of all references
TBDs are marked for resolution

Module II. Software

103

D.SoftwareRequirements
Specification14
Considerations for Producing a Good SRS - IV

Characteristics of a good SRS (continued - II)


Consistent With higher level documents; types of conflicts
Specified characteristics of real-world objects
Logical or temporal conflicts with two specified actions
Redundancy
Ranked for importance and/or stability All of the software
requirements are not equally important
Degree of stability (expected changes to occur)
Degree of necessity: Essential, Conditional, or Optional
Verifiable a requirement is verifiable if and only if there exists
some finite cost-effective process with which a person or
machine can check that the software product meets the
requirement.
Non-verifiable - Terms such as good, well, or usually
are impossible to define

Module II. Software

104

D.SoftwareRequirements
Specification15
Considerations for Producing a Good SRS - V

Characteristics of a good SRS (continued III)


Modifiable Requires that the SRS
Has a coherent and easy-to-use organization
Not be redundant
Express each requirement separately (redundancy
can lead to errors)
Traceable If the origin of each of its requirements is
clear and it facilitates the referencing of each requirement
in future development or enhancement documentation
Backward traceability ( i.e., to previous stages of
development)
Forward traceability (i.e., to all documents spawned
by the SRS)

Module II. Software

105

D.SoftwareRequirements
Specification16
Considerations for Producing a Good SRS - VI

Joint preparation of the SRS Should begin with supplier


and customer agreement on what completed software must
do.
Customers usually dont understand software
development well enough to write a usable SRS
Software developers usually dont understand customers
well enough to specify requirements for a satisfactory
system

Module II. Software

106

D.SoftwareRequirements
Specification17
Considerations for Producing a Good SRS - VII

SRS evolution The SRS may need to evolve, as some


details are impossible to obtain during the projects initial
phases. To handle this situation
Specify as completely and thoroughly as possible; note
incompleteness if it is known.
Utilize a formal change process

Module II. Software

107

D.SoftwareRequirements
Specification18
Considerations for Producing a Good SRS - VIII

Prototyping Should be used as a way to elicit software


requirements
More likely for customer to react to view than to reading
Displays unanticipated aspects of system behavior
SRS tends to undergo less change during development,
thus shortening development time

Module II. Software

108

D.SoftwareRequirements
Specification19
Considerations for Producing a Good SRS - IX

Embedding design in the SRS avoid it


A requirement specifies an externally visible function or
attribute
A design describes a method to achieve that requirement
Every requirement in the SRS limits design alternatives
The SRS should not specify
Partitioning of software into modules
Allocating functions to the modules
Describe the flow of information or control between
modules
Choose data structures

Module II. Software

109

D.SoftwareRequirements
Specification20
Considerations for Producing a Good SRS - X

Embedding project requirements in the SRS The SRS


should address the software product, not the process of
producing the product.
These following project requirements are reserved for
other documents:
Cost, delivery schedule, reporting procedures,
software development methods, quality assurance,
verification and validation, or acceptance procedures

Module II. Software

110

D.SoftwareRequirements
Specification21
IEEE 830 - The Parts of an SRS - I

Table of Contents
1. Introduction
1. Purpose
2. Scope
3. Definitions, Acronyms, and Abbreviations
4. References
5. Overview
2. Overall Description
1. Product Perspective
2. Product Functions
3. User Characteristics
4. Constraints
5. Assumptions and Dependencies
3. Specific Requirements
Appendices
Index

Module II. Software

111

D.SoftwareRequirements
Specification22
IEEE 830 - The Parts of an SRS - II
Functional Hierarchy [RT04, p. 4-51]
3. Specific requirements
1. External Interfaces
2. Functional requirements
1. Function 1
1. Introduction
2. Input
3. Process
4. Output
2. Function 2
3.
4. Function n
3. Performance requirements
4. Design constraints
5. Quality attributes

Module II. Software

112

D.SoftwareRequirements
Specification23

Writing a Requirement
Suggested Method [RT04, p. 4-53]
Requirement should be written as a single sentence, with a
minimum number of conjunctions, and using modal verbs
consistently i.e. shall, will, can, may. Example:
Arm011: On completion of the arming sequence, there
shall be a time delay equal to the escape period before
the alarm enters the armed state
This statement of requirements requires that the terms
arming sequence, escape period, and armed state be
defined in a glossary
Use model verbs, e.g., use shall to indicate an essential
requirement
Arm011 is the requirements unique identifier

Module II. Software

113

D.References

[IE610] IEEE Std 610.12-1990, Standard Glossary of


Software Engineering Terminology
[IE830] IEEE Std 830-1998, Recommended Practice for
Software Requirements Specification
[IE1233] IEEE Std 1233-1998, Guide for Developing System
Requirements
[IE1362] IEEE Std 1362-1998, Guide for Information
Technology System Design Concept of Operations
Document
[RT02] Thayer, Richard H., Software Engineering, Volume 1:
The Development Process, 2nd Edition, IEEE Computer
Society, Los Alamitos, CA, 2002
[RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 4: Software Requirements Engineering Concepts

Module II. Software

114

D.References2

[SW04] SWEBOK Guide to the Software Engineering Body


of Knowledge: 2004 Version, IEEE Computer Society, Los
Alamitos, CA, Chapter 2 Software Requirements

Module II. Software

115

D.Quiz
1. Which document is used to derive the software requirements
specification?
A.
B.
C.
D.

The System Definition Document


System Requirements Specification
IEEE 1362 Concept of Operations
IEEE 1016 Software Design Descriptions

Module II. Software

116

D.Quiz2
2. What should the software requirements specification (SRS)
writer avoid placing in the SRS environment of the SRS?
A.
B.
C.
D.

External interfaces
Performance or functionality
Attributes or classification
Either design or project requirements

Module II. Software

117

D.Quiz3
3. Which of the following is not embedded design that would be
written in the SRS?
A.
B.
C.
D.

Partitioning of software into modules


Specify logical requirements for the software
Describe the flow of information or control between modules
Choose data structures

Module II. Software

118

D.Quiz4
4. Which of the following phrases most closely approaches
verifiable language?
A.
B.
C.
D.

A good operability
Well enough
According to Standard X
Usually acceptable

Module II. Software

119

D.Quiz5
5. Which of the following is not a good characteristic well written
of a software requirements specification?
A.
B.
C.
D.

Consistent
Ranked
Redundant
Verifiable

Module II. Software

120

E.RequirementsValidation
Defined

Validation 1. The process of evaluating a system or


component during or at the end of the development process
to determine whether it satisfies specified requirements.
Contrast with verification. [IE610] 2. The process is a
process for determining whether the requirements and the
final, as-built system or software product fulfills its specific
intended use [IEEE/EIA Std 12207.2, Para 6.5]

Validation (error = external customer requirements - product)

Verification (error = internal specified requirements - product)

Module II. Software

121

E.RequirementsValidation2

Objectives of Verification and Validation


To find errors in the software process and product as early
as feasible
To assist in determining good requirements and design
To ensure that quality is built into the software and that the
software will satisfy the software requirements
To provide software management with insights into the state
of the software project and product
To satisfy users that the system is being developed
according to standards and specifications
To predict how well the interim products will result in a final
product that will satisfy the software requirements [RT04, p.
4-58]

Module II. Software

122

E.RequirementsValidation3

Requirements Validation - I
Requirements documents may be subject to validation and
verification procedures
Formal notation permits
Software requirements validated to ensure that software
engineer has understood the requirements
Verify that a requirements document conforms to
company standards
that it is understandable, consistent, and complete

Module II. Software

123

E.RequirementsValidation4

Requirements Validation - II
Different stakeholders should be able to review requirements
documents

Requirements documents subject to software configuration


management as are other deliverables of software lifecycle
processes

Multiple points of validation in requirements process


schedule
Pick up problems before resources are committed
Helps ensure requirements document defines the right
software [SW04, p. 2-8]

Module II. Software

124

E.RequirementsValidation5
Subjects of Requirements Validation

The SWEBOK has identified several knowledge areas of


importance for the study of software requirements validation:
Requirements reviews
Prototyping
Model validation
Acceptance Testing

Module II. Software

125

E.RequirementsValidation6
RV / Requirements Reviews I

reviews -- A process or meeting during which a work


product, or set of work products, is presented to project
personnel, managers, users, customers, or other interested
parties for comment or approval. Types include code
reviews, design reviews, formal qualification reviews, and
requirements reviews, test readiness reviews. [IE610]

Module II. Software

126

E.RequirementsValidation7
RV / Requirements Reviews II

Validation often done by inspection or reviews of


requirements documents

Reviewers look for errors, mistaken assumptions, lack of


clarity, and deviation from standard practice

Composition of reviewer group should include important


stakeholders (customer for customer-driven project)

Checklists are helpful

Module II. Software

127

E.RequirementsValidation8
RV / Requirements Reviews III

Can be done after completion of


systems definition document
systems specification document
software requirements specification document
the baseline specification for new release
any other steps in the process

IEEE Std 1028 provides guidance for reviews

Module II. Software

128

E.RequirementsValidation9

RV / Prototyping I
A means of validating the software engineers interpretation
of the software requirements

Also for eliciting new requirements

Many different techniques

Many different points in the process where prototype


validation is appropriate

Module II. Software

129

E.RequirementsValidation
10
RV / Prototyping II

Makes it easier to interpret the software engineer


assumptions
And give feedback when wrong

Danger is distraction of resources from core functionality


towards cosmetic issues
Some suggestion prototypes that avoid software, such as
flip-chart based mockups

Module II. Software

130

E.RequirementsValidation
11
RV / Model Validation

Validating the quality of models developed during analysis


Example: In object models, perform static analysis to
verify the communication paths exist between objects
which exchange data

If formal specification notation used, use formal reasoning to


prove specification properties

Validation (error = external customer requirements - product)


Verification (error = internal specified requirements - product)

Module II. Software

131

E.RequirementsValidation
12
RV / Acceptance Tests

Essential property of software requirement is that it should


be possible to verify that finished product satisfies it

Requirements which cannot be validated are wishes

Must plan how to verify each requirement

Validation requires quantitative expression

Non-functional requirements difficult to validate

Module II. Software

132

E.RequirementsValidation
13
Levels of Testing Versus Types of Errors Found
Levels of Test Types of Errors Found
Unit
Coding
Integration
Design
System Requirements (Developers Interpretation)
Acceptance
Requirements (Users Interpretation)

Errors made first are discovered last [RT04, p. 4-56]

Module II. Software

133

E.References

[IE610] IEEE Std 610.12-1990, Standard Glossary of


Software Engineering Terminology
[IE830] IEEE Std 830-1998, Recommended Practice for
Software Requirements Specification
[IE1028] IEEE Std 1028-1997, Standard for Software
Reviews
[RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 4: Software Requirements Engineering Concepts
[SW04] SWEBOK Guide to the Software Engineering Body
of Knowledge: 2004 Version, IEEE Computer Society, Los
Alamitos, CA, Chapter 2 Software Requirements
[IE12207.2] IEEE/EIA Std 12207.2 Standard for Information
Technology, Software Life Cycle Processes
Implementation Considerations

Module II. Software

134

E.Quiz
1. Software requirements validation should be viewed by whom
and how often?
A.
B.
C.
D.

Requirements analysts, often


Stakeholders, often
Customers, never
Users, never

Module II. Software

135

E.Quiz2
2. Requirements reviews:
Can not be done before completion of the
A. Systems definition document
B. Systems specification document
C. Software requirements specification document
D. Baseline specification for new release

Module II. Software

136

F.RequirementsManagement
Defined

software requirements management -- In system/software


system engineering, the process of controlling the
identification, allocation, and flowdown of requirements from
the system level to the module or part level, including
interfaces, verification, modifications, and status monitoring.
[Thayer & Thayer Software Requirements 1997]

Module II. Software

137

F.RequirementsManagement
2

Observations
The requirements process suggests a linear sequence (from
elicitation through validation)
A strict linear logic breaks down for complex system
development
Not every organization has a culture of documenting and
managing requirements
As products evolve:
Need for feature changes demands review of original
requirements
Need to asses the impact of proposed changes
Requirements documentation and change management key
to successful requirements process [SW04, p. 2-9]

Module II. Software

138

F.RequirementsManagement
3
Two Type of Management
Both of these Approaches Manage the Requirements
Project management
Planning the project
Organizing the project
Staffing the project
Directing the project
Controlling the project
Technical management
Problem definition
Solution analysis
Process planning
Process control
Product evaluation [RT04, p. 4-60]

Module II. Software

139

F.RequirementsManagement
4
Duties of the Software Project Manager - I

The project manager is responsible for:


Estimating the cost of the system based on the
requirements
Re-estimating the cost and schedule of the project when
the requirements change

Module II. Software

140

F.RequirementsManagement
5
Duties of the Software Project Manager II

The technical manager is responsible for:


Determining the adequacy of the requirements
specifications
Managing the requirements configuration of the system
Controlling the volatility of the requirements and manage
change history
Perform requirements traceability
Negotiating requirements changes between the acquirer
(customer) and the developer

The chief system engineer is frequently the technical


manager [RT04, p. 4-61]

Module II. Software

141

F.RequirementsManagement
6
Key Requirements Tasks of the Project Manager

Change control Change control is the process of inhibiting


unapproved changes to the software system
Version control Version control is the process of insuring
the various versions of the software system is indeed that
version
Requirements tracing Requirements tracing is the process
of assuring that every requirement can be connected
downward to the design module that implements it and
upward to the system requirements that initiated it
Status tracking A system for maintaining information on the
processing and implementation of the requirements [RT04,
p. 4-62]

Module II. Software

142

F.RequirementsManagement
7
Subjects of Requirements Management

The SWEBOK has identified several knowledge areas of


importance for the study of software requirements
management:
Iterative nature of the Requirements Process
Change Management
Requirements Attributes
Requirements Tracing

Module II. Software

143

F.RequirementsManagement
8
RM / Iterative Nature of Requirements Process - I

Shorter development cycles, especially in competitive


industries

Often project is upgrade or revision of existing software

Often requirements are never perfectly understood or


perfectly verified
Understanding that requirements continue to evolve as
development proceeds

Module II. Software

144

F.RequirementsMa1nagement
9

RM / Iterative Nature of Requirements Process - II


Risk of rework spans the whole software life cycle
Change has to be managed through review and approval
process
Requirements tracing
Impact analysis
Software configuration management
Configuration management (CM) -- In system/software
engineering, a discipline applying technical and
administrative direction and surveillance to: identify and
document the functional and physical characteristics of a
configuration item, control changes to those characteristics,
record and report change processing and implementation
status, and verify compliance with specified requirements.
[IE610]

Module II. Software

145

F.RequirementsManagement
10
RM / Change Management

Procedures need to be in place and applied to proposed


changes

Module II. Software

146

F.RequirementsManagement
11

RM / Requirements Attributes
Requirements are not just composed of a specification, they
should also include:
Additional information to manage and interpret
requirements
The various classification dimensions of the requirement
Verification method or acceptance test plan

May also include additional information


Summary rational of each requirement
Source of each requirement and change history

Most important requirement attribute:


A unique and unambiguous identifier

Module II. Software

147

F.RequirementsManagement
12
RM / Requirements Tracing

Concerned with:
Recovering the source of requirements
From software requirement back to system
requirement it supports
Predicting the effects of requirements
From system requirement into software requirement
and code modules that satisfy it

Requirements tracing for a typical project form a complex


directed acyclic graph (DAG) of requirements

Module II. Software

148

F.RequirementsManagement
13
RM / Measuring Requirements

Concept of volume of requirements for particular software


product

Useful in evaluating size of change in requirements

Useful in estimating cost of development or maintenance


task

A denominator in other measurements

Technique: Functional Size Measurement (FSM)

Module II. Software

149

F.RequirementsManagement
14
Graphic, next slide: The Relative Cost to Correct A Software
Requirements Error [RT02, p. 155]

Module II. Software

150

F.RequirementsManagement
15

Module II. Software

151

F.References

[IE610] IEEE Std 610.12-1990, Standard Glossary of


Software Engineering Terminology
[RT02] Thayer, Richard H., Software Engineering, Volume 1:
The Development Process, 2nd Edition, IEEE Computer
Society, Los Alamitos, CA, 2002
[RT04] Thayer, Richard, 2004 Certified Software
Development Professional (CSDP) Preparation Course,
Chapter 4: Software Requirements Engineering Concepts
[SW04] SWEBOK Guide to the Software Engineering Body
of Knowledge: 2004 Version, IEEE Computer Society, Los
Alamitos, CA, Chapter 2 Software Requirements
[Thayer & Thayer Software Requirements 1997] Reference
unknown

Module II. Software

152

F.Quiz
1. Which of the following is the technical manager not
responsible for?
A. Determining the adequacy of the requirements
specifications.
B. Controlling the volatility of the requirements and manage
change history.
C. Re-estimating the cost and schedule of the project when the
requirements change.
D. Negotiating requirements changes between the acquirer
(customer) and the developer.

Module II. Software

153

F.Quiz2
2. Due to the iterative nature of the requirements process,
change has to be managed through the review and approval
process. Which of the following is likely to require the least
amount of management?
A.
B.
C.
D.

Requirements tracing
Impact analysis
Software configuration management
System definition

Module II. Software

154

F.Quiz3
3. Requirements tracing is most likely concerned with the
following:
Recovering the source of requirements from:
A. Software requirement back to the system requirement it
supports
B. Observation to elicitation technique
C. Analysis into requirements specification document
D. Software requirement to validation test

Module II. Software

155

You might also like