Escolar Documentos
Profissional Documentos
Cultura Documentos
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
Objectives
After completing this module, you should be able to
To present an overview of software requirements
engineering
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
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]
Introduction2
A Perspective
Introduction3
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
Introduction5
Introduction6
10
Introduction7
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
12
Introduction9
Quantifiable Requirements
Avoid vague and unverifiable requirements which depend for
their interpretation on subjective judgment
13
Introduction10
14
Introduction11
Recognizing the Importance of Software Requirements
Engineering [RT04, p. 4-7]
15
Introduction12
Role of Software Requirements in the Lifecycle [RT04, p. 4-17]
16
IntroductionQuiz
1. Which of the following requirement properties would be
considered an emergent property of a software program?
A.
B.
C.
D.
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.
18
IntroductionQuiz3
3. Which of the following is most true about a non-functional
requirement?
A.
B.
C.
D.
19
IntroductionReferences
20
A.RequirementsEngineering
Process
A Process Defined
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
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]
23
A.RequirementsEngineering
Process4
SRE Process Activities - I
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]
25
A.RequirementsEngineering
Process6
Process Models
26
A.RequirementsEngineering
Process7
Process Actors - I
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]
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]
29
A.RequirementsEngineering
Process10
Process Support and Management
30
A.RequirementsEngineering
Process11
Process Quality and Improvement
Uses:
Process improvement standards and models
Requirements process measures and benchmarking
Improvement planning and implementation
31
A.RequirementsEngineering
Process12
Other Issues in Software Requirements Engineering I
32
A. RequirementsEngineering
Process13
Other Issues in Software Requirements Engineering II
33
A.References
34
A.Quiz
1. According to the SWEBOK Guide, what are the four major
activities of the requirements engineering process?
A.
B.
C.
D.
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.
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.
37
A.Quiz4
4. Process quality and improvement relies most on which of the
following?
A.
B.
C.
D.
38
A.Quiz5
5. Product requirement validation occurs primarily after:
A.
B.
C.
D.
Elicitation
Analysis
Specification
Testing
39
B.RequirementsElicitation
What is Requirements Elicitation?
40
B.RequirementsElicitation2
Major Issues Involving Requirements Elicitation - I
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.
41
B.RequirementsElicitation3
Major Issues Involving Requirements Elicitation - II
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
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
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.
Interviews
A traditional means of eliciting requirements
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
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
47
B.RequirementsElicitation9
ConOps - An Elicitation Tool - I
48
B.RequirementsElicitation10
ConOps - An Elicitation Tool - II
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
50
B.RequirementsElicitation12
Elements of IEEE 1362 (ConOps) - I
51
B.RequirementsElicitation13
Elements of IEEE 1362 (ConOps) - II
Scope (Clause 1)
Identification
Document overview
System overview
52
B.RequirementsElicitation14
Elements of IEEE 1362 (ConOps) - III
53
B.RequirementsElicitation15
Elements of IEEE 1362 (ConOps) - IV
Notes (Clause 9)
Appendices of the ConOps
Glossary of the ConOps
54
B.References
55
B.Quiz
1. As requirements are elicited, what source is most likely to
impose previously unidentified user processes?
A.
B.
C.
D.
56
B.Quiz2
2. What is considered the traditional means or requirements
elicitation?
A.
B.
C.
D.
Observations
Scenarios
Interviews
Prototypes
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
58
B.Quiz4
4. Which technique overlaps for use in requirements elicitation
and requirements validation?
A.
B.
C.
D.
Prototypes
Facilitator meetings
Interviews
Observations
59
B.Quiz5
5. A concept of operations document (ConOps) should not be
written
A.
B.
C.
D.
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.
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.
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]
63
C.RequirementsAnalysis2
First, Find Requirements Sources
64
C.RequirementsAnalysis3
Software Requirements Analysis - I
65
C.RequirementsAnalysis4
Software Requirements Analysis - II
66
C.RequirementsAnalysis5
67
C.RequirementsAnalysis6
Requirements Classification - I
Several dimensions:
68
C.RequirementsAnalysis7
Requirements Classification - II
69
C.RequirementsAnalysis8
RC / Attributes - I
Each Software Requirement Shall Have:
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)
71
C.RequirementsAnalysis10
RC / Attributes - III
Each Software Requirement Shall Have:
72
C.RequirementsAnalysis11
73
C.RequirementsAnalysis12
74
C.RequirementsAnalysis13
75
C.RequirementsAnalysis14
76
C.RequirementsAnalysis15
Conceptual Modeling I
Their purpose is to aid in understanding the problem, not
begin a design solution
77
C.RequirementsAnalysis16
Conceptual Modeling II
78
C.RequirementsAnalysis17
CM / Structured Analysis
(Yourdon)
[RT04, p. 4-38]
79
C.RequirementsAnalysis18
CM / Real Time Structured
Analysis (Ward & Miller)
[RT04, p. 4-39]
80
C.RequirementsAnalysis19
CM / Object-Oriented Analysis
(Object Diagram)
[RT04, p. 4-40]
81
C.RequirementsAnalysis20
CM / Use Cases
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
83
C.RequirementsAnalysis22
Requirements Negotiation
Also known as conflict resolution
84
C.References
85
C.Quiz
1. Which dimension of requirement classification is critical for
consideration of tolerant design?
A.
B.
C.
D.
86
C.Quiz2
2. What is the most important attribute of a requirement?
A.
B.
C.
D.
Identifier
Source
Verification procedure
Priority
87
C.Quiz3
3. Which of the following is not a type of software requirement?
A.
B.
C.
D.
Functionality
Performance
External Interface
Complexity
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
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
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]
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]
92
D.SoftwareRequirements
Specification3
In Context with Other Requirement Documents
93
D.SoftwareRequirements
Specification4
94
D.SoftwareRequirements
Specification5
IEEE 1362 - The ConOps Document
95
D.SoftwareRequirements
Specification6
96
D.SoftwareRequirements
Specification7
IEEE Std 1233 (SyRS)
97
D.SoftwareRequirements
Specification8
98
D.SoftwareRequirements
Specification9
99
D.SoftwareRequirements
Specification10
100
D.SoftwareRequirements
Specification11
Considerations for Producing a Good SRS - I
101
D.SoftwareRequirements
Specification12
Considerations for Producing a Good SRS - II
102
D.SoftwareRequirements
Specification13
Considerations for Producing a Good SRS - III
103
D.SoftwareRequirements
Specification14
Considerations for Producing a Good SRS - IV
104
D.SoftwareRequirements
Specification15
Considerations for Producing a Good SRS - V
105
D.SoftwareRequirements
Specification16
Considerations for Producing a Good SRS - VI
106
D.SoftwareRequirements
Specification17
Considerations for Producing a Good SRS - VII
107
D.SoftwareRequirements
Specification18
Considerations for Producing a Good SRS - VIII
108
D.SoftwareRequirements
Specification19
Considerations for Producing a Good SRS - IX
109
D.SoftwareRequirements
Specification20
Considerations for Producing a Good SRS - X
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
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
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
113
D.References
114
D.References2
115
D.Quiz
1. Which document is used to derive the software requirements
specification?
A.
B.
C.
D.
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
117
D.Quiz3
3. Which of the following is not embedded design that would be
written in the SRS?
A.
B.
C.
D.
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
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
120
E.RequirementsValidation
Defined
121
E.RequirementsValidation2
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
123
E.RequirementsValidation4
Requirements Validation - II
Different stakeholders should be able to review requirements
documents
124
E.RequirementsValidation5
Subjects of Requirements Validation
125
E.RequirementsValidation6
RV / Requirements Reviews I
126
E.RequirementsValidation7
RV / Requirements Reviews II
127
E.RequirementsValidation8
RV / Requirements Reviews III
128
E.RequirementsValidation9
RV / Prototyping I
A means of validating the software engineers interpretation
of the software requirements
129
E.RequirementsValidation
10
RV / Prototyping II
130
E.RequirementsValidation
11
RV / Model Validation
131
E.RequirementsValidation
12
RV / Acceptance Tests
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)
133
E.References
134
E.Quiz
1. Software requirements validation should be viewed by whom
and how often?
A.
B.
C.
D.
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
136
F.RequirementsManagement
Defined
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]
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]
139
F.RequirementsManagement
4
Duties of the Software Project Manager - I
140
F.RequirementsManagement
5
Duties of the Software Project Manager II
141
F.RequirementsManagement
6
Key Requirements Tasks of the Project Manager
142
F.RequirementsManagement
7
Subjects of Requirements Management
143
F.RequirementsManagement
8
RM / Iterative Nature of Requirements Process - I
144
F.RequirementsMa1nagement
9
145
F.RequirementsManagement
10
RM / Change Management
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
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
148
F.RequirementsManagement
13
RM / Measuring Requirements
149
F.RequirementsManagement
14
Graphic, next slide: The Relative Cost to Correct A Software
Requirements Error [RT02, p. 155]
150
F.RequirementsManagement
15
151
F.References
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.
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
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
155