CSDP Preparation Course
Module II: Software Requirements
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 Requirements
2
Objectives
After completing this module, you should be able to…
• To present an overview of software requirements
engineering
Module II. Software Requirements
3
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 Requirements
4
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 Requirements
5
Introduction – 2
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: Don’t assume that all your project stakeholders
share a common notion of what requirements are. Establish
definitions up front so that you’re all talking about the same
things. [KW03, p. 8]
Module II. Software Requirements
6
Introduction – 3
•
•
•
•
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 Requirements
7
Introduction – 4
•
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 Requirements
8
Introduction – 5
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 Requirements
9
Introduction – 6
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 Requirements
10
Introduction - 7
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 Requirements
11
Introduction - 8
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 Requirements
12
Introduction – 9
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 Requirements
13
Introduction – 10
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 Requirements
14
Introduction – 11
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 Requirements
15
Introduction – 12
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 Requirements
16
Introduction Quiz
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 Requirements
17
Introduction Quiz – 2
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 Requirements
18
Introduction Quiz – 3
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 Requirements
19
Introduction References
• [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 Requirements
20
A. Requirements Engineering
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 Requirements
21
A. Requirements Engineering
Process - 2
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 Requirements
22
A. Requirements Engineering
Process - 3
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 Requirements
23
A. Requirements Engineering
Process - 4
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 Requirements
24
A. Requirements Engineering
Process - 5
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 Requirements
25
A. Requirements Engineering
Process - 6
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 Requirements
26
A. Requirements Engineering
Process - 7
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 Requirements
27
A. Requirements Engineering
Process - 8
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 Requirements
28
A. Requirements Engineering
Process - 9
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 Requirements
29
A. Requirements Engineering
Process - 10
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 Requirements
30
A. Requirements Engineering
Process - 11
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 Requirements
31
A. Requirements Engineering
Process - 12
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
• Developer’s knowledge of the customer domain greatly
influence the quality of the specifications
Module II. Software Requirements
32
A.
Requirements Engineering
Process – 13
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 Requirements
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 Requirements
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 Requirements
35
A. Quiz – 2
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 Requirements
36
A. Quiz – 3
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 Requirements
37
A. Quiz – 4
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 Requirements
38
A. Quiz – 5
5. Product requirement validation occurs primarily after:
A.
B.
C.
D.
Elicitation
Analysis
Specification
Testing
Module II. Software Requirements
39
B. Requirements Elicitation
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 Requirements
40
B. Requirements Elicitation - 2
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 don’t 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 Requirements
41
B. Requirements Elicitation - 3
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 Requirements
42
B. Requirements Elicitation - 4
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 Requirements
43
B. Requirements Elicitation - 5
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 Requirements
44
B. Requirements Elicitation - 6
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 Requirements
45
B. Requirements Elicitation - 7
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 Requirements
46
B. Requirements Elicitation – 8
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 Requirements
47
B. Requirements Elicitation – 9
ConOps - An Elicitation Tool - I
• Definition – concept of operations (ConOps) document – A
user oriented document that describes a system’s
operational characteristics from the end user’s 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 Requirements
48
B. Requirements Elicitation – 10
ConOps - An Elicitation Tool - II
• Describes the user’s 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 Requirements
49
B. Requirements Elicitation – 11
The ConOps Document Style
• A ConOps document must be written in the user’s language
using the user’s 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
developer’s technical requirements documents [RT04, p. 428]
Module II. Software Requirements
50
B. Requirements Elicitation – 12
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 Requirements
51
B. Requirements Elicitation – 13
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 Requirements
52
B. Requirements Elicitation – 14
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 Requirements
53
B. Requirements Elicitation – 15
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 Requirements
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 Requirements
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 Requirements
56
B. Quiz – 2
2. What is considered the traditional means or requirements
elicitation?
A.
B.
C.
D.
Observations
Scenarios
Interviews
Prototypes
Module II. Software Requirements
57
B. Quiz – 3
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 Requirements
58
B. Quiz – 4
4. Which technique overlaps for use in requirements elicitation
and requirements validation?
A.
B.
C.
D.
Prototypes
Facilitator meetings
Interviews
Observations
Module II. Software Requirements
59
B. Quiz – 5
5. A concept of operations document (ConOps) should not be
written
A.
B.
C.
D.
In the user’s language using the user’s format
Mostly in narrative prose
With visual forms
Primarily in the developers technical language
Module II. Software Requirements
60
B. Quiz – 6
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 Requirements
61
B. Quiz – 7
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 Requirements
62
C. Requirements Analysis
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 Requirements
63
C. Requirements Analysis – 2
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 Requirements
64
C. Requirements Analysis – 3
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 Requirements
65
C. Requirements Analysis – 4
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 user’s manual
• Determine the system interfaces [RT04, 4-32]
Module II. Software Requirements
66
C. Requirements Analysis – 5
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 Requirements
67
C. Requirements Analysis – 6
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 Requirements
68
C. Requirements Analysis – 7
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 Requirements
69
C. Requirements Analysis – 8
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 Requirements
70
C. Requirements Analysis – 9
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 Requirements
71
C. Requirements Analysis – 10
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 Requirements
72
C. Requirements Analysis – 11
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 Requirements
73
C. Requirements Analysis – 12
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 Requirements
74
C. Requirements Analysis – 13
•
•
•
•
•
•
•
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 Requirements
75
C. Requirements Analysis – 14
•
•
•
•
•
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 Requirements
76
C. Requirements Analysis – 15
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 Requirements
77
C. Requirements Analysis – 16
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 Requirements
78
C. Requirements Analysis – 17
CM / Structured Analysis
(Yourdon)
[RT04, p. 4-38]
Module II. Software Requirements
79
C. Requirements Analysis – 18
CM / Real Time Structured
Analysis (Ward & Miller)
[RT04, p. 4-39]
Module II. Software Requirements
80
C. Requirements Analysis – 19
CM / Object-Oriented Analysis
(Object Diagram)
[RT04, p. 4-40]
Module II. Software Requirements
81
C. Requirements Analysis – 20
CM / Use Cases
Module II. Software Requirements
82
C. Requirements Analysis - 21
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 Requirements
83
C. Requirements Analysis - 22
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 Requirements
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 Requirements
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 Requirements
86
C. Quiz – 2
2. What is the most important attribute of a requirement?
A.
B.
C.
D.
Identifier
Source
Verification procedure
Priority
Module II. Software Requirements
87
C. Quiz – 3
3. Which of the following is not a type of software requirement?
A.
B.
C.
D.
Functionality
Performance
External Interface
Complexity
Module II. Software Requirements
88
C. Quiz – 4
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 Requirements
89
C. Quiz – 5
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 Requirements
90
D. Software Requirements
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 Requirements
91
D. Software Requirements
Specification - 2
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 Requirements
92
D. Software Requirements
Specification - 3
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 Requirements
93
D. Software Requirements
Specification – 4
•
•
•
•
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 Requirements
94
D. Software Requirements
Specification – 5
IEEE 1362 - The ConOps Document
• The IEEE Std 1362 is a guide which describes the elements
of a ConOps document
Module II. Software Requirements
95
D. Software Requirements
Specification – 6
•
•
•
•
•
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 Requirements
96
D. Software Requirements
Specification – 7
IEEE Std 1233 (SyRS)
• Recommended practice for developing system requirements
specifications
Module II. Software Requirements
97
D. Software Requirements
Specification – 8
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 Requirements
98
D. Software Requirements
Specification – 9
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 Requirements
99
D. Software Requirements
Specification – 10
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 Requirements
100
D. Software Requirements
Specification – 11
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 Requirements
101
D. Software Requirements
Specification - 12
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 Requirements
102
D. Software Requirements
Specification - 13
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
• TBD’s are marked for resolution
Module II. Software Requirements
103
D. Software Requirements
Specification - 14
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 Requirements
104
D. Software Requirements
Specification - 15
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 Requirements
105
D. Software Requirements
Specification - 16
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 don’t understand software
development well enough to write a usable SRS
• Software developers usually don’t understand customers
well enough to specify requirements for a satisfactory
system
Module II. Software Requirements
106
D. Software Requirements
Specification - 17
Considerations for Producing a Good SRS - VII
• SRS evolution – The SRS may need to evolve, as some
details are impossible to obtain during the project’s 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 Requirements
107
D. Software Requirements
Specification - 18
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 Requirements
108
D. Software Requirements
Specification - 19
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 Requirements
109
D. Software Requirements
Specification – 20
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 Requirements
110
D. Software Requirements
Specification - 21
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 Requirements
111
D. Software Requirements
Specification – 22
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 Requirements
112
D. Software Requirements
Specification - 23
•
•
•
•
•
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 requirement’s unique identifier
Module II. Software Requirements
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 Requirements
114
D. References – 2
• [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 Requirements
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 Requirements
116
D. Quiz – 2
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 Requirements
117
D. Quiz – 3
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 Requirements
118
D. Quiz – 4
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 Requirements
119
D. Quiz – 5
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 Requirements
120
E. Requirements Validation
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 Requirements
121
E. Requirements Validation – 2
•
•
•
•
•
•
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 Requirements
122
E. Requirements Validation – 3
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 Requirements
123
E. Requirements Validation – 4
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 Requirements
124
E. Requirements Validation – 5
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 Requirements
125
E. Requirements Validation – 6
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 Requirements
126
E. Requirements Validation – 7
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 Requirements
127
E. Requirements Validation – 8
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 Requirements
128
E. Requirements Validation – 9
RV / Prototyping – I
• A means of validating the software engineer’s 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 Requirements
129
E. Requirements Validation – 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 Requirements
130
E. Requirements Validation – 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 Requirements
131
E. Requirements Validation – 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 Requirements
132
E. Requirements Validation – 13
Levels of Testing Versus Types of Errors Found
Levels of Test
Unit
Integration
System
Acceptance
Types of Errors Found
Coding
Design
Requirements (Developer’s Interpretation)
Requirements (User’s Interpretation)
• “Errors made first are discovered last” [RT04, p. 4-56]
Module II. Software Requirements
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 Requirements
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 Requirements
135
E. Quiz – 2
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 Requirements
136
F. Requirements Management
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 Requirements
137
F. Requirements Management –
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 Requirements
138
F. Requirements Management –
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 Requirements
139
F. Requirements Management –
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 Requirements
140
F. Requirements Management –
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 Requirements
141
F. Requirements Management –
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 Requirements
142
F. Requirements Management –
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 Requirements
143
F. Requirements Management –
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 Requirements
144
F. Requirements Ma1nagement
–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 Requirements
145
F. Requirements Management –
10
RM / Change Management
• Procedures need to be in place and applied to proposed
changes
Module II. Software Requirements
146
F. Requirements Management –
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 Requirements
147
F. Requirements Management –
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 Requirements
148
F. Requirements Management –
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 Requirements
149
F. Requirements Management –
14
Graphic, next slide: The Relative Cost to Correct A Software
Requirements Error [RT02, p. 155]
Module II. Software Requirements
150
F. Requirements Management –
15
Module II. Software Requirements
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 Requirements
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 Requirements
153
F. Quiz – 2
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 Requirements
154
F. Quiz – 3
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 Requirements
155
Descargar

MODULE II REQIREMENTS